Tuesday, April 12, 2011

pyweek: nanite_fight

I participated in pyweek for the first time last week.  It's a twice-yearly competition to make a game in Python in one week.  I didn't start until Wednesday (looks pretty par for the course), but it was my first time spending 12-18 hours every day on a programming project.  I rather liked it. 

It was also the first time that I aimed to design a relatively small, contained game.  Without resources to develop much content, it makes sense to aim for really emergent gameplay:  a small set of options that can be combined in many different ways to create a large number of outcomes (e.g. the game Go).  

Design
nanite_fight is a programming game.  You get conditions and actions, a limited coding space, and function calls to jump around the code.  You can change the code while it runs.  If your nanite shoots another nanite it makes it into a copy of itself that independently runs through the same code.  A second player can do the same thing.

That's pretty much it, but it does allow for a huge number of permutations.  Unfortunately I didn't have time to make a great interface for two players playing at the same time (but you can load saved scripts from two players).  Also, the skill-curve seems diminishing: a nanite that just turns and shoots is way ahead of a nanite that just shoots.  You can make a nanite that will consistently defeat it, but it will take substantially more time.  Defeating that nanite will a lot of work.  There are too few opportunities to learn a new trick and gain an advantage.

Programming
I set a goal to write this outside of my usual object-oriented paradigm.  I didn't define a single class, and a nanite is essentially a struct of ints in the form of an array.  

All the nanite programming is handled with first-order functions.  The code grids are 2D arrays of pointers to functions, and the nanites store the row and column they're on, do it, then move to the next. 

I made extensive use of hash tables in handling both input (which is all drag-and-drop) and visual and audio output.  The code grid is an array of functions, so the view has a table with function keys and icon values.  Each time a nanite takes an action, another table looks it up in a table with function keys and sound effect values. 

No comments:

Post a Comment