Month: October 2005

The chinese artists work hard but I can see the communication barrier is too great. After a month they still don’t understand normal mapping and after many times trying to explain it they still just don’t get it. All I get are emails “We worked so hard for 2 days on this technique” which winds up totally missing the point and all it accomplished was for me to once again repeat what I already explained.

I have to admit I’m getting annoyed because they have the editor there already. If they simply spent a day experimenting they could have figured it out. Instead they rush forward like bulls with blinders focused on the wrong target rather than spending a minute looking around first. But I understand this is why artists are artists rather than technical people. If I had someone there who was fluent in both chinese and english and could manage them it would have worked out.

If I can I’ll have them properly finish what they can in the time available but it’s a risk to the project to rely on them. So I’m going to go with a professional to do this.

Once they get the normal mapping correct this should be acceptable.

One of the things I like about being the lead programmer on a game is my exposure to architecture. This is something most programmers don’t get to experience very often and I enjoy it.

Architecture is difficult because it’s high level planning. Like all high level planning you deal with unknowns or partially knowns. The human brain is designed to skip over the flood of small details we encounter constantly through our senses so it’s definitely a learned skill.

Some people propose doing very detailed architecture. I disagree with this because, at least for me, it’s impossible to come up with detail that solves all useful cases. While a high level architecture is beneficial, once you start thinking at a function level there’s just too many mistakes, wrong assumptions, and forgotten cases to be usable as a spec. We’ve all seen cases of architecture that causes bloat but doesn’t solve any real problems. This is a fundamental problem caused by a detailed architecture with wrong information.

The approach I try to use is to first think of any obvious cases where architecture is necessary or beneficial. For example, I know that the client and server will both need shared code. So I split the project up into client only, server only, and shared. However, in other cases it’s harder to tell. When I pass a data stack between states how much architecture should I put into it? Is it worthwhile to put the stack structure in the state itself to avoid copying the data on state start? Should I handle memory allocations automatically or should I handle it per-instance?

I don’t know. So once I solve the high level problems I can accurately think about, I just write the code using the simplest case possible. Every so often I try to take a break and think back about what I did. If, armed with new knowledge, I think of a better way to approach the problem I refactor. This is also what extreme programming proponents advocate.

Refactoring throughout the day takes discipline and can be annoying because it involves rewriting a lot of already working code. However, if I don’t do it the program will quickly become unmaintainable.

As I gain more experience I think I get better about seeing the cases where I should think about planning ahead, rather than at the planning itself.

My outsourcing experiment isn’t working out as well as I hoped. I anticipated communication problems but hoped they would be speed bumps on the road of progress as opposed to the 10 foot deep potholes they are turning out to be.

The causes are fourfold:
1. English is not their native language.
2. Most artists aren’t good at writing or logical thinking, which is necessary for email exchanges.
3. They work when I’m asleep AND
4. They don’t have reliable always-on internet access.

These map to the following problems:
1. I can’t make complex ideas understood and even simple ideas don’t get across very well.
2. They have a hard time meeting technical requirements even when they do know them.
3&4. Every email exchange takes 1 day. This means that your normal office-type 5 email exchanges now take 5 days instead of 30 minutes.

This is why, now like a month later, I still don’t have a single correct model and I’m still repeating the same requirements that I told them at the start of the project.

On top of that they are slow. I understand they are students but it shouldn’t take three people three days to remove some polygons from a model and add a few texture details. This is a constant problem I’m facing.

I think outsourcing could work with the proper setup. For example, if I had a technical person there who was fluent in Chinese that would overcome the communication problems. My wife calling them in Chinese helps immensely and is the only reason I’ve gotten anything at all. But she is not technical and I can’t rely on her to call them that often.

Their work is pretty good. It’s just not good enough for what I’m doing. I sincerely hope I can make this work but given the choice between releasing the best possible game and spending more money I’ll spend the money.

I’ve been more motivated this weekend due in large part to taking a break over last week. So on Saturday I got the ability to show multiple materials on a single mesh. You simply apply more materials and 3DS and the game will automatically detect this and assign names to each group of polygons. It will even load the specular, diffuse, and ambient colors that you set in 3DS max.

Since I store the name of the material with the polygon group I can use this to flag polygons. So I can name a polygon group “SpawnPoint” for example and now in the game I know where to spawn.

With this, I’m pretty sure I can skip the whole phase of writing a ship and a level editor.

That took most of my energy. But today I got the basics of the client / server framework up. With my very first game I had two different applications – a client and a server. The problem with that is that it was almost literally double the code,, with a lot of cutting and pasting. Maintenance was pretty hard and it was hard to test. With my second game I had the server and client on the same computer but they shared memory space. This means for every situation I had to think of what to do for client only, server only, and client and server. A lot of my network code went through the system, so was good for testing, but a lot didn’t get tested this way. With this game the client and server are independent, each with their own launchers. However, they are both in the same solution and code is split between client only, server only, and both. For testing, I use the client and have the server class inside the client framework using a #ifdef. This is nice because it’s a complete test yet is still easy to manage, with no duplicated code. I don’t have to think of local or remote clients. Lastly, I can do everything on one computer, in one instance of the program.

I’m exhausted again. I ordered Black and White 2 and X3. I will probably just play those for a while to recover. In the meantime I’m waiting for my wife to start working to relieve the burden of this.