Tagged: dev

Now that I have released January’s game to the wild, it is time to begin thinking about my next game. As the month went on, I decided that I did not want to finish my LD48 #24 game from last August where the theme was evolution. I like the game, and I made a lot of neat additions to it, but I think in the end it’s just not going to be fun for very long. The aliens had a bunch of different traits and as you killed them the ones that were most successful in surviving and damaging your ship had their traits passed on to the next round. The problem is that there isn’t much strategy with the player. They click and shoot. Click and shoot. Eventually the aliens would become harder but the strategy remains the same. However, if there were multiple different approaches the player could use to defeat the aliens, they would be forced to try something new as the difficulty ramped up until they found something that worked better. This, in turn, would cause a different set of traits to bubble up to the top and start the difficulty increasing again. The way that game is now, it would need some major remodeling and a rethink of one of the basic rules I had when I started, a static firing location. It makes more sense to start over, and I am not ready for that.

I worked throughout the month on LS-MAN bouncing around to each of the different aspects of development. Coding of many features, but also graphics, sound and UI. This meant that the game grew in many different directions, at roughly the same time. On one hand, when I got bored I just changed gears. On the other hand, it took me until week three to really have a playable game. I have read #1GAM father Crister Kaitila’s ‘McFunkypants Method‘ and think that for February I will try to follow them. The one I want to attempt primarily is to get a simple working game completed in the first week using only placeholders for art and sound. This would mean that I have the rest of the month to add all the cool features and polish.

One of the other tips is the “save points” where you have what you could consider a deliverable. The first deliverable is the working game with placeholders. Not overly exciting, but it’s a game. As you add features you’ll come up with other save points. These make for great moments to tuck the game away in a safe place. Should everything crash and burn, you’ll have something to fall back upon.

I have an idea for a game to be completed later this year, but it is probably too much work for one month. I was trying to figure out how to break it into pieces and realized that I could implement one aspect of the game now as it’s own stand-alone game and use this module later when I work on the game with the bigger picture. February is also a short month, so something with less work would be a plus.


My drawing of Glob, top right, and Glub, bottom left. All the rest is my son drawing his own versions. Also, people with big feet.

One part of may January game that I really enjoyed was showing my four and a half year old son my progress. He would constantly want to see the game run and watch the creatures explore the maze while LS-MAN gulped the pellets. I drew some concept art for the creatures; he looked at them and did his own versions. It was easier to get him ready for school on days when I had something new to show him, like a newly animated creature or pellets. I thought it might be neat to make something that he could play, so for this month’s game I will likely be making a shooting gallery, not unlike those found in older arcades, carnivals and boardwalks. He’s really good with intuitive touchscreen UI, but this is the desktop so simple point and click with the mouse would be a great introduction. This would then become one aspect of a future game.

First stop, however, is to set up source control that I lost when I upgraded machines. I also want to yank out some of the utility classes that I have created over the past couple years into their own library so I can continue to add to it as the year goes on. I just updated FlashDevelop from 4.0.2 RC2 to 4.2.4 and so far so good!

The game started as an entry to the Ludum Dare competition over a month ago with the theme “You Are The Villain.” I completed a reverse-Pacman game where you controlled the ghosts in order to trap Pacman and keep him from gobbling up your pellets. There was very little AI in it. I have a couple pathfinding classes that it uses to pick the path from the ghost to the player’s cursor, so most of my time had gone into creating the pathfollowing code and trying to get that correct.

For One Game A Month, I continued to work on it. I revamped the graphics so I would not get into intellectual property trouble should I chose to sell it and renamed it LS-MAN. I refactored many parts related to the size of the cells and gameboard, rewrote the pathfollowing code, implemented a potential field to use for AI, surrounded the game with a main menu and end conditions, and generally tried to add polish.

I did a lot of this all at the same time, which was nice because I could do something else if I got bored. Unfortunately, it also made it take longer to get a playable game since I was putting things in that weren’t necessary for the minimum threshold where you can call it a game.

What Went Right

The pathfinding was a class that came from Untold Entertainment. I had used it before in some unreleased side project and it worked well, so I grabbed it again for this. It was easy to drop in and modify for my needs. There is a Node class that contains a lot of the implementation specific stuff. I ended up using the Nodes to hold most of my data for the map.

For the invader’s AI, I learned about potential fields from AIGameDev.com. It’s a method used in real-time-strategy where the goals and threats have positive and negative effect, respectively, and those values are radiated outward. This was a very CPU intensive step. I was using the Nodes from the pathfinding to hold the potential data and it was something that needed to be recreated often. If not, LS-MAN would be using stale data to decide his path and make a wrong move. It didn’t run too bad in Release mode, but the delay was noticeable every second or so and any delay would be unacceptable. There ended up being two solutions for this and they go hand in hand.

The first fix was to change how the pathfinding algorithm went about finding the nearby nodes. The pathfinding connected node function searched every node in the grid to see if it fit the requirement of being one away either horizontally or vertically. Regardless, pathfinding is really fast but we also know it’s not searching very many nodes in most cases to find a path, so this excessive connected node function wasn’t a huge deal.  However, the potential field calculation searches _every_ node which means every node’s neighbors are requested. And since there are multiple sources of the field, certain nodes could be recalculated and set multiple times. This was just not going to work.  I had made changes to the connected node function to enable the wrapping off the edge of the screen, so I felt that searching every single node to see if it was connected was not really that bad as long as we didn’t have to do it a lot. We do have an advantage–once loaded, the map doesn’t change. Therefore we could actually do the (relatively) slow calculation at map load time and store the result on the Node object. Now whenever potential field calculation or pathfinding needed to know what was nearby, it was returned quickly. This reduced the number of CPU cycles per frame a huge amount, but we still had a delay every few frames as it waited for the field calculation to complete.

