Hi everyone ! Because we really love finished work and because peoples are wanting to play our game but find it too difficult we decided to make the enhanced version in two difficulties (Easy & Hard) !

In comments, people said that they really loved the music. Thanks everyone, it’s a pleasure to read this kind of comments. Because you loved it, we have decided to make it available to everyone. Feel free to use it or just listen it but if you want : you can leave a comment on our post to say so ;).

All the download/play links are available Right here on our post !

Bonus, a walkthrough video with the entire history (alternate ending also) :

About the HUD of body resistance :

I’m pretty glad about the simplicity of this hud.

To remember, in Evolvorous you evolve in differents environnements to adapt and transform your species in order to survive.

To know where your species can move, we made a special hud showing the resistance of your body to an environnement because when your species walk onto an environnement, she takes damage if she’s not prepared to live in. Logical.

In this HUD, the middle green cube show the default environnement (plain) where all the species can evolve without trouble (except with enemies :)).
Each of the others cubes show an environnement where you will adapt your body in order to survive. So when you can survive to train your body resistance to an environnement, a new cube appear and a part of your body evolve ! The limits are in the amount of resistances/cubes that you can get because it’s equal to the numbers of parts of your body you can change. And it’s 3.

I will probably develop this Hud in future games, because it’s clear, easy to read and simple.

To test it in game.

My pairs and Me

This Ludum Dare 24 was my second participation to this great event. I totally love the principle of the LD compo. I think it’s all about find a simple and effective concept, that we can lead as far as possible, and polish at maximum to provide players a lovely little sincere and fun experience. We shouldn’t go into something too complex, ‘cause 48 hours is kinda short. So find a concrete idea and go for it !

The fact is this time the theme was Evolution. Not a bad theme, I think instead it’s a word that speak a lot and bring many ideas quite easily. Maybe too much and too easy. I wouldn’t do anything too obvious about evolution, especially since I was already working on a project on this theme outside the Ludum Dare. So when the theme went out I was like AOW NO, NOT AGAIN…

Finally, I started coding without knowing where I was really going. I wanted to do something about evolution in society and in environment, and about religion and leadership, with humor and things… Gradually I went on something finally too complex, with random behaviour in ten guys who tend to evolve differently depending on a number of features and action YOU messiah do. In fact it was really not concrete, and it became a sandbox experience, I think.

Sandbox here I mean there is no goal, exept the goal you want to reach. And regardless what your goal is, you have to experiment, try, restart again and again. Then, you’ll begin to understand, maybe, how it works. It’s an experience for curious and patient gamers, and I wish the players have fun trying to understand what the huck is happening.

Reading the first comment on my games, I understand the side “WTF happens ? But I laughed !” is working. And I’m happy to see that the overall incomprehension can provide some kind of fun. On the one hand, evolution is not something very “square” and concrete, obvious, so the incomprehension in the game could be a part of the experience. But I don’t want people to think that all this game is about random events you cannot influence, and that’s why I’ll try now to explain how some secret mecanisms in the game work.

To summarize the game first, you control sort of prophet holding a stick that can throw lightnings to dig or punish. You live on a small island with 10 of your pairs, who’re not holding a thunder stick but who live their live on this small randomly generated world. Each of them have somme kind of personality, with different value of violence and fear. All of them tend to happyness, but violence and fear decrease the happyness. In the game, more people have free place to move (that means a dirt block with 2 free block above), more they are happy. Plus, more big they are, more happy they become.

So ok but what happyness is about ? Happier they are, more the guys have chance to find a job. There are 3 job in the game : Farmer, lumberjack and fisherman. The farmers plant wheat that can be eaten by other guy who become bigger (and happier, you follow me ?). Lumberjack go choice a tree and they huh, turn around it. Fishermen go to a water point and begin to catch fish.

Other points…If a guy stay too much time in water, he becomes a fish. If a guy stay too much time in air, he becomes a bird. When you destroy the house of a worker, or a tree of a lumberjack, the guy becomes a rebel, and start to follow you and beat you to death. If there is not enought space in the island, there’s a chance that some people become rebels too. More a guy is violent, more he has chance to hit a pair. When a guy is beaten, he becomes more violent. A lightning in the face decrease the violence but increase the fear.

I realize that it can still a bit confuse, but hey, that’s how is the evolution, maybe…I just want you to understand a bit more the not-concrete system of this sandbox experience. The goal still yours. Do you want to make a peacefull place with golden wheat fields and happy lumberjack ? Or an oasis with fish family ? Or a bird colony ? OR PUT ALL THIS WORLD ON FIRE ? In fact you can do lot of things. If I had more time, I would have added more jobs and animals, and behaviours and things, like a rebel master stuck in a bunker and shooting around everything that moves, lava blocks that throw fire particle, meteor shower and all…I think this is a kind of experience, like most of sandbox experience, that becomes better with more content and polish.

Anyway, sorry for my broken English, I hope you’ll have fun playing this crazy game/experience/sandbox thing, earing the crazy sound and enjoying the crazy bugs, and thank you and I love you all awesome people =3

My pairs and Me

This JAM was really interesting and a great way to see how we can work effectively to reach a little game :).

Like the most of us, we weren’t searching about succes but more about challenge, fun, testing ourselves and getting comments on our work to evolve ^^.
Evolvorous is available here !

Let’s see how Evolvorous evolved :

Basic construction of the map

Putting some elements to making this more diversified

The map real size with many hex. Many hex in this game creation !

Putting the first grapbics of the snow environnement

Adding others graphics to see how this could render (even if the graphics willn’t be used, they can construct the idea)

Adding a new graphic for the snow

Tree graphic for snow

Adding the desert’s graphics

Adding some old monsters to work on characters placement

Adding the fog of war to hide the other species/enemies

Adding the swamp’s graphics

Adding the volcano’s graphics

Changing the size of graphics for a better rendering by reducing number of hex on the map

Adding the plain’s graphics and changing the testing ressources graphics  and changing to those provided in the game

Random placement of graphics for the ressources used for food

Adding the first monsters ! It’s the monster for volcano species

Adding new species !

All the species are created and they can be merged

Defining how the species should look like when the player escape or attack in his way of gaming

Polishing the species with more beautiful and harmonics colors.

Working a bit more on food ressources

Adding new graphics to represent how carnivorous and herbivorous should look like when they eat food.

Duck mouth for the herbivorous and mouth teeth for carnivrous.

