LS-MAN Postmortem

Posted by of LoneStranger Designs (twitter: @lnstrngr)
December 19th, 2012 1:20 am

It is pretty depressing to work on your idea for a few hours on Friday night only to realize that at least one other person is doing the same thing as you. I had looked at a Google image search of “Atari 2600” just to see some basic game implementations and ponder how to reverse them. When I saw the Pacman game, I realized that it was something simple enough to do in 48 hours, and complex enough to not be just a concept demo (I think I fell somewhere in between). A game where the ghosts are trying to trap the Pacman wouldn’t terribly difficult: minor AI, simple screen, few animations, basic controls. It seemed like a good idea, and it was, which is probably why someone else selected it, too. After Friday I refused to read the “other” journal for fear of 1) unconsciously directing my creativity choices and 2) to not get discouraged and quit early. I continued on.

On Friday night I decided I wanted to use a mouse select->command scheme for control. Ghosts randomly move around the map until you click the ghost and tell it where to go. It will follow the path to the destination, where it will return to roaming. I didn’t want them to just stop somewhere because then you’d be able to camp out and essentially block Pacman while you herded the ghosts at your own whim. Having them roam would make it more difficult to trap Pacman. Friday night, after I created the map and creature code, I implemented the pathfinding system.

Most of my wasted time on Saturday was spent implementing the pathdirecting and pathfollowing system. This drove me nuts and I nearly threw it at the wall. I don’t think I ended up using most of what I did because it got to complex. I was able to rewrite it so it made more sense and was easier to debug. Once this was done, the ghosts could be directed, but also wander. I added some sounds and replaced some of the placeholder rectangles with bitmap graphics. At this point I had the makings of a game, but not things to make it an actual game: game over condition, accomplishment measurement or general polish.

gameplay

I don’t actually remember much of what happened on Sunday. I worked on some of the same things, but by the time there were only a handful of hours to go, I knew I wasn’t going to be able to make it. The deadline came and went, and I was onto the Jam. Monday I had to work, but I was able to spare a couple hours afterwards to add the game conditions and finish the UI to give the illusion of a finished product before submitting.

What Went Right

placeholder graphics – Usually I sketch things out while I flush out design and end up using them as the graphics. I like the resulting style. It give it that cheap cartoon animation feel. For this entry, however, I didn’t sketch a thing and used placeholder squares and lines. It let me implement features earlier instead of spending time trying to animate or adjust images. I don’t think sketching things is ever bad; it can help you bring your game idea to life even if you never use the image in it. Placeholders force you to work on what is more important and spend less time on things that would get removed or reduced near the deadline.

pathfinding – I used a couple AS3 classes from Untold Entertainment (which only needed a couple tweaks, see their comments) and it worked out really well. There are a few things that I could do to make it more efficient, but it was good for this task. I will definitely use it again.

codebase experience – I’ve been using Flashpunk for a couple years now, so I am getting much more familiar with it. I have built up solutions using it and have been able to leverage those solutions in future projects, reducing some wasted time trying to ‘reinvent the wheel.’

I submitted it! – At the end, I managed to get something that could actually be considered a game, even if it’s not up to the finished idea in my head. I really didn’t want to submit a demo or sandbox because that doesn’t really count as a game.

What Went Wrong

endgame came late – I didn’t actually get the endgame stuff in there until the last hour before I submitted. I should have worked on this earlier. I think next time I will be sure to add the endgame circumstances, even if the rest of the gameplay isn’t there. I still have to write gameplay before the end, but this would allow me to push the more dropable stuff to the end in case time got tight.
reconnaissance – I probably should have investigated my partner-in-idea’s logs at some point to see if there was something I was indeed missing. Based on the review comments so far, I really should have added a better method to select the ghosts, perhaps buttons on the screen and/or keys on the keyboard.

AI – I initially thought the AI was not going to be hard, but I ran out of time and never really had a chance to implement it. The Pacman and undirected ghosts are essentially random. I wanted to have them show a little personality, perhaps chasing or trapping the Pacman, but not so much that you don’t have a job when you play.

random change of position – I don’t believe the real Pacman game allows the ghosts to change direction except at an intersection (or when a power pellet is used). It’s been awhile since I played, so I might be wrong. Anyhow, a lot of my wasted time was trying to get them to not return to the just-traversed hallway without going around. I eventually gave up. Looking back now, it doesn’t seem like it was that big of a deal to warrant that much time spent on it.

node/tile types – I designed the game to keep pathfinding nodes separate from map tile data. The pathfinding system uses nodes with only three options: edge, wall and hall. At some point, however, I realized I needed more than just those three tile types or would have to hack in other properties. I would have to go back throughout the entire pathing code to implement new types. This introduced a few problems and I even had to back out a couple hours of changes. I think next time I am going to go with a standard tile that doubles as a node and contains properties that can be used instead of checking specifically for certain tile types.

Conclusion

I have to rate this as a successful competition because I was able to submit something that I can consider a game and not just a pile of crap that lets me vote on entries. I’m not completely content with the end-of-compo result, but I don’t know that it is possible to ever be fully happy. I’m probably sitting somewhere about half satisfaction. It was a great experience, however, and I can really tell that I have made progress over the years. Can’t wait for the next LD competition in April.

Tags: , ,


Leave a Reply

You must be logged in to post a comment.

[cache: storing page]