Pyweek #2: done!

It was a whirlwind of coding, although not much of a game came out of it.  As I was developing the game, I kept a journal of ideas to add.  Over the week, I just had a ton on inspiration, but I think that the idea was not really a good fit for a week deadline.

Things I did right:

*  Good games come from good ideas, so I spent the first day brainstorming and developing ideas (i also didn't have time to code!)

*   Breaking down elements of the game into manageable chunks, setting goals for each (i.e.: next hour get the input working)

*   Using an established codebase (lib2d from my last pyweek)

*   Research into genetic algorithms helped a lot

*   Using Tiled for map creation

Things that I didn't do right:

*   Being waaaay too ambitious

*   Getting stuck on details

*   Not spending time on art, sounds, music

*   Literally in the last hours, modifying the map rendering system!

The concept that I had in mind in bullet points:

*   the core mechanic would be that monsters could breed with each other

*   you could capture them as well, selectively breed them for qualities that you liked

*   use them as pets

*   if you were clever enough, you could release your bred creatures into wild populations

*   get the other monitors to interbreed with itt

*   the populations would have home areas, and all have similar traits

Maybe, one group is tough to kill because they run quickly. so you release slow moving creatures in that area, and maybe in a couple generations they will be easier to kill/catch.

 

Since the end of this pyweek, I've worked out a few bugs and maybe in a couple weeks, I'll have more to show for the game.  I really like the concept and I'm going to continue tinkering with it for a while.

A few people have talked to me about Lib2d, which I'm going to package separately and document some.

The most important features of Lib2d that helped the pyweek were:

*   Simple ini fie based animations

*   Fast multi-layer tilemap renderer, (threaded, too!)

*   Solid state-management that [imo] simplifies and consolidates input, displays, and game flow

*   "Avatar" class for animated sprites with multiple directions

I also used DRI0D's tmx loader, but I've since abandoned it since I couldn't really figure out how to use it with the latest version.

There is a repackaged version of the game (i'll just call it MH) with the renderer fixed, a new tmx loader, and a draft of the script that I wrote for the story.

 

Now, who wants to draw me some sprites?  ^_^

 
and finally, here is a link to a bug-fixed (not bug-free!) version:
mh.zip

The source code is now available for download.
I hope it will be useful to someone.

G.

As I played a bunch of PyWeek games during the weekend I found the postmortems detailing the intricacies of the games and their development a great read. They also spawn good discussions of what is missing and what could be changed. So...

Genetics

Lab Lab Bunny Lab's creatures are defined by their virtual DNA. This DNA is a string made up of ABCD characters. Some sequences carry meaning. These are the genes.

It appears the final version has 19 genes:

• 3 for texture: leaf, furry, scaled,
• 5 for color: red, green, blue, bright, dark,
• 3 for special organs: eye, wing, tooth,
• 4 for controlling the shape of a body part: inflate and shrink control the radius, contract and widen control the eccentricity,
• 2 rotate the body part clockwise or counter-clockwise,
• one starts a new body part and another concludes the description of a body part.

The sequence of genes is very much like a turtle program that describes how to draw the creature. To make it more interesting there are a few special rules, for example:

if material == 'furry':
 if r and g: # Brown is dominant.
 b = 0
 g = min(r, g)
elif material == 'leaf':
 if g: # Green is dominant.
 r /= 2
 b /= 3 

Inheritance

The creatures actually have two homologous chromosomes. Two strands of DNA that are read in parallel. The gene sequence of the creature is the merging of the gene sequences of the two chromosomes.

When you mate two creatures they each create one "mixed" chromosome by crossing over their own chromosomes at random points. The offspring gets one mixed chromosome from each parent.

Exercise

This setup makes it possible to observe Mendelian inheritance. Put a bunny in the mutator and press it until something notable happens. Say a leg becomes brighter. This could be explained by damaging the dark gene of the leg on both chromosomes or by manifesting the bright gene on one chromosome by good chance.

Let's figure out which is the case! Clone the mutated rabbit and breed it with its clone. (Yeah, sex chromosomes are not simulated. Makes experimentation easier... and weirder.) If the dark gene was destroyed none of the offspring should have a dark leg. If the bright gene was added it should be inherited by 3 out of 4 offspring. This is because each parent passes this gene on with a 50% probability and if either of them does, the offspring will have a bright leg.

This is already Mendelian inheritance but you could carry on crossing specimen from later generations and verify the statistics predicted by the theory. Gregor Mendel cultivated 29,000 pea plants — see if you can make do with less!

Regrets

I have basically managed to finish one of three pillars intended as the basis of the game. The missing two are:

Intermediate genetic manipulation. The Digitalizer gives absolute control but is no fun to use. I had planned some tools to fill the gap between the Mutator and the Digitalizer. A Sequencer that would report the list of genes found in a DNA. An Autopsy service that would destroy a creature and provide body part-level information (maybe break up the DNA into per-part fragments). A Retrovirus designer that would allow you to replace some sequences with others in a creature.

Outside world. An environment into which you can throw your creations and have them solve problems. You could control them through a Controller where you bind sequences to keys on your keyboard. Pressing the key would activate the part that has that sequence. You would capture new creatures (with exciting new genetic material) from this outside world, probably by beating them up.

I am not sure how I could have fit these in the week. I am not Cosmologicon :). I probably aimed too high. Tuning the genetics soaked up a lot of time and it could not be skipped since it is the core of the game. Features that can soak up indefinite amounts of time are the number one enemy in PyWeek in my opinion.

I also spent quite some time on the UI. I did not use a toolkit because I can write the line for checking where the user clicked faster than I can figure out a toolkit. Turns out a UI with drag and drop, vertical and horizontal containers and all this stuff is a bit more work — looks like it clocks in at 300 lines. Also it took me ages to draw the graphical elements. And I don't even have a button click animation!

Ah, and I only realized on Saturday that saving the game is not as easy as pickle.dump(game, file('save_game', 'w')) when every object references a few sprites :).

