I wasn’t really expecting to do a postmortem, but due to all the feedback i ‘ve been getting i just said “Meh, why not?”.

First things first, here’s the timelapse and the game in question.

• What went right:

-The concept: Like i always do with most things, once i heard what the theme was  i started thinking ‘outside the box‘, something that no one would think about doing with the current theme….

Luckly for me, i got a great concept 30 minutes in, a heavilly-text story oriented game, something i never even attempted to make before, but i managed to stick with it till the end and the final result was pretty good.

-Coding: Due to my experience with the (not always so great) Game Maker, i was able to program the engine from scratch in only a few hours. Sure its not the greatest engine ever, but it gets all the work done which gave me plenty of time to concentrate on my cons. Speaking of cons…

-Graphics:  Usually, i would put this on what went wrong,  i’m just terrible at drawing but, for some reason, i really like how some of the art came out. Sure, its nothing spectacular compared with most of the games around here, it might even be on the ‘1|2 star type‘,  but I was really proud of what i did.

• What went wrong:

-Sounds/Music: I always have trouble with this part, i tried to make the sound effects myself (using the mic, etc), but i just couldn’t make them properly so, after wasting about 30 minutes, i went for the overused sfxr which can get the job done but the sounds get too similar to most of the games around the comp, but what really upset me the most was the lack of music. Music would be great for a heavilly-text oriented game but, after using OpenMPT for about 1 hour and getting near the deadline, i decided to scrap the music idea which really hurt the game in my opinion.

-’Lack‘ of content: For a 48h game, its quite a lenghty game, with several diferent paths and decisions to choose from, 7 diferent people and 4 ‘zones’. Unfortunately, i planned to have +10 people and 6 zones and 2 more paths but, around the end of the first day, i saw that i wouldn’t be able to do that, which made me rewrite most of the dialogs for the NPC’s, sometimes making them say and give the same quests on diferent paths. And, while its possible to have 2 ‘diferent endings’, they were rushed out on the last minute, something i REALLY didn’t want to for this kind of game…

Aside from all that:

-I was able to finish the game in 48 hours =D.

-About 40% of the time was spent writing dialog for the NPC’s.

-I learned alot on how to handle ‘dialogs’ and ‘scripted events’.

-Music making is not for me…

That’s about it i think.  I might plan to complete the game later on since i’m getting a lot of great feedback, something i wasn’t expecting from this kind of game .

or “What not to do during a compo” xD

Once again I’ve taken part of the Ludum Dare. Last time I ended up really slacking off… So, this time, I forbade me to do anything not related to making a game =D . Turns out this didn’t worked as planned… But I must say that I really had fun.

Though I made a game about a tiny little creature that eats others tiny things (what, in my opinion, doesn’t really have anything in common with the theme… since it’s missing the “World” =x) this wasn’t my original idea. After seeing the theme, I thought about what to do and came up with two ideas:

• backup idea: a game about a tiny creature that is hungry and keeps eating until it grows so much that it can eat the planet, then it would go to another one; (this is a little diferent from what I ended making)
• main idea: explore a tiny world, interact with it’s tiny inhabitant, then [the player would] play in their tiny reality…

I really don’t know why, but I thought the latter would be better. Even though the idea was interesting, when I completed the “macro world” parts I couldn’t think about anything to do in the tiny world… And what’s worse: the game wasn’t fun at all! >_< (at least, I learned how to implement a “random dungeon generator”… or, how I really did it, “random paths between objects in a random landscape” =D )

So, within 8 hours from the compo end, I had something I wasn’t happy with (by “wasn’t happy” read “couldn’t work anymore @_@”). Then I did what any (in)sane person would do: I scraped that idea and start a new project… Since time wasn’t exactly on my side, I quickly remembered the basic feature: you eat things and grow bigger. I also had a new idea: you can jump on things to shrink them. Since I was using Flixel, i didn’t have to remake the core… but I couldn’t reuse anything usefull from the original idea (well, I copied the “control” class… but since I didn’t allow user modifications to the controls… it was kinda useless… xD).

Then, in a hurry, I began doing everything needed: coded, drew the sprites, coded some more… Had trouble comming up with the song xD. Then, with the base working kinda properly, time to design the stages! I ended up doing only tutorial stages and two that should have enemies… but I ran out of time to implement them. =x

Since I rushed so much, I didn’t realize that I forgot to allow the creature (which had already been named Hummy =3) to grow bigger than the world in order to eat it… Anyway, in the end, I was able to work something out that (even though wasn’t exactly what I had planned) I really liked. =D

Next time I must be sure to think throughly about what I’ll be doing… Though I must say (now, after the compo…) that it was fun… it would be really better if I didn’t repeat this. I regret not doing a better game (especially since I know that, had I choosen this idea from the start, I would be able to do something better). =X

If you haven’t played the game, why not play it now? =D

Thanks for reading. =]

Crosspost with my wordpress – seagaia.wordpress.com

This past weekend I made a game, “Naos”, for Ludum Dare 23, around the theme “Tiny World”. If you haven’t played Naos yet, you should do so now, the blog post will make more sense.

http://www.ludumdare.com/compo/ludum-dare-23/?action=preview&uid=7853

The sound.

