What went right:

I had a lot of fun making this one. I think the mix of platformer and tower defense rush actually work really well. I really like how fast and chaotic the gameplay feels, and definitely want to continue to improve this game post-compo.

HaxeFlixel is a great game engine, and Haxe is an awesome language. I have a bit more confidence in my tools this time around, and I think the amount I got done in 48 hours really shows that. I would use Haxe and Flixel for Ludum Dare again for sure.

Things I would do different

I think the biggest complaint was that the gameplay got a bit repetitive, and I would have to agree with them. I definitely had more plans for variation that would have made you move around the level a bit more, but the usual story goes that I just ran out of time.

I did plan to have a few different weapons, and powerups. This is why the base weapon was not auto-fire. I was going to add auto-fire as either a powerup or as a separate weapon pickup or reward.

I also planned to make a few very different enemies. Fast ones, big heavy armored ones with shields that would protect the others, and small ones that wall run along the walls and ceiling. This would force you to shoot all angles.

But overall I think I made a pretty fun game with a lot of potential, and some pretty sweet gib action. I am super stoked with the response and the comments have been awesome to hear.

Thanks to everyone who has played already, and if you haven’t, then you can play and rate Barricade here.

Tags: post-mortem

Started working on a post jam version. I may eventually make an awesome game and hopefully port it to Android.

I’ve changed:
-godly tower is 4x faster
-poison is 1/3 as deadly
-pauses
-randomly generating waves
-basic missile is costs 50
-countdown

Link to the link of the post jam:

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

Have fun! 😀

Didn’t really get into the theme of the dare so I ended up dropping out :/

My body is ready!… again!

lets go >> http://www.twitch.tv/skyllartor

Tokyo Station

Mini-post-mortem

I tried doing something a little different for this Ludum Dare – I spent the first few hours putting together the soundtrack, then tried to build a game around it. I thought I’d post up a soundcloud link to the original soundtrack:

http://snd.sc/14fnJBr

(Can’t seem to get the soundcloud widget to work )

The good

I’m pretty happy with how the music turned out.  After a few youtube tutorials, I’m starting to get my head around the FL Studio interface, and there’s a huge range of instruments and effects to play around with.

The visual side of the game just came about through experimenting in Unity. I set up some walls moving towards you that you needed to avoid, which was nice enough, but giving them all rotation speed just gave the whole thing this mesmerising, tumbling sensation, which I loved. The epic background countdown came from my hatred of blurry 2D Toolkit fonts

I was also able to get the game up on Kongregate, so that people can compete for high scores (although the actual recording of scores doesn’t seem to work that reliably for some reason). I haven’t been able to work out whether Kongregate have some sort of dev environment where you can test things like submitting scores, if anyone has any idea, please let me know!

Naming my games is also a lot easier now that I delegate that decision to wikipedia’s random article…

The bad

Controls are always the part of game dev that I find hardest, and Tokyo Station was no exception. There are a few problems with the current controls, and I have a few ideas on how to possibly resolve them in the future:

• Its hard to estimate the distance between you and oncoming targets, and the perspective of the camera, which makes it hard to tell if you are going to collide with an object. I’m thinking it might be possible to resolve this by having some sort of laser-targeting line emitting forwards from the player. I don’t want to change the perspective of the camera, as that would kill of the sensation of falling, but the chromatic aberration effect should probably be toned down a bit at the edges.
• The controls feel a bit floaty and imprecise. I think this is because there isn’t a 1:1 relationship between your mouse position and your player position. I might be able to get around this by just hiding the cursor.
• Some of the powerups get spawned right at the edge of screen and are impossible (or very difficult) to collect. This is a bit of a symptom of how quickly the game was made (the original version was created on the Monday, for the jam). There is no fixed “play area”, the player can move around in a certain zone (which is probably slightly too large) and the walls and powerups spawn in a roughly overlapping zone. I just need to lock everything to the same play area.

Now its time for me to put the game to one side for a while and rate more games! 😀

I had a run at a few LDs before, but every time something came up that didn’t leave me the space to flesh out my concepts (which also happened to be quite ambitious most of the time). Between the last LD and this one I gave in and picked up Unity. For a while the proprietary/closed nature of it and the scene/gui-centric design scared me (as did the reporting of information about my machine during installation). Unity itself clicked with me quite quickly after I started doing things with it, and it is just what I needed for prototyping. I start (way too) many small experiments, so I want something that allows me to easily setup lightweight projects. In regards to that I only wish Unity would let me setup an empty project with metafiles and text-based assets from command line.

