Eidolon Games

One finger, two buttons, is all it takes to be a martial arts master. I’m talking about One Finger Death Punch, an absolutely brilliant game wherein you play a stick figure martial artist. I’ve been playing it every day for the past two weeks, and you should too!

The way it works is you have a stick figure in the middle of the screen, and enemies come running at you from left and right. When they get within range you click to attack. Left click to attack left, right click to attack right. If you click before they are within range you will miss and be stunned for a moment. If they get too close they will attack you and you will lose some life. That’s it, but the complexity they build from those simple rules is both deep and beautiful in its elegance.

Each level only takes a few minutes to play, and it’s a few minutes of absolute flow. You move from enemy to enemy striking in quick controlled bursts to make sure that you never miss and give them an opportunity to strike you. Some enemies will dodge back and forth requiring several attacks to defeat. You’ll fight ‘brawler’ enemies that engage in a prolonged one on one battle with you. Some enemies will throw weapons at you, and you’ll snatch them out of the air and send them flying back to their source. And all of it is done with just the two buttons.

It’s an absolute work of art, and only cost $1.99, if you enjoy games (and if you don’t I’m not sure why you’re reading this), you really, really should go give it a shot. You won’t regret it.

Here’s the link again, so you don’t have to scroll back up to the top.

Games have to manage a lot of data, information on all of the weapons, ships, enemies, etc. Plus all of the player  information like owned ships, layout of the planets, cash, allies, etc. I use a series of hash maps, a data structure that lets you store data with indexes so that it’s easy to pull back out pretty quickly. That allows me to access it while the game is running, but I have to store things between game sessions as well, and that’s where serialization comes in.

Serialization is when you take some data in memory and convert it into a series of binary data, ones and zeros, for easy storage. Yes the data is stored in ones and zeros before serialization, but it’s sort of like the difference between having your clothes hung up in a closet vs having them packed in a box. They still take up the same physical space, but they are a lot easier to access in the closet, and a lot easier to store in a box.

Serialization works really well, you just serialize your data and write it out to a file, then when you want to use it again just read it out and deserialize it and it’s ready to go. The only problem is that if the structure of any of the objects change after serialization then you can’t read the objects back out. It would be sort of like if you went to watch one of your movies on VHS, but the format changed, now we use DVDs and all you have is a DVD player, so you have to throw out the tapes and get disks. Compounding the problem is that I store all of my game data in a single file. So if I make some structural change to any object, no matter how insignificant, I lose all of my game data and I have to renter it, which is a real pain.

I decided to do something about this. Not only does it make things difficult for me during development, but after I release the game, if I ever made a change to any of the payer data objects then all of the player’s saved games would basically be deleted. Which would probably get me strung up. So how do you hold on to your data when any changes could destroy it? You could refrain from making any changes, but that’s basically impossible if you plan on making any fixes our improvements. I finally settled on the solution of reducing all of my game objects to sets of objects that won’t ever change. There are very basic types of data that aren’t likely to change and if all of the data I serialize is composed of these types then I shouldn’t ever run into a problem reading my saved data.

So I have all of my objects reduce themselves to basic data types that won’t change and I save that to a file. Then when I pull it back out I hand the collection of basic data to each of the objects and they know how to rebuild themselves from it. This not only protects against changes in the objects, but also means that if I do have a problem then I only lose the bit of data that had a problem, while everything else is restored just fine.

This should make development easier as I don’t have to worry about all of my test data being destroyed. It should also prevent an angry mob of gamers showing up on my doorstep because I lost their saved games.

I’ve been doing some thinking about the battlefields recently, for a couple of reasons. First players are going to be doing a lot of fighting, and it’s going to get old pretty quickly if you’re always facing off in a big empty arena. And second, I’m setting up the scripting so that hopefully events will be able to occur in randomly generated battlefields and still make sense. So suppose that you have a story event where you get ambushed, the mission scripting will have to be able to specify a ‘ambush position’ for the enemy ships without having any control over the layout of the battlefield. So if I can generate an interesting battlefield with built in ambush positions, etc. then the scripted missions will be able to work with whatever type of battlefield they are given.