Final polish onto all the graphics

Adding the HUD

The final render :

Hey all,

I know its a little late to write a postmortem about Collect (game about collecting and evolving) but I was busy past few days on work so I didn’t have the chance to write here

1st Day (6 hours of work):

First of all how the game idea pop out?? that’s was pretty strange as on the first day I found someone posting a picture about his game (I don’t remember the name of the game nor the user right now) but the image was blue background with white box around it and there was some white circles in it and some drawn lines. I didn’t know what his game about but when I saw that picture I remembered an old game by Scattle called Constellation Chaos, it was sponsored by newgrounds at that time and it had a nice track by Souleye (musician behind VVVVVV) go and check it (link) it is worth checking

So I started thinking how could I make a game so I told myself why I am not a shooting star and leveling trails behind me and these trails will cause me to reflect with it. and my goal is to kill all enemies and I get experience every level where I can evolve my shooting star (at that point I decided there will be moving enemies and they are killed if the collide with my trail like in constellation chaos and I stop from jumping when I hit a + sign on the field so I can re-jump again)

So I started to make my engine for checking intersection and reflecting the player, I wrote the physics engine but there was a bug I couldn’t figure out at that time so I spent around 6 hours trying to make a shooting start that leaves trails behind it and it reflect with this trails if it hit it, but that doesn’t work which was bad.

So I was upset and I had a meeting with some friends outside so I decided to go out and when I returned I got to the bed early to get up early and try again with my engine before using Box2D physics engine.

About the art style I always been fan of simple figures with some awesome effects you can check most of my games since I started all use that (because I am not so good at drawing art especially making animation) so I decided just some simple figure (lines and ball) and since I love to make an overlayer to add effect to the graphics that makes the game looks nice and before LD48 I was talking with Noel Berry about the scanline effect he made in his game and he said it is just an image no special effects and send the image to me so I used that scanline image effect to add to my game after making some modification on it

2nd Day (12 hours of work):

I started at the early morning straggling with my physics engine but I figure out it is not worth all that and if I keep struggling I will waste my second day without making the game so I decided to try Box2D and it was my second experiment with it and most of time I didn’t know what to do and I got lots of bugs but I figured out most of the issues and make the engine works very nicely.

After I finished that I started thinking what to do next so I decided to remove the idea of enemies and start deciding what are the upgrades in the game so I got 4 types of upgrades (speed, distance traveled, bouncing) but since I removed the moving enemies and any moving platforms so the speed is now useless so I decided to fix it and keep the other 3 upgrades.

At the beginning I was deciding that the upgrades will be shown after each level and on death but a spark ignited in my mind a decided that only will appear if I die so I can improve that generation and produce a new one and since the new generation made is new so I decided to repeat the levels again as if it is a real experiment and new creature better than old one is evolved and to be sure he is good we must re-evaluate it across all tests.

Since the enemies are removed so I changed the level goal to get all the + signs in the field and told myself to make all the tricks in the bouncing.

After finishing everything in the game except the game levels I decided to make 10 levels at least but while I was developing the game I find out it is very difficult to play the game and the bouncing is very difficult to be predicted so I decided to cut the levels to 8 levels and none of them needs double bounce or more to solve a level

What I think about what happened:

Using Box2D was something amazing it is very efficient and I am glad my engine didn’t work as that make me learn and use Box2D and figure out how much it is awesome.

Working on game for LD48 is something amazing and having small time frame caused me to get a small nice idea that is weird and nice at same time

Wasting a lot of time in developing my physics engine left me with small time frame of one day to finish the game where this limitation caused me to change the idea to a better form (in my view)

Like Petri Purho (guy behind Crayon Physics Deluxe) said having limitations and being poor is something nice and not bad in lots of time (link to presentation)

Thanks for reading and Plz Check the game and rate it, Hope you like it

Collect: Game about Collecting and Evolving

It helps to stay relaxed when making a game all on your own.

My first Ludam Dare/game jam/non-tutorial aided game, and I gotta say, this was a blast! I asked a lot of seasoned game devs in my city for tips, and at the top of the list was scope. So the first thing I did was to get things moving on screen! I didn’t even write a design doc, I just drew one, and even then it wasn’t much to begin with.

Yup, this is some wizardry right here!

Once I decided to make the head follow the player character, things started rolling. I added a few obstacles, and a way to progress. All this took about two hours. After that, was level design!

I didn’t expect to have much fun with making levels, but it turned out to be the best part of all. I often caught myself playing for about 30 minute stretches, just testing and tuning for fun and difficulty. By this point I was confident I’d finish my game. That being my only true worry from the very start. Not how cataclysmic my game mechanic would be, not the number of plays it would get, but just getting it finished. That’s one skill I want to hone.

Sprite sheets are kinda satisfying to look at. Kinda.

I can go into more detail, but I’d rather just sum things up here.

Suceeeess(es)

Getting the damn game done! – I wasn’t too sure about this, but the small scope of the game almost ensured it would happen

Coming up with a mechanic that was simple, yet fun. – A rabid rabbit head hounding it’s body, as it grabs food and dodges death on the way. And guess what? You’re the body on the run! I actually feel I can take it a bit further and make a polished game out of it, but that’s for after I make a few more games.

Making all the content myself – I managed to make the music, sfx, art/animation, and coded (simple as it may be). I had no idea what a time sink each element would be! But I learned a lot in the process.

The art! – I can draw just fine with a pencil on paper, or with a tablet on screen, but this time I was confined to the mouse. For I picked a style and toyed with symmetry a bit. this saved me a lot of head aches.

I kicked the editor and agent out of my room! – I didn’t judge myself unreasonably, or start thinking about “the market.”  I just got up each day, and made the game. It was as natural as natural as a kid crying for candy at the super market (whatever that means XD).

To Be Improved…

Even after the successes that have been mentioned above (and more), I still definitely need to gain more command of programming. there were a few things I wanted to add, but I ran out of headaches to spare, during the jam.

The volume of my sound wasn’t as I’d expected! The music was low, for some reason I didn’t have time to look into in time of the deadline. Poooooo!

*****

One of the easiest levels in the game.

Anyway, that’s about all I find worth saying about my game. Please give it a try, and let me know what you think.

Good Jam I can’t wait for the next Jam. JAM JAM JAM JAM

Spoilers! This is the last screen of my game.

Play/Rate

