Month: October 2005

So here I am for the third game needing a text manager class. Something to hold text strings for periods of time, display them in an ordered list, and handle text wrapping.

The first game that needed this used DirectX so I had lots of DirectX code in the text manager. It would compute the length of strings, edit the list of strings to split them up, etc.

This was useless for my second game because it used a different graphics engine. I copied some parts over, but a lot was changed. One of the biggest changes was that fonts were now in a separate class, where DirectX handled them as part of the graphics engine. Also DirectX took the strings to render directly where this new engine had a manager. So a lot of code was changed.

Now for my third game I look at what I did for the second game and again see that it is useless. Faced with the prospect of rewriting something that has the same functionality for the third time I decided enough was enough. Time to actually apply some engineering principles. Browing the web and remembering what I learned in college I decided to try out a factory class with a model / viewer pattern.

At first I was hesitant to do this because it didn’t seem to solve any problems. At best, I would split up the viewer into two classes that I could have done with a simple if statement. However, as I wrote more I began to see the wisdom behind the architecture.

First, I wrote the factory. This forced me to think about what parameters I would use in advance and whether they belonged in the model or the viewer.

Second, I wrote the model – which is just a list of text strings. This was completed much faster and easier than I had done in my prior implementations because I didn’t have to think at all about how the strings would be displayed. The model is totally independent of the graphics engine.

Third, I wrote the viewer. Some parts of the viewer, such as accessors for data, have nothing to do with the graphics engine. Some parts do. So in a flash of inspiration I had the viewer Irrlicht implementation derive from the viewer base class. I then modified the factory to return an instance of the Irrlicht implementation.

Presto! Now I can use this in future games. All I have to do to switch graphics engines is to derive a new viewer. I don’t even have to change the game code because it got an instance of the base class rather than the Irrlicht Implementation. I can just change the factory for the graphics engine I want. I could even support multiple graphics engines by passing different parameters to the factory.

I just finished adding the ability to read double clicks. There’s a lot of little things you have to consider:

1. You have to click the same button twice, not two different buttons rapidly in a row
2. You have to account for mouse drift of a few pixels from the last click location
3. Triple clicks should not count as two double clicks

The reason this is noteworthy is that it’s a good example of how trying to write TDDs that handle every detail of the code is impossible because normal people don’t think at that level of detail. I was watching this show about autistic people and how some of them remember all the small details they see if you let them glance at a room. A normal person doesn’t because they are bombarded with information and the brain filters out most of it.

This is why I take the approach “Write what you know, refactor what you don’t.” This is totally opposite the concept of high level design.

It’s also why, when you ask for a spec from a customer, the spec invariably misses out on details. Programmers are trained to do this sort of work and forget things. What can you expect from a customer who probably barely knows how to open Word? Extreme programming accounts for this by involving the customer in the design and implementation process which sounds like a good approach.

I wrote a table GUI widget today. It supports highlighting and selecting elements. It populates the fields through derived classes that calls the owner state.

Doesn’t sound like much but it’s a lot of work. I can reuse it later on for lots of things such as player lists.

Tommorow I will handle chatting and connecting to unset servers to setup the game state. If I have the energy I will also implement part of the game state.

I was looking at Manifesto Games yesterday. It’s a publisher for independent developers. That sounded pretty odd to me. The point of starting an independent developer, in fact its very definition, is that you are independent of publishers.

A publisher brings three things to the table: up-front funding, distribution, and advertising. For a large game this makes sense. Very few people can afford millions of dollars to fund their own game. Very few people have the connections or money to distribute and advertise their games. You might be looking at an upfront cost of $20M to develop and $10M to publish and advertise an AAA game. If the game sells a million copies you make a nice profit. Otherwise you take a loss. The publisher model is based on gambling. Take this risk many times. Most risks will fail while a minority of blockbusters will pay for the failures. It’s actually a tax-advantage for them because the losses are written off against the profit from the successes.

With independent games, you fund yourself. Distribution is easy – let people download the game. It’s not that hard to rent a server and put up a hyperlink. So the only thing left that a third party can offer is marketing. I wrote to the CEO of Manifesto, Greg Costikyan, asking about this.

Kevin:

We’re very early stage, but hopefully, we (eventually) bring a number of things to the table:

1. Exposure to a community of indie game enthusiasts to whom you might not otherwise be exposed.

2. Yes, you can do your own promotion and marketing, but this isn’t something that most independent developers are good at, because it’s not a core competence; we think we can do that more effectively than (most) indie developers by themselves.

3. We don’t ask for exclusivity–if you want to sell it yourself off your own site as well, feel free. The question then becomes: Does selling through Manifesto cannibalize my sales, or does it provide incremental sales I wouldn’t achieve otherwise?

That’s a judgment you’d have to make, but I think we will be able to demonstrate that we can help partners achieve larger sales than they would otherwise.