Also “error CS1061: Type `int’ does not contain a definition for `f’ and no extension method `f’ of type `int’ could be found (are you missing a using directive or an assembly reference?)” some day will make me break something.

Visionary

I designed ReTurtle) as some kind of puzzle-shooter. You would have 10 seconds to beat a boss, so you need to find out how to do enough damage to him in the time. To make things interesting you would record 10 8 6 5 characters, one after another, where the coordination would give the game some depth.

At first I was worried that coordination would be trivial. To fix this, friendly fire would make the player have to actually adapt the path for each incarnation to keep them out of each other’s aim. That doesn’t necessarily make for non-trivial coordination. Every character could still have his own small space he would stay in and just move a little now or then to avoid attacks. So it became the enemy’s job to make them move. I designed a set of attacks to get this done:

• Motion: He would move everywhere once, and cover some space with bullets, so the whole group would be pushed around the stage, having to avoid bumping into each other.
• The Grid: Having attacks that separate the playfield into cells would force the player to pick different safe spots for his individual characters if he wants to keep shooting at the boss.
• Grenade: The grenade aims for the current position of every player. This way you have to consider where your previous incarnations will move to, while picking your path, which adds another aspect to the puzzle. The second use of it is that it avoids any completely safe spots.

Now having an idea of the base concept, I wanted to add a bit of depth, so I added two mechanics.

• Gun Charge: Friendly fire is already there to keep the player’s finger off the trigger, but I didn’t want to make him feel bad about it, so I added a small challenge. While not firing, the gun charges for one second. Firing once the gun has fully charged does quite a bit more damage but getting the most damage out of it requires focus. This creates space to improve.
• Shield: You would have a shield that reflects attacks (by either player or enemy), making them more powerful in the process. To make things more interesting the shield is not able to reflect projectiles right back (which would leave some space for abuse). A frontal deflect would just destroy the projectile, while bouncing it around at 90° would maximize damage.

The numbers were designed so you can do 25% damage with one character through rapid fire. This means you need four of your five incarnations to beat the boss that way. Using all perfectly timed charged shots lets you raise that to 34%, which is just enough to win with three characters, but requires to not waste time between the shots (and of course every shot to hit). An optimal reflect doubles the projectile’s power, so reflecting a charged shot adds the equivalent of another on top of it (without needing charge). This way the first character can replace the third, if all shots are perfectly reflected by the second. So every mechanic was designed to cut one character by perfect use (note: due to projectile flight-time it probably doesn’t, but gets close).

Back to earth

For the first day I planned to make all core mechanics work and do all the visuals. That’s quite risky, since I couldn’t tell whether the parts would work together at all. So after day one I had incarnations being able to get recorded, shoot and reflect shots. The boss just sat there and fired a shot straight down now and then. Modeling the boss took me longer than it should have and he didn’t look much like my sketch (I suck at blender). To make up the time the player built from a few 2D-Layers without any animation. The stage suffered the same fate. Planned were multiple layers of tech-y plates and a stripe in the center with numbers running through it to show you the remaining time. But to close out day one, I made what is in the game now instead.

Schedule for day two was boss-actions, menu and intuitivation (that’s a word now), sound was pushed to what would be left. After attaching a hitbox to the boss and making him move through the stage, I could finally test some of the feel. To my surprise coordinating characters already was more interesting than I expected at that point. One of the challenges I didn’t think of is that under pressure one tends to react to an attack the same way every time. This makes the act of creating different paths for all characters challenging by itself, since any time you have to rely on reactions you end up in the line of fire for another incarnation.

Fireballs were already there from day one, so I only had to implement lasers and grenades, which went smooth. Unfortunately not everything went this well. With most gameplay in place, shield just didn’t work out. I boosted its value by making the scaling multiply. That doesn’t help if you can’t set it up though. It’s still too powerful due to a bug, but quite useless for proper gameplay.

What threw my schedule off was the upgrade for player-visuals that got pushed over from day one. I wanted only the ‘head’ to move and the game also needed something to point at the currently controlled character. Some information on the charge-state and something to show the number of an incarnation was critical too. With all of this done I was already closing in on the deadline.

I still had to add a menu, and link everything together. So I threw together the atrocity that is the main menu, added some hit-detection for clicking, and moved handling of the game-progress to the new scene. That left me just enough time to set up a dropbox-account until the submission-hour started. What fell off was sound and any kind of ingame-instructions, including any hints on what you have to do on the main menu.

Conclusion

