After thinking about what it means to be successful at Pyweek, I've decided not to try to make the game with the best ratings or most fun this time. I don't know how yet, but I want to mix things up. Some potential ideas:

• As long as they don't overstay their welcome, I like those indie games with unclear goals that involve exploration and lateral thinking. They tend to be kind of artsy, but they don't have to be:
  http://www.ludomancy.com/games/today.php
• Related to that, I really like when there's a secret hidden in plain sight. Maybe an object that you assumed was part of the decoration that turns out to relate to the gameplay somehow. Taken to the extreme, you can have 100 secrets hidden in a single room:
  http://www.kongregate.com/games/ArmorGames/achievement-unlocked
• My favorite genre is the wide-open sandbox, but that requires a ton of content to really make it interesting. If I can come up with some creative way for that to exist, I would love to make a sandbox game.
• On a different tack, I've been getting into the work of researcher Jane McGonigal, who champions games (including video games) for social and self improvement. I wonder what would happen if I tried to make a game that makes people better.

Anyway, those are just my initial thoughts. Of course whatever I make will follow from the theme. If I can't think of any way to do something different, I may fall back to a standard game. But we'll see!
Good luck to everyone!

As I suggested in my last diary entry, I want to do something different. I've now got ideas for each theme candidate that I'm happy with. Some are more unorthodox than others, but all of them should challenge me in some way or other. I'm posting them now, in order to "lock myself in". (Once the theme is announced, I'm sure I'll be scared, and want to change to something in my comfort zone. By posting my game idea, I'm preventing myself from doing that.) So here goes, in order from least innovative to most innovative:

Mr. Fixit: Puzzle game where you have to fix machines by fitting the right pieces into the right places. It starts out normally enough, but as the game goes on, you have to be creative about where you pull the pieces from. By the end of the game, just like a real handyman willing to cannibalize anything around him for a quick fix, nothing is off limits.

Negotiator: A wide-open sandbox where all your attributes (such as health, attack ability) have to be purchased. You can either pay the (high) asking price, or find out what the seller wants and use it to convince them to bring the price down. The gameplay itself is not terribly innovative, but I want to use guided procedural generation to make a large game area to explore, and still make the challenge level and game duration right. While I'm at it, I'll try to make graphics (and if I'm feeling ambitious, audio) procedurally as well. Mechanics are very simple, possibly like Solar Winds: The Escape.

Mutate!: Inspired by Grow, in this resource-management game you control a quickly-mutating, cartoonish organism that interacts with its environment through a variety of appendages you cause to grow out of it, and appendages that grow out of those appendages. If possible, the game will be completely wordless.

Mysterious Stranger: Point-and-click adventure where you're the main character of a noir detective novel, involving pursuing a mysterious stranger. The clues you uncover are words that get integrated into your own narrative, changing the world around you. Like Today I Die, except that there's a timeline, and words you uncover late in the story can affect the earlier scenes. The story itself is very short, and you have to play it through several times and see several different endings to complete the game. If this works, I may also submit it to the Experimental Gameplay Project, whose theme this month is Story Games. (I may change the setting, since I have difficulty writing anything even remotely sexist, and it's hard to avoid that in straight-up noir, as much as I like the genre.)

More Criticals: Definitely the scariest for me. The idea behind this game is to learn to give and receive constructive criticism. Players will upload text, drawings, or recordings of them performing feats, like telling a joke or composing music. Other players will give criticism of the feats. The criticism itself is then scored. In order to decide the mechanics, I'll investigate what are the psychological barriers to giving and internalizing feedback, and find a way to gamify the confrontation of these barriers.

People still like hexes, right? I also have a fancy darkness effect I had to look up the logistic function for. That's all I got so far.

Thanks for working that one out for me, French automotive engineer Pierre Bézier.

The graphics are coming along nicely, although I'm going to have to work real hard on the gameplay to do them justice. The best part is, I still have an empty data directory, because the graphics are all procedurally generated, yay! Just goes to show that there's no problem that can't be solved with a few thousand calls to pygame.draw.circle.

I'm on an 8 day schedule here, since I'm counting both last Saturday, when I worked at night, and next Saturday, when I'll work during the day. So today is Day 5.

I spent all day yesterday refactoring my graphics engine. Normally I would advise against fixing what isn't broken during Pyweek, but it turned out to be worth it. I found several speed improvements, and went from 11fps to 30fps, and my machine is pretty slow. If I can keep it in the 20s I'll be happy; it should run faster for most people.

I've spent some time today getting the UI working. I still have a long way to go. After that I have a lot of work to do implementing the various gameplay components (organs) and balancing. Oh, and figuring out some sort of goal. Days 6 through 8 are going to be action packed.

Anyway, people seem to like the graphics so here's the latest. Just please keep in mind that good graphics don't necessarily make a good game! :)

I've got about 20 hours left, and I need to use as many of them as possible. I'll take a break now to talk a little about the game, but then I'm going to work as hard as I can to reach the deadline.

I just barely have the game in a state where I can play it, and it's a far cry from being in a state where other people can play it. On the plus side, I thought of a good name for the game. Obb.



You anagram-lovers out there will be happy to know that Obb is an anagram of Bob.

So, some thoughts about the gameplay. I wanted to challenge myself this Pyweek, and for this game I decided to eliminate all written instructions. When you're not told the rules of the game, figuring out the rules itself becomes part of the gameplay. I definitely like this aspect of games, because it feels like you're exploring. Some people hate it, though.

It's also slightly complicated by the fact that Obb already has two layers to it - it's a tile placement puzzle game and a real-time strategy game. So by adding the third layer of figuring out the rules, I'm really risking that I'll frustrate some people. It's hard for me to convince myself to do this, but I wanted to take risks. I may learn my lesson and never try this again. :)

Also, there's currently no way to die and no way to win. The gameplay reacts to your ambition, so if you scale it back, there's no point at which you're eliminated from the game. I'm thinking of keeping it this way. I like this in terms of the story it tells (and since my games are usually heavy in dialogue, it's driving me crazy that I get to write only three letters). Obb doesn't really have goals - Obb is just Obb.

So I like it for aesthetic reasons, but I'm not so sure I like it in terms of gameplay. I like games to have goals and a sense of progression, and this is a little too open-ended for my taste. I'll see what I can think of as I'm playtesting. Hopefully I can find a happy medium.

All right, back to the task at hand. See you on the other side!

To people who said to watch your health and get plenty of sleep during Pyweek, I did the exact opposite. This was the most intense week of coding I've ever done. Looking back at my posts from Day 1 and Day 2, I can barely remember ever being in that position.We'll see if it paid off. (Fourth) final submission here:

Obb version 4

Please let me know if you catch any major bugs I can fix!

Good luck all!

I threw together a script that makes an image of the entire map in your Obb game from your savegame file. You just put the script into your root game directory and run it with python. Here's the script:

make-obb-map.py

And here's an example image that it generated (1.1MB, minor spoilers?):

obb-map.png

There are some options given in the script. If anyone thinks their map is interesting, I'd love to see it. :) But really I just made this for myself and I decided to share it. Thanks for playing!

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!

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