Like he said, the question is will the marketing they provide offset the unspecified portion of your sales they take? It’s hard to say.

According to “Marketing without Advertising” (and I agree or I wouldn’t cite it) word of mouth is the cheapest and most effective form of advertising. Sending out ads to disinterested parties is the most expensive and least effective form of advertising. Large companies do this because they already have covered the other forms of marketing have the excess cash to do it. Because large companies are so large, the cost per unit to advertise is relatively small.

As a simplistic example, lets say McDonalds runs a 5 million dollar ad in the US and they have 500,000 stores. Then each store only pays $10 for ad. Even if 99% of the people who saw the ad didn’t care about it, it will still be financially viable to run the ad. 1% of all the TV watchers in the US is a lot of people and will make more than $10 in profit for each store.

For an independent game developer your sales will probably range from a few hundred copies to 10,000 copies if you are a huge success. It costs from $2000 to $10,000 to run a banner ad on a site for a month. I’ll let you do the math, but consider that banner clickthrough rates are generally less than 1/10th of 1%. Of people who click on your banner, most will not buy the game. I won’t bother making up numbers but I will say that at small levels there are much better ways to get returns on your investement. For example, spending that $4000 on some nice new music or ship models will more likely generate better retention and sell-through rates and greater total sales.

The other thing to be aware of is that getting more eyes to see your game early on is NOT necessarily a good thing. When I released RakNet I had more unique visitors in the first month than I ever had since then. All those people that looked at the initial release of RakNet now have an opinion formed about the library and it’s unlikely they will revisit the library just because it’s now at version 2.4. Yet version 2.4 probably does not have a single line of code the same as in version 1.0 and has many times more features. It’s more stable, literally thousands of times faster, and takes something on the order of 25X less memory. So again, when we are talking about low budgets it is much more sensible to spend all your money improving your product than it is getting more people to see your initial release.

That is not to say that marketing is not important. It is, and there are ways to do it that make sense. One is building up your business. Find what the customers of your first game like and try to sell them your second game. Another is a newsletter. People who like the kind of games that your company make can get periodic updates of news games that you release. Another is in-game references to other games, such as showing a list of games in your exit screen or putting links to your other games in the startup menu.

A lot of this information comes from my favorite pair of websites:
A pyrogon Postmortum

which is commented on by
A shareware Life

This kind of marketing is effective, but is not something a third party would be able to do.

What can a third party do?

One option is nearly free advertising (such as hitting up review and news sites). I used to run a gaming website and know that connections do matter. It makes the difference between your game release posted on the front page of Blues News to being some unknown entry on Game Hippo.

The other option is the portal model. Suppose that Manifesto advertises 100 different games, and that they have some standards for what they will advertise. A site with 100 different good games is a pretty good draw to people, especially if that site advertises itself and puts its own promotions before that of the developers, such as Real Arcade. The problem with this is that your game only succeeds if the portal markets it. And according to the Shareware Life:

By putting their entire destiny in the hands of the portals, Pyrogon put the success or failure of their business into the hands of people who simply did not care whether their business succeeded or not. The entire burden of selling their product was put into other people’s hands

In summary, if you want EXTRA sales from using Manifesto as an advertising source, for a game that has already been released, AND they give you all the customer information it may be worth doing.

I never told the chinese artists that I wouldn’t use them, maintaining hope that I could at least use some of their art in the game. It looks like the problem resolved itself. I haven’t gotten a daily report in 4 days and the last one was short and had an impatient if not hostile tone. I assume this is discouragement over consistently having their submissions rejected.

Legally, if such a thing applies here, all their work was for-hire and I didn’t accept any work so I’m not obligated to pay. Professionally, I was going to give them a pay-off anyway since they did put genuine effort into things. If they are just going to disappear though I won’t.

I’ll see over the coming days if I ever hear anything from them again.

It’s not much to look at but there’s a lot going on under the hood to get to this point.

I can now start a local server and connect to it up to the point where I download the zone and player data. I’ll do a bit more work on this and next work on adding the chat capability to the bottom of the screen.

I spent most of the morning getting the stupid “Remember Password” button working on the main menu screen. Irrlicht uses wchar_t instead of char*. Eventually I got fed up doing conversions so I added the ability to use setText with char* directly to their engine.

My design has every game state totally independent of every other state. When a state enters it is allocated and when it exits it is actually deleted. From a modularity perspective this is awesome because I don’t have to worry much about states not working if I run them more than once. I also don’t have to worry about new states breaking existing states.

This created a problem with “Remember Password” because the GDD specifies that if the checkbox is checked it still won’t remember the password unless you have a successful login. Since the connection state knows about login-success I have to transfer data between states.