Young Earth Road Trip was my first LD game. I had a great time (for the most part: see Period of Despondency), was able to include all of the major features I wanted, and learned a lot.

What Went Right

• My game plan worked very well. Friday brainstorm, Saturday build, Sunday polish.
• I only had one strong concept idea, but I was able to develop the rest of the story and the game play very quickly once I decided that my core idea was, “YEC pilgrimages to the Creationist Museum.”
• I narrowed my scope early on. The original neighborhood had eight neighbors, plus Miguel’s house at 316 and a few other locations, but I decided to go with the four strongest characters and only have 4 locations.
• Gained confidence in my graphic abilities. I mentioned this when I finished the game, but I thought the real crutch would be graphic assets. But once I got started, the graphics part went very quickly and the assets are “good enough” to convey the story and some of the humor.

What Went Wrong

• Most notably, music. I “scouted out” music tools beforehand and decided, “Oh, I’ll just use inudge.” Somehow, I didn’t notice that inudge had no convenient way to export the song, so when I started working on music about three hours before deadline I realized I was stuck. My computer doesn’t have speakers, so I couldn’t even record a crappy version that way. I didn’t trust myself to learn how to use new software before the deadline, so I ended up pecking out something on piano for the ending (the rest of the game has sound, but no music).
• My Period of Despondency: Early afternoon Sunday I started to wear down. I was tired and I wanted away from the computer. The game was technically complete, but there were a lot of graphics, music, and sounds to add. I didn’t think I would be able to finish the ending sequence, which required a lot of new images. Fortunately, I got a second wind (had to give myself a little pep talk there).
• When I leave an asset, I really leave it. Forever. On a number graphic assets I told myself I’d come back and add detail work, but never did. In the future I’d go ahead and spend the extra minutes polishing up each one before I move on.

The Future
I ran out of time for a few things, like a parallax bus-driving scene and blinking eyes, but overall I was able to include everything major that I planned for. With the exception of adding music and a splash screen, I probably won’t make any changes (and I might not even make those, since this game is a nice time capsule of my current skill level). But I’d like to take some of the things I learned (like how to make the random God hints) and apply them to new games.

Tags: ld24, postmortem

Link to my LD-Entry Firefly

I don’t want to present a list of good and bad things, so I’ll take a bit more of a narrative approach to my post mortem (although english is not my native language)

The Idea – and how bad at drawing I am

This is my first Ludum Dare entry. I didn’t really know what to expect from myself, and the first few hours after theme anouncement, I was constantly switching between a “lets try just to have fun” and a “Lets see what is the best I can do in 48h” mood. I ended up somewhere in between and I felt very good doing things as I did them.

I had a very precise idea for an evolution based theme in my head but I took some time to make up some others to see if I could find a better one. The only one that I really came up with was  “The Darwin Award Game – Kill yourself as dumb and fast as you can” which I gave up on once I told my girlfriend about it and she only shook her head, saying nothing. So I decided to go for the “plants and bee’s”-theme.

I wasn’t really sure what the final mechanic should be like. I only knew that one fundamental process should be part of the game-play: Bee’s pollinating plants and mixing genes following rules similar to mendels-rules.

So the first thing I did was drawing a sketch of what a game-screen could look like. Here you see a comparisan graphics of what the sketch, and what the game that I finally submitted look like: (I am not good in drawing obviously, but for the amusement I’ll add the sketch anyways – and hey! It was 5 AM!).

The Programming

I had decided the day before theme announcement, that I would start with very sketchy placeholder graphics and spend the first 24hours coding. I would then start to create nicer graphics and add sounds to finally do some polishing. I stuck to that plan and dived right into an empty eclipse project that I had prepared with the libraries that I chose (Libgdx and Artemis Entity-System-Framework).  I planned to submit an Android and a java version of my game. That was important to plan upfront because I had to map all interactions to touch-input (at least in my head) when designing controls. Artemis proofed once again to be a perfect match for rapid development like it was required for LD. But I really feel very comfortable with libgdx and artemis anyway. (I ended up messing with the Entity-System pattern a bit when I had no time left and produced some not so good looking code :))

I think it helps a lot not to spend all the time with a new api or tool you haven’t tried before. Why do so many entries choose tools or libraries they never used before for a LD entry? It doesn’t sound like something fun for me (unless you need to give yourself a handicap because any bunch of numbers turn into an incredibly looking, sounding and playing game if you only look at them).

Sunday morning, I finished the last systems I felt mandatory to be present to… yes … to what? I realized in that moment that somehow I was still not really clear on what the gameplay should be like exactly. What I had was:

• Plants, growing blossoms (not really because the placeholder graphics didn’t look like it, but I knew what it could be like).
• Three slots where you could put a plant.
• A weather-system which would randomly spawn snow, rain or heat.
• Plants could die from weather that they were not resistant against.
• Bees were flying from plant to plant eating their pollen and pollinating other plants

If you played my game, this might sound familiar to you, because this sounds very similar to the games tutorial – for a reason.

The Game-Mechanics – or how I would first do something else

Not many things changed concerning the game play. Things that I introduced sunday morning to have at least something to work with was:

• The pollination process got a bit more complex (Mutation was added for example).
• Generic-Seeds that would give you some start-stats and are required to grow plants with new random stats were introduced.
• Blossoms were made harvestable after being pollinated so you could plant them and grow a new plant with the blossoms stats (which are independent of the plants base stats after being pollinated).
• Bees were renamed to fireflies (because bees suck).
• Bees could have stats attached when they entered the game that were random (to bring a bit more diversity into the whole setup).
• The player was able to smash fireflies if he didn’t want them to pollinate a plant with stats he didn’t like

That’s basically it. I didn’t think about what the gameplay would be like anymore because I couldn’t spontainously come up with something and just started to hope that I would stumble about a brilliant idea in the process of creating the assets. So I started creating graphics (I did them all in inkscape).

This is what the game looked like sunday early morning:

I started to work on the plants and played with different background graphics. It was fun to do, but I always had in mind that I still had not the perfect game-play that I wanted.

Another step in the process:

So you have seen in the beginning of my post what the game looked like in the end, so I won’t insert more screenshots. (Pro Tip: To find out what it really looks and sounds like, it’s helpful to play and rate the game ;-))