So, to that end I did a lot of thinking, what sort of structure does a good battlefield have? My first thought was to do something like what Spelunky does with their randomly generated levels. It’s some pretty clever stuff, but it didn’t take long to realize that the layout that makes a good platformer level is very different from what makes a good strategy battlefield.

So my next thought was to take a look at levels in strategy games. I took a look at multiplayer maps for Command & Conquer and Warhammer: Dawn of War. But again they serve different purposes. In multiplayer strategy games a lot of the game is capturing and holding resources, which requires several resource locations that are interesting to capture and hold. But my game doesn’t play like that, you don’t have any resources on the battlefield, you enter the battlefield with all of the units and resources you will ever have.

Finally, I realized that the best comparison would be the single player maps for games like Warhammer: Dawn of War II, especially the maps from Retribution. And those maps are essentially mazes. Which really works well, all of the battlefields in the game take place at jump nodes, where ships jump in, move a relatively short distance, then jump to the next point. One or more entrances, one or more exits, sounds like a classic maze to me.

Which is a really long winded way of saying that I started looking into map generating algorithms for generating the battlefields. And I found this lovely page that describes a multitude of algorithms, along with their strengths and weaknesses. I know you’re dying to know what algorithm finally ended up choosing, and it was Wilson’s algorithm. Chosen primarily because it generates all possible maps with equal probability. Which is really a pretty interesting property if you think about it.

So, after an implementation frenzy, I told it to generate asteroids, and got the following results:  Asteroid fields with sharply defined corners, very natural looking. After a bit of tweaking to round out the corners I started getting results like the following:

It’s a bit better, especially when you’re not viewing it from a distance. Up close it looks quite a bit better, and more confusing too, which is good, I think. From there it was a short jump to have it vary the size and density of the rocks, as well as the occasional field of deadly space gas, and it looks like this:Honestly, it still looks kind of funny, again up close it looks better, but still not quite where I want it. Still, it’s been fun, and it’s looking promising, and it’s pretty fun to fly ships through. Next up is to have the maze generator add multiple paths through the maze, which should make it more like a field of random debris and less like a contrived obstacle for you to bypass. And some efforts to get it to look a bit more natural.

I spent some time this week doing some more work on the random encounters, trying to get it to behave the way I want. The way I wanted it to behave is that there are many social factions in the game, and each planet has an affiliation with a particular faction. The closer you are to a planet of a given faction, the more likely you are to run into one of their ships. I wanted it to fall off pretty sharply so that you would be fairly likely to run into ships from the faction when you were close to the planet, but then extremely unlikely when it started getting farther away. I also wanted the likelihood of meeting a ship from a faction to be higher if there were several planets from that faction close together.

So I determined upon a solution where after the map is created, each planet updates all of the nodes in the map with a ‘presence’ value, based on how far away the node is. Once all of the factions have contributed their presence to a node, I use the total faction presence to calculate the likelihood of encountering a ship there, and the approximate strength of the force that you are likely to encounter. I dug up some equations that would give a nice slope, decreasing the presence, but never quite hitting zero presence. The presence curve looked like this:It’s got a rapid fall off, with a long tail, pretty much what I wanted, but when I added some code to visualize how likely you were to run into a particular faction, I got the following output:The green circles around planets mean that the planet belongs to a particular faction, and the green half circles show how likely you are to encounter a ship from that faction at the given node. Notice how it doesn’t matter how far away from the planet the different nodes are, the probability is basically unchanging. I did a lot of tweaking of the numbers being fed into the equation, but nothing really seemed to help. No matter what, the probability was basically the same across the board.

