Self set Challenge: 2 month dev cycle

Started by
33 comments, last by djz 12 years, 7 months ago
I think its time for a confession - i did overengineer, in two cases. This project wasn't just focused on getting a game developed in 2 months, I was also exploring a new methodology theory I had - how to combine DOD with component based logic.

I'm refactoring the game to use the type of structure I usually use for rapid development games.
Don't thank me, thank the moon's gravitation pull! Post in My Journal and help me to not procrastinate!
Advertisement
I think zedz is saying that, well, you don't need all the components of the framework ready and perfect in order to have gameplay. Right now you have a tank driving around and turrets shooting at you - You could have totally do that in a few days instead, right? It might not have been the world's more sophisticated component data-driven system or what have you, but you would realize a more significant goal - have quick, tangible results that give you positive feedback and encourage you to go on. As you said, it could be an iterative process; you work in order to have gameplay as soon as possible, and in parallel you refine the core components as needed and when needed. I find that works better anyway, and I'm trying to take that route with the game I'm making atm.
yes mikemans right, just get the basic gameplay up and running, make it playable (hacking is good, since you will find >50% of the stuff/ideas you have dont pan out i.e. dont spend time perfecting something that you find doesnt meet your expectations, you can always rewrite your hacky code later)

FWIW heres what Ive done Im not sure how long it took, ~50 hours I think (including making the music,art,testing etc).
attack of the smilies yes I know, terrible name. Also please dont share the link as Im waiting until the sound api enabled browser hits mainstream.
a couple of bugs (with the sounds not resetting at the start of each level, which I have fixed & will upload a newer version later & also I should remove the debug text)
also u need a new version of chrome -> http://mlab.taik.fi/mediacode/archives/1533 to hear the sounds.

for this game the order of things I done was roughly (I plan & write this the night before in a exercise book)

A. add a 2d board of blocks
B. add a player 2d sprite, that moves from block to block (no animation)
C. change colors of the blocks
D. able to complete a level by coloring in all blocks
E. add an enemy smiley, that randomly moves from block to block
F. coldet between smiley and player

the result is a playable game, within a day. I think you could manage this in a day?
after that, go from one side to making a 3d cube playing field, expand from 1 enemy sort up to 10 enemy sorts, add bonuses, fx's different levels etc.
But ultimately youre just working on the same basic idea

At the moment Im thinking what game to do next

btw, cheers for updating this thread speciesUnknown
It really depends upon the game design. If your aiming for something simple sure you can probably hack something together in day but for more complex projects it will take alittle more though and time. Given that your setting yourself a 2 month goal, you have to be realistic about the design and your abilities. The other side is do you have the tools to execute the design, your not going to create a full 3d engine, physics engine, or gui engine within 2 months and still have any time left over for the game. Your toolkit is just as important as the design. Maybe you have an awesome design but it will take more than 2 months to execute, no need to hobble yourself on the artificial time frame.

Good Luck!

-ddn
Don't be afraid to put code RIGHT where you need it. Refactor only when you really need to! Don't even "engineer" it if it works. This has been the hardest lesson for me to learn in programming...ever.

Every coding session, make simple, short term, achievable goals. Move forward constantly. First, get something on the screen. Next, create a Player object that does some things. Do everything inside that class, until you start to have logic in there that can clearly be placed in its own bucket. If you get to a point where you can't achieve your short term goals in a single session, you need to:

A) break your goals into smaller chunks or
B) refactor to make achieving your goal easier. But you must always balance this with A.

THE PLAYER WILL NEVER SEE YOUR CODE. They don't care HOW you implemented a feature. So focus on goals that have a real, tangible effect on the way your game actually plays. As far as your code goes, you should only be concerned with two things:

A) does it work?
B) can I work with it efficiently?

assuming you have the basics covered (i.e. properly managing/disposing resources, etc.), if you satisfy A and B you are flying.

Always remember the 80/20 rule. It takes 20% of the effort to get 80% of the result. So focus on that 20% that gives you the most gain, as far as your PLAYER is concerned.

Disclaimer: i'm not saying don't refactor your code. But if you feel like you *need* to refactor your entire codebase, it's probably because of some aesthetic issue that only bothers you. There's probably a few small steps you can take right now that will help you implement features faster, so just worry about those. Get shit on the screen, moving around, make it do things - that's what counts.

Mark your progress, set weekly goals. Beat your goals. Surprise yourself!

As far as working fulltime goes, that's 40 hours a week. You're probably not 100% productive for all 40 hours (I've never known somebody who was). If you can put in four hours a night on weeknights, and five hours a night on weekends, and focus you should be able to get output close to the equivalent of what you can get programming full time. If you can't scrape together that much time, then you're probably fucked. Serious business requires serious commitment.

This topic is closed to new replies.

Advertisement