I finished most of the graphics around 5PM on Sunday (around 10 hours before the deadline) and started to search for the cables that I needed to record from my e-piano to my computer. That took a while (I drank far to many energie-drinks by that time – thats really a don’t. I could hardly concentrate and giggled like crazy for  a while…). Once I had calmed down again I recorded the music for the game (that was really a quick thing, I knew I didn’t have much time to work on it because there were several other things to be done). An hour later I had the music cut, and written a system that would load and play them in the game. I created some more sounds for selections and mutation on plants but ran out of time quickly so I couldn’t record sound effects for the weather or the fireflies for example (Would have liked to do that).

The Wake-Up-Call

Once these things were ready there was not much time left. Maybe 3 hours. I was really pleased with what the game looked like, given my drawing talent and the short time. But I was (and am) very unsatisfied with the gameplay. I mean its all fine, once you read the tutorial or found out what possible interactions are, it’s really playable. There is goal to achieve and there is actually quite some complexity involved in it (The goal is to cultivate a plant that survives 5 minutes) But when I was play-testing, I could hardly achieve that goal. There were two reasons for it:

1. The feedback loop was hardly present. As mdkess wrote in my games comments later: It was hard to figure out how good you were doing.
2. The game was actually to hard. The pollination process was rarely beneficial and you had only a low chance of a mutation to be beneficial either.

But the deadline got close and I knew I had not enough time to change the game to improve point 1. So all I could do was to insert an easy and a hard game mode. The hard game mode has all difficulties left as I describe them here. The easy mode really is much easier, so if you want a challenge, try the hard mode (though I suggest to start with easy mode to get to know the game). The other thing that I put into the game within the last hour before the end of the compo, was a tutorial. I really don’t like what it became like. Obviously I couldn’t integrate an interactive tutorial (which I usually like to do). So its just 10 screens filled with text and some spare graphics to explain everything. There is now a tutorial outside of the game that is a bit cleaner and easier to understand. I suggest to read that one 😉

So I guess now that I wrote so much about it I actually want to do a list :D:

What was gooooood

• Schedule was nearly perfect. Although some things are not as polished as I like them to be, I feel like I really spent my time on the right parts to have a full game done by the end of 48 hours.
• Programming was great. I really did some not so pretty things shortly before submission deadline, but that was not avoidable to get done.
• Idea to game conversion worked really good. Comparing my sketch with the result its actually not that far away from each other.
• Graphics and sounds are much better than I thought I could do.
• Porting the game to android was a matter of 60 minutes. Planning for an android release really paid off.
• Really not many bugs throughout development. If there were some, I found them fast and it didn’t take long to fix them.

What was baaaaaad:

• This whole game-play thing really sucked. Now, a few days later I really think the game-play itself is great, but it’s the lack of communication to the player that prevents it from shining.
• Too much caffeine. I know, there isn’t sth. like too much caffeine – but – yes there is.
• One of the libgdx extensions I used (freetype) has a bug which led to most of the first visitors of my game not being able to play it. Took a while to figure that out. In the end it wasn’t my fault, but I hated that people who wanted to try my game were unable to do so. (It should all be fixed  now).

Can’t think of anything more right now. Maybe I’ll remember sth. later and add it.

So much for my first Ludum Dare. Thanks for reading this, hope you found at least parts of it interesting.

Now go and play it if you haven’t

Best,

Tim

Link to my LD-Entry Firefly

My game ^

Postmortem thingy:

What i did wrong: >Time, Balance, Progress, Evolution.

What i dd right: > Tweening, Lighting (THANKS FOR IDEAS SOS), particles.

Eh, since you’re still here, Feel free to like : http://www.facebook.com/Cellusious

This entry was posted on Thursday, August 30th, 2012 at 10:47 am and is filed under LD #24. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

As I said, I wasn’t able to participate, but I was making a game anyway. The game appeared to be too complicated for time I had, so I didn’t finish it yet.

The game title is “Groundshaker”. It’s a shooter-like game, but instead of shooting, there is throwing! (Of course, I didn’t know the theme) You throw a stone and it lands where you click. It also considers heigth of objects, so you can throw the stone above the wall if you throw properly.

The ability system is also original. You can have up to 3 abilities at a time and you can use them at the same time. So if you use both “Big stone” and “Vertical throw” abilities, you both deal double damage and throw the stone very high (shown below). But is requires much more energy.

And yes, this game is minimalistic. (Most graphics are placeholder)

McPixel is on Steam Greenlight! Help McPixel get to Steam, he needs your thumbs!


Vote McPixel for President!

Hi everyone,

This was our first Ludum Dare entry and we’re so happy with the community response up till now, we’re already giving it a complete sucess mark! We’re just two students from a Computer Engineering degree – me (Ivo) am majoring in Multimedia and I’m going to do a specialization on games; Sandra is going to major in AI and hopefully build something that conquers the world.

Check out the game if you haven’t at http://www.ludumdare.com/compo/ludum-dare-24/?action=preview&uid=15074

So enough of the pleasentries let’s go straight to the point:

What worked:

Pixel art – People keep mentioning that our graphics are great but to me it’s just simple art done in GIMP. Since I’m a programmer thats about all I could do, however here’s a few tips to all in the same situation as me:

1. We’re not artists but if we’re not satisfied with it we rework it. Yes its easy to just draw some cat and be done with it but then we can’t be entirely satisfied with our work, can we?

2. Check and recheck if animations feel real, I can’t stress this enough because this is the point of animations: to feel real – and that can only be seen while playing.

3. If you’re like me, and you’re no artist, then look at images of what you want to draw,  I did that with the tryceratops and I think it looks awesome.

Triggered events – We aren’t here to make extensive compeling story-based games but we can do a couple of interesting things with 2D triggers. If our character passes a certain X something happens. This was our basic storytelling tool, expecially for the ending.

Music – We didn’t do the music, like it’s stated on the credits it was made by Brioskj (from the album Escape To The City), but since it’s tied to Creative Commons by Atribution it’s not Copyrighted. Creative Commons is becoming majorly spread and I think thats great for indie development. The sounds were also licensed by Creative Commons but we were careful not to use Non-Derivative sounds because we might always need to edit them. For more on Creative Commons go to http://creativecommons.org/.

What didn’t work:

Music – The music worked great except it was far too big, not sure if people compress it or stick to one track, the only thing I know is that my game file is huge and can’t be submited to Kongregate u.u.

Pacing – We really wanted to stress out that the Cat moved at different speeds and that Baby Cat was more energetic than Old Fat Cat but, you’re all right, we did overdo it. We ourselves felt it was tedious and frustrating, and despite that being the feeling we wanted to convey – that old age makes us unable to do the things like we did before – it’s still a game so next time more speed (just a bit).