I’m mostly ok with how the game turned out, I got to play with a few mechanics and they didn’t rip each other apart. It is desperately in need of instructions, some tuning for the core and an overhaul in regards to presentation. I gave myself a week to tweak everything, before I let the game go and focus on other prototypes. The time is up and I’ve added the post-compo-version you might want to try after playing the compo-version. You could also try to beat these informal challenge-times in the post-compo-version: under 6 seconds as a ‘silver’-mark and under 5.5 seconds as ‘gold’-mark. I’ll follow up with an overview of the changes soon, this post is long enough already.

Tags: LD27, postmortem, unity

I wanted to post some technical stuff about how our jam entry, Dango Rush, was developed, but it has been hard finding a time to do so while we have so many interesting games to play and rate! But, I finally decided to take a break and write down some development notes! So, let’s start!

PLAY AND RATE!

The game’s title screen! =D

Tools we used

I started out using FlashDevelop and the Flixel library to code, but ended up using the FlashPunk library instead because of some helpful stuff it has already implemented. Also, because I was completely new to Flixel but had already read a lot on FlashPunk and found it more comfortable to go on a weekend-long project.

Aline used a Bamboo Capture drawing tablet, along with Adobe Sketchbook Express (that comes with it), to draw all the graphics. I also used it a little to draw some sketches. Paint.NET was used for editing (adapting) the drawings to a format acceptable by Flash/FlashPunk.

For the audio, PxTone was used by Carvalho to compose the music for the game and I used sfxr for the sound effects (as usual).

Early sketch of the game’s ideas.

First intentions and end result

Initially we decided to make a mix between The Binding of Isaac and Mii Force. The player would have to explore randomly generated dungeons while collecting and equipping different power ups, each one providing a different type of bullets you could shoot at enemies, while avoiding being hit by their bullets as well. These initial mechanics turned out very difficult to implement and we decided to simplify the game.

Aline suggested that we used “dangos” as characters in the game because they are very simple to draw (she’s not a pro artist) and very cute. The title “Dango Rush” was immediately adopted. =p

In the end, we removed a lot of stuff we wanted to put in the game, simply because we wouldn’t have the time to implement. It turned out to be more of an Isaac-like game than Mii Force-like. But we were very satisfied by the results, nonetheless. Of course we knew the game had problems (I’m glad people pointed out some of them while rating the game) and we plan on releasing a post-jam version pretty soon, fixing some stuff we couldn’t because we didn’t have the time, and adding some stuff people are pointing us to on the comments! So that’s your chance do play and rate, and contribute to the post-jam version of our game! =D

In-game screenshot.

Final regards

This is the fourth time I participate on a Ludum Dare event, second time on the jam and first time actually finishing the game on a LD jam. The first time we had some problems, maybe because we were too large a group or because we lacked intimacy with each other as game developers, and ended up giving up. This time I went for a more decentralized approach. While we had some specific ideas and goals, everyone on the team had a significant amount of freedom to do whatever they wanted. I think that’s a good way to work on a game jam. We also worked in different things in parallel (programming, drawing, composing), while the previous time we tried to focus on having a working prototype instead of focusing on different aspects to create a good synergy.

That said, I believe LD28 Jam is confirmed for me and whoever wants to take a role in my team. LD27 was definitely a good experience and we are loving to read all the feedback we are receiving! =D

Evening everyone. I have just released an early version of my chiptune composer. It only works in chrome for now.

Example songs:

Giana Sisters
Tyrian Shop
Demoscenish

Composer itself (click the image).

TL;DR: Somehow not a complete failure.

I’d basically written my game off as being completely terrible. It evolved from being a simple test of the game loop, and I basically felt like I did it because I had painted myself into a corner. However, there seems to be a lot of love for the game. A lot of people think the mechanic is interesting, but the game is too simple. It probably is at that.

If I were to do it again, I’d refine the mechanic by making the planets “stick” together instead of disappearing. This would change the difficulty curve of a level: instead of becoming harder and harder as the level went on, you would balance that somewhat by having a much larger “planet” with which to smash the smaller “left over” planets. One person suggested that I stop the planets from entering too tight an orbit, which was something I was considering, but the game becomes simply too difficult. With the planets “squishing” together, I could decide to make the planets bounce off the sun or keep distance some other way like suggested.

I didn’t tune the difficulty curve of the levels enough I think. They become slightly too difficult too quickly, which I think was picked up on.

On the sound / graphics front, it was noted that I had no sound and the graphics were very minimal. I definitely wanted a refined “fun” mechanic before I moved on to the more visceral aspects, and I just didn’t get there in the end. I’m actually far more confident in my ability to fine tune the graphics and sound than I am in game design, so that’s where I was concentrating this LD (and I will probably continue to do so in the near future).