Aesthetics were very important for me in this jam game. So I tried to pick carefully what kind of music I wanted to write. The game wasn’t supposed to represent a wholly realistic thing, so the music sort of reflects that in a haunting/minimal way (the organ-like house loop, the chime-like thing in the forest). The more action-like piece at the cliff helps to show that there is some action going on there (i ended up redoing this one the most…). As for the intro/ending thing…I couldn’t really think of a fitting melody, so I added some fancy-ass white noise that I thought fit.

I like the chimes piece the most, and would like to expand upon that. I feel like part of it was definitely influenced by listening to the Fez OST ( http://disasterpeace.com/ )way too much over the weekend – especially with the bitcrushing it uses, which I felt I may have overused in a place or two. Two pieces in particular I found salient were Spirit and Nature.

https://player.soundcloud.com/player.swf?url=http%3A%2F%2Fapi.soundcloud.com%2Ftracks%2F44156155 Seagaia – Songs from Naos (Ludum Dare 23) by seagaia

Graphics style…WHY? MY EYES!

Admittedly the game’s blur was a bit much. I did think it suited the quiet/haunting/ethereal-esque nature of the game, though. I wanted to try the scribbly style. Spending more time would have of course improved…well, everything. In a normal setting they wouldn’t be that rushed, I’d use a tablet, etc. Right now, it looks just good enough to not seem completely sloppy. (But is, still, of course, sloppy  )

I was playing a lot with BitmapData objects in AS3 (surprisingly for the first time…why? I don’t know…but now I’ve got a level of comfort). They more or less represent what will be drawn to screen. And you can do interesting things like pull out certain color channels, transform them, and superimpose them on the original graphic. Or, you can blur things at different levels. The way I did blurring wasn’t ideal, I surely could come up with a more plug-and-play way of doing it, rather than the somewhat terrible way I have now (at least it’s organized terribly), which was to copy the sprite’s data, and keep some external data that determines how much to blur it – essentially, I have a copy of the data – I copy it to the displayed sprite, blur it, draw that to the screen, etc. The same idea goes for the color offsets. I played around until it looked okay.

I also played with a new logo for Seagaia today. It shows up on the intro screen. I like it. It’s a bit of a rip-off from. It was fun to make, at least the top part. There’s this nice thing in GIMP where you can copy and paste every other row, and then you make it a bit transparent, modify it a bit and superimpose it to get this neat shadow-y effect.

oh so how was the coding

Straightforward for the most part. Every room was a different state, with its own events and so forth.

Became an ugly mess near the end with the event coding since I haven’t figured out a nice way to do events with flixel yet…want to definitely figure that out. I’ve been asking around a bit, but not much in the way of detailed cutscenes. x_x

Since I already talked about the graphics coding, the only really interesting aspect was the events. How do they work? Well, for one, it helps to draw a tree of your dependencies with state variables. For example, “E_CLIFF_2″ represents the 2nd cliff cutscene, “DRAWING_1_DONE” represents finishing the second drawing. And so every iteration of the game loop, depending on what screen we’re in, we check to see if we need to start an event. Essentially, events just freeze character controls, and wait for some condition (my player’s x being at some point, pressing x to advance text) to occur. Each event has an “event_pos” variable that is incremented when that condition is true, bringing the event to the next part (text, movement, whatever).

While this method works for a game jam, it doesn’t really scale well (see the other game I’m making) when it comes to moving many sprites that you don’t want to have to hard code into the game…and it’s a bit hard on the coder with the repetitive switch statements (see.https://github.com/SeanHogan/seagaiald23/blob/master/src/CliffState.as JEEZUS.)

An interesting bug resulting from this was that I didn’t nest one of the “if you press x increment the event counter” things deep enough, so if a player pressed X before they should have on the forest screen, you would be frozen when you actually pressed X over the right thing. Thanks to my friend Runnan for showing me that issue…gah!

One way this could have been done better is to have only checked for events once upon entering a screen, or have had some single “an event happened” variable to be checked, rather than all of these conditions on every iteration of the game loop. While this is okay because performance didn’t really become an issue here, it would be something to think about in some sort of later implementation.

so what the hell was this about?

it’s a secret! well, a few people have messaged me on NG about it, surprisingly. My interpretation of it is more or less solidified, but it’s interesting to see other people’s takes on it as well. In lieu of not looking all pretentious, i won’t write about it here. but if you’d like to know, shoot me a message.

that’s all for now.

if you found this interesting, you should follow me on twitter . http://www.twitter.com/seagaia2

Well, my Ludum Dare submission contains the whole message I wanted to send, so I’m happy with it. But it lacks a lot of gameplay and you play only for one minute before reaching the end, that’s obviously to short ! So here’s a release with many levels (in fact, infinite levels) and more challenges. I also added some features as a red flash when you’re hurt, some graphics changes so you can see best your player in the middle of the “cells crowd” and some tiny stuffs around.

Have a look and try it ! (it’s also accessible from the same link as the official jam release, just click on the “post compo release” on the bottom)

If you haven’t played our game yet I strongly encourage you to do so. We are hungry for feedback!

Well, ok, is time to do this; post-mortem time!!

(more…)

For LD23, I decided to go full-retro, and make a z80-based game that runs on Pac-Man arcade hardware. I’m not going to lie to you, I didn’t even come close to completing it, and I’m totally fine with that. You can see the “finished” product here. From there you can get the romset (mspacmab – bootleg spaceman, for reasons I won’t get into), the source, and the link to the google code repository that has my Z80 kernel which I used for it. Fact of the matter is, I wanted to do a Z80/Arcade rom game for LD, I did it, and I’m happy that I did. I think I may do this for future LDs as well, learning from each (failure) along the way.

I knew I wouldn’t be able to finish something in time for either the regular compo or the jam, but I wanted to see how much I could get done in time, without going out of my way to devote all 48 hours on it.

I was coming home from a work trip, so if you watch the time-lapse off of the link above, you will see that I’m actually working on it in an airport (in Atlanta, Georgia) as well as on an airplane, along with on the couch at home and at an office desk. I squeezed in as much time as possible.

The main thing that prevented me from getting (a little) further is that I was planning to spend evenings on the work trip i was on, in re-aquainting myself with the tools (assembler, z80 kernel, etc) that I haven’t really looked at in about 5 years. I also wanted to add support in my “Llemonide” z80 IDE/emulator, for building and better debugging. Instead, for various reasons, I was unable to have any downtime at all on the work trip to devote to this project. I was essentially going in to LD completely green on the subject. I spent a lot of time creating the project, remembering how my z80 kernel works, basics like that which should have been old-hat.

So what did I learn? Spend A LOT of time getting familiar with your tools. Do practice jams. Try to minimize the amount of boilerplate stuff you’ll be recreating to save time. You need to spend your time making your game, not fumbling with your tools.

Better luck and progress next time!

As a sidenote, all of the source for mine is available at the page for Tiny World ’82, along with links to the tools/kernel, and the romset. I have included instructions to running it within the Google Chrome browser, in case you don’t have MAME handy. Check it out and review it if you like. I’m just hoping for an non-zero score on this one.

Check out this timelapse for Invasion Of The Trivials made in Unity!

I did it in the style of The Humble Indie Bundle’s Broadside Express Timelapse!

Play the game here!

I’m a student at the University of Oklahoma and we set up a couple of teams to compete in the Jam this time around.

My team was responsible for Science 101: The Sewer Chronicles. (The other team did Spaceships: Origins.)

Originally, we were going to do it in Unity (which the other team managed to do), but difficulty with doing a 2D platformer in a 3D engine caused us to switch to the more familiar XNA. Sometime on Saturday night we all lost our minds. And gained a hilarious voiceover and story to go along with our game.

The Good

• Shifting the main character from a mad scientist to an insane professor worked really well
• Our art asset guy went crazy first and started recording dialogue for our main character late Saturday night
• The other coder decided that making the game as hard as possible was a good idea
• We got a fourth person to write our game description (who did an awesome job)

The Bad

• Spaghetti code, ho!
• Collision is still very buggy
• We lost a day to Unity before we switched to XNA

Things we didn’t get to do

• There were going to be enemies and Professor Searcher was going to have a ray gun (which used his energy)
• Win condition isn’t very good, we were going to have him actually escape from the sewers rather than just collect beakers
• SCIENCE 201!: INTRODUCTION TO DIFFERENTIAL ACID BATHS AND JUMP KICKS!

We had a lot of fun doing this… but now we have to go back to the land of tests and class projects.

See ya next time, Ludum Dare.

Fedor and I made this completely from scratch in three days (with little sleep):

http://www.ludumdare.com/compo/ludum-dare-23/?action=preview&uid=13139
We’re proud of it and couldn’t wait to show this off to you guys! Please spread around, rate and comment

I will now attempt the daring feat of sharing what this experience felt for me, so we can all benefit from it as game designers/developers/artists.

Development notes:

It was exhausting and super fun. I particularly enjoyed composing the music, and how we came up with an interesting gameplay mechanic (teleportation).
Coming at it as equals and negotiating ideas did a world of good for our game. Our main inspiration was the Touhou series of games for Fedor (I’d only seen gameplay) and Ikaruga for me (finished the game several times).

I started doing graphics on Saturday morning. I worked on a mockup photoshop file full groups of layers, to which I returned throughout development. For example, when I needed a new enemy, I would fire up the mockup, draw the enemy next to all the other sprites and then paste it into another photoshop file and animate it separately. I would then export as individual .PNGs (Photoshop’s “Render Animation to Video” was very helpful).

Dropbox of course saved our lives, and we communicated through skype’s chat. In fact we haven’t even seen each others’ faces.
I used Photoshop CS5 for all animation and graphics, and Fruity Loops with free soundfonts to write and perform the music.
Fedor used Unity and I don’t know what else ^-^

Post mortem: We gave it our absolute best. A coding set-back made the scrolling clouds unusable, so Fedor had to wing it at the last moment, which left the background a little bleh in my opinion ( I had no time to make changes to the cloud graphics and scrolling). But even so, when at the last minute he managed to fix the clouds so we at least had some, it was very exciting. The level is very very well thought-out and very fun to play. It took Fedor, what, 6 hours? to come up with the patterns that complement the teleport mechanic.  The 3 hours before deadline were, for me, mostly about helping Fedor out with any requests, like changing sprites or giving him a list with all the visual elements he had yet to implement. I made a second enemy ship graphic in 15 minutes, since Fedor made enemies with two different numbers of hit points, and I felt we needed to be able to tell them apart. This was done 2 or 3 hours before deadline, when Fedor was struggling with the stupid clouds. He added the second enemy graphic in the game 1 hour before deadline.

I also wanted finite lives implemented (9 of them, as many as the tails of the Kumiho fox-spirit), shown only everytime you are resurrected from a death, in order to keep the interface as clean as Fedor wanted it. Scoring wouldn’t have hurt either. But we didn’t have time to even negotiate it, because the ideas came too late. Even if they had come early, we wouldn’t have had time. I stayed up Sunday 12am to Tuesday 6am, and it’s the longest I’ve ever been awake.

So, overall, I couldn’t have wished for anything better, I had the fastest and best coder at my disposal, we had a crazy schedule and working hours, and implemented almost everything we set out to implement, and still had time for a little polish.

Pocket Strife Entry

What went right:

• Git helped me keep everything in order, and even supplied me with a gource! In a Jam, as opposed to compo, git would have been perfectly, but in retrospect, it’s a little superfluous for a compo. I would still do it, as it is really only a few extra minutes of my time, and gives me something to roll back on if need be.
• Being well rested makes a world of difference. I got three or four more times more done on Sunday when I was well rested than I did on Saturday in only double the time.
• Know your tech – using love (love2d.org) was pure awesome, as I knew the API and I knew Lua.
• Bring your own tech – I prepared for this LD by asking myself, what are libraries that one would normall find in games? These are the ones I used from the ones I brought with.
  • Build scripts for all OS’s (This was a blessing. When I was done, all I had to do was run two scripts, and I had the *.love, *.exe and *.app ready to rock and roll). Sure, mine only work on linux, but they output to everything!
  • Love Menu: There is nothing more wasteful than re-writing a god damn menu system. I wrote this one a long while back, and have used it multiple times. It looks good, and is fully scriptable. Build one giant view object, and let the library do the rest.
  • Bar lib – Again, another common element, this code ended up being a one-liner in my main.lua, but it saved so much time and looked so much better than just a random solid green bar.
• Timelapse yourself. It stops you from screwing around much
• Minimal scope is the best scope. Remember, you can always add more later, but you can’t release a game if it isn’t a game.
• Make sure the art you make can be made quickly, and with high quality – I have recently discovered that I can actually push a lot of awesome pixel art out, as long as I only use two bit graphics (4 colors) So I open up GIMP
• Don’t waste time generating! Making some crap from scratch when you don’t need to is probably a big waste of time! ALl you need is a few cases to make something seem random, why does it actually have to be random? I used this fractal world generator five times, http://donjon.bin.sh/world/ and used that as the map system.
• Forget performance, call it a feature, not a requirement. You won’t believe the shortcuts I took to make this happen, but in the end it goes back to knowing your tech. I wouldn’t have had any of these issues if I had know how to do isometric tiles correctly. Reducing the framerate should have come later.
• Stop bitching, and get working! Seriously, I saw so many people wasting time on IRC bitching about the theme. The themes LD gives are so vauge, you can do just about any thing you want. Oh, folks, stop naming your game “Tiny World” please.

What went wrong:

• Know your tech. Working with isometrics was a god damn horror, and caused 95% of my framerate and mouse issues. Use concepts you are used to. This is not a time to learn new tech, this is a time to produce a game you know how to make. In retrospect, I should have made this game in straight 2d tiles.
• Plan more! I should have planned for another hour or so. I found myself making the game up as I went along, and when I started noticing I was making assets and code that were out of scope, and then later removing them, I had to sit down with my notes again, and decide what the hell I was actually going to do
• Make your machine ready for you. Have your stuff built, make sure it’s up to date, and stable. I had about fifteen minutes to rebuild love 0.8.0 from tag on ubuntu 10.04 (and keep in mind, it doesn’t build if you are running 10.04, so you have to do some hackery)
• Kittens don’t let you code much. They seem to think everything in your monitor is real, and your keyboard is for sitting on.

Conclusion:

What this showed me is to participate even if you don’t have time! I did this entire game in 13.5 hours.

Pocket Strife Entry

I’ll start with the part that’ll interest more people….now that I’ve rated 150 entries, here are my top 7! (in no particular order)

Bottlecolonies By tcstyle : A clever little strategy/puzzle  game, the art direction is great, the sound both fitting and awesome, and the gameplay itself is solid and complete…a joy to play

Nanofactory By JustinMullin: A solid puzzle game about a nanobot assembling widgets, a little hard and cryptic at first but the puzzles are both simple and clever

ANT SURF HERO: THE SURFENING By Jigxor:  A refreshing change from the massive number of dull uninspired platformers,  aside from a few physics issues it’s really fun,  and riding on top of the ant is amusing to say the least.

Housefly By dacap: You play as a fly on a mission: to get back outside!  It’s a short but very immersive adventure game with solid controls, great visuals and sound…its hard to describe but the flight control feels “right” for a fly. Very fun.

Recluse By chambers: You play as a snail with a neckbeard in a “metroidvania” type game….but with a twist.  Easy 5/5 for innovation personally, I don’t want to ruin it by the starting room is misleading and it quickly introduces one of the most unique gameplay mechanics i’ve ever seen. (even if it is mostly a gimmick…it fits the theme very well)

Hero of Rain By 31eee384: Extremely incomplete but what there is of it is very enjoyable, the story is both fitting and interesting, the gameplay is for the most part pretty good (though touchy at parts). All around a good feel to this game.

Fusion Time! By NeiloGD: A simple but solid arcade-type game where you fuse atoms in a sun.  Theres not much too it but the explosions and strategy of timing the fusing makes it surprisingly fun to play.

Please try these out if you havent! Most still have a pretty low number of ratings and could use some more love! Also, <shameless plug> I really wouldn’t mind a few more tests on my entry as well, it’ll be linked below with the timelapse and postmortem</shameless plug>

Post-Mortem:

First off, here’s the link, try it out yourself and let me know what you think!

http://www.ludumdare.com/compo/ludum-dare-23/?action=preview&uid=7131

I have to say…I had more fun with this theme than I would have thought, it was a lot easier to make a game that fit the theme but was still….you know…a GAME..than it was for “alone” (LD22)

What went right:

•  My game Idea! I came up with it MUCH faster this time and IMHO it’s a much more fun game than my 22 entry
•  My cross-compilers were already set up, saving me a lot of time testing the windows build
• Using my sprite editor (listed in the tools section to the right) I was able to do what little spriting I needed very quickly with decent results, it was MUCH easier than trying to do it in GIMP (great editor….not so good for animating)
• I planned fairly well what I would have time to do,  I was complete (though had to cut a few units) and able to submit before the rush.
• Deciding early to render with opengl instead of plain SDL was a good call,  I ended up abusing it quite a bit to scale/recolor graphics & text (SDL can do it but it’s so slow it would be near unplayable..).  Having recently written a LOT of OpenGL code also it was pretty fresh in my mind and I was able to painlessly get it up and rendering.

What went…welll…not quite as right:

• Once again, LD fell on a weekend I had to be gone quite a bit, I wasn’t home on saturday till nearly 6pm, so I lost a good 18 hours of copetition time there (seriously, i had NOTHING planned that couldn’t be moved for like.. a month prior and a month after…only that one day)
• I had to take care of some stuff outside friday and was EXHAUSTED after the theme was announced, ended up losing even more time by going to bed early. (though i did finish a opengl renderer + sound system before then)
• I had a OpenGL/SDL/Angelscript based game engine I’ve been working on for quite some time that I was going to use so I could concentrate more on game code….unfortunately I had some last minute issues and there was no way I’d get a windows build of the engine working in time, so I had to change plans and just write a renderer/sound/input engine from scratch during the competition.

And of course, here is the timelapse video! (with soothing music added)

Hello everyone. This was a fantastic Ludum Dare for me and I wanted to share a postmortem for my game, NanoBot Adventures. All in all, this was a pretty good game jam for me. 

Here’s a link to my game:  http://www.ludumdare.com/compo/ludum-dare-23/?action=rate&uid=4263

The Good

Using Legos to build my NanoBot sprites worked out really well. My sons love playing with Legos so while I worked on the game, they built an army of little Lego robots. I picked my favorites, setup an impromptu white backdrop and used my cellphone camera to take pictures of them. I wanted the graphics in the Viewport to have a bit of a grainy, pixelated look to them so I took the original images and in Paint.Net I cut out the white backdrop, saved the file as an extremely low-quality JPG, reopened the file and cut out the white background so I had a transparency again and resaved it as a PNG. This process worked out so well that I will be using it again in the future.

Another good thing was my HTML5 canvas framework. I wrote it a few Ludum Dares ago for the Escape theme and it has served me well. I use JQuery for the UI pieces and it has a very basic Update/Draw game loop. I am planning on sharing it on Github in the near future once I get the basics for music/SFX put in as well. Follow me on Twitter (@mattperrin) or follow the #LD48 Twitter tag and I’ll put it up there.

Another good thing was that my local community of game dev friends (www.clevelandgamedevs.com) really came together for this event. We had a LD kickoff event at a local start-up incubator and collaborated for a few hours Friday night together before splitting off. To keep in contact with each other and show progress, we setup an IRC channel that was used all weekend long. Seeing my peers working helped keep me committed and interested too.
The Bad

I still haven’t gotten sound or music working in a LD game. I tried with this one but I couldn’t quite get it to work properly. I used Caustic on my Android phone to create a chiptune-esque drum and bass song. When I connected my phone’s headphone jack to my laptop’s microphone jack, I either got an ear-splitting loud feedback tone or a barely audible recording of the song. Caustic has a song export feature that I used to make an OGG file but when I tried to get it looping in my game it wouldn’t play. After all of those headaches, I decided to skip trying to do sound all together and focus on some UI polish.

I never got around to adding power-ups or boss fights. I had wanted the exploration of the “tiny world” to be a bit more dynamic. Visiting the Capacitor Forests, Resistor Swamps or LED Ruins was supposed to trigger dynamic events like boss battles, upgrades or NPCs with storyline clues. I ran out of time though and only the basic quest of “Find the broken CPU Chip” were completed.

The Ugly

The Draw calls I use to make the minimap are extremely inefficient. Instead of having a global frame counter and incrementing across the pixel color arrays for each TerrainGameObject I instead have individual frame counters in each TerrainGameObject that are incremented during the Update call. For the glowing circuit traces, I used the X coordinate of the tile to offset the pixel color arrays so that’s how I get the shifting glow effect. Kind of cool to look at, horribly executed by me. The reason I went this way was because as part of the boss battles I was going to have the minimap change to become more “alive” as you beat them. LEDs would start glowing again, resistors/capacitors would generate more circuit traces.

I should have added arrow key buttons to the UI instead of relying on only the keyboard arrow keys. I could have then added Touch Events to those buttons allowing for the game to be played on mobile/tablet devices as well.

Issues with sound and my family took up way more time than I intended. I used Chronolapse to make a timelapse of my work and the amount of time lost dealing with squabbling kids or just “being a Dad” are clearly shown. I’ll be posting this video sometime this week (I’ll share on Twitter) . I think I maybe only got to spend 20 hours or so on the game as a whole.

Hey !
I’m Eldaryze, the programmer and sound designer of the getRandomName() Jam Team.
Here is my 72h Timelapse of the game making.

Check our entry here !

If I had hair I’d be ripping it out right now. I was so happy when I finished my game, felt like a huge weight was off my shoulders. Those hours upon hour of coding finally produced something fruitful. I breathed a sigh of relief…

And then it happened. People found bugs in my game. I was disheartend, that euphoric high I had after completing my game came crashing down… I franticly searched my code to see why these bugs existed. Then I saw my mistakes… the simple rookie mistakes I had made… man I wanted to kick myself in the ass, how could I have made those stupid rookie mistakes!

So I have some advice for you all, two words. BETA TEST, BETA TEST, BETA TEST!

Test everything! I cannot stress this enough…

Seems I need to update the “What I’ll do better next time” with this tidbit of information.

- I will test everything in my game to make sure everything works the way I intended it to

-KunoNoOni

So, I did not complete anything for this Ludum Dare.  Maybe next time.

What Went Wrong

• Could not come up with a good idea for the theme
• Sick with a persistent headache all weekend
• Debugging quirks in Unity took longer than expected

What Went Right

• I liked what I made
• The character controls feel good
• The animation is kind of nice
• I think it could have been kind of fun if I had a few more days

Play The Unfinished, Unsubmitted “Game” Here

Well, even working up to the final minutes, I wasn’t able to get enough game into my…uh…game.  The control mechanics and getting the scene put together with all of the UI elements ended up being more complicated than I expected.  I’m happy with the way the game feels at this point, though, so I’m looking forward to adding in the combat to see how the full arc of the game feels.  Here’s a screenshot of the final state as of the jam ending:

You can play what I ended up with by the jam deadline here.  Since there wasn’t any time for any real tutorial or documentation, some instructions:

- Drag the mothership to move around.  The mothership is the online thing under your direct control.
- Clicking on the buttons on the lefthand side of the screen produces a new computer-controlled minion.
- Minions will stay near the green waypoint (the little green icon that starts on your mothership).
- The waypoint (and thus, your minions) will stay with your mothership unless you place it somewhere by clicking within the green circle representing your area of control.
- If you move too far from your waypoint and it leaves your area of control, it will return to your mothership.

Things That Didn’t Make It

- There’s no AI.  That big purple mothership?  It’s just sitting up there.  It should be chasing you, pumping out it’s own minions to hunt you down.
- Speaking of that, there’s not combat.  All those health bars and nothing to do with them.
- There’s no cost to making a new minion – the intension was to have a cooldown cost for each ship type, as well as a materials cost.
- With combat working, I was hoping to have each destroyed minion leave behind wreckage that could be reclaimed by a non-combat gatherer minion.
- Sound effects, menus, and any other polish stuff.  I never get to these, though, so I almost forgot to add them here.  I really need to learn to pump out a couple of basic sounds and a simple background loop right at the beginning so these don’t get left behind.

The Future

Without a game to actually play in here, I don’t know if the thing is any real fun if you actually had human or computer enemies.  My immediate plans are to hit the points above that would turn it into an actual game.  After that, I think I’d like to give the whole thing a less-abstract coat of paint and play with some different art styles.  I’d also like to see the thing running on an iPad or iPhone, since all the interaction maps well to touch.  From there, I’m not sure – should it be some sort of arena-based competitive thing?  Should it grow into a more open, exploration-based single-player experience?  Assuming interacting with the game proves enjoyable, I’d like to explore some of these possibilities.

Well, we finished. Barely. With 5 minutes to go I was making a build and realized there was no game icon so I quickly let my artist know, she tossed one in the dropbox, and the build finished with two minutes before the deadline. Our finished game is called “Aqua Wars”.

CLICK HERE TO PLAY THE GAME!

WHAT WENT RIGHT?

The art. The artist for our group was Kiki Snell and I usually have her doing the art for me whenever I do game jams. She did a great job and threw together this awesome little timelapse video to show her progress…
http://youtu.be/vRduXqTZ3CA

WHAT WENT WRONG?

It took far to long for us to figure our our idea and gameplay. I had a few ideas for some of the themes but wasn’t expecting Tiny World to win. We kind of came up with a rough plan and fleshed it out as we went along. With past game jams I’ve had more time to focus but I was gone from my house until Sunday afternoon and was just able to do a little bit of coding with my laptop. Once I was home on Sunday we made a lot of progress but then I had work all day Monday and only a few hours to make any finishing touches. The next time I plan on taking off time from work and putting aside the entire weekend to completely devote it to making a better entry.

We started tossing ideas around as soon as the theme was announced and had an idea for making a city building sim type game but base around a microscopic Sea Monkey type creature. That idea didn’t really stick for long but we had already gotten a decent amount of art for an aquarium type setting so we kept going in that route. For the first 24 hours we didn’t really have much down as far as gameplay went. We thought maybe something like a Tamagotchi where you would just care for the fish, but that sounded more like an interactive screensaver and we wanted something a bit more fun. We ended up turning the assets we had into a sort of tower defense type game. You guide a small school of fish around, clicking other types of fish that appear to attack them, and buy more fish, feed your fish, and buy plants for the aquarium. I’m not sure I’d really call our game a success, even though we finished I think we could have done something better…

After 72 hours of development (including skipping school Monday), I have finally finished by Jam entry.  You can play and rate it here.  Overall, I am very pleased with how this LD went down.  I wasn’t expecting Tiny World as the theme, so when I was looking down the theme list I neglected to pre-think of a game idea – but it didn’t really matter.  My brother, who also did the game’s soundtrack (download link on game page) helped me do a lot of brainstorming to get a good idea, think up pun-ny names for the abilities, narrow down the feature list and expand it again, and in general was a fantastic second opinion on making game design choices.  I am proud of how the game turned out.

I’ve learned a couple things:

-Happiness is intrinsic to success.  Last LD I gave up on the last day of the Jam because I was depressed and couldn’t handle the constant solitude and sitting involved with a 72-hour game jam.  I was going to do the 48-hour Compo this time for that very reason, but I went back to doing the Jam because I wanted to include my brother’s music.  Everything ended up better than last time: since he was hanging out in the office I had occupied, I wasn’t so lonely (ironic considering LD22 was Alone).  I also was oddly optimistic Saturday and Sunday.  It’s important to be happy and make a game that makes you happy – I’ve seen a lot of people now give up because they didn’t like their entry.

-The small changes make the big differences.  The difference between the finished-looking product I have now and the clearly-in-development game I had two days ago isn’t much about the features I added – it’s more about the small graphical niceties.  For instance, the background: it was just blue, but then I made an image filled with blue-ish noise.  I let you know when the camera was scrolling and, as a bonus, looked kind of like a microscope.  That similarity led Lectvs to comment that it looked thus, which gave me the idea to add the scope graphic – something that made it look even more like a microscope.  The great Notch once said the difference between a prototype and a finished game is about ten thousand particles, and that was true of this game too – particles added to the aesthetic quality.  Similarly for the change from armor being a tint to a shield-like graphic.  Small things like that, or sweeping menu transitions, make a game look professional.

-Microsoft XNA deployment is unnecessarily complicated.  I mean, seriously, Microsoft?  There’s so much stuff to customize and fit into big-budget company things where they know what they’re doing, but there’s no simple “Make a .exe out of this, kthx” button.  I hope my installer/standalone thing covers all the bases.

-It’s really easy to make something that isn’t a platformer. I went with a top-down game not only because it was what the game idea entailed, but also because there’s no collision engine.  It’s really easy to do stuff without having to worry about what happens when it hits something.  The closest I have to collision is things running a query for the closest bacterium to a position – nothing really complicated.

Short description from game page - You are a bacterium struggling to survive, thrive, and evolve. Attack other bacteria with a variety of weapons, get a variety of upgrades and buffs, and for goodness’ sake watch out for bacteriophages.

There are 2 references to kittens.  Can you find them?

Well, my first time participating in an actual Ludum Dare was interesting at least.  I was  just coming back from vacation without internet so I had no idea about the theme or enough battery life in my laptop to get started until Sunday.  A minor setback I suppose.  Hah.  Anyway, I threw around a bunch of ideas, which all resulted in failure, until I came upon the idea for Tiny Archaeologist, which you can play here: http://www.ludumdare.com/compo/ludum-dare-23/?action=preview&uid=8229 Originally the ending was supposed to be a section where you are chased by water, but after two hours that still wasn’t working so I scrapped it and put what is there now.

Anywho, let me start with the theme.  I loved it.  It fit with so many ideas I’ve had floating around my head for a while now so coming up with an idea was easy.  Of course I made up a new one, but that’s besides the point.

Now let me talk about my game.  In my opinion it’s a solid meh.  I think it came out okay, but it could have been way better.  Let me start out on things I liked about it.  Firstly, I liked the idea.  I love games with tiny characters and huge worlds, so it was awesome to be able to make one myself.  I also am moderately pleased with the graphics, while they could have been better, they are some of the better pixel art I’ve done.  One of the best parts of this was I got the opportunity to work with Stencyl 2.0, and this was a really great crash course on some of the new features.

Now for the negative. I spent most of the time on the graphics, but I still don’t think they were varied or bright enough.  They seemed a little dull to me.   The music was just a simple loop, but I didn’t have time.  And putting music always gives me difficulty because of the long process of getting it from pxtone to Stencyl, so the ending got a little chopped off.  The gameplay is barebones and incredibly simplistic.  I wanted to add more, but since I started late, there was no time.

I’ll end this on a positive note: I had a really great time working on this, and I look forward to more LD’s and more games in the future.

Until then, see you,

toaster

Hello everyone !

So this is my post-mortem for Tinysasters, my LD# 23 48h entry made in Flash.

Play and rate Tinysasters

As I said before this was my very first participation. I hadn’t planned to enter the event until about one week ago, and I didn’t prepare. But I work on flash games every day, so this must count as some kind of preparation

I was a little anxious, because I had never developped a game in such a short amount of time, and I didn’t know if I could do it. But everything went very smoothly.

The game

Tinysasters is a puzzle/simulation/gestion game. You play on a 8*8 randomly generated tile map and have to build workplaces, shrines and cities in order to collect ressources. The goal is to build a level 4 shrine. Natural disasters happen every now and then. They reconfigure the ground and make your life harder !

Build the level 4 shrine to heal the ground and spare the world from disasters like earthquake !

The idea was to make something between the boardgames Settlers of Catan and Labyrinth ; basically a Settlers of Catan where the tiles move and change of nature.

At first, I was absolutely not happy with the theme. I rated it -1. I liked “Artificial Life” and “Castles in the Sky” a lot better, but I don’t know if I could have made something good out of them. The theme doesn’t matter a lot actually.

As for the nature of the game, to be honest, when it comes to play, my heart usually goes to platformers and adventure games with a good story. But programming is my strongest point, so I thought I should rely on it a lot for my entry.

What went right

- (almost) no time wasted on debugging ! That was a good surprise. I’m used to spending a lot of my time fixing problems that seem to come out from nowhere and make absolutely no sense although they usually end up being all my fault after all. That’s one tremendous benefit of working on a very small project : I just had to see a bug to know where it came from because the entire code of the game was so fresh in my mind.

- I was a little scared at first when I started programming the tile animating sequence that happens when there’s an earthquake or the player generates a land. But it went smoothly and the TweenLite library was very handy.

- I hate building / coding menus and interfaces with so many buttons, and so many textfields, and tabs, and they all have to update, show the right information, show a red color when there aren’t enough ressources, etc., and it’s so overwhelming… It was very tedious but it went ok. There are a lot of ugly duplicates in my code but I guess I can live with that.

One of the many possible states of this interface box…

- About 40 minutes before the deadline, there still were no sounds, and the tiles were still rough colored cubes. I rushed on as3sfxr to generate some sound effects (very useful tool), made a quick music arrangement, added an underground effect to the tiles, some texture and some decorations.

Despite the fatigue (it was about 2 AM and I had worked all day), I found myself inspired so everything went quickly and I finished on time.

- I’m very happy with the result. I enjoy just watching the game playing disasters and reconfigure the map into wild deserts, forests and lakes. The mountains always prevail, eventually.

Invasion of the mountains !

What went wrong

- The firsts hours of coding were the hard part. Sometimes I’d finish coding a new fonctionnality, like the map generation, and had some kind of a mental blockage : I just couldn’t figure out what to do next. What I had in front of me was so far from being a game… it was a little overwhelming.

a depressing early stage of the game

- Like I said, I only had 40 minutes to polish the sounds and graphics. I had great expectations for the animations, I wanted to use beautiful particles effects… I wanted the tiles to explode in a thousand of pixels when they reach the borders of the map instead of those mere alpha fade outs… I wanted the volcanic eruptions to set the map on fire… I wanted the flooded tiles covered with shiny swinging blue water drops… I wanted a little flying god inpersonating the player’s actions react to the disasters and constructions…

Nothing of that was done. I am so sad. Maybe in the enhanced version

Also, more types of disasters were initially planned. Disasters that only affect the constructions : plague, civil war, etc.

- 7 hours before the end I was like “Great, 7 hours left, I have PLENTY of time to do everything I want !”. But 7 hours in the end are not like 7 hours in the beginning, especially with the timezone I’m in. I was so tired I was like a zombie and sometimes found myself spending half my time just starring at the disasters do their thing. It’s a good thing the game was already well-advanced at this point.

What went terribly wrong

- But the biggest problem I encountered came from the nature of the game itself.

“Do the game mechanics even work ?”

I couldn’t answer this somewhat significant question before the game was ready to be tested. The disasters had to be coded, same goes for the ressources, the buildings, the upgrades and all the time-consuming interfaces that come with it.

The game was ready to be tested 2 hours before the end.

I had my fiancé test the game. He told me he was troubled by the game even though he knew what he had to do.

At first, I didn’t listen to what he said and continued to blindly code what I could. Coding more interfaces wouldn’t have bothered me that much at this point.

Then, I had to face the reality : the game mechanics didn’t work as they were.

I had to balance the costs and gains of ressources, add difficulty settings to avoid overwhelming the new player or boring the experienced one, write a “how to play”… For that, I had to test the game a lot which takes some time… And the game navigation (title screen, restart…) wasn’t done yet, nor the graphics and sounds, not to mention the fancy particle effects I still hadn’t given up on !

The last minute how to play screen

Damage control was done, but the game ended up being less challenging than I would have wanted. Hopefully a future enhanced version will correct that !

Final thoughts

I’m very glad I participated !

Thank you for reading and don’t forget to rate Tinysasters

Play and rate Tinysasters

Link to the to-be-enhanced version on Kongregate

I hope you’ll enjoy the game, I enjoyed making it a lot !