Jump to content
  • Advertisement
Sign in to follow this  
  • entries
  • comments
  • views


Sign in to follow this  


The primary problems I face on a daily basis with game development are often down to the amount of trouble you have to go through in order to get certain things done. Some tasks seem to be far more resistant to implementation than they ever should be, and this tends to lead to those tasks either being done poorly, or not as often as they should be, or both. This should be pretty self-evident, of course, but it's interesting to see where the bottlenecks show up.

One example in the current project is adding a new file. Refactoring old code and writing new code often involves adding new files. But when that involves doing a full update from the version control software, checking out the project, adding the files, checking that it all builds, checking in the new files, checking in the project, and re-applying any local amendments to the global project, you tend to be wary of doing it too often.

Similarly, localisation can be an issue. You have to think twice about adding more text to the game when that means you have to think up a unique identifier, check out the localised strings data, add in your new identifier with the associated text, run the exporter tool to update the data files, test that it builds, test that it shows the correct text, and check the lot back in.

(It's worth noting here that these methods are imposed upon us in order to interoperate with another company.)

It's these problems that Big Upfront Design models like the waterfall method were designed to fix. After all, if you can plan all your classes before you start coding, you won't ever need to add files to the project later. And obviously your string database can be done first too, making localisation later easier. These are examples where software development is like traditional engineering - making changes is slow and costly, and therefore should be planned for meticulously.

Unfortunately the vast majority of software development is not engineering, and never will be. If you could rebuild a car or a bridge to make a minor change in 2 minutes, you can bet that traditional engineering would be done vastly differently. We also have to react to market and design forces more rapidly than most engineers do - some of this is a problem with management, but much of it is inherent to the industry. You have to be able to adapt to shifting requirements. Computing power can double in the time it takes to complete a project and expectations can rise with it. Software development, and especially game development, needs to be agile.

But how do you mix developmental agility with lumbering systems that require so much effort that they actively discourage their own use? Things like source control and localisation are necessary evils of course, and there are probably better ways to do them, but there are many smaller scale issues of a similar nature, such as generation of graphical assets, getting sounds into a game (anybody used the Sony tools? ouch.), etc. I'm sure many of our problems come from the tasks that turn out to be far more resistant than they should be.
Sign in to follow this  


Recommended Comments

There are no comments to display.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!