Level Design – This one came as a total wake up call to us, I study game design and production in my free time but I never did level design maybe I should start. And if we had decent level design in the final level players wouldn’t be so frustrated to play with Old Fat Cat because then there’d be something else to focus on.

Well that’s it people, hope our insights help some of you, and we’ll keep on participating on this awesome competition.

And to all who said nice things about our game — Thank you!

“Pre” because the game isn’t actually finished yet…

This was only the second LD I’ve made an attempt at, and as such I think I did fairly well even though I couldn’t produce a submission in time. I still really like my idea, and fully intend to finish it.

I suppose the biggest lesson learned is that I really should know my programming system BEFORE the timer starts ticking, instead of assuming I’ll pick it up fast enough as I go along. That’s a good lesson. Hope I remember it.

One excellent decision I made was to keep my basic idea small and relatively simple, something that actually had a hope of getting itself completed in the allotted time. That’s well worth remembering. Another thing worth remembering is to come up with a halfway decent idea as quickly as possible, and then stick with it, instead of wasting time waiting for a lightning bolt of supreme inspiration. (I need to apply that to my writing.)

I also learned quite a lot about AGS programming, so that was good too. The really biggest A-number-one thing I learned here was related to the reason I ran out of time. I was stuck — absolutely dead stuck — for a day and a half because of a programming error. It turned out to be a mistake so stupidly basic that I’m too embarrassed to say precisely what it was. Eventually some nice folks at the AGS technical forum pointed it out. (Thanks, guys!) But by then it was too late to put the rest of the game together in time. So that’s definitely one mistake I’ll never make again.

Thanks to all the great people here who posted such entertaining updates — and especially to the OVER 1400 PEOPLE (!!!) who managed to put together a whole working game and submit it in time! I doff my hat in humble awe.

Looking forward to trying my hand at the next Mini!

Pre-LD Warm Up

Going into LD #24, I knew that I wanted to create a faster-paced, more “arcady” game, since my previous two entries were a turn-based strategy game and a moody story-based game.  Two weeks before the competition, I decided to do a warm-up based on a theme that NEVER wins the LD voting…Evolution.  So…yeah.

One valuable thing I learned, after a few dead-end ideas, is that while I *love* simulations and that I’m really interested in simulating biology and evolution…it was hard to find the game in literal evolutionary processes because it’s supposed to be rather…automatic and non-interactive.  I couldn’t come up with something that was simultaneously enough of a “game” but also felt like “legitimate” evolution.  Just making a _________ and tacking on an Upgrade system is pretty ridiculous.  If that’s the kind of thing that’s acceptable, then 90% of the games on the market are about “evolution”.

Ultimately I decided that the right thing to do would be to start from a strong gameplay concept and use evolution as a pure story/visual theme, rather than a mechanic.  So for my warm-up I ended up doing an (incomplete) implementation of a Tower Defense game in the style of The Space Game or Creeper World, where you are building a linked network of structures.  You would represent a multi-cellular creature that was developing specialized cell/tissues/organs.

I still think the Tower Defense evolution game would have been great, but I didn’t take that route for the actual Ludum Dare because:

a) I’d already done a partial implementation and I always want to try different things.

b) I assumed that Tower Defense games would be very common submissions. Turns out they have not been, and now I’m wondering if I should have gone for the TD idea because I think it would have proven very fun and popular.

PINBOLOGY: An Overview

In addition to a more fast-paced, arcady game, I was also hoping to do something that had a very “physical” tone (this would give me a chance to really explore the physics engine in Unity 3d, something I have not done before). I decided to go very literal with the physicality and arcadiness and called up my love for classic pinball machines for my submission.

PINBOLOGY attempts to faithfully mimic the components, mechanics, and physics of old electro-mechanical pinball machines while incorporating zones, combos, and special actions themed around evolution. Fun gameplay would be top priority, along with a sense of real physicality.  I wouldn’t have the opportunity to measure the actual physical response of different surfaces of a pinball table in 48 hours (different rubbers, plastics, wood, metals, glass, etc…), nor develop really good shaders, but I would do my best to create something that could possibly exist in the real world.

Five Things That Went Well

1. Livestreaming: There is no better motivation to continue to work well past the point of tiredness/boredom/craziness than having up to 500 people watch you program. It does prove as a bit of a distraction at time, especially since I tried to narrate as much as possible and talk about why I was doing certain things and how I was doing them, but I still wouldn’t trade it for anything.
2. Building Scenes in Unity 3d: I’m a programmer first and foremost, and I get turned on by things like randomly generated procedural content. That sort of thing is not appropriate for a pinball game, so instead I played to Unity’s strength: hand-placing objects.  Since pinball tends to be extremely fussy about exactly where objects are, there was a CONSTANT need to tweak object placement, especially as new components were added in and the overall shape of the tabletop evolved.
3. Building Objects in Blender: This was my first time doing a 3d game with anything more than basic primitives, and I wasn’t sure if I’d be able to figure out how to get everything working, but everything went really well!  I feel that I pulled off some nice 1950’s components (bumpers, kickers, flippers) and somehow managed to make a complete mesh level that works well in the physics engine.  I would have liked rounder curves and there’s one messed up set of vertices on the right-hand side that causes the texture/lighting to look a little wonky in that spot, but altogether I’m counting this as a win. That being said, while most of the objects were also quick to put together, the level geometry ate a LOT of time.
4. Making What I Knew: As with writing a novel, programming a game that you already understand is a huge boon.  I know what components make up pinball tables, I understand how objectives should flow together, and from start to finish I knew what how each feature would need to behave. I didn’t have to stop halfway through and re-evaluate my core gameplay mechanics. That being said…
5. Learning Something New: I see LD as an excuse to try learn at least one new thing. You don’t want to overreach here, but this was my first time using Blender to create objects that I would then use in a game. This was my first time really using UV mapping and mesh collisions. This was also the most I’ve done with the Unity physics engine.  This is significant, practical knowledge that I can draw on for the future.

Five Things That Went Badly