However, one unforgiveable sin was having no sound at all. I really should have had a minimal soundscape and sound effects. I was disappointed with createjs’s sound capabilities. I was hoping I could pipe through sine waves and I couldn’t. I really wanted that minimalistic vibe, and I really didn’t want a point when I was putting sine waves into an MP3 and playing that.

I could also have chosen slightly more representative colours for the planets, the sun, and space, although, being firmly in the ludologist camp, I actually feel happier that they’re not representative — I want the game design to talk to the player, not the graphics. That’s one thing that’s great about a game like Osmos or Eufloria: You can be at planet-scale or at microscopic scale, it isn’t clear, but the behaviour of the system shines through. However, the bigger problem was I did nothing for the smashing of the planets. Disappear or not, they really needed to have a visceral impact on the player — the thrill of catching two planets in orbit and then having them smash together needed a far bigger pay-off than I was giving (which was none). It’s a lesson learnt though: a simple visual flourish actually has a huge effect on the game design. I wouldn’t have said that before this competition.

In the end I had a great time, and really want to try again, and that’s really the whole point, right?

So I think this one was my all time favorite of the games I have made for Ludum Dare. During the voting I wanted castles to win, even though that wouldn’t be a good theme I still wanted to do something with castles. Decided that the best way to do this was to have something to do with castles that only takes 10 seconds.

What Went Right

The Castles- They are not perfect but I like how the castles looked, I didn’t get time to go back and make better textures but I think they look decent

Rigid Body Control- Making this game using a character controller just wasn’t going to cut it. So I programmed a character controller that uses the rigidbody add forces and velocity for movement. It needs work but it’s a good starting point for other games in the future.

Terrain- I spent too much time working on the Terrain of a few of the levels. I find them rather nice to look at.

Basic Catapult Launching- It launches you in a up direction…which is what its suppose to do.

Music- It’s simple, but I think it’s fun.

What Went So Wrong

Catapult- the model was a placeholder that I ended up not being able to redo. Main issue though is the power, in my sleep haze I decided that the catapult needed to be able to reach the castles on zero power…which meant that you never went over like 20 power on most maps. Also I didn’t have time to make a simple animation for it

The Super Jump- Because of the way I controlled the player with a ridged body you could run at the catapult and launch yourself much much further.

Moving Catapults- There were several glitches with this, you could get them stuck in the ground or flip them upside down if you are not careful

Terrain Size- I underestimated just how far and how high you would launch, so you can see outside the map, which is just not cool

The Correct Spelling of Trojan- I need spellcheck everywhere…at all times…

I learned a lot while making this, going to be able to use my new knowledge in a game I am working on. I am hoping to gather together a team before the next ludum dare, would really be helpful.

Here is a link if you have not played it.

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

Tags: post-mortem

It was the first LD I patricipated in, and I’m quite satisfied with the game I made. I found the theme a bit too constraining, though I managed to get an idea of my game fairly quickly. So, without breaking everything in good and bad aspects:

• Graphics. My programmer art really sucks so I went for a minimalist graphical style. My inspiration was Super Hexagon which manages to look really good without having sophisticated graphics. I think my game looks quite well, and that’s mainly due to particles flying everywhere.
• Music. In short, there’s none. I found out I couldn’t make a good-sounding soundtrack and I didn’t want to resort to autotracker.
• Gameplay. It’s unoriginal and repetitive, as it’s just your everyday top-down arena shooter. Magnet phase makes things a lot more interesting, though I got comments saying that it’s confusing.
• Scope. I didn’t pick a complex idea, so I was sure that I could complete it in 48 hours. I was right about it, almost all mechanics were done during the first day.

Taking part in an LD was a great experience, and most of all a fun one. Looking forward to next compo!

Click on the screenshot to play my game!

Tags: postmortem

Hey! So, my LD game was a text based “Dungeon Simulator” really, it is just a puzzle game in text. (I know, a recipe for disaster. Hahah) If you want to play it:
Dungeon Simulator 2013

This is what the menu looks like.

Anyway, I worked really hard on it, maybe you can’t tell, but a lot of work went into it. I know for you all of you Expert Coding Ninjas, 540 lines in 48 hours is NOTHING, but to me it was actually a bit of a grind. I won’t go into details, but if you want to read more about it you can read my post mortem. Anyway, I have a little announcement:

My game will be having a post-post mortem release!