I figured that it was because none of the nodes were close enough to the planets to take advantage of the high values at the start of the curve, they were all basically stuck in the long tail where there wasn’t a lot of variation. Fortunately, I finally stumbled upon a solution, I squared the input distance, and used that rather than just a straight distance. With a little tweaking that rendered a presence curve that looked like this:As you can see the graph goes for a ways before it starts dropping off again. This also gave me the following result from the game:You’ll notice that there is a large disparity between the areas close the the planets and the areas far away from the planet.

I’m continually amazed, and pleased, at the wide array of skills demanded by game development. Before now, I’ve never had to search through equations and try to grasp the way that numbers interact with each other in order to come up with a way of modeling a desired behavior. The opportunity to learn and apply new skills is just one of the awesome perks of working on a game in my spare time. You should try it, you’ll love it, I promise.

One of the very valuable things that came out of the indie game sneak peek a couple of weeks ago was the ability to watch people interact with the game, and see what they tried to do. Like people typically tried scrolling the map by moving to the edges of the screen, rather than clicking and dragging as is how it currently scrolls. The two that stood out to me most though were: first, that the movement interface seems to work pretty well. As I mentioned before, most everyone who spent a couple of minutes with it was able to grok the way movement worked, and had little trouble getting their ship to go where they wanted it. I think a good tutorial would take care of any confusion. So that’s something that I did right.

The other thing that stood out was how poor the ship equipment screen was. Most people who visited it looked at it for a few seconds, potentially tried clicking a few things, then left confused. The few people who ended up using it could only do so with me walking them through every step of the way. Which is pretty bad. So I spent some time this week fixing that.

Previously equipping a new ship part required you to click the part you wanted, then click the ‘equip’ button so that it was toggled on, then click on the spot where you want to mount it, then click on the ‘equp’ button again to toggle it off. There was also a buy button, it would send the part you had highlighted directly to your inventory, rather than putting it on the ship. That confused everyone. It was a mess, even I thought it was clunky when I used it during testing, but it was really easy to write.

Anyway, I spent some time this week fixing that. It’s all drag-and-drop now. You parts from the store onto your ship to purchase and equip them. You drag parts from your ship to your inventory to store them, or from your ship to the store to sell them. You drag parts from your inventory to your ship to equip them. It’s all so much easier, and honestly it ended up being a lot easier to code than I was fearing.

Anyway, it’s obvious when you think about it, but it’s still easy to forget just how opaque your interface can be to someone who doesn’t spend dozens of hours working with it. Oh, I also added missiles, they are pretty cool looking. I’ll put together a video at some point showing them off. Someday. Probably.

This week I spent time on the power management system, it was kind of working before this point, but it was buggy and had way too many sharp corners on it. Fortunately, it’s working pretty well no. Basically during combat you can double click on any of your ships, and you’ll get a screen like this one:It shows all of your components, how much power and heat the ship is producing, and how much power or heat is being used. In the picture you’ll notice that there are fourteen units of heat being generated, and none being used, since the ship has no heat sinks. Also with all of that extra heat the ship will cook itself pretty quickly. The idea here is that you can load up your ship with more systems than you can actually power all at once, and only turn on the ones you need at the moment.

Along with that I’ve also been doing some debugging. One of my favorite bugs is when you’re trying to find the angle between two vectors, and the vectors are supposed to be on the same z plane, but they aren’t, so you always get weird angle measurements off of them.

In other news I also purchased the domain flamewarriorgame.com, so you can go there for all of your flame warrior news needs (you’ll just end up right back here at the moment).

So, not a big update, just long enough to leave you wondering if this is actually better than three months without updates.

Yesterday Tripleslash Studios was kind enough to host an Indie Game Sneak Peek where they invited local gamers to come out and preview some of the games being developed by local indies. I was fortunate enough to be able to show off Flame Warrior (that’s what I’m calling it now, by the way) and get some great feedback.