My solution was to include a “StateStack” class which is just a structure that indicates the caller and state-specific derived data. It is passed from the old state to the new state and managed by the state manager. This has worked out very nicely and is equivalent to passing parameters to a function. It is independent of the states themselves, lets me easily pass all the data I want, and I can store all the data in the new state with a memcpy. Since the connection state is used by multiple states (both connecting to the server chain and to a particular server) I also store the followup state in the state stack. This fixes a big problem I had working on SOG. In SOG, the state manager would remember the current and last state. It was only through hacks that we could get shared states to progress to the next state that we wanted. This solution lets me specify all the data I need in the StateStack class so there is no ambiguity.

Some data set by states needs to be known to the entire game, such as the password to save on shutdown or the current resolution. Those are stored in the game class I derive from the application interface. So far there isn’t much data of that sort and it’s worked fine.

In somewhat related news, I designed the network packet handling architecture to pass particular packet types to the states themselves. If a state does not choose to handle a packet, it goes to a default handler, which either handles it or does an assert. This is nice because the state itself handles packets particular to that state, minimizing information exposure, grouping related data, and eliminating the need for an external controller.

In all my prior games there was a network class of some sort that was responsible for all packets and would control the game. In theory this sounds like a good modular approach. In practice it was pointless because there is no functional relation between any of the operations handled in that module. This design created a lot of work because I had to put in custom accessors for every possible multiplayer operation. Changing states was especially a pain in the ass and usually involved polling for a variable changed by multiplayer code. I had cases where I had a while loop inside of a function that did nothing but call NetworkUpdate (to read packets) and wait for a variable to be set. Inside the loop it would check a variable to see if the escape key was pressed to cancel. With my current approach I could do the same thing with a state enum inside the state class and update the enum when the packet arrived in the OnNetworkPacket function. I could exit the state in the OnKeyPress function. This is much easier and cleaner.

As I work on the game I am reminded again why I always multiply my original time estimates by four. When I got home today I thought it would be a simple issue to fill out all the packet types and negotiation for basic connectivity. In fact, I spent the entire morning just setting up parts of the framework I previously forgot. Then the entire night doing a single packet and setting up remembering the last password and username used. About half the time goes into refactoring existing systems to reflect updated design decisions.

A lot of the time I write some straightfoward code and use it for a while. Then later I need similar code for a similar but different circumstance. I’m very consistent when it comes to never duplicating code or data so everytime this happens I have to spend time refactoring, then debugging everything I just changed.

I’m not sure if I can get a vertical cross-section done in one month because even at full time work my estimate is 2 weeks. Multiply that by 4 and you get 2 months full-time. I’m only doing this part-time though so the time doubles yet again. I’m going to try to speed things up by leaving TODOs all over the place on anything that isn’t a gameplay feature (such as the DB or the server mesh).

My biggest current hinderance is my day-job. It takes time for me to get into the flow of things and working mornings and nights forces me to stop working just as I really get going. Then with GU I want to do a good job so I put my energy into that rather than my own game. That drains my enthusiasm and energy for programming my own game so by the time I get home I don’t feel like programming anymore. Even on the weekends lately all I want to do is play games because I’m getting burnt out from what is now going on a three month two-job crunch.

It’s very likely that a professional company is going to do all the art for my game starting the middle of next month. It’s going to cost me a lot of money although it’s cheap from a business perspective.

As a result, I really need to crack down and get a gameplay vertical cross section done by then in order to minimize the number of changes I need to ask for.

This includes:
All menus
Ships flying around
Ships shooting
Ships launching from carriers
Spawning carriers
Space stations
Radar system
HUD
Ship interaction (destroying each other)
Ship customization
Chat

And a lot of other things. This is going to be a lot of work and even if I had a month full time I’m not sure I could do it. So I need to spend every available moment from now on accomplishing as much as possible.

I might use my vacation days from work to try to get more done in time.

I’ve been dealing with a lot of code lately at work where I have to look again at stuff I last changed for some particular context 3-6 months ago. Either that change had a side effect or it broke some other edge condition. This is especially true with magic numbers, where I tweak the numbers until they work in one particular case in one particular level.

In general, for both myself and others, I see that the most effective comments are those that explain the why, rather than the how or what. Yet the most common type of comments explain the how or what, rather than the why.

For example
// Move foward on the balance beam
if (InDistance(10)) then PressStick(foward);

This is much better than nothing but I can usually figure it by in the context. Here’s another way to comment it

// This will ensure that we reach the threshhold range of grabbing the edge
if (InDistance(10)) then PressStick(foward);

With the first comment, I had no way to know if changing the 10 would have broke the code or if pressing forward had other effects. With the second comment, I could delete the code entirely and implement something else without breaking the dependency.

The golden rule of commenting IMO is to reveal intention. Code Complete says to comment variables over code but this is just an effect of commenting intention. Variables tend to reveal intention better than code does. I’m going to add this to my coding rules on the front page.