1. Overspecialized Code: I failed to properly general the code for my components, so as a result I ended up writing very similar code many times.  I should have planned things out a bit better so that I could have reused more of my scripts. Not only did this make debugging a pain, and reduce my ability to improve my scripts, it also substantially cut into my available time, which led to problem #2.
2. My Schedule: I’ve always used the same schedule for LD’s, and it’s gone perfect in the past: Friday night is for coming up with the basic concept and doing a rough implementation to make sure it makes sense, with the idea that I can always restart Saturday morning if something proves unworkable.  Saturday is when all major features get developed. Sunday is for polish, like replacing the placeholder art, adding sounds, main menu, GUI, etc… This time, I was still working on major features on Sunday — I was even added the rotating disc 45 minutes before the deadline! I had to do quite a bit of tweaking and tuning to the level mesh, and I had to rebuild the ramp three times to get the look, physics, and just general size and angle where I wanted it.  This lead to problems #3 and #4.
3. Artwork: My art is always going to suck, and I’m not going to freak out about that too much, but there are several things that I wanted to do and could have done which would have *dramatically* improved the game, but I ran out of time.  A slightly better main menu, to establish the theme right away, would have been one thing. By far the biggest thing, though, would have been decals on the table surface to label various features. Real-world pinball machines have this for everything. “10,000 points”.  “Ball Lock when Lit”. That sort of thing.  Makes a huge difference for gameplay, but also theme. Decals would NOT have taken very long to do. Maybe an hour, tops. But time was that tight.
4. Game Balance: This pinball machine is HARD. Many old-school machines are also this difficult (since they were designed to eat quarters), but this isn’t terribly appropriate for the competition.  The Extra Life bar is set a little too high (partially because for a while there was a bug that gave away excessive bonus points).  The DNA targets and Ball Lock area are rather hard to hit, partially due to the width of the table (because I wanted something “organic” looking and also to accomodate wide-screen monitors), and partially due to a last-minute change to the maximum angle of the flippers.  The biggest problem with this isn’t that you run out of lives too quickly (you don’t have to feed it quarters to play again), but rather because it’s very difficult to execute the combos…and that’s where almost all of the theme lives.
5. Theme Execution: Between the artwork deficiencies and the fact that a casual player may never unlock the “Survival of the Fittest” multi-ball, the Evolution theme is not obvious.  To me, this is my largest failure because I’m actually extremely proud of all the “real” evolution references that exist in the game: Extinction events, geographical isolation, genes, etc…  When you trigger a multi-ball, the color of the balls diverges from the parent — and the last one standing becomes your new species (i.e. its color is locked in as your ball color, at least until the next multi-ball). I think these things are GREAT…but they’ll only be seen by people who really know their way around a pinball table. You have to know how to trap balls, how to abuse various cycles, and how to tilt the table at just the right time.  Otherwise?  You just get a green pinball table and no real hint that the theme exists.

Going Forward

After LD, I always dream of developing my game further and turning it into a real, finished project. I don’t know if I actually have the time to do that, between my day job, my existing projects, my YouTube videos, and family time.  But I would like to very much:

• Re-write the scripts that manage the component behaviours to be more generalized, so that components act more consistently and to make it easier to add more.
• Re-write the “toast” (notifications/achievements) system.
• Re-make the level mesh to be more polished, but also narrower (and therefore play a little easier).
• Add very nice shader effects.
• Add considerably more models.
• Add more tables with different themes.
• Add an in-game level editor and the ability to share and rate designs.
• Make a trillion dollars.

We’ll see how that goes.

In any case, I can’t wait for LD25!

In the interest of less typing, first, read my post from last ludum dare on this topic, as it covers 90% of what I want to say right now.

http://www.ludumdare.com/compo/2012/04/27/how-to-ensure-more-people-can-sucessfully-run-rate-your-game/

Basicly though, the short of it is, if your game REQUIRES a setup procedure, or requires me to go out and install some other libraries or runtimes on my system itself before I can play, I will (most other people will too) click the “back” button and move on to the next game in the list of 1400.  This goes for you too love2d people! (ESPECIALLY love2d people!) Even if i did manage to figure out how to get the mess of severely outdated libraries love uses on my system without destroying my entire OS I would still have to deal with the fact that love versions don’t work with games made in other versions, so no matter which one I install it would only work for half the games!  Pack the interpreter for love, it’s a TINY set of executables and libraries, i showed a few people how to do this last LD and it seemed to be a huge success, a lot of people were able to play the game that otherwise wouldn’t have.

To add on to this as well:

* No I will NOT install a different web browser, if your game has issues in firefox I talk about the issues in firefox and rate it based on that, sure chrome may be a better experience in your game but I don’t use chrome.  If it has MAJOR issues under firefox i just leave a note saying it doesn’t run on firefox and move on. I’ve seen a lot of instances of people pointing out bugs/lag issues that break the game and the response basicly being “oh…just test it on chrome”

* No, I will not upgrade my system core (libc, libstdc++,etc…) just because you compiled with the latest git version of gcc and don’t want to take 10 seconds to copy those shared object files into the tarball.  “just upgrade gcc/libc!” as a fix to get your game working, leaving me with a month worth of tracking down every package that breaks and bug testing all my code against a new gcc version is not going to cut it.

* No, I will not install sun java 7.  Seriously, unless you have some sort of HUGE PRESSING REASON to be compiling for sun java 7, set your compile target for java 6, now magially those 90% of users complaining in your games page about “crashes on start” or “wouldn’t run” can run the game just fine!  Also stop using the non-standard java extensions for different sound types included in sun and microsoft’s jre’s only, it breaks your game under the default vm’s on android, linux, and basicly any system using anything but those two vm’s

A few extra tips to add on to the ones in the linked post:

* Linux Games:  on top of what i already posted last LD (READ THAT POST!!!)  another common mistake i’m noticing is distributing the linux games in zip files.  Remember, zip does not preserve permissions! This means that your executable files will not be executable after download, and you simply have to hope that the user knows how to re-flag the file executable. (you’d be surprised! linux is far more mainstream now, the majority of users do NOT know why that file “just wont run”…even in something here like LD) . The preferred distribution format is .tar.gz , i don’t know offhand the gui programs for linux that can create them but even from a shell it’s as simple as

tar -pczf filename.tar.gz /folder/path

* Naming your links:  Please stop simply calling everything “web” it makes filtering for platforms next to impossible, and LD’s search function next to useless.  At least make them say, “web(html5)” or “web(unity)” so that when i’m  browsing html5 games on my android or such every other “web” link isn’t silverlight or unity telling me “lol…i trolld you, i don’t have a web plugin that works on your device!”.  There’s also quite a few games that named their links “windows” “mac” “linux” and all three of them point to a windows executable, sometimes with a blurb that it “hopefully” works under WINE.