Here are a couple of screenshots showing off what I’ve been up to for the past two silent months. Here’s some basic combat, and you’ll notice a lot of new things going on, and even a few things that weren’t on display yesterday because they were too buggy. I added health bars to ships, in the form of those inner circles around the ships. They shrink and turn scary colors as ships get closer to exploding. I also added armor, which is being displayed by those gray quarter circles around the ships. Each ship has front, rear, left, and right armor that can be equipped and repaired separately. You’ll also notice the green outer circle on some of the ships, that is a layer of shields. Finally, there are some brightly colored puffballs on display. Those are clouds of space magic that do different nasty things to your ship. I don’t remember what all of the colors do, but they do things like damage the ship hull, drain shields, corrode armor, even add heat.

Which reminds me of another new mechanic not featured in any screenshots, because it’s still really buggy. But it’s the ability to turn ship systems on or off to balance power requirements, and to balance heat output. Components output heat, and if you don’t manage it correctly it will build up and start wrecking your ship from the inside.

I also updated the movement controls somewhat, they still work the same way, they just look better now. You’ll also notice the partial green circle, that represents your rotational freedom, so it’s much easier now to see what your acceleration needs do to your ability to rotate.

Overall it was a great experience, I got a lot of good feedback, lots of people really liked the combat mechanics, which is good. It was very encouraging, and I really appreciate Tripleslash for setting up the event, and everyone who came by to play the game.

This week I read a postmortem for the game AI War. There are lots of interesting numbers and graphs, as per usual in a postmortem, but what really grabbed my attention was his discussion of game monetizing models. He talks about how traditionally someone will release a game, then maybe do a couple of add ons, but essentially they leave the game and move on. But with AI War he has continued to support the game with free content updates, as well as several paid expansions, incorporating player feedback. And the really interesting part is that he has continued to have strong sales over the last four years.

This is really encouraging to me. I really like the idea of releasing a game, and then continuing to develop it, especially with feedback from fans. The space strategy game that I’m working on could be expanded into a huge world, with lots of interesting things to do and interesting people to meet. But it doesn’t all have to be done right now. I can release a relatively small game, for a relatively small price, and continue to develop it and add to it. Hopefully the continual development will help keep it fresh and increase it’s exposure.

It’s just a great idea that a game can continue to improve and grow after release, and that just because it doesn’t immediately skyrocket on release, that doesn’t mean that it’s done for.

I was recently reading this article on the escapist. It talks about abduction as a form of reasoning. The verb form is abduce, so it isn’t related to the abduction that’s frequently performed by aliens. Basically, abductive reasoning is when you take two unconnected facts, especially facts that don’t seem to belong together, and infer a state of the world that would connect the two facts. It gets used a lot in tabletop roleplaying. Like when the gamemaster says “Everyone shows up in this town that has a fair going on.” And you say to yourself “Why would my character show up in a town that has a fair?” And you come up with a good in-character reason for your character to be in the town.

Right, so it’s the process of connecting two previously unrelated facts. This is the very process that forms the basis for the procedural stories in Tales of Sigma Draconis. And now I have a name for it. My thought is that if the system can generate loosely related events, like events concerning the same item, or same group, etc. Then the player will use abductive reasoning to provide the causal linkage between the events.

I imagine it working similar to how cuts work in film. Lev Kuleshov was a Russian filmmaker who performed an experiment wherein he took a shot of an actor with a blank expression. He then intercut that footage with shots of other things, like food, a child, a coffin, a woman, etc. It was the exact same shot of the blank faced actor each time, but the audience perceived the actor as showing different emotions based on what the actor appeared to be looking at. The same sort of thing happens with montages, we see a series of shots that are loosely related, by featuring the same characters, or same location, or similar theme, etc. and we view them as depicting change over time.

So my thought is that if you take two story events, that are loosely related, then the mind will abductively fill in the causality between them, leaving the player with the impression of a continuous story. I’m planning on having the world not take itself too seriously, because if the world itself is somewhat strange, then tenuously related events or non sequiturs will hopefully be more easily accepted. In any case, I think that the system can’t do too much worse than many of the video game plots written by actual humans.