That is right, I was inspired enough to do more work! Whoa!
No, no, but for real my game is actually fairly buggy. Most notable the tutorials and some level bugs. This was mostly do to the lack of play time and testing I did the “finished” game. As I said in my post mortem “I might have played through the whole game maybe…Three times all the way through? Sorry.”
Anyway things I hope  to bring to the next release:

-Fixed tutorial(s)
-Re-build level three from the ground up.
-In addition to new level three, add three more COMPLETE and PLANNED levels. I will draw them out this time and make sure they at least work on my machine.
-I will try and make the “engine” (If you will.) a bit more robust.

I will be releasing this on the 20th right after voting (Sorry, I don’t want to mess up voting and I start school here in a few days, so my schedule is going to be tighter than normal. :c Be patient.)

I will be doing weekly “Updates” with what I have been working on. (Maybe even a preview, maybe?)

Stay tuned for more! If you have played my game and you have input or things you think should be changed, that I didn’t say ^above, please feel free to say it! I would love to hear some more opinions from you guys. After all that is what keeps me motivated. (:

Good luck everyone.

~Blade

So I’m already developing a mobile version of my LD entry. Time Annex will become Overflow. If you enjoyed my LD game you can follow progress on my blog here. It will be released for both Android and iOS. Here’s a new visual style I’ve been playing with.

I’m glad I joined in on the fun for the Ludum Dare.  This was my first game unless you can count a four line program from when I was 8 years old.  Well it was my first push into actually finishing a game.  When I don’t have a deadline I work on a project hoping to finish it but of course I say to myself keep it simple.  1 week later from the moment I say keep it simple i’m trying to make my own AI and every other extremely complex thing under the sun.  The challenge of making a game in 48 hours was good because I knew I could not do this.  So I went with an idea then stripped everything I could till it was done.  I then added more to it but not something I could finish in the time I had.  This seemed to be the best method to making a game.  Hopefully another LD will come soon because I can’t wait to have a good solid, non changing deadline.

The Ludum Dare #27 is over but I decided to enhance my entry Logic Bomb a bit further. According to the comments my game was quite enjoyable but was a bit too easy up to level 10. So I updated the random level generator and it is now a lot more complicated to cut the right wire!

I also added the ability to cut multiple wires at once – this gives an advantage especially when dealing with more complex bomb layouts.

Furthermore I ported the game to Android because I think it is perfect for being played on tablets! Unfortunately because of some problems with Google’s Play Store, I uploaded it to Amazon’s App Store first. I will post another update when Logic Bomb also becomes available on the Play Store.

But for now: my entry Logic Bomb for Android tablets:

Sky Trader is my third game made for LD48 and my first game of arcade genre. I only made point-and-click games before so making such game was a truly new experience for me. In this article I’ll try to describe what I’ve learned while creating the game.

Theme

Almost everyone who rated my game mentioned it doesn’t match the theme. I definitely agree with this. The only thing that somehow matches the theme is fuel – each can lasts exactly 10 seconds. But it’s definitely not enough to say that the game matches the theme. However, it can be easily explained: I tried to create a fun and interesting game first and make it match the theme later. Obviously, I failed to make it 10-secondish enough

Skeleton App

During previous competitions I always started development from empty folder. I created Rails application, added all required libs, configured deployment, etc. it usually took from hour to several hours, depending on the weather.

This time I decided to create a skeleton app which already included a set of libraries I was going to use, tested deployment scripts, and some boilerplate game code I use for my other games. It took several hours on Friday to make this app usable and it definitely saved me a lo

t of time and mental power to focus on the game itself. Instead of setting up the app I started coding the game itself from the first minute.

Coding

I decided to make the game with HTML5 and JavaScript using pixi.js framework. I already had some experience with it so it was a good choice. Pixi.js is pretty simple and it doesn’t restrict you to a certain game structure, genre, or development cycle – it just takes sprites from you and renders them to the canvas with WebGL. It also automates some simple game routines such as sprite atlas loading, animation, rotation, and transparency.

I began the development with some mockup arts and spent the whole first day implementing game logic – ship movement, clouds, pirates, fighting, viewport movement, trading with cities, etc. My coding skills are much better than my art talents, so I decided to make as detailed experience as possible and focus on the art later.

At the end of day one I had fully working version of the game deployed to Heroku. Being able to test the playable version earlier helped a lot – I was able to submit the game as soon as the submission form was open.

Art

I was pretty much surprised that the art for this game got so many positive responses. I’m not an artist and I was extremely pleased to receive positive feedback. I’ll try to describe the art development process in details, probably it will help someone to succeed during the next competitions.

Initially, I was going to draw everything in pixel art, but after trying to draw just one sprite I understood that it will take a day to draw the ship alone, not to mention animations, pirates, cities, and so on. So I decided to try something else.

I started drawing simple sketches in Photoshop at 10x scale of the final image I would like to get in the game. Say, I want to have a city sprite 100×100 pixels. I started drawing it 1000×1000 pixels. Sketches were terrible, but they allowed me to draw images without focusing on precious details of every pixel. Here’s the sample sketch:

After drawing the sketch I started adding layers one by one, painting every surface of the object. I focused on colors, shadows, and texture, tried to use Photoshop effects where possible. Half-painted image looks like this:

The final image at 10x scale looks terribly, but when scaling it down to the designated size it looks OK (large vs. final size in the top right corner):

Animations

After making a static version of the image I created a frame-by-frame animation by copying layers in Photoshop and adding motion blur effects. I had about an hour for each sprite, including animation, so I decided to add just one animated element per sprite – rotors for ships and cities, flag for upgrade stations.

Even the simplest possible rotor animation for the main ship made the game much more live and visually appealing. I decided to add animated elements to every object in the game. But I had only few hours left before the compo submission is over, so I had to find another way to animate things rather than drawing everything in Photoshop.

Pixi.js provides simplest API for object rotation and transparency – I decided to use them. Instead of drawing two separate states for static ship and flying ship I decided to simply change inclanation of the ship depending on its speed. It game perfect results – the ship started to feel like real, it got some kind of visual inertia. I decided to use the same effect for pirates, added tilting for bonuses, made cities float up and down.

Audio

I didn’t have enough time to make any sound effects or music for the game, so I decided to just skip this part. My skills with audio software are poor and I don’t think I can produce something satisfying in less than a day or two of trying. I should practice it outside of the competitions to be able to properly use the skills in the limited time frame. I think that the game could be much better with proper sounds and many voters think the same.

Conclusion

I think that I pretty much succeeded with the game – I made a game of a kind I never did before, its visually appealing, it feels good, and I’m even thinking about the post-compo version of the game.

Here’s the short instruction I would recommend myself to follow during the next compo:

• Make a skeleton app with as many features as possible, excluding features specific to a certain genre or setting
• Try to stick to the theme – it’s one of the most important things to get good rates
• Art and sounds are crucially important and require at least 50% of the time limit.
• Good animations can be done with rotations, scaling, and transparency – and they’re very easy to do.
• Early feedback is very important. Show your game to your friends and family as early as possible – it will give you new ideas.

Vote!

I would be glad if you’d check my game and let me know your thoughts.

Tags: html5, post-mortem

WHOA! I HAVE 48 REVIEWS ON MY GAME! This actually means a lot to me.
Half of the fun of making games is reading input people give you. Not to mention that this is only my second LD, so, to get this much recognition from the community already is just wonderful. 48 is special to me, because that means for one hour of work, I got one review. Whoa. (That is pretty much Minecraft status, right? Hahah.)

Thank you so much guys. (‘:
~Blade

For the fifth time I took part in the Ludum Dare, this time I decided to use this oportunity to learn libGDX library. One week before the competition I read oficial wiki and write some prototype code that included all basic operations like key input, movment, sprite handling etc. I haven’t thought about game ideas for final round themes as always because I didn’t have time due to my work/home/family responsibilities.

Game idea for “10 seconds” struck me very quickly but it was a little bit different then what I ended up with. I wanted to create a platformer where a main character has a bomb that will explode in 10 secounds and he have to carry it all around the map and recharge timer in special points. During the weekend idea has evolved into what you can play now, mainly due to programming problems and lack of time.

What went right:

– programming
As I said before this was my first real game using libGDX and I must say that I’m realy supprised how easy it is and how many features it has. I will definitely try to better understand it and use it again. If you write in java I realy recommend you check it out.

– art
I’m very happy of how game ended up looking. This is far the best looking game I ever made. I spend lots of time drawing sprites (it took me more than an hour to create a crate).

– level design
The best part of whole LD was when all programing and drawing was done, everything worked and I was creating levels. It was pure fun to create and test them.

– sound
Until last moments I didnt know if I will manage to create audio. I always left this for the end, because audio is my weakest point in whole game developing. Happily there was still enough time to create some simple theme.

What went wrong:

– programming
Because it was my first time with libGDX there were some problems. I couldn’t generate TextureAtlas (still don’t know why). I had big problem with adding a font and then scaling and I ended up using standard font. But all of those issues was caused by my lack of knowlege in lib. Besides libGDX troubles I had to face my old nemesis with was collision detection. I had big problem with proper collisions for crates, character and map when it was all working together.

– controls
The worst thing about my game (as I can tell from comments) are controls. During development I knew there was bad and I wanted to change it but only if I still had some time left. Character animations was directly connected to them and I was too afraid I will break everything.

Conlusion:

I must say that when I run game with graphics, and sound for the very first time it was a beautiful moment and I couldn’t stop smiling playing. And for moments like these I participate in LD and I will participate as long as I can. Overall I’m very happy with how final game looks like, and with all the comments I have received. Thank you all!

If you haven’t playd my game you can do it HERE

Well, it has been a little more than a week now, and since I got some feedback, I might as well do my postmortem now.

So yeah, this was my first Ludum Dare, even if I try to participate since roughly two years now. I did not make much games before that, the biggest one was a 7-level platformer on Nintendo DS in C which was basically my learning project for the C language. Even so, I had a good grasp on the basics and I knew I could at least produce something. It is also my first game jam, although I did do a tower defense in  weekend as part of a school project.

Well, on to the actual entry now. I enjoyed the voting rounds, and with each one I tried to prepare myself to at least the wining theme, so as to be able to start right away with the code. The theme “10 second” was one of my favourite, because it was easy to use (you could do mini-games as well as almost any kind of gameplay with an added time-limit) ; but even so, I was failing at finding that great idea that would make me completely motivated to make something great. I guess I was more or less waiting for an idea to fall in my head, saying “You cannot do anything else, because that is the greatest idea you ever had”.

This game is a bomb – well, the Bomber toy is, technically.

I then chose to solve the problem the same way I do when I fall short of inspiration : add some more constraints. One of the theme I also liked a lot was “Death is useful”. While thinking about a way to mix the two of them together, I thought “Well, I could make some sort of game where the player dies every ten seconds ; and the level cannot be completed without dying several times, each death unblocking the path in some way or another”. As I could not think of a unique way to die that would allow for several different game mechanics, I chose to have several characters, each one with its own way to die. That happened during the Friday, so that when the theme got revealed (it was around 3 A.M. on Saturday in France), I already had a pretty good idea of what I wanted to do (the platformer format more or less imposed itself to me on its own. Besides, I suck at making graphics viewed from the top).

That was the genesis of the project. Now is the classic good/wrong part :

What went wrong

– Collision code : I knew it would be the worst part to write, and it was. It took me almost half of the time I spent coding (or at lest it felt that way), and it still is not perfect. I went through three separate approach, rewrote  the same piece of code several times, and ended up chosing a dirty “test one pixel at time” way which will surely slow down the game with more entities (the player is the only entity in the game as of now, save for the spinning vortex which spawns you).

– Playtesting : I did do some playtesting by making sure each level was achievable, but most of it got eaten up by “ok, collisions seem to work, see if I can break it again with some tricky falling-on-a-tile-form-the-upper-left corner case”. I did see that waiting could be annoying, but adding a suicide button felt cheap and, worst of all, allowed for playing a life in less than 10 seconds (in my mind, I was being disrespectful toward the theme). With some thoughts, I think I was so annoyed by the collisions not working properly that I brushed of this problem as being a “mere balancing task, something done when all the rest is working”, even though I knew by experience that in a 48-hours project, there I rarely time left at the end to polish things up.

– Submitting my game : although I knew I had a slow Internet connection, I did not expected my game to be 15 Mo ; that was the first and last time I packaged libraries in the same jar. As such, I almost could not submit my game before the compo deadline, and it was because of the music, which took roughly half the size of the game, and ended up not even playing correctly. The Submission Hour totally saved me that time, and I was happy to learn it even existed.

What went right

– Graphics : the only times I did pixel art, I did not have any time limit, and I spent around 2 hours doing a single 13 frames animation with Paint. This time, I went for simple graphics, but since I learned one thing or two about color palettes, I tried to put it to good use (yeah, being colorblind, that was the right part to start from…). I ended up creating every piece of graphics in grey (most of the time, four tones were enough, although I used five at some point), then choosing the colors and doing the substitution. Anyway, that part was fun.

– Music : I did some music ! That is an accomplishment, since I had little experience with the software I used (Aria Maestosa). It ended up being also quite fun, although finding the right note is harder than finding the right color. I spent 2 hours and a half on the main theme, and 1 hour and a half on the level background music.

– Code : I started warming up during the summer by learning libGDX, and started a basic platformer on Friday to be able to identify right away the most problematic issues. Turns out, the only one I encountered was the collision code… But there was no other big, time-consuming bugs or features (even the circular selection went good ; Mathematics classes were really helpful with that one !).

As a conclusion…

Of course, I am working on a post-compo version of Ephemeral. I think I will let the title as it is now, but some changes will be made according to the feedback  I got and the ideas I want to implement. Right now, this means I already have a suicide button and animated tiles in the game. I also corrected some of the code, which will make it easier to modify the map dynamically for me.

I enjoyed participating in my first Ludum Dare, and I hope I will be able to enter it again as soon as possible. I hope I will be able to make games I will be even prouder of than this one!

I have played and rated about a hundred games by now (by the way, is that a lot? I have no idea). Overall, the quality and creativity are impressive. Almost every single game has at least one aspect that totally rocks!

However, I don’t know what to do with entries that don’t use their own music or their own graphics. These may sound or look good, but do they really deserve a good rating for something that was not in any way made for Ludum Dare? I don’t think so. In a way I feel like these people are gaming the system with content they didn’t make themselves. Am I being too harsh here?

I’ve finally had some time to sit down and write this.  It’s also my first Ludum Dare, so I wasn’t even aware I should do this until just the other day.

So I created C:\\Bluescreen.  The game turned out surprisingly well and I’m actually pretty happy with it.  It’s one of my better games, only because I believe it’s completely bug free and I didn’t try to pack a thousand ridiculous features into it (though I’ll admit at the end feature creep started to show up.)

The process:

So when the theme was announced I wasn’t really surprised and I was actually kind of rooting for 10 Seconds.  But once I realized it was official, I had absolutely no ideas in my head.  Luckily I was stuck at work (undercover loss prevention agent) so I had plenty of time to walk around and get my imagination going.  Finally I had an idea.

The idea spawned from a situation one of my developer friends had just recently gone through.  He updated a new driver for his graphics card and suddenly his pc bluescreened on restart.  After restarting several times he learned that he had approximately 10 seconds to delete the new updated driver before his pc shut down.  Eventually he got it after a dozen tries.  So I decided that because this kind of thing happens often, I’d use it as part of my theme.

So the original idea was to have a reflection of some nerdy kid in the screen who was constantly downloading viruses which you had to destroy before they bluescreened the computer.  Due to time, the reflection didn’t make it into the game, and due to the 1980’s theme downloading turned into installing software.  The software that contained the virus ended up being “Busty Cops II” and at the top of the installation screen in tiny font you could see the Paladin Virus Hunter Software (which you’d know about if you read the readme.txt from the title screen) warning you that the software contained malicious files.  Of course…. you install the pixelly goodness anyway and the game begins.

Language:

So I used Stencyl to code the game.  I’ve been learning C# in my downtime, but I knew I’d never be able to create anything worthy of LD in 48 hours with my knowledge so far.  So I went back to what I know.  Stencyl is really easy to use once you know the basics of logic and what each logic block does.  For a prototyping engine it does wonders for game jams.  As soon as I had the outline for the game I started writing the pseudo code in my head while I was at work.  By the time I finished art and was ready to start coding, I had the entire game written out already.  The only thing I had difficulties with was adding the power button to the PC.  I added multiple copies because I changed tactics halfway through and it was causing the PC to shut off and turn back on immediately which was a very frustrating 20 minutes.

The Challenges:

I think the only part that was really challenging for me other than time constraints was the music.  I’ve never actually created my own music for games before.  I usually have a friend do it, or borrow it from a website.  So after multiple hours of attempting to create something using various softwares I decided to find a random music generator.  Finally I went with Sfxr for sound effects and Wolfram Tones for the music.  It turned out pretty good for randomly generated music.

The Rewards:

After the planning stage I went immediately to art.  I hate using placeholder art because I call myself a game artist.  Creating sloppy boxes for placeholders is too difficult for me to do when I can just create the finished product with just a little more effort.  When I decided that I was going to mix pixel and vector art in the same game I got really excited.  I’ve used both in games before, but never together.  I decided to make the computer as realistic as possible (given my lack of vector skills) and then use the 80’s theme for pixel art, which was ridiculously easy since I only had to settle on one color…. green.

The fact that the game came out bug-free (to the best of my knowledge) within less than 12 hours of actual work makes me ecstatic.  Bug testing and fixing is the worst part of game dev to me.

In essence:

I’m thrilled with how it turned out and at all the good feedback I’ve had.  Usually I get a lot of “Why didn’t you do this?” or “This part is too difficult”, etc.  But I really haven’t had any negative feedback that made me cringe while hearing it.

Thanks for reading!  Go play the game!

Tags: compo, flash, post-mortem, postmortem, screenshot