The Voronoi Toy I posted here in the last post has been massively improved, all the glitches that I could find ironed out and I threw in curves because those look cool. You can mess with it here if you are so inclined:
Click To Interact
But now I’m getting back to the project that started me messing with these algorithms in the first place. I don’t think I’ve talked about it here yet, it is called Civilian and it is a small turn-based farming sim/wargame.
What I have been focusing on with it is trying to randomly generate some nice looking Risk-like world maps that will be different for every game. The method I am using to do this is basically to feed some random points (with some rules constraining them) into the Voronoi algorithm to generate borders, then doing some recursive subdividing to make the straight lines between the cells all crooked and more organic looking. What’s especially useful about that algorithm for this purpose is that it also generates a dataset called the Delaunay triangulation that tells me which countries are adjacent to which as a kind of free bonus – so this map generation process actually does feed back into the game. Here is a screenshot of my first attempt at generating a random world map generated using this method:
First Map Screen Attempt
That shot is from somewhat late in the game after the various countries have all gone to war with one another. That is functional, which is what I tend to settle for in my games (not being a visual person in the slightest), but in this case I decided to keep trying to get it looking more stylish. I changed the font to something nicer, put a paper texture behind it, vastly improved the fractal border algorithm as well as putting some filter effects on the borders between land and water, and now the map screen looks like this:
Map Screen
It still needs some work! But I’m starting to like it as a starting point.
Site Notes
I have updated the project list on the side to reflect what I’m actually working on right now. I put in a page for Ancients, an Android game project that I have put on hold for now, because I hope to get back to it once this game and Ema are completed. It has a picture of the fancy OpenGL 3D graphics I started messing with for that project.
One of the things I’m working on for a game project is procedural map generation. I have a pretty cool idea for how to do it, but to get there I needed to be able to generate Voronoi diagrams quickly and easily.
So I read up on Fortune’s algorithm, and after banging my head into it for a day or so, I came up with a pretty efficient implementation of it in Flash. I’m sure there are still glitches and some numerical instability, as I haven’t done any rigorous testing of this yet, but since I happen to think Voronoi diagrams just look really fucking cool, the first thing I did with the library is build a little toy that uses it.
This weekend there was (in Europe, anyway) an extra hour. As daylight saving time ended at 2:00 AM on October 30th, everyone’s clocks rolled back in time by an hour and game developer Sos saw the opportunity to one-up all other short duration game jams ever by throwing the 0h game jam to take place right in the middle of the anomaly. A poster and a wonderfully drunken keynote address later and people were off and coding.
It’s worth mentioning that this jam is still going on, as the North American daylight saving shift doesn’t hit until next week – however I participated on Euro time because I saw a few friends jumping in, and I was struck by inspiration that wouldn’t wait a week. I’m pretty sure this is in keeping with the spirit of the rules. I may very well jump in again next weekend when my clock actually changes, if my schedule permits.
Post Mortem
The one thing I’ve learned from doing a few short-duration game jam projects is that they are exercises in compromise. My original design idea was this: A spaceship made of a particle cloud that can expand and contract (I had it in my head that it would contract into the shape of an actual spaceship sprite, and resemble a cloud more when it expanded – this was the first idea to hit the chopping block for the purpose of time) flying through a tunnel full of obstacles to dodge. When contracted, it could thread the needle between obstacles with more precision, but would move faster and be more dangerous. When expanded, it would move slower and hit more obstacles, but each hit would do less damage.
I wanted the level to branch a bit, occasionally offering multiple paths. Walls would show up that the player must contract and punch through, and there would be enemies that the player could expand and absorb. Getting into the realm of completely ridiculous ambition here given the 1-hour time limit, absorbing enemies would fill up an energy meter that would allow you to regenerate your particle cloud or fire off attacks.
I think this design is pretty simple, and would have been well suited for a slightly more sane time limit, like the 48-hour Ludum Dare compo.
I saw the problem with this design as soon as I first looked at my watch after getting the first controls test done. It was already 20 minutes after the hour, and all I had working was the basic ship movement. So instead of a level, I put in a bunch of scrolling squares to act as obstacles and then cut out literally everything else for time. At the end of the hour I had this: Prototype 1
There wasn’t any expansion or contraction, no punching through walls or enemies, no graphics or sound, no score-keeping or acknowledgement of a loss-state, but dammit it had controls and a goal so in the larger view I think it was a success as a 0-hour game. Still though, I couldn’t sleep and just leave it in that state, so I put on They Live on Netflix, bought a bunch of snacks and settled in for a night of coding to see if I could come up with something more presentable before I physically crashed. A little help from my friend with the music, some UI elements and an actual Game Over state and I think it’s actually playable as a game now, even if it still doesn’t come close to the design I had for it. The music, by the way, is appropriately unfinished as well – he sent it to me as a work in progress and I threw it in the build and it was still there by the time I began falling asleep in my chair and decided to post the game.
So yes, even going over the original 0-hour time limit for another 8 hours or so into the night, it is still an exercise in how to utterly compromise on everything. Which I think is a worthwhile skill for me to be building.
Site Notes
I haven’t updated around here in while. The main reason for this is that I have been pretty much the personification of The Optimistic Indie and grinding away on too many projects simultaneously, making no big progress on any of them and pretty much unable to let go and leave some ideas aside. I have 4 projects going right now, and I think I am going to apply some of the lessons I have learned about compromise and drop at least 2 of them for the time being and focus on actually finishing something worth putting out and showing to people.
So, with any luck, more updates here more regularly coming up. With pictures of stuff I’m accomplishing.
I’m currently messing around with a platformer on iPad/iPhone, and I have been trying out a number of different control methods to try to find one that is intuitive and precise enough to make the game fun. I’m still a long way off from finding the perfect scheme, so I would love to get comments from people reading this on what they think works well in other touch-based games.
Here are a few of the ideas I’ve burned through so far:
Prototype 1: Tap and drag
My first attempt was to have the player drag their finger on the screen to make the character follow the movement, and tap above the character’s head to jump. There’s something satisfying in this, at least the dragging part, where you feel like you have direct tactile control over the guy on screen. It captures a little bit of the sense of “magic” Apple likes to talk about with the iPad, where you feel you are reaching into the world on-screen and interacting directly with its objects.
Here is some cellphone video of me using this prototype:
The first big problem with this is responsiveness. Jumping in a direction involves lifting your finger to go tap, then quickly putting it down again to drag, and dragging also turns out to be a lot slower then you would like when the character has a long way to walk. The other problem is that your hand is right over the part of the screen that’s important, obscuring your view.
Prototype 2: Hot zones
The second idea was to use the sides of the screen to move the character left and right, while treating taps anywhere else as a jump. This allows you to move the character while still seeing where he is, and holding down in one spot to keep him going in one direction is a lot less work for covering distance than moving your finger the whole distance and having the character follow.
The problem of jumping and movement being discrete actions still exists, though. In order to jump in a direction you need to either tap then quickly move your hand to a hot zone and hold, or use two hands.
There’s also the issue of feel in using the far opposite sides of the screen to move left and right. It makes precision movement, like trying to land on an object as you come down from a jump a very difficult and awkward feeling, as you tap each side of the screen slightly for small adjustments.
Prototype 3: Swiping and analog hot zones
What I wanted was for the player to be able to guide the character with one continuous touch, moving their finger left and right to make adjustments in movement or to be able to hold the edge of the screen to walk in a direction without stopping.
By increasing the hot zones so that they fill the whole screen, with half the screen corresponding to each direction and the character in the middle, you can hold your finger down and pull it from inside the right hot zone to the left hot zone to reverse direction without feeling like you are doing two separate actions. So if you are descending from a jump and trying to land on a point, you can aim easily without doing a series of small discrete taps on opposite ends of the screen to adjust the movement. I also made the hot zones analog, so that holding your finger closer to the center would make you move more slowly, while touching near the edge would move you more quickly.
The biggest problem with this method is how to work jumping into it. I wanted the player to be able to hold their finger down for the entire movement, without making them stop moving in order to tap the screen and jump. To accomplish this, I made the jump action into a simple swipe that can be done at any time. To be honest, after my attempt at gesture control in Forest Fight, a game which is interesting to me personally but that utterly fails whenever anyone else tries to play it, I was worried about how this would feel when I built the prototype.
As it turns out, I think it works very well and solves all the problems of jumping from the previous schemes. You can be moving left and swipe your finger upwards to jump, while still keeping the leftward movement going. So now movement can be one long unbroken input, and jumps can be given direction just by where you are holding your finger when you swipe upwards.
This is all completely work in progress stuff, and there will likely be a lot more iteration on the control (as on every other aspect) before this game comes out. Actually testing this against other non-me people will be absolutely essential in getting it right, I’m sure.
So what do you guys think? What games have you played that tackled the touch input problem really well? What ones did things in a way that you hated? Let me know!
So alongside the competition, Ludum Dare also does a simultaneous jam, with easier rules on collaboration and 24 extra hours to finish up the game. When pneuman made me a track I knew I had to put it in the game, so I quickly built another version of it for the Jam (leaving the original competition version of it where it is unchanged for the competition voting).
I also added character sprites which make the game very funny to me when they are flying through the air. Looking at it now I really wish I had taken the time to do this during the competition for the main version. There were a few minor changes, fixing a bug that lets you skip levels and adjusting the mix on the boulder sounds to be far quieter compared to the others.
And I put the game up on Kongregate, just as an experiment since I’ve never tried that before. You can play it here:
I made another game for the Ludum Dare 48-hour compo.
It’s called Waterfall Rescue and you can play it here.
I wasn’t completely sure if I could finish this one in time. It was touch and go throughout the second day when I wound up rewriting my core mechanic over and over again trying to make it feel natural and fun. In the end, I managed to complete it right as the buzzer sounded (as of now, about 15 minutes ago), and I’m actually pretty happy with the results.
I built and posted playable prototypes over the course of the weekend, and got some very valuable feedback both from Twitter and IRC. Thanks to everyone who played those and responded! The final prototype was in fact very close to what I ended up submitting, I used the last two hours to build a better tutorial and add a much-requested Mute button to the game (press M or click the icon on the upper right.)
Now to get some sleep! Then play everyone else’s games.
Ludum Dare, the completely crazy 48-hour game jam that happens every 4 months, is starting in about 11 hours – about 9 PM in my time zone. I am going to try, unless there is a catastrophe of some kind, to participate this time.
The last time I participated in this was Ludum Dare 18, with Flinger. Somehow that made its way up to the top spot for innovation, which felt pretty good. I’m not holding out hope to top any of the categories this time, but whatever the theme turns out to be I’m sure it will be fun to do. What is really great about the whole event is all of the people who take time out to play your game and give you good, honest criticism on it at the end of it all. That is probably the most valuable thing a developer can find on the internet.
I will be blogging about the development process of my game using their site once it’s started, so you can follow along with that here if you are interested.
A couple of updates on Ema, just to make sure everyone knows I’m not dead.
Tools
This game is the first game I’ve ever tried building a tool for. The levels for it are stored in big XML files, and at first I was editing all of them by hand. Doing it this way, I’ve managed to build two kinda-okay maps, but it is an incredible amount of work – and difficult to tweak when I want to change things. So I’ve set out to learn Adobe Air and use it to build a level editor to make the job easy – it still needs a lot of work, but here is a quick video of me building a small demonstration map which would have taken me quite a long time by hand in 6 minutes:
A few notes about that video: I don’t have any controls in the editor yet to place units and items, I’m still putting those into the XML by hand after generating the base landscape from the editor. This will probably change soon. Also, all the tilesets in you can see in that video are placeholder stuff, to be replaced by better graphics as I am able to create them. The tree was stolen from Google image search, so don’t give me credit for that one.
Setting a scope
Looking at the scale of everything I’ve got planned for this game versus how fast I’m actually producing content, I have started chopping like mad. Basically, my plan now is to release this as the first of several episodes. I’ve got the main outline for the campaign chopped up and this first episode calls for ~5-8 levels – more complex ones than the one up there, but hopefully with some good tools they will be similarly easy to create. This will pretty much help me limit everything I need to create – for the first episode, I’m planning for around 15 item types to equip on your troops, and around 10 spells to learn as you level up.
The biggest hurdle, of course, is still all the content creation. I’ve been busily working on real tilesets to replace the ugly placeholder ones I’ve got, and building characters in Blender and rendering out their animations. Attempting to jump into 3D animation has been a major adventure, and once I’ve got some better stuff to show I will definitely be writing a post up about some of the things I’ve learned there.
So now I’ve got a plan, and it is much clearer than it was before. Hopefully this will help me make more steady progress on the game, which in turn will hopefully let me update this site more regularly. Until next time!
The So Many Rooms game jam is this really cool idea, where they took a whole ton of flash game coders and had each one of them make a room in 36 hours, then put all of those rooms together into one gigantic continuous string of game. I couldn’t resist jumping in and making a room myself.
The music in my room was done by the awesome pneuman.
Long Overdue Business
Alright, I haven’t updated here lately with my progress on Ema. This is mainly due to a prolonged period of post-holiday procrastination, but know that I am still working on that game and I will be posting some awesome videos of what I have built since my last entry soon. And probably looking for people to help me test it out. Soon.
For now, though, I am going to catch up on all that sleep I missed due to the game jam this weekend!