The second solution was to refactor the potential field calculation so that it wasn’t doing it all at once. Since the default algorithm has you storing the to-be-calculated nodes in a queue, it was easy to add a state machine to it and iterate through that queue over multiple frames. Whereas before it was looping until the queue was over, my implementation would now also quit the loop if a certain amount of time had passed. In my case, it would only do up to 5ms per frame and then stop, letting the rest of the game continue, and pick up where it left off the next turn. Once it completed a batch, the old values were replaced by the new values, and the cycle started over again. Now when LS-MAN reached an intersection, he would look at the potential field values for each path and take the one with the highest value. This would lead him to pellets and away from the creatures trying to get him.


Debug mode screenshot showing the positive potential field of the pellets and the negative field given off by the creatures. Blue is a positive field, red is a negative field. Black is nothing. Upper left corner of each node is the actual value.

Super pellets were a different matter. In order to give LS-MAN some kind of above-minimal survival instinct, I had the pellets give off a large positive potential when LS-MAN was within a certain distance of a creature. This results in the appearance of him seeking a pellet when he knows he’s being actively chased. In order to keep the pellets around longer, I actually have them give off a negative field which should dissuade LS-MAN from choosing that path when no creatures are around and instead have him continue eating regular pellets.

In my original LD48 implementation, people said it was hard to select the ghosts. I took that critique and added keypresses that would select individual creatures, as well as adding buttons to the screen. If I eventually port to a touchscreen format, these buttons would be perfect.

I used OGMOv2 to create the levels. I really enjoy being able to rapidly create even though I only had two for the released game.

What Went Wrong

Not really wrong per-se, but it would have been nice to have had a working game earlier. I did spend the middle of the month focusing mostly on pathfollowing, even rewriting the code at one point, but I also spent a long time tracking down bugs that the game ended up ‘shipping’ with anyway. I should have noted that they were not show-stoppers much earlier and went on to finish aspects that would make it that much closer to a game.

I’m not really happy with the scoring. I knew time and the number of pellets should be the gauge, but I never had time to come up with a score based on those two values.

As time went on the code became more difficult to manage. I think it was because the board was lumped in with the main world code. They are tightly connected, which is fine, but I think pulling out the board stuff into it’s own class would have kept the code neater and probably easier to navigate.

I gave each creature different levels of ability to give them somewhat of a personality, but I’m not really happy with the level of balance. I never really got any external playtesting so I don’t know how they feel for everyone else.

Looking Forward

I would love to add high scores and new levels at some point. If I end up writing the server code to store scores, I would certainly add something that reports back.

Bonus Reading

Long after the point of no return I found this gem of a post at GameInternals.com. Since the goal of LS-MAN is different from traditional Pacman, the AI didn’t carry over much, if any, however I if I had seen it earlier I might have picked up the method of board construction and makeup for my own instead of using a static grid size for everything. I recommend reading, especially if you like simple implementations that result in the appearance of a more complicated intelligence.

The latest in the Ludum Dare 48 Hour competitions is less than a week away! Time to get out that base code and wait, right?

WRONG! There is so much for you to get ready and practice. You could be doing any of these:

  • Draw some sprites for a random animation, either directly in a bitmap editor or on paper and scan them.
  • Polish that basecode to fix that thing you found last compo that really bugged you.
  • Install GIMP or Audacity or other development related application and practice how to use it.
  • Pull out your microphone and record yourself and other sounds around the house to create a song in Audacity.
  • Create a Towlr.
  • Think of witty motivational posters.
  • Rip CDs to MP3s and create a great 48hr in-the-zone coding playlist.
  • Stock up on food for the weekend.
  • Clean and organize your desk.
  • If you are feeling adventurous, take your first steps with that new language.
  • Vote!
  • Spend some quality time with the family so they know you still love them when you ignore them over the weekend.

Whatever you do, please share it with us on Ludum Dare! And also, no matter how much or what it is that you do, you’re a winner in this pre-compo competition!

Of course, none of these things will actually be used in the LD competition since that is against the rules (except the basecode) however they can’t keep you from using the skills you just learned!

The 13th Ludum Dare 48hr Game Programming competition starts this Friday, so it’s time to get the tools in order so there is less fussing when time is running short.  Also, my wife and I have been invited to Thanksgiving, The Sequel this Friday, so I won’t be home when the topic is announced.  I’ll try to check in to LD.com with my phone so I can at least start planning things out in my head.

So let’s take a look at what I’ll be using… (more…)

It’s time again.  Seems like just a short bit ago I was working on LD48 #11, and maybe it was.  The contests are on a much better schedule now which should help in participation. 

I’ve been keeping myself busy working on a reborn and re-imagined project from back in ’03.  I’ll probably release more info on that when I have something good to show off.  If we get a compatible theme, perhaps some of the work on LD48_12 can be reassigned afterward to my other project.  Honestly, working on that project the past week has kept my skills and mind frame in the perfect place for the LD48.

Last time around I had to take time out from the alotted 48 hours to attend a baseball game.  I won’t have that problem this year, though I am in the mood for a good egg and bacon breakfast at a local joint Saturday morning.  I hope to remember to take a picture of that for the food compo.

This time around isn’t going to be much different than last time.  I’m going to use mostly the same tools as before:

  • Java 6 SDK
  • Eclipse 3.3.2 IDE
  • Photoshop CS2
  • HP OfficeJet 6450 All-In-One for scanning doodles
  • No Fear Energy Drink (Go Boris Said #60!)
  • Everlasting Gobstoppers
  • mIRC for chattery
  • Killer Game Programming in Java and the base code I used from last compo.

The only thing we need now is a theme!

Good luck, and see you in 1 day, 9 hours and 48 minutes!