Jump to content

  • Log In with Google      Sign In   
  • Create Account

Interested in a FREE copy of HTML5 game maker Construct 2?

We'll be giving away three Personal Edition licences in next Tuesday's GDNet Direct email newsletter!

Sign up from the right-hand sidebar on our homepage and read Tuesday's newsletter for details!


I must be doing something wrong (slow development)


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
30 replies to this topic

#1 Nairou   Members   -  Reputation: 428

Like
3Likes
Like

Posted 05 June 2012 - 04:09 PM

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.

Sponsor:

#2 jefferytitan   Crossbones+   -  Reputation: 2218

Like
1Likes
Like

Posted 05 June 2012 - 04:36 PM

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.

#3 Madhed   Crossbones+   -  Reputation: 3063

Like
2Likes
Like

Posted 05 June 2012 - 04:38 PM

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.

#4 jefferytitan   Crossbones+   -  Reputation: 2218

Like
0Likes
Like

Posted 05 June 2012 - 06:19 PM

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).

#5 Promit   Moderators   -  Reputation: 7333

Like
6Likes
Like

Posted 05 June 2012 - 07:04 PM

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.

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.

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.

#6 Fredericvo   Members   -  Reputation: 417

Like
0Likes
Like

Posted 05 June 2012 - 07:11 PM

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)

#7 M6dEEp   Members   -  Reputation: 893

Like
1Likes
Like

Posted 05 June 2012 - 09:19 PM

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.

#8 szecs   Members   -  Reputation: 2169

Like
3Likes
Like

Posted 06 June 2012 - 12:12 AM

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.

Edited by szecs, 06 June 2012 - 12:15 AM.


#9 xbattlestation   Members   -  Reputation: 320

Like
2Likes
Like

Posted 06 June 2012 - 12:38 AM

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.
Storm Clouds over the Western Front - 2D aerial combat WIP | DarklightXNA on Twitter | 2DFlightSim on Youtube

#10 Goran Milovanovic   Members   -  Reputation: 1104

Like
0Likes
Like

Posted 06 June 2012 - 01:27 AM

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.

+---------------------------------------------------------------------+

| Game Dev video tutorials  ->   http://www.youtube.com/goranmilovano |
+---------------------------------------------------------------------+

#11 Tribad   Members   -  Reputation: 872

Like
0Likes
Like

Posted 06 June 2012 - 02:58 AM

I am working as a software engineer and would say my preferred working is in "rapid prototyping" but I am even creating software that goes into products and get sold.
One big difference is that for a product you "must" create lots of papers because all and everything must be checked, tracked, tested again.
Someone working as hobby developer need not all that things. But should create some simple papers that explain the ideas behind. That helps later to identify problems.

For a prototype it is essential that it runs quickly, after a short period of codeing. For a product it is essential that it works at the end.

If you have a running system and get stuck because your code cannot be changed without a big effort its time to "re-design" parts. Identify the problem and create something that will fit better with the new requirements.

For a prototype the programming language is some kind of important. Because you need to make changes easy. Restructuring should not take weeks but a day. So you will find OO languages convenient because you can introduce new abstractions easy without changing tons of code.

A prototype need not catch all faults and is allowed to crash. Its the job of the prototype to show you what can be done and what not. Sometimes you find that extending the code is a problem but something you need for further development. So change it.

In my spare time I wrote a Web-Server that shall work as a front-end for a game. I started in 2007 and now I am in the fifth iteration of this web server and at any iteration I thought it would be the last. The changes made to the code are going less and less. So I my guess is, that this will be the last iteration to the web-server. :rolleyes:

As a matter of interest I use UML tools to structure my work and to let generate the code. This helps on one side because restructureing is only a drag-and-drop action, but it is another thing to learn to work with these tools and so it is not an easy task to create good structure even with UML.

Hope this helps a bit.

#12 DekuTree64   Members   -  Reputation: 986

Like
2Likes
Like

Posted 06 June 2012 - 04:24 AM

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.

I would fall into that group. It took me 5 years to develop a decent amount of skill, at which time I got snapped up by a mid size game studio. It wasn't until after completing a couple of games there that I was capable of competing in 48 hour competition type stuff. As Promit says, a lot of the work setting up a flexible architecture is bypassed, and only the exact parts necessary are written. The trick is, you have to have a pretty clear idea what the full version would look like in order to do that. Also, even when starting from scratch, I've witten and worked in the basic parts of a game enough that I know it by heart, so I'm limited more by my typing speed (which is fast) than my thinking speed for a lot of those 48 hours.

