The Road to PyWeek -- Why I'm Doing Practice Runs
Akake on 2009/04/01 13:59
of The Laser Samurai
I'm probably going to shelve the thing. I'll come back to it after the compo if I do, and probably use it as a springboard for more work on Peachy Keen. For now, though, it looks unlikely. The code has turned into a mess. I'm starting to think I should have made a flowchart, or at least planned some part of how the code would work.
That said, this is ultimately why I decided to do full practice runs this time. Because I knew there was still the chance of things getting away from me.
----
As for the next run, the friend that I have coming up with themes for me has given me a list of the possible themes. She decided to use themes that were phrases, like some Pyweek themes have been, and she also threw in a theme that I'm not familiar with (#2), because she says that such a theme may be the one voted in, and I'd have to do something with it.
The theme for my next practice run may be:
0-Running on Ice
1-Shake it and Bake it
2-Red Rider
3-Turtle Shells and Cupcake Smells
4-We can Only Improve from Here
She hasn't given too many hints about which one she'll have me do, but I thought I'd post theme for anyone who might want to play along.
My next practice run will (Because I've abandoned the first one) start today at 12:00AM UTC
----
The Adventures of Jenny Carlyle, Episode One:Post-Mortem
While I haven't quite thrown in the towel on my first run, I'm going to share what went wrong, for the record, and so I can try to not make these mistakes again.
Problem One:Built early framework on unit test framework
I didn't have a plan for the game flow code until about day three of the run. This made it hard to move anything over to the actual game framework.
Problem Two:I've said it before and I'll say it again, Boilerplates are a time sink!
I spent the first two days, and two mornings getting up at two in the morning writing them. I can't afford to do that in the compo.
Problem Three:Not enough planning
There's something to be said for Big Design Up Front programming. This project has made me realize that. What really killed me in the end was the lack of planning. I had the game planned, but not how the code would be structured. That needs to change.
Problem Four:Distractions
I got distracted by many things. School, of course, is largely unavoidable, but there were many other things in my way. I need to learn to not become distracted from my goal.
Problem Five:Nothing tied together
I'm not sure how to explain it, but my code was very disjointed. I'm certain this was due to my lack of planning. My code simply never came together. I'm still working out how to correct this mistake later on, but I think having a Big Design Up Front will help greatly.
Problem Six:Code bloat
My code simply kept growing and growing. There were several functions to load things from files that were largely identical, and there were member variables that I simply didn't need. I also overcommented... alot, and wound up unable to navigate my code because of it. The whole thing eventually became too big, and that's how I would up where I did.
In Conclusion:
Many mistakes were made, and there is a minimal chance of a running demo by the deadline.
On a brighter note, many lessons were (re)learned, and I can only improve from here.
All things considered, this concept will probably be my first game after the competition, but for now, I think it can be laid to rest. I will have to start fresh to get it working, and I don't have time for that in this run, I'm afraid.
(log in to comment)
Comments
Akake on
2009/04/01 23:11:
I think you're right. I just need to get more into the rapid development mindset XD
But hey, better to learn that now than in the actual competition, right? :)
And as for the better programmer part, I can't disagree, but I do admit that I'm taking it too seriously, which was a problem I had last time as well. (Remembers having several breakdowns, including several that (thankfully) never made it into IRC)
I think that's what I need most of all. To calm down.
I'm going to be trying a different development technique in my next practice run, too:Top-down development.
In other words, I'll write the broad structure of it first, and then I'll write things like the collision detection and the like.
Truth be told, I had fun in my first practice game, I just got kind of frustrated about all the self-set deadlines I wasn't making. :P
I think next time I'll focus on having a structure to fit everything into and then I'll worry about having things like classes to handle character animations and a cleanly-made data file format XD
I admit, I'm a big engineering buff when it comes to coding. I probably need to tone it down, yeah, but I like to have things very cleanly coded.
I find that my code comes together faster when I make it very clean and organized, but that's me. I work best when it's clean.
Come to think of it, that's probably why debugging goes relatively quickly for me most times. Last Pyweek, it was difficult, and I never did quite get it working, but for most games I've found that debugging is fairly easy for me.
The trade-off there seems to be that clean code takes longer to write, but less time to debug, whereas messy code can be written fast, but takes a while to debug.
But meh. The next practice run should go a bit better, now that I've found where my problems lie.
--Akake
bencoder on
2009/04/02 00:15:
I guess my general technique is to broadly separate my program into a few classes - graphics, sound, input, main-character, world/environment/level, Enemy/AI character.
Then I start building the main character class first, just so I have something interactive. I add functions to the graphics and input classes as I need them in order to make my character class work. Then I build the world class and add functions as necessary to the other 3. Then the enemies, same process. And finally the sound class.
And then I have a game :) but it's very important to me that each step be testable so that I can see some progress.. if I don't have that then I get very discouraged to continue and lose interest and motivation.
But yes, I guess you need to find a method that will work for you and keep you motivated without over stressing on it.
Again, best of luck with your next practice run :)
nikolajbaer on
2009/04/21 00:58:
My last entry, Robosub (http://www.pyweek.org/e/robotkiteclub/), was in 1 file. Basically it started out as a sketch of an idea, and i kept hacking it in the evenings i had available til it formed into something amusing (albeit far from perfect).
Not saying this is the ideal way, but I think it allows for a more artistic approach to game design. I think it is thanks to python (and pyglet/pygame!) and its terseness that we can even do this!
For practice runs, or the real thing, I advocate starting with an idea, and then just flesh it out, much as one would a sketch or painting
Cthulhu32 on
2009/04/21 17:21:
1. I came out with almost 4 different games :)
2. The back end engine was clean, but I spent so much time on it I lost some of my design elements.
(This is for RoboFusion - [Link] )
I had a full physics actor system that could support any type of gravity & speed variations with simple inherited variable changes, but my game had grown too complex and I wound up with a difficulty that was way too frustrating for the average player. I also lost sight of my design goal a bit due to how much code I was writing, and I barely had time to do the tiles and animations.
Its a hard balance between spaghetti code, initial design, and overall fun, but I think you should go somewhere in the middle. Try to keep your code clean enough that you can spot obvious bugs, but don't obsess so hard on it that you write an engine in a week and have no time for the fun! Also, take a step back when you're writing your code. If you see a large chunk of it on day 4 that is causing you a headache, and its hindering you from moving forward, rewrite it or mold it in a way that better suits what you need to do. Don't worry about re-usability of your code base (5 file open functions that all do slightly different thing) because chances are you'll never touch this code base again.
Woodwolf on
2009/04/21 18:41:
Akake on
2009/04/22 00:19:
But I don't tend to add features once I've started coding. In fact, once I've started coding, unless I don't actually have any idea of what I'm doing, it (usually) goes fine. It's the design that really kills me.
All that aside, though, I actually code better with a clean base. The coding (usually) gets done in a timely manner. It's the designing that turns into a time sink for me.
I find the more I try to fix spaghetti code, the more bugs develop. I need a clean base to work with.
And who said anything about my code being re-usable? I write everything from the media and input engines up anyway. I don't like having to deal with too much existing code. I gets tripped up in it.
That's the main reason I decided not to go with retrogamelib. It has too much implemented. :-/
Still, I get your point, but the first practice run was a matter of not having a clean structure for the thing, the second was eaten by too much designing, and the third was cut off because I didn't think things through. (The third practice game didn't have any terms of failure, and I hadn't even really decided whether to make levels or generate them procedurally :-/) I've never had an issue where my code was too neat ;-)
Actually, that's one thing I did last time that I intend to fix this time:Messy code.
Last time, my code was hideous by the end. I'm going to fix that this time around.
If I stay organized, I can do anything. If I get to where I'm stepping on my own feet (Breaking features with bugfixes), then I get nowhere. I've learned that much in the admittedly short time I've been making games. I can't work with kludge. It just gets more and more nasty as I go, and if I do get it working, I usually realize it's become organized, and that I should have and could have written it cleanly before.
But eh, whatever. Everyone has their strengths and weaknesses. My weakness happens to be feature-creep and an inability to debug messy code, and my strength happens to be meticulousness and the ability to organize my code. Everyone works differently.
saluk on
2009/04/22 01:18:
Akake on
2009/04/22 11:41:
I'll keep that in mind. ^_^
That's another thing I did badly last time. Gameplay style changed several times. :-/
I'm also likely going to stick with a genre that I'm relatively familiar with. I've developed a small number of (demo) platform games, and will probably stick with them, unless something brilliant comes to me that I can find a plausible way to do, like a puzzle game or a (simple) strategy game.
Still, I'll keep that in mind. Stick to the design as best as I can.
----Akake
bencoder on
2009/04/01 20:54:
I think you might be taking it too seriously. When making a game in a week.. the code really doesn't matter that much, I think if you look at the code for some of the entries you're mostly going to see garbage - they all start out well but when you're rushing to add features it's what happens.My technique:
Which is interesting because it's almost the opposite of what you say was the problem - not enough planning. So it's probably not much help. That said, you're probably a much better programmer than me for trying to keep it neat, doing unit tests, etc. But I personally think these are unnecessary in a 1 week game competition.