So i failed. The beginning was good though i must say. After first day i got delayed at work. Third day migrene kicked in and then i got sick. Just a hevy cold but still it required pills and help of a doctor. It drained my brain as a zombie off diet.

Yet i will finish my game. More about it will be posted on my bog in series of tutorials (eventually). This is my way of learning stuff, just write tutorials...

See you guys next year. I will be here for sure!

pyglet.resource.ResourceNotFoundException: Resource "data/queen.png" was not found on the path.  Ensure that the filename has the correct captialisation

Cosmo and Rectifier pointed out a bug:

pyglet.resource has a cache. This cache gets invalidated by the previous games you played (but didn't happen on my machine, as I played my game first).

Cosmo fixed it by adding (at the top of run_game.py) :

    pyglet.resource.path = ['data']
    pyglet.resource.reindex()

    and removing "data/" from all the resouce loads.

It might be possible to just do:

    pyglet.resource.path = ['.']
    pyglet.resource.reindex()


 

In the data/saves/ directory of Monster Mechanics, you'll find screenshots (and JSON dumps) of all the monsters you've created.

I'd be interested in seeing whether anyone's come up with anything interesting - for example, any monsters that have grown to a reasonably large size without turning themselves inside-out. Or do you have any other interesting pictures in there?

In this screenshot I'm getting in there with some vicious butt-spikes:

I've already talked about the game concept. In this post I'll talk about what went right and wrong, and my development process. Then I'll talk a little about the graphics engine. Again, please feel free not to read this if you've heard enough from me already!

Someone said to make sure to get enough sleep during PyWeek. But for me, PyWeek is a great opportunity to lose myself intensely in a project. I decided to keep track of when I was working. Here's the results:
 


Green represents time I was actually sitting down at the computer actively working on the game, and it totals 72 hours. I was also thinking about the game and doing some design work during the times colored red and gray, but 72 hours is the lower limit of the amount of time I spent on this game during the week. That's 4, 7, 6, 9, 7, 16, 12, and 11 hours for each of the eight days shown, respectively. From the time I got home Wednesday night around 9:30, it got pretty intense and stayed that way right up to the deadline.

Sleep is shown in gray. The gray bars shown are 7, 10, 9, 5, 5, 7, and 3 hours for each of the seven nights, however, each of these is about an hour more than I actually slept that night, because I was designing or brainstorming while falling asleep. I would estimate that I averaged 6 hours of sleep a night. Four of the seven nights I was up past 3am.

Also shown as green vertical lines are code checkins. There were 130 during the competition, for people who like to know that sort of thing. Also 4097 lines of code, for what it's worth. :)


So what went wrong? Not much. The game turned out pretty much how I wanted. I don't feel like I made any mistakes or really bad decisions, and I didn't run into any trouble with libraries or anything like that (with the exception of the pygame bug that causes a memory leak for some people). I feel like those 72 hours were well spent. The only way I could really have saved any time was by avoiding the graphics engine refactors I did, but practically speaking that's unlikely.

I was able to tackle a whole lot of features really fast, which allowed me to pay a lot of attention to details, some of which most players may not even notice or appreciate. These features are minor, but I feel good about them. For instance:

• You can actually set the resolution with a command-line option and zoom in and out. How many pygame games let you do that, huh?
• There's a parallaxing starfield in the background. I've done stars in so many games, this took about 20 minutes tops.
• Buttons on the UI light up when you click them and gray out when they're not available. You can deselect a button by clicking on it again.
• Save/load and autosave. I love pickle. I know it gets a lot of flack, but it's so handy. This feature took about 30 minutes. If I'd had to deal with my circular references serializing manually, this feature would not have happened, and nobody who the game crashes for would be able to play it.
• Tips appear in funny-looking thought balloons instead of rectangles.
• Eyeballs blink, and do so along their respective axes.
• Tiles roll in from the left.
• Hex outlines appear in the background when you have a tile or organ selected.

There were a few things that I obviously didn't spend much time on. They were fine in that I just needed something there, but I didn't take the time to really make them fit the game.

• Icons: I just used some free clip art I found.
• Music: I couldn't be bothered to pick appropriate music, or have the songs transition smoothly. So I just found 4 songs I liked and let you pick which one you wanted to listen to.
• Dialogue: Obb's caveman speech pattern is... uninspired. I just went with the first thing I could think of. I had a clever idea later, maybe the words could become more sophisticated the more brains you have. :) But I definitely would not have had time for that.

I was satisfied with the sound. The squishy growing sounds were taken from a recording of someone mushing up pumpkin guts. It's actually pretty gross. There was a period of time where the game was effective at grossing me out. For testing, I would have a whole bunch of body parts growing at once. (You can see it by setting debugkeys in settings.py to True, and then pressing Backspace within the game.) Without music or goofy dialogue, this can get kind of disturbing if you have to keep watching it.

I did have a short to-do list of some details I planned but didn't get around to. I decided to use the time for balancing instead, and I think that was the right decision. Nothing major, just:

• Have the mouth open and close
• Have the thought balloons form and unform rather than just appearing
• Have the shields look a little cooler than just a circle, possibly with something transparent
• Different kinds of enemy ships

Once again I used straight-up pygame. That's the way I roll. I'm quite happy with pygame, and it handles pretty much everything I need from a game library. Seeing some trouble that some people have with dependencies, I'm glad I went this route. I made extensive use of the surfarray module this time, which I'll cover more in the next post.

 
I think I'm getting much better at time management during PyWeek. It used to be that the deadline would sneak up on me, and the only way I could complete my entry was to trick myself into aiming low, and by cutting features that I wish I could have kept. But the last three PyWeeks, that's changed. I've had a pretty clear picture going into the last couple of days of what features I (or my team) would have time to complete, and I didn't get too many surprises.

I think this ability to judge your timeline just comes with experience. Between PyWeek, Ludum Dare, and practice games, I've now made a game in a week or less about 12 times now, and it helps. So my tip for how to be successful at time management in PyWeek is simply to finish a lot of PyWeeks. :)

I'm going to write a 3-part postmortem. I feel really self-indulgent doing this, so I hope it doesn't offend anyone. Please don't read it if you're not interested! This first part covers the game concept, the second part the development process, and the third part the graphics engine.

I started Pyweek 13 saying I wanted to do something different, to challenge myself somehow. In retrospect, my initial idea for Mutate! was the least different of the five, but I found ways to challenge myself. It certainly was not as unorthodox as it would have been for More Criticals, but as for my goal of doing something different, it was a minor success.

The final game is pretty much what I had in mind from the beginning. When I was brainstorming on the theme of Mutate, I considered genetic algorithms and natural selection simulations. Genetic algorithms are actually my favorite technique for solving optimization problems, and I use them every chance I get. But I decided not to go with my first instinct, and instead thought about as unrealistic, science-fictiony mutation as possible. I think this was a good choice, because lots of games wound up with a simulation aspect, and it would have been harder to distinguish myself.

One way I tried and failed to innovate was to make the instructions wordless. This is something I'd like to get good at, to make games that internationalize easily. The word balloons that appear were originally going to be pictographic instructions...
 


However at one point I made the (very wise) decision to change from manual healing of organs to automatic healing. (Originally you'd click the heal icon and then click on an organ to heal it. Now when you click on the heal icon, you go into a mode where you can toggle whether individual organs heal automatically. The new method is much better.) But I hit an absolute block trying to represent "toggle auto-healing of organs" pictographically. What I'm sure would happen is that you'd click on an icon that has something to do with health (red cross or heart) and no indication of "toggle automatic". Then you'd click on an organ and turn it red and wonder whether you just healed it or what. Then 10 minutes later that organ would be destroyed and you'd have no way to make the connection to the action you took 10 minutes ago, if you even noticed that the organ was missing. So I abandoned this goal. I think the game would have been much more frustrating and confusing if I'd stuck with it. But hopefully I'm learning some lessons about it.

Another concept I abandoned was exploration. I wanted you to be able to find weird and interesting items in space, but I couldn't think of anything good. I wanted the spaceships that attack you to resemble heroic ships from fiction, like Star Trek and Star Fox. You know, to remind you that this is essentially a space monster story from the monster's point of view. But yeah that didn't make it in.

So how about the things that actually made it into the game? Honestly, I lucked out majorly with the gameplay. I spent almost no time planning it, and it worked out pretty well. The concept of using hexes, the positioning of stalks and organs with respect to each other, and the idea of three colors corresponding to three types of organs you would need to build up in parallel, all just came to me while I was working on the graphics and layout engine and needed something to test it out. The fact that those concepts needed little refinement to get somewhat interesting gameplay was rather surprising.

I did need to spend some time at the end thinking up new organs, because I knew that the game wouldn't be nearly as much fun with only 3 different organs. But even that was inspired by the graphics engine: I thought, okay what can I render, and what would an organ looking like that do? The eye and the brain were the most obvious ones. They're definitely in there because I could draw a good-looking eye and a good-looking brain. I'd originally planned leaves, and mouths with tongues that shot out. But when I tried to render them I couldn't think of a way to make them look right with my graphics. So they became the stars and the laser bulbs.



In this game there's no way to win and no way to die. I didn't plan it like that originally. I originally planned to have different stages. After you survived a certain number of waves, you would reproduce by budding off another mouth, which would travel away and then begin the next stage. It was a conscious choice to switch to the current system of one unending stage, because I don't think the gameplay is interesting enough to bear repeating. I guess I could have put up a you win game over screen after a certain amount of time or something, but as much as I miss not having a win condition, I think this game as it is is better without one.

Incidentally, this is the third sci-fi real-time strategy game I've done for Pyweek. I think this might be my favorite genre to write. I'm definitely progressing at it.
PyWeek 6 screenshot
PyWeek 8 screenshot
PyWeek 13 screenshot

This postmortem is getting kind of long, so I think I'll split it up. I still want to talk about the traditional "what went right/wrong", and also go into some detail about the graphics engine.

Thanks for playing!

For the compo I made all the music and sound effects myself with a microphone. The song was played on both a drum and a kalimba that I bought on a missionary trip to Africa years ago. To put it succinctly, I've never took music lessons, my sense of rhythm is pretty terrible, but hey, I made it myself.

I usually finish with a game that's unpolished and at least has a little progress and an ending. This time, I ended up with the opposite: a game that turned out to be polished the part you play it and has no progress or ending. There's sound, music and graphics that turned out fine. It's more of a vertical slice. Also, I didn't try to be as experimental as I usually do.

It was fun to change my process, but I'm not sure I'll be doing it again. I think I prefer a complete and unpolished game rather than an incomplete and polished one. I barely could implement the theme mechanic, which would have a greater impact later on. I had a nice and creepy story planned but none of it was used. There was a lot of work to do and I didn't have enough time — maybe games like this would be better done in a team. It was interesting to do it this way, but I think next time I'll be back to my unpolished "complete" games.
 
As for the game itself, it's so short that there's not much to say. I like the title and how the title screen turned out. I think (I hope) it's a bit scary, especially with the background music and sounds. Besides the framework, I intended to have essentially two mechanics in the game, curtains and mutations. I like the curtain mechanic as it makes you anxious about what will happen when you open it, not to mention things that you might stumble upon while walking towards the curtain. I was going to make better use of the mutate mechanic if I had the time: it's a simple mechanic yet it's effective to keep the player on his toes, especially if you add randomness to it (which was the original intention).

The original idea of the game was to use mutations to make the player paranoid of everything, hence the title and the mutating "a". I think it would've been a great use of theme if I could play with that, to have the actual theme be the source of fear. Unfortunately, I didn't have time to even touch that idea, but I think it was a promising one.

I used DR0ID's tiledtmxloader for loading maps and I liked it, although I admit I've struggled with it quite a bit during this Pyweek. I should've checked it out before the challenge started. At least next time I already know how to use it. Anyway, thanks, DR0ID.
 
It'll take less than 5 minutes to play the game, but I hope you enjoy it. :) As usual, I love verbose feedbacks, so please let me know what you think (although I guess there's not much to say this time).

This time unfortunately I might not have much time to play and rate other games, but I'll try to play some of them.
 
As always, thanks to Richard for continuing to host Pyweeks. :)