But even when writing at full quality and not on a time limit, it gets faster the more games you make. You'll develop instincts for how to approach new roblems, and a library of knowledge about what worked well and what turned into a mess... and a lot of the time, there is no way to get the game to behave the way you want it to without parts of the code turning into a mess. But you can at least try to minimize it.

In other words, experience is the best, and you're gaining experience right now, so just keep at it :) But doing a short game or two may be a good idea as well... even if you don't need a lot of the architecture of large projects, you'll still get to experience the end stage of tying it all together and fixing bugs. Starting a new project and whipping up the basics goes fast, the mid stage just drags on and on building and building every day, and the end stage is panic and chaos and fixing and finishing everything that was mostly-done and the light at the end of the tunnel just doesn't seem to be getting any closer. But eventually, the bugs run out, and you're just polishing up little things to make the game extra special, and you ship it whenever you decide it's good enough... because it will never be as good as it could be.

#13 Fredericvo   Members   -  Reputation: 417

Like
0Likes
Like

Posted 06 June 2012 - 08:27 AM

I think one of my problems is that I haven't been able to make the paradigm shift towards OOP yet. I know basic C++, what's a class, inheritance etc but still always think procedurally. I believe it's because I'm very much a bottom-up thinker and was exposed to assembler at the age of 11. I learned C much later and initially with great difficulty as I still thought in assembler and had trouble understanding how even a simple while loop tests the condition at the start of a block but the actual compare and branch in assembler happens at the end. After a while I 'got' structured programming by analysing lots of compiler output. I did something similar to understand classes in C++.

#14 Karsten_   Members   -  Reputation: 1632

Like
1Likes
Like

Posted 06 June 2012 - 08:44 AM

I personally feel that it is really important that a developer sticks to one platform and becomes an expert in it. It really does seem like a waste of time to keep jumping between platforms and onto the "latest trendy thing" because you need to learn too many new things and never truly become an expert in one.

It also is very important to stick with a platform which does not change so much that it renders your work wasted. (i.e OpenGL and C/C++ are extremely stable and contrary to what almost anyone pushing their own platform says, also remain the easiest and most documented. They also have the most libraries available for them, are the most portable and have the best tools and compilers behind them)

So I would be very weary about committing to things such as Unity, Flash or XNA because even if their futures were set in stone... They could also change so much and drop a key feature because they no longer think it is "cool".

Unless of course, your project is purely for fun, learning and experimenting.. Then they are all awesome :)

A tad off-topic:

Tribad, What UML tools do you use? Do you know of any that are open-source or don't have online activation? IBM rational used to do some good ones but the later ones no longer quite do it for me ;)

Edited by Karsten_, 06 June 2012 - 08:51 AM.

Mutiny - Open-source C++ Unity re-implementation.
Defile of Eden 2 - FreeBSD and OpenBSD binaries of our latest game.


#15 Nairou   Members   -  Reputation: 428

Like
0Likes
Like

Posted 06 June 2012 - 10:27 AM

Thanks for all of the responses! It sounds like my development speed is due to lack of experience more than anything else, which I suppose is both good news and bad news. :)

In thinking about it, I'm starting to wonder if a small part of my problem is also due to poor code organization. I have my code divided into separate files based on what it affects, but this division is very rough (one file for server code, one file for client code, one file for common game logic, etc.). The files tend to be rather large, and I spend a good deal of time hunting around for a particular function I need to edit or refer to. Organizing them into groups of smaller files might make it easier for me to find what I need without getting overwhelmed. I just need to put some thought into how to split them up so they make sense.

Another thought, is that I spend a lot of time making changes to multiple parts of the code base for each small feature. For example, let's say I add the ability to change a unit's color. Sounds simple enough, but what actually happens is I write the code to change the unit color, then create a network command struct to specify unit color changes, then add code to the server to package up and broadcast the unit color change to the clients, then update the client to receive and unpack this command, and finally re-implement the code (or refer to a shared function) to change the unit color locally. Every little synchronized action takes a good bit of time because of all of these steps. I've considered trying to make shared data more modular, so that it can contain its own code for network packing/unpacking and transmit, so that adding a new feature is more self-contained, but I haven't come up with a good idea for doing this yet that doesn't feel limiting.

