Essentially, I'm curious what methods people use (whether they be tools, processes, etc.) for speeding up development when working on a game.
I am currently working on a game, which I have been working on in my spare time for the past 2 years. Granted, I have learned a lot in those 2 years, but I don't feel that the game "looks" 2 years old, if that makes sense. It still has very much of a "tech demo" feel to it, with large portions of both the gameplay and underlying framework unfinished.
But beyond that, I feel like I am just really slow at making progress. As an example (and not the target of this post), I recently got a portion of the game working, allowing the player to instruct units to construct particular types of buildings (this is sort of an RTS game). I had been working on implementing this portion of the game for the better part of a month (in my spare time), working out the interactions between the UI and the game state.
Now that it was playable, we were able to see some of the issues with the way it was designed, and made changes to the design, requiring me to go back and make some significant changes to the code I had already written. I've been at it for a week now, and feel that I am little more than half done with the changes. And this is just for this one piece of the game.
By comparison, I see people on these forums throwing together prototypes on a matter of days (I don't even understand how you can prototype a game, with all of the underlying framework that is required). People participate in the Ludum Dare competition, creating full games in under 48 hours. And full released games on Steam, like Terraria, which were developed in only 6 months.
So what are they doing that I'm not? How do other game developers throw together a functioning game in hours or days, and I struggle for weeks trying to implement a tiny portion of my own game?
Only thing I've though of is maybe changing the way I write game code so that it is a bit more modular, rather than writing out all of the client and server bits by hand wherever they are needed. But I'm not even very clear on how I would do that, and at this point it would be (again) rewriting existing code rather than finishing the game.
How do you develop features for your game at a decent pace? I would appreciate any opinions and ideas at this point. Thanks.
I must be doing something wrong (slow development)
I'm very curious about this too. My guess (and this is only a guess) is:
1. Keep your goals modest.
2. Use tools that you know well and/or are good for rapid prototyping.
3. Don't fall in love with a coding problem. Usually if something seems hard you can work around it in a fast unsexy way.
4. Don't be a perfectionist.
5. Get help with the stuff you're bad at. If you're no artist, either "borrow" assets or get an artist to make them.
1. Keep your goals modest.
2. Use tools that you know well and/or are good for rapid prototyping.
3. Don't fall in love with a coding problem. Usually if something seems hard you can work around it in a fast unsexy way.
4. Don't be a perfectionist.
5. Get help with the stuff you're bad at. If you're no artist, either "borrow" assets or get an artist to make them.
1. Existing codebase
2. Scripting languages
3. Experience
4. Experience
5. Experience
It really comes down to this. The year is 2012 and there are a lot of options to get a prototype up and running quickly.
Take Unity3D for example. A complete engine with an integrated editor and 3 different scripting languages to choose from, support for many different file formats and a great library of example scripts. If you want progress fast there is really no excuse to roll your own engine anymore.
On a more general note, try not to get distracted by perfecting every little piece immediately. Aim for the larger picture first and then polish.
Make a todo list and sort the items by impact on the final game. Do the most important first, the "guts" of the game if you will and you can play the game - even though a bit rough - faster and spot things that need changing.
2. Scripting languages
3. Experience
4. Experience
5. Experience
It really comes down to this. The year is 2012 and there are a lot of options to get a prototype up and running quickly.
Take Unity3D for example. A complete engine with an integrated editor and 3 different scripting languages to choose from, support for many different file formats and a great library of example scripts. If you want progress fast there is really no excuse to roll your own engine anymore.
On a more general note, try not to get distracted by perfecting every little piece immediately. Aim for the larger picture first and then polish.
Make a todo list and sort the items by impact on the final game. Do the most important first, the "guts" of the game if you will and you can play the game - even though a bit rough - faster and spot things that need changing.
Definitely number 1, and probably the same for art assets too (as placeholders for new games). I lack number 1. And 3-5 (game-wise, not development-wise).
There's your mistake. No framework is required. Some developers use existing frameworks (Unity, Allegro, whatever) and some just plain freeform it. The key to coding fast is to throw architecture to the winds. This is a healthy skill to have, though whether you should make a habit of of it is another matter entirely.
By comparison, I see people on these forums throwing together prototypes on a matter of days (I don't even understand how you can prototype a game, with all of the underlying framework that is required). People participate in the Ludum Dare competition, creating full games in under 48 hours. And full released games on Steam, like Terraria, which were developed in only 6 months.
Rapid prototyping is a valuable way to build out the basics of a game, make sure it's worth building at all, and catch early design mistakes. I would suggest that it's vastly more useful than the idiotic design documents everyone thinks they need. Sit down and write a full, playable game in a week. It will force you to think very hard about what is actually machinery for the game, and what is your own toying around with code. Eventually you'll learn to do this in a way that doesn't defy expansion into well engineered code later.
I have the exact same problem. I'm a very slow coder. I take days to think about problems in my head first and I also suffer from acute tutorialitis lol. (the need to browse for nice tutorials for each and every detail)
The most important skill to have as a programmer in my opinion is to be able to conceptualize a project's parts and their relationships and then put them down into code. I think that the better you are at identifying the most important bits and seeing how these things can work together, the faster you'll be at implementation time.
As far as tutorialitis goes, I can totally identify with you there because I have been in your shoes lol. My suggestion is that you try to focus on the algorithms and not the implementation as much (i am assuming you are looking at things like how to do shadows etc). The more you can remove yourself from thinking in implementations the better you'll be at conceptualizing the algorithms and then implementing them. After you make that step you'll start looking at articles, papers, and the occasional thesis on all the cool stuff instead of waiting for someone to make a tutorial on it in your language of choice.
As far as tutorialitis goes, I can totally identify with you there because I have been in your shoes lol. My suggestion is that you try to focus on the algorithms and not the implementation as much (i am assuming you are looking at things like how to do shadows etc). The more you can remove yourself from thinking in implementations the better you'll be at conceptualizing the algorithms and then implementing them. After you make that step you'll start looking at articles, papers, and the occasional thesis on all the cool stuff instead of waiting for someone to make a tutorial on it in your language of choice.
1. Making a prototype is very different from making a shipped game.
A prototype's """framework""" (I cannot put enough quotation marks around the word) is nothing but a big bulk of duct-tape. Almost all of its functions can come from older projects, but these functions are just thrown together.
2. For the actual game, the neatness and blahblah of the framework is very important, but don't get too hung up with it, especially if you are a beginner. I guess you are always going back to refine code, don't overdo it. Just get it done, especially if you are a lone coder. Your next game will be better.
3. Same goes for "optimisation". Don't do it, (in my opinion) until you have a playable game (unless optimisation is needed in a gameplay-wise crucial feature). Functions should be black box functions if possible, so you can go back to optimize any time (and with proper profiling).
4. Yup, aim lower. Don't compare an RTS to some puzzle/shooter game prototype. An RTS is complex, a few weeks won't be enough to prototype it. Since, in contrary with my 1st statement, an RTS can be so complex that it required a more designed framework.
These are just opinions of a hobby programmer (more precisely tinkerer) about newbie development. With experience, opinion 1. becomes irrelevant, because you will produce solid frameworks anyway, that you can expand. Some duct-taping applies anyway.
A prototype's """framework""" (I cannot put enough quotation marks around the word) is nothing but a big bulk of duct-tape. Almost all of its functions can come from older projects, but these functions are just thrown together.
2. For the actual game, the neatness and blahblah of the framework is very important, but don't get too hung up with it, especially if you are a beginner. I guess you are always going back to refine code, don't overdo it. Just get it done, especially if you are a lone coder. Your next game will be better.
3. Same goes for "optimisation". Don't do it, (in my opinion) until you have a playable game (unless optimisation is needed in a gameplay-wise crucial feature). Functions should be black box functions if possible, so you can go back to optimize any time (and with proper profiling).
4. Yup, aim lower. Don't compare an RTS to some puzzle/shooter game prototype. An RTS is complex, a few weeks won't be enough to prototype it. Since, in contrary with my 1st statement, an RTS can be so complex that it required a more designed framework.
These are just opinions of a hobby programmer (more precisely tinkerer) about newbie development. With experience, opinion 1. becomes irrelevant, because you will produce solid frameworks anyway, that you can expand. Some duct-taping applies anyway.
I have the same problem, but maybe it isnt a problem?
Sounds like your game is a complex one - at least RTSes are not simple. You have AI, pathfinding, tech trees, command structure to code, lots of different units to create graphics for, etc. I think you'll find the ludum dare games are much more simple in design, and therefore much faster to code. Sounds like you are making a much more heavyweight game.
Also, a lot of the games you'll see on Steam are written by teams, and often it is their day-job. I dont know if you are a single dev guy, or working in a team yourself, but this will make a massive difference. I *wish* I could develop my game as a day job! It'd be complete by now, probably up to the third sequel even.
If you are anything like me, a hobby game developer, you'll be spending any spare time you can, outside of normal work hours on your game. But then real life gets in the way (e.g. having a baby, like I did 4 weeks ago), and you cant really spend much time on it. But as long as you have a clear idea of the work left to do, and if you dont continually sneak in new features, you'll get something complete one day.
One thing that might help actually - have a clear design before you start coding. Doesnt have to be a formal document, but something showing a basic layout of the classes / components in your project, and the features, and how they'll work, is a very good idea. Try not to add anything (or as little as possible) to this as you code. This will encourage you to stick to the plan, and not go off implementing cool new feature X or Y that really doesnt impact the game.
Sounds like your game is a complex one - at least RTSes are not simple. You have AI, pathfinding, tech trees, command structure to code, lots of different units to create graphics for, etc. I think you'll find the ludum dare games are much more simple in design, and therefore much faster to code. Sounds like you are making a much more heavyweight game.
Also, a lot of the games you'll see on Steam are written by teams, and often it is their day-job. I dont know if you are a single dev guy, or working in a team yourself, but this will make a massive difference. I *wish* I could develop my game as a day job! It'd be complete by now, probably up to the third sequel even.
If you are anything like me, a hobby game developer, you'll be spending any spare time you can, outside of normal work hours on your game. But then real life gets in the way (e.g. having a baby, like I did 4 weeks ago), and you cant really spend much time on it. But as long as you have a clear idea of the work left to do, and if you dont continually sneak in new features, you'll get something complete one day.
One thing that might help actually - have a clear design before you start coding. Doesnt have to be a formal document, but something showing a basic layout of the classes / components in your project, and the features, and how they'll work, is a very good idea. Try not to add anything (or as little as possible) to this as you code. This will encourage you to stick to the plan, and not go off implementing cool new feature X or Y that really doesnt impact the game.
By comparison, I see people on these forums throwing together prototypes on a matter of days (I don't even understand how you can prototype a game, with all of the underlying framework that is required). People participate in the Ludum Dare competition, creating full games in under 48 hours. And full released games on Steam, like Terraria, which were developed in only 6 months.
I have a feeling that those people have a very, very long history as programmers and/or hobby game developers.
Probably a decade or so, before they had the necessary skills to produce decent games quickly.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