* Don’t put things like “sorry linux users”  “sorry mac users” “maybe next time i’ll do html5” or things like that in your description text, it makes your game come up when filtering for those platforms and makes the ludum dare search feature entirely useless.

* Make sure your zip/tarball has a well named folder your entire game is contained under in it, do not have all your files simply sitting on the top level.  there’s 1400 games to test, most games do this properly but a few still do not, if you dont contain your stuff in a folder it will happily unzip all your files all over other peopel’s test directories, generally containing other games we’re testing or want to keep around to try farther/review, and now instead of just having a folder to remove i get to hunt and peck files, sometimes hundreds of them, from the main directory trying not to delete the ones i meant to keep…

Tags: ld24, ld48, protip

Play De-evolution.

This was my second try at Ludum Dare, and in the end it was very similar to my first attempt, Tin World — it’s a side-view shooter where you walk right and shoot enemies. But it wasn’t supposed to be like that. I spent half a day thinking about a game that would use the theme nicely but at the same time be simple enough for me to make and tweak in the limited time. Nothing. Then I started sketching things to find inspiration. Somehow only guys with guns as simplified monsters were drawn. I posted my drawings here, and somebody suggested a gun that would evolve or de-evolve things, similar to the Portal gun. Then I decided to go with similar mechanics to the last time, only more advanced.

The good:

Graphics. Basically, I used the same technique as the last time, but with some more time spent on the details and more character to the main character. I’m rather happy with the effect — the black-and white, sketchy pictures, with a white outline, animated by moving them around — no frame-based animation. It was inspired by the minipato anime, by the way. A lot of people seem to praise that in the comments, so I will certainly stick to it in the future.

Scrolling. That’s something that I planned for my previous game, but didn’t have time to do. No I planned to have scrolling from the beginning, and it’s there. There are some tricks to keep it very efficient even with limited PyGame options, but I think it works quite fine.

Level. This time I decided that I can’t just randomly throw things at the players — they need to have a level that is designed, so that they can actually finish the game. I really like the feeling I get from finishing games, so I wanted to have it here.

Release. Last time I did some experimenting and managed to package the whole game in a single exe file for windows, and an executable zip file for all the sane platforms. I used the same approach this time, and it worked without any problems — preparing the release took me 10 minutes, including booting an old windows laptop for it.

The bad:

Controls. In my previous game, people complained that the controls worked sometimes, and sometimes they didn’t. After some investigation it turned out that people didn’t realize that they couldn’t move after shooting, while the weapon was being reloaded. I introduced that, because I wanted them to think a little before shooting, to make sure they will have the few milliseconds to reload safely, before pulling the trigger. It didn’t work, turns out players just want to move all the time and don’t want to plan their trigger pulling. Fine.

This time I really made sure that you can move around freely from the beginning. I even added some nice inertia effects to make all the movement super-smooth, and I made it possible to move around quite fast. That was a mistake — people complain about the inertia making it harder to control the character. A second mistake I made — despite the experience from the previous Ludum Dare — the energy gun didn’t feel powerful enough, so I made the player character stop while shooting it. Soon enough I saw my mistake — the very first comment complains about “lackluster” controls.

I think I have learned my lesson: never stop the players from moving their characters.

Difficulty. My decision to have a designed level backfired at me. Or maybe it was just that I underestimated how much work it would be to make it. Anyways, the level is much shorter than I wanted, and because of a last-minute change to the last wave of enemies, the game is insanely hard — almost unbeatable. You seem the last monsters were initially very weak (but lots of them), but then I decided to add some variety, and since it’s at the end, and I didn’t have a debug mode, that part wasn’t tested as often as the others…

Code. In my last game, I used some clever tricks to make all the animations and effects easy to code (I used python’s iterator generators for effects). This time I went with a haphazard approach, just doing random stuff that seemed straightforward. The code is a mess and much more elaborate than I would like, as a result. I will stick to the generators in the future, they work really well for this.

In summary, I’m really happy that I finished a game, but a little disappointed that it turned out to be very similar to the last one. I hope to really get a better idea next time. I will definitely stick to this graphics style and iterator generators, but I will make sure you can always move.

First off, thank you everyone for your reviews on my first LD entry “Entourage.” I was meaning to participate for a while and I am now glad that I took the time to enter. It is ironic that I entered at the same time the theme “evolution” finally got its light of day after many years of voting. Lucky me heh! Keeping an open mind during the theme voting, I was pondering on the gaming ideas for each and every popular theme. When “evolution” was announced, I figured I could develop a game with parasites that have their own set of instructions that they could follow after certain things happen. Glad I had finished it, so now I would like to share how my development went!

Things went right…

Objective — My primary goal was to take control on parasites and give them commands to eliminate the bad ones when certain conditions were met. When that happens, it will execute a command with or without the selected target. Overall, I believe my objective was presented clearly, but there are still some clarifications needed to be presented. Although, more could have been added to improve the idea of “Entourage” to give it more depth.

Stability — I did put a good amount of effort for bug checking. The logic for looking through instructions were complicated, but, after taking little steps of a time, I was able to pinpoint the cause and found a work-around. As of now, the commands were executing correctly, there are no problems adding new instructions.

Structure — The parasite’s instructions seems to be running as it should; although, not 100%. More needs to be done to allow certain conditions to be executed properly without cancelling other executed instructions and so on.

Focus — Considering how complex the game was, I only focused on getting the game play finished while keeping graphics and audio at the very least priority. Regards, I wanted to get the user interface prepared so everyone could play the game easily; even if the graphics were a bit plain.

Things went wrong…

Execution — Sort of a hit and miss depending on how you play the game. For me, I take one parasite and add instructions for attacking the bad, and then program the other parasites to follow that parasite. Tedious? Yep. Of course, I was keeping it simple and keeping my focus on finishing the main objective.

Preparation — Unlike other game programming tools, BlitzMax leaves you with nothing other than a few modules. So in order to make information windows and buttons, I had to program them by scratch. It wasn’t hard to do, but it did take some time to get them working properly. Another thing too is using some new things such as using the mouse to zoom in or out and move the field around. It was supposed to be simple, but the math has gotten to fuzzy. After several hours of trail-and-errors and drafting, those procedures seem to work basically well. I could had worked on a few small BlitzMax products before participating Ludum Dare, but I was feeling the need to challenge myself!

Using BlitzMax — I would say that I’m experienced enough to use BlitzMax at the fullest. However, because it had been while since I last used BlitzMax, there were some problems that appeared during development that I had forgotten. One example was to add images with transparency. While I know in general how to add pictures with transparency, “Entourage” doesn’t want to keep the transparency. After trying a few methods, I was already taking too much time doing that. Therefore, I’ve left the background black and added the pictures with black backgrounds.

Performance — It is not a major factor in this case since the game was made on a small scale. I did adjust the number of good and bad parasites to 200 each — making a total of 400 parasites — too see how the game takes it. Yeah, it was pretty slow; so that was why I maxed each parasite to 100 each. I sort of expected that since it was looping through every existing parasite 5 times. I could have definitely find a more efficient way of updating each parasite, but due to limit time obviously, I just let that be.

Too many ideas — Each parasite has its own HP and EXP, but they weren’t used to their full potential. EXP was supposed to make a parasite better at many things, but I didn’t give it much time to work on. At least HP was working as it should, with an advantage to recover after certain hours were passed. Definitely a lot of ideas were cut at the last few hours, but my main purpose was to present the game’s idea. So many ideas at a very little time, making the game watered down to the very last bit.

What’s next for me?

“Entourage” seems to have potential according to you players. Although, I do have another game that I wanted to get through first before I move on. I’ll just say that I’m returning back to my original ways of developing new games and actually enjoy it for once. Meanwhile, I’ll keep “Entourage” stored away and come back when I feel the will to fully construct it.

If you like to see my other games that I’ve made in full, check out… http://www.acoders.com .

Philosoraptor

Evolution for me was the worst choice of all possible themes. The problem was that I thought of evolution as a linear progressing system with no real conflict. But what drives evolution is always competition between parts of system. The reason for evolution isn’t adaptation. Adaptation it is the outcome of the process. The evolving creatures are not aware of the fact, that they are adapting themselves to be fitter in the competition. I thought that it would be interesting to turn this concept upsidedown: so I created advance wars with dinosaurs.

Dinos and Eggs

The game is a turn based strategy/tactical game where the goal is to eliminate all opponents. You move the dino around on a tiled and grid fixed map. When you a dinosaur breaks an egg, it evolves.

Jurassic Crunch

Ludum Dare is always exciting but this time I went deep down the rabbit hole. Even though the produced code is not in any way ‘good’, the whole time I felt in control of what I am doing. Normally when the crunch at the end of day 2 sets in my code quality suffers and due to concentration problems it takes a lot more time to debug stuff. Not this time. Because the idea was quite simple I had enough time for some debugging in the end. That made the game a lot better(=less embarrassing bugs) than my previous entries.

Pixel Rex

Pixelart and retro snes music are always fun to make but I hope to try out other art styles(maybe a bit more ‘serious’ and less cute) in a future LD. However, I had no big problems making them. My trusted set of tools – Pixen for art and FLStudio+Supercollider for music, did not let me down. As a more code oriented guy in real life it is always great to dive in this side of the gamedev process

Conclusion and Future

I am still working on this game and a bugfixed version with added mouse(!) controls is available here. I tried(and still try) to improve everything that was criticized by you guys. I am also planning some boss fight, different levels and more stuff for the future to make this a more complete game.

I hope the fun I had developing translates at least a bit into the experience of playing. Let me know what you think. Have fun testing this little game!

After some waiting, some LD game rating and some more rating, my timelapse is finally rendered and uploaded. GLapse destroyed the quality on the last part of it, but there’s nothing I can do about that now. Anyway, the timelapse is below and my game is here.

Tags: ld24, timelapse

Here’s my gameplay video and postmortem for “EvoWord”. I had a great time, and I think this entry, though not without it’s share of problems, turned out really well. I’m definitely getting better at making complete, if not yet very polished, entries.

Unfortunately youtube squashed the video so it’s a little stretched, apologies.

Evoword Gameplay Video

What Went Right

• Time Management – Yep, I can finally put this one in the “went right” column. I certainly didn’t have enough time, but for once I feel like I budgeted it well and if I had spent more time in any one area others would have been even worse.
• Waiting for a good idea – I had some ideas initially but I wasn’t sure about them, but I thought it through and waited until I had an idea that felt both realistic and fun. I’m really glad I didn’t just go with my first idea, in retrospect they seem pretty ridiculous.
• Making a game that I want to play – I really like word games, even capturing the gameplay video above there are long stretches where I got absorbed in the gameplay. Thankfully I’ve edited most of those out.
• Gameplay first – I had the basic game working with just floating letters and no graphics at all before I started on anything graphical. That’s always been difficult for me to do, but this time I stuck to it and I think it paid off.

What went wrong:

• Overcomplicating the creature evolution algorithm. My initial algorithm seemed simple enough on paper, but as I got to coding it it kept revealing itself as too complicated. The final creatures don’t have nearly enough variety (only size and color scheme, really) . I think I could have gotten further if I started with the simplest thing that could possibly work, and then building on that.
• Testing and Release Builds – I waited until the last hour to try a release build, and it crashed. Because of this I was unable to include the cool floating bubbles. There are also a handful of small bugs that I could have fixed if I had stopped and took breaks for testing every so often. I’ve made this mistake a few times, maybe this time it will sink in.
• Overcomplicated the graphics – I had big plans for the graphics, including blender sculpt mode and normal maps and a shader that wasn’t terrible. I wasted a bit of time on those things, but not too bad, I fell back on the simple creature soon enough. However, those few hours of experimentation would have been better put to gameplay.
• Clarity – It’s obvious to me how to play because I wrote it, but it’s not at all obvious to a player, especially with no tutorial or instructions. In the future, making sure the user is aware of what they can do at every step is going to be my top priority. Even so, this was more discoverable than a lot of my previous entries so I’m getting better at this.
• glBindFramebufferEXT() – I spent over an hour trying to debug my thumbnail rendering code, thinking it was something complicated wrong, when really I just forgot to bind the framebuffers again after the first draw. Always go back and recheck the simple stuff, verify your assumptions and make sure your code is actually doing what you think.

Anyways this was a lot of fun, and I hope I’ll get a chance to go back and add more depth to the creature evolution code and tune the gameplay a bit to somehow eliminate the long stretches of waiting for the right letters. This was a lot of fun, as always!

Jovoc