I appreciate all of the replies, and any further suggestions or ideas are very welcome.

#16 Tribad   Members   -  Reputation: 872

Like
0Likes
Like

Posted 06 June 2012 - 11:03 AM

@Karsten_:
My absolut favorite is not an opensource one, ArtisanStudio.
But another one where I am afraid the support will die at some time is OpenAmeos. http://www.openameos.org
Even it is not an UML-2.x tool it has the ability to run your own code generators, so you can create whatever text-based output you want. TeX for documentation would be one.
And it is capable of working with a group on the same database. So everyone in the group can see any changes in real-time. It is available for windows and linux but mixing it does not work well.

For my private projects, the web-server and later the game, I use ArtisanStudio which has the same capabilities as OpenAmeos, but is absolutly up-to-date. So you can share the development in a group and can create any text based output you want.

Pardon for advertising the tools. But UML can help to get projects managed and I am curious why no one is using them. But that is another topic.

#17 jwezorek   Crossbones+   -  Reputation: 1897

Like
2Likes
Like

Posted 06 June 2012 - 11:39 AM

Programming fast, in a way, is a skill that can be learned and improved upon like any other software development skill.

I think one thing that hinders writing code fast is stopping, building, and testing every ten lines of code. Beginners get in this habit because, well, they are beginners and can easily write themselves into a corner if they misunderstand the semantics of a language construct or a library they are using. If you don't know what you are doing, it makes sense to run your program to do sanity checks frequently.

However, if you do know what you are doing constantly building and running the application you are working on will slow you down enormously. I'm not arguing against testing, I'm arguing against getting into the habit of compulsive building and using the compiler as a syntax checker. You need to develop the confidence at a certain point to realize that what you are writing isn't complete garbage. It may have a few syntax errors or whatever but you can sort that out later.

If you are a fairly experienced programmer and feel that you work too slowly, try writing more lines of code at a time. Try to write a whole module without building it until it is done. This is the way that the most prolific programmers (and often the best) that I have known in my career have worked and I learned from them.

Edited by jwezorek, 06 June 2012 - 12:48 PM.


#18 taby   Members   -  Reputation: 336

Like
3Likes
Like

Posted 06 June 2012 - 06:33 PM

With regard to productivity, Patrick deWitt (winner of the 2011 Canadian Governor General's Award for English language fiction for his totally awesome book The Sisters Brothers) gave out a really great tip during the 2011 Scotiabank Giller Prize awards telecast. It was something along the lines of: Turn off your Internet connection at 8am and don't turn it back on until 5pm.

IMHO, that's just genius advice.

#19 larspensjo   Members   -  Reputation: 1557

Like
0Likes
Like

Posted 07 June 2012 - 02:20 AM

A lot of good ideas and thoughts above. One thing I consider very interesting and important is coding for flexibility. Quite frequently, you find that your design isn't good enough for the problem you want to solve (if it is a real project). That means you have to go back and redesign something. The effort to do so depends very much on how flexible the source code is. Now and then, I have to go back and redesign/reengineer something. It takes time, but usually pays off handsomely. It also usually ends up in me learning something.

How to code flexible is something that took me much time to learn, and I am still learning. OO, used correctly, can help a lot. Coding for flexibility already in the early stage requires more effort, so there usually have to be a compromise. Only experience can help you to find where the best compromise is.

If you have perfect requirement specifications, it is possible (in theory at least) to set the design exactly right at the first attempt. But this is quite unusual. I like one advice above, to spend a week on a prototype (that can be thrown away afterwords). It will help you a lot to find out what the challenging parts are. That is, it will help you create the requirements.

One recommendation I have, is to adopt some ideas from agile development. That is, try to make a new release every month, which should work. It is not allowed to crash or go into stuck states. That will force you to not leave major open issues, which otherwise tend to accumulate with time. It will also allow 3:rd party testers to give valuable feed-back.
Current project: Ephenation.
Sharing OpenGL experiences: http://ephenationopengl.blogspot.com/

#20 Tribad   Members   -  Reputation: 872

Like
0Likes
Like

Posted 07 June 2012 - 03:38 AM

One thing to help on re-design/re-structuring is to have some kind of nameing convention. This makes it easier to shift complete modules.
And try to use speaking names for variables.
From ancient times of programming you have i, j, and k for simple counting variables. So i use them only for that purpose.




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS