Smooth Operator is my LD 28 entry and my 3rd comp entry.  It is also my most successful Ludum Dare entry (in my opinion). So without further ado, lets post mortem!

What went right

Most of the last day was testing and polish

I learned this one the hard way during my first compo dance. I developed a platformer (first time) and did not have another person play it until a few hours before deadline. It was apparent then that the controls were floaty and difficult, but there was no time to really iterate. What resulted was a frustrating control scheme that hampered any other interesting or compelling qualities the game had.

I am very pleased with my time management and scope on this LD, which left me all of Sunday to test and polish. Perhaps even more important though, this time left to test and polished was sufficient to work at a relaxed pace, meaning those hidden gems and changes that reveal themselves only toward the end could be investigated instead of put on a list for a post compo version. (There is still a list! but I got to address the most intriguing/simplest to execute issues during the compo). I spent this time adding in some juiciness and nice feedback for the player, while also having some friends play the game and making some adjustments based off their feedback. (We had a local meetup for the compo at the offices of my company, Super Soul, which was great for feedback, testing and all around great times!)

I went home the first night AFTER having a basic prototype to test a few times

The first night I spent in its entirety developing the code, visuals and sfx to have a functioning prototype to play a few times before going home. This gave me a nice metric to judge how the rest of the weekend would go. It also separated Friday and Saturday along a nice line, Friday being prototype, Saturday being implementing the game. Driving home Friday night and waking up Saturday morning, I had a significant amount to mull over, while also having a fairly clear direction of what I needed to accomplish on Saturday. After spending the first few hours on Saturday planning and designing what I needed to execute on, the rest of the day was fairly straightforward implementation.

I found a good balance between the different ingredients of my LD cake

I attended a talk by Jenova Chen years ago where he discussed a game being as strong as its weakest element. He illustrated this with a bucket full of water, and each core element of the game represented one wooden slab of the bucket. Each slab’s vertical length corresponded to its quality and execution, thus the water in the bucket was only as high as the lowest slab. I really enjoyed this metaphor for game development, and I now try to follow through on this concept whenever I am working towards building an experience through a game, as opposed to when I am working on a demo and/or investigating some aspect of game development.

I did a pretty good job of dedicating the proper amount of time to mechanics, visuals, sound, UI, feedback, etc. so the game is pretty equal on all fronts. There are many areas I would like to improve, but for the time restraints I am happy that I didn’t allow myself to be consumed by one aspect or ingredient to the detriment of others. I believe the relative times needed for each element, wooden slab or ingredient, to be proportional to my skill and speed, and the relative importance is dependent on the game and its goals. So for Smooth Operator I really wanted a solid experience, in and of itself. While it may be a shallow experience, I believe it has a decent level of polish and consistency to it to give a feeling of completeness (for a jam game of course! )

What went wrong

The game needs depth, as it stands it is a novelty

I am pretty happy with how people have responded to Smooth Operator, and it is certainly my best compo to date. However, I feel there is something missing in the game, and the absence of this something, whatever it is, is why the game lacks depth. As it stands, I think the game provides enjoyment, but is not a game you would want to keep coming back to. To me this is a result of a combat system that while fun, lacks any depth that allows/encourages players to develop and refine their skills, develop strategies, etc. that results in a sense of progression and accomplishment in the players abilities.

I am working on a post compo version of the game now, trying out different ways of adding complexity and depth to the combat. My goal is to keep the input and controls simple, but adding more ways the player can use these inputs, which I hope leads to more strategy and depth. I hope that I can figure out that something that can keep a player coming back.

The visuals should do more to give the game style

I want the game to ooze style. It doesn’t It is a decent start, but nothing along the lines of what I would have liked. I think some of this stems from the menus lacking the smooth personality I would have liked. I also feel the game has a bit of a personality crisis, wanting to be comical and frantic during combat, then smooth and slick the rest of the time. Well, writing this just made me reallize I am not sure what I want the game to be! No wonder I failed on this. Oh and I am not very happy about my color scheme. I wanted it flat and iconic, and I was leaning towards a 70’s groove style. But there is something about the colors that kinda bother me. Oh well…post compo!

I continue to slap on UI elements such as controls and how to play

I guess my rationale is that it is 48 hours and info such as controls and how to play descriptions are important only for functionalities sake. However, I just got done commenting in the things I did right about the importance of all game elements executed to the same degree to maintain a games integrity! For 48 hours I think it is somewhat acceptable, but it frustrates me that my menus and descriptions appear to be an after thought. After all, this is the first experience the player has of the game, and establishes the tone for their experience.

I would like to find better ways to implement my game screens and info. I really don’t have any good ideas, but I certainly love many of the ways others have handled this info in their games, so I am not lacking inspiration and research content. My hope is that moving forward I can integrate this content into the tone and aesthetics of the game itself, which should increase the overall experience and consistency of the game.

Well, that is it. Thanks for reading. You can find my game here: http://www.ludumdare.com/compo/ludum-dare-28/?action=preview&uid=13158

4

This entry was posted on Friday, January 3rd, 2014 at 10:36 am and is filed under LD #28. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

Hello all!

I didn’t receive any comments to my 2nd failed attempt in a row post (can’t blame anyone, nothing to show at the time and it was a long post: http://www.ludumdare.com/compo/2013/12/17/ld28-post-mortem-2nd-failed-ld-in-a-row/)

However, the past week I went back at it at full force and finished my very first game ever!!! The only thing I’ve done in the past was the start of a Pong game that never finished. I was pretty stoked last night regardless of how bad and simple the game is.

The only downside is that it’s a 2 player game because I don’t know how to do AI yet but I am going to work on it. I wanted to submit it in time for December 2013’s #1GAM.

Try it out if you’d like. “a” is to shoot with Player 1 and “l” (lower case L) is to shoot with player 2.  Press UP, DOWN, LEFT, RIGHT for the #1GAM secret. The game was made in C++, SDL 2.0.  I didn’t post this yet but if anyone is willing to look at the simplistic game code for me, I’d extremely appreciate it!

Game:

https://www.dropbox.com/s/28obuvkq727ee0k/YOGOSRelease.zip

 

I me made the game in Unity2D and added a whole lot of new features and better controls. Try it out https://dl.dropboxusercontent.com/u/7343751/Asteroid%20Bust%20webplayer/Asteroid%20Bust%20webplayer.html

 

Ludum dare entry: 

Now:

 

 

Link to entry (windows):

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

I have been updating my game a lot recently, and just cant update the pictures, it is too much work. If you do not like the pictures on a game, download it and try it, it might be good!

 

Please play and rate my game,

 

Luke

Hey,

I just made a port of my entry, One Shot, for android.

You can get it on the google play store here:

https://play.google.com/store/apps/details?id=com.JoeC.LudumDare28&hl=en

Here’s a screen shot, now with fancy lights!

Faif is all about gambling. Take this spin for example. There is 3/5  chances to get a skull (-1 heart), 1/5 chance to get a heart (+1 heart) and 1/5 chance to get a sword (making +3 damage to your opponent, one for each skull in the selection). So what was the outcome? Victory of course!

1/5 winner spin!

What’s next?

We are currently fleshing out faif, uploading new versions every couple of days here, improving gameplay, balance and general performance. We added a new tile type (gems), a shop (even some “sale” logic into it!) and a couple powerups. We plan to add instant spells (playable during your turn), more tile types (weapons, effect tiles and so), boss battles, story mode…

And we need your help! What features would you like to see in the game? (Please share your thoughts and comments here in this post, at the game entry page or on the post-compo version of faif!)

Scoop!

Next week will be uploading and Android version to Google Play! (iOs version is coming later in the development process).

So Faif!

• Jam version: http://www.ludumdare.com/compo/ludum-dare-28/?action=preview&uid=26231
• Post-compo version: http://beavl.com/faif/post.html

Cheers and have a great weekend!

Tags: beavl, faif, gambling, LD28, mashup, puzzle, unity

Happy New Year to everyone!

I’m still working on porting my game, 8bit Rebellion (play and rate it, if you want), on mobile.
And now we can turn it on with a cool “swipe”! ahahah 😀
I think I’ll change the name of the game because I found another app that uses 8bit Rebellion!

Also I’m working on some new enemies to make the game more funny…
Here is the list so far:

---

 

Classic Goomba
Tap it one time to kill. Tauroo
Like classic goomba, but it runs 2 times faster. Ghost
They’re tricky, because change row without notice!   Hedgehog
Do not touch them without thinking. Triple
You have to tap them three times in order to kill.   Cannons
This cannon will position itself behind the button’s hole where all enemies come out. It will shot 3 bullets with 2x speed. Bomb
You can drag and drop it into button’s hole in order to shot the main character.

---

I want also to introduce a sort of Bosses every 5 waves or so…
But at the time I don’t have many ideas.
Could anyone help me with some ideas?

–Alessandro

Fellow dares,

 

regardless the voting output, I consider my LD28 game a success, Creator Saga Story Tycoon. There are simply several good comments! I promised to create an Enhanced Edition, dealing the most common issues, specially with saving and scrolling.

 

HOWEVER, I’m in the middle of a funding campaign in Indiegogo of my other game, Picubic. You cannot imagine how much work it demands. All days writing about it in blogs, sites, facebook, google and twitter; dealing with the t-shirt and statue makers, etc.

I promised to build the Enhanced Edition, and the promise will be kept. I will try to spare some time this weekend to finish it. And for all those that played the game and liked it, my sincere thanks!

 

regards,

Bruno Massa

Gamenific

Hey guys! 2 more days until the end of Judging! I can’t wait!

I’ve been working hard on NIKRA in the mean time. Please check out my blog if you have the time

CLICK HERE

Here’s a photo of the new and improved NIKRA!

Until next time 😀
-Seth

I’ve been developing software for a while now.
With my skills, I enjoy making games on the side.

I’m finally going to be making a game for a reason, to enter it in the MiniLD 48!

I took the past two days to finish a game named “The Creeps” I had sitting around, code gathering dust.

(Note: I also make tend to my games from scratch with only standard language libraries or my own hand made code library)

The game is lacking a lot of the little features but the core gameplay is done.

The game is full of pixelated noise to add panic when being chased.

Games are a big part of my life, now and as a kid. But, making games isn’t what I want to do. Having taught myself computer programming, and basically everything  I can about computers, I realize there is a lot out there, and its all just as fun. So, making this, and doing the MiniLD has a different feel from creating IRC Chats, Screen Capture, Word Processing, you name it. I take pride in that I make everything on my own, so games involving art and sound are not the norm, but I’m still gonna try.. And hopefully you’ll like it!

You can download one of my small games, and some of my software at my website: (Also made from scratch c; )

www.andrewfabiandev.x10host.com

3

This entry was posted on Saturday, January 4th, 2014 at 8:39 pm and is filed under MiniLD #48. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

I’ve always thought the term “postmortem” to be an odd one.  A game doesn’t die when it’s released; it’s more like a birth!  So, I’m calling this a “postpartum”.  Not that this is necessarily the best time to start using that term- my “finished” game isn’t really a complete product, and I’m not too proud of its current state.  But anyway…

Instead of trying to create the most polished game I could in 72 hours, I focused on using the jam as an excuse to force myself to learn something I’d otherwise put off- in this case, developing a mobile game (which I’d never done before).  As it’s an uncommon approach to a game jam, this postpartum is as much a referendum on that approach as it is on the game itself.

The Concept:

The Result:

What Went Right:

• I learned a new skill!  As many drawbacks as my approach has, there’s the one big benefit: I actually accomplished my goal.  Before this Ludum Dare, it seemed like it would be a nightmare to start developing for mobile devices- learning all the considerations that don’t apply to desktop and web development and getting all the necessary components to cooperate with each other.  Now, making my first real Android game seems like it will be a lot simpler of a task, though much of that is thanks to…
• The tools.  I’ve been wanting to use OpenFL (a library for developing multiplatform applications using just one codebase in Haxe) for quite some time, but I had problems setting it up before.  Those problems have been mostly resolved, and it worked like a charm.  Installing the Android tools took way longer than I anticipated, but thanks to OpenFL’s capabilities, I was able to develop and test the game in Flash while I waited for the tools to download without having to change huge chunks of the codebase for the Android version. There seemed to be a few things that worked in one platform but not the other, but resolving those issues didn’t take too much time.  I also tried a new IDE, IntelliJ IDEA, because I was tired of Haxe code completion not working in Eclipse’s Eclihx plugin.  Code completion worked much better in IntelliJ, though it appears not to detect files in the same directory as the file in which you’re working (importing classes from those files compiles fine).
• The control scheme.  I’ve heard horror stories about virtual joysticks on mobile games being the Worst Interface Ever, but the constraints of my idea (a limited camera view that may not necessarily be looking at the player character) prevented me from having the player directly touch objects to move them.  As such, I worked out a two-“joystick” setup that avoids the usual virtual-joystick problem: having to constantly make sure your finger is on the spot of the screen that represents the joystick.  Instead of having a joystick at a fixed point on the screen, my game uses wherever your thumb lands as the center point (that’s what the thumbprints represent in the concept screenshot above; the circles represent where the thumbs have been dragged to), re-centering it every time you touch your thumb to the screen anew.  As a consequence, you don’t have to look at the interface to re-center yourself.  It also has the added benefit of allowing people with different hand shapes to play the game comfortably without having to adjust the UI.

What Went Wrong:

• The phone’s accelerometer.  See my previous post for details on my problems with that.  It set me back about 24 hours, but I still had a whole compo’s worth of time left to go.
• Distraction.  I spent Saturday and Sunday working very efficiently and brimming with confidence.  Come Monday, boom- my resolve suddenly disappeared as I debated whether or not I could finish something workbale in time, and figuring out how to implement some important bits.  I ended up spending many hours just trying to de-stress myself by doing things unrelated to Ludum Dare.
• Collision detection.  Ironically, the big time-sink that became the reason why my game has absolutely zero polish (and no levels of substance) was not one of the many technological experiments I underwent in the making of this game, but rather the inherent limitations of the one tool I was familiar with: the Flixel engine.  I knew going in that I would have to implement circle-to-square and circle-to-circle collision because Flixel does not support those, and I didn’t want to spend valuable time importing and figuring out a full-blown physics engine like Nape.  I implemented those types of collision easily enough.  The problem was that I assumed that circle-to-circular-sector collision, which I also needed, was just a subset of circle-to-circle collision and would also be easy to implement.  I realized too late that the problem was not so trivial, and spent about half of my final day attempting (and failing) to work it out.
• The aftermath of the jam.  This is the major problem with the approach I tried this LD:

I knew that I was probably going to turn in a less polished product than I usually do, because this time, I wasn’t focused on making the best game possible so much as one that worked under the constraints I set for myself.  As I said previously, I was willing to accept that risk this time around, because my goals were different from what they’ve normally been since I started LD two years ago.  However, now that I have taken that risk, and I have put out an unpolished tech demo, I’m not so sure I want to do it again.  While my idea worked in principle (using the time pressure of the jam as a tool to learn a skill), I made a mistake in choosing Ludum Dare as the venue to do it.

A major purpose of Ludum Dare is to make something you can share with others- both for the joy of being involved in a community, and so others can evaluate your work to help improve your skills.  This game is not something I really feel is shareable- not in its current state, anyway (I felt a little dirty submitting it).  I’m well aware of the maxim “it’s never too early to playtest”, but I feel there are limits to that idea.  This game isn’t just “I didn’t get to include all the features I wanted” unfinished; it’s “I haven’t even completed the core mechanic” unfinished.  Because of this, I actively didn’t want to play and rate anyone else’s games– not only because it would draw unwanted attention to my own game (through the Coolness system), but I feel like if this is what people see of my work, than I have no grounds on which to evaluate others’ work (even though I’m a student of game design who’s been doing game jams for years).

So, will I use this approach to LD again?

Probably not.  I underestimated the level of gratification that comes with trying my best to make the most polished game I can, and I didn’t realize that redefining “success” as something irrelevant to the final product (in this case, the learning experience) takes away all the joy of the 3 weeks after LD.  That said, am I glad to have done it?  Yeah, I can’t really complain about having opened the door to mobile development for myself.  My technique worked as intended, not for gaining a complete understanding of mobile development, but as a way to prove to myself that I can do it without agonizing over it forever.  I’d just rather do this again in a context that has much less of a focus on other people evaluating my work.  Maybe I’ll do it again in a MiniLD- no ratings/rankings, no pressure.

See everyone next LD!

Note: this is a post by lonely2012, made using team account.

Out of Mind is a turn-based tactical hallucinogenic cyberpunk action game, made mostly by two Eastern European guys in a single room, with some great help from our teammates all over the world, including the same room.
http://www.ludumdare.com/compo/ludum-dare-28/?action=preview&uid=7122
I guess we could have made it outside, but it was rather cold.

It started as a perfectly standard turn-based crawler with perfectly generic progression through entirely typical level. But things rarely go the way we plan them. So about half-way into production things turned out a little bit bonkers, especially on my end. Which happens to be art, level, and overall gameplay design. On the bright side, that’s how the game got it’s name, it works, it’s entirely completable and sorta really fun. At least to me it is.  Especially post-ld re-balanced version, aka the ode to my giant overcompensating ego. With actual end-game challenge. And patched map. You should totally check it out.
My partner’s coding stuff went surprisingly well though, aside from one rarely and randomly occurring gamebreaking bug. And about one and a half out of seven pick-ups don’t really work the way the way they were written on paper. However they do work, and it’s a good thing.
One notable difference of this LD to all six of our previous ones is that this time we were eating less, and made objectively more playable game. Perhaps in the future we should stop consuming human food and make something brilliant.

Also here is a player death image that was censored out of the game by my partner on account of him being too squeamish:

Tags: post-mortem

You can find my LD 28 entry here. May I suggest you give it a try before reading further?

Introduction

Going into the Ludum Dare challenge a couple weekends ago, I knew I wanted to use Unity. I had been using FlashPunk for every entry over the past few years, but it was time to move on. Unity has been my engine of choice for the past four or five months. I have especially learned a lot by participating in the Shroud of the Avatar Scene Jam competition held in September and October. Those jam competitions were first-person and used pre-made assets.

For Ludum Dare, however, I wanted to do something that wasn’t FPS. I’ve been gently ruminating on some kind of top-down arcade type game for awhile, so I thought I would make an attempt to do something simple using that perspective.

Friday came and the theme was announced. You Only Have One. The obvious two choices are one life, and one piece of ammo. I did not start on Friday, instead choosing to watch a movie with my wife. Saturday morning I began to tinker around with Unity and created a simple flat platform, added the player and off and on over the next couple days I managed to piece this together.
The Idea

I decided I wanted some kind of runner. I couldn’t come up with any better interpretations of the theme other than limiting the player to one shot. I thought about doing some variation to the Star Wars Death Star Trench Run, where you’d have to dodge obstacles on your way to the end and you’d have one shot to fire into the hole and blow the thing up. I thought about Moon Patrol as well.

What I ended up with was a game where you control the player via an over-the shoulder view down an alley. The goal is to get to the end and use the one bomb you have to blow up the ultimate evil. Along the way you have to go around blocks, avoid holes and dodge bolts shot from guns.

You Only Get One Bomb in action.

What I Don’t Like

The Holes

I wasn’t really happy with the solution that allowed the player to fall through the holes. The holes have a collider that triggers when the player touches it. It turns off the collider of the ground and the player falls through. The fact that it turns it off for the entire board didn’t cause any problems in this, but I could see it causing problems in other situations where I have other objects that rely on it being there. Another implementation next time around is to use blocks or hexes instead of one giant plane, and then remove them individually. It would require a new batch of code to manage the board, but would allow for different layouts and perhaps even hills and other height changes. Perhaps more elegant, but I could have used a terrain object.

Jumping

This was something that wasn’t really in the initial idea, but something I got for free when using the Unity platform controller. I didn’t change the default settings too much, but I know it was not really ideal. If you noticed, you could jump on the side walls and run to the end that way. It was a easter egg, in a way, since I left it in on purpose. It was my quick-solve while testing events down at the end.

Theme

I didn’t have a problem with the theme. I think my interpretation of it was weak. I couldn’t come up with something clever or a twist on the most common interpretations. There is no reason the player will feel forced into using their one bomb earlier than the end. Horrible design flaw.

What I Liked

Pre-existing Scripts

Having pre-existing scripts, like the player movement and camera movement saved time. It’s nice that you don’t have to solve some of the same problems over and over again. There is also a wide community with answers to common issues. All it takes is a Google search and then sorting past answers for older versions of Unity and incomplete responses. It certainly makes it a bit easier to work on the game rather than the stuff behind it.

Sound In Minutes

I was able to add sound to the game in about twenty minutes with Bfxr and Unity’s built in sound components. It was quite literally a last minute thing, and I was surprised at how fast I was able to get it up and going without any problems. It also seems every time I make that milestone of adding sound to games I am amazed at how much it can transform the project. Definitely a confidence booster.

Next Time

If I’m making a runner in the same vein as this one, I’d like to do it so movement was 3D, and have it be more like the Star Wars trench run. I think that might be more fun. I am not much of a modeler, so if I choose from the beginning to just do the Jam, I could plan ahead with assets from the Unity store or elsewhere.

You can find my LD 28 entry here.

Tags: LD48_28

So, I managed to rate 100 games and I wanted to share four games which stood out for me not by mechanics or gameplay but by the unique experience I had with them. They weren’t even much fun most of the time but great in their own ways. So, let’s go!

Doubt by rxi

One of these “mood” games, but it does so much right: Awesome pixel graphics, awesome (and tasteful) post-processing, awesome audio design and … it has a cat.

 

Drain by  adnzzzzZ

Minimalistic but very dynamic (!!! this makes a huge difference) graphic design, dense audio and a very clear tutorial made this stand out for me.

 

superfrozenkittengetsonlyonesecretbottleforyou by evilindiegames

The game is kind of bad. But wtf the graphics, especially that warped perspective. Not a game I want to win LD but surely one I can’t forget.

 

Data Stains by Evilion

I have a confession to make: I don’t like most of the 3D Ludum Dare games, simply because it’s too hard to create a pleasing conventional 3D environment in that time. I loved this game, because it took stuff that’s technically very easy to do in 3D and created something unique and aesthetically pleasing.

 

This was my very personal pick of the 100 games I rated. If you haven’t played it yet you can also try out my game Ballkeeper.

Time for a little graphics postmortem for our entry RGB. Which you can play here  The theme was anounced the same night we had a big xmas party at the company. Which of course ment massive hangovers with all teammember

Like last time, our team was 6 people, two of them working on graphics.

 

Finding a look, part 1 : Last time we could make an art test before we started working on the actual graphics. This time we originally planned to use a technique involving crayons and an iron ( I spare you the details ), but had no real time to test it properly. It didn’t look appealing enough,so by late saturday, we had to completely re-orient the style. Lesson learned :  Know what you can achieve using a technique, there’s little room for experimentation to get a difficult look right if you’re new to the technique. Finding a look, part 2 :

This was the final styleframe we arrived at

After some time fiddling around in 3dsmax we arrived at some very lowpoly crystaline structures. We worked till very early in the morning to design and model the character models and getting a style frame to look right. The Style heavily used post effects, but we were using the indie version of unity, planning to install the pro trial later on to add those finishing touches. But that never happened due to time constraints, so the game is missing some of the eye candy.

Some concept iterations while we worked on the characters

Lesson learned : If something is incremental for the look, don’t treat it like the thing you can switch on quickly later, because later, there might not be time left. Workflow : We had no idea how to work with unity collaboratively. So there was some constant back and forth where we had to stall the coding or level design process to get assets integrated or to tweak little things. Lesson learned : If you work with a specific engine, figure out a way how to effortlessly work together with several people at the same time. It’s very good to controll the entire process from creation to final integration the asset.

This it how it looked like in the end :)

But what went right, was that we got something decent together. And doing something realtime 3D was fun. Tools used : - 3dsmax - Photoshop Although this Ludum Dare went a whole lot rougher than the previous one, we learned alot more from our mistakes this time. We’ll post a coding postmortem later this night Looking forward to the next one  Teamflare

As the competition is reaching it’s end, I’ve decided to add the post compo version to my game’s page so anyone who likes the game can always find it through Ludum Dare and play the improved version.

The new version adresses some balance issues and adds more stuff. If you’re interested, click HERE!
If you want to rate my game, please play the original version. Thanks!

We did a four and a half hour stream and edited it down to 37 minutes for those who want to see our progress.

It was a fun experience and we’ll hopefully participate next Jam too!

 

Happy New Year Everybody! As the competition results are coming, I’ve been working on a post-compo version of my game The One Fork Restaurant. It’s a kind of “time-management” game. It takes place in a restaurant where people come to eat various meals, but the restaurant only have one fork, so customers have to share it!

Since the compo, I’ve been doing the following:

• Added music and some new SFX, a credits screen and some animations in the menus (i.e. polishing)
• The highscore is now saved on the local machine
• Some fune-tuning to the game balance
• Added the ability to pause the game
• Released a working Android version

I’m currently looking for overall feedback, in order to see if there are any other areas where the game need to be improved! After that I’ll release the post-compo version officially (for now, this improved version is only published on my test server and only in the Web/Flash version).

Play the Work-In-Progress version here

Thanks in advance for your feedback!

Since there’s less than a day left until ratings are finished and I haven’t gotten around to doing it yet, I figure I might do a little post-mortem of my LD28 Entry One Jump (not to be confused with a couple of other entries with the same name). This was my 2nd Ludum Dare game but the first submitted for the 48 hour compo.

My primary aim during the weekend was to avoid some of the mistakes I did in my last entry (such as time management) and submit something playable in time for the 48 hour compo. Prior to the competition, I decided I wanted to use Unity (specifically the new 2D tools) for a couple of reasons:

• Familiarity (I’ve used Unity before but not for a Ludum Dare entry) instead of trying to learn a new language/engine in 1/2 weeks
• More widespread deployment: Compared to my last entry (which used XNA), using Unity meant that I could easily deploy my entry to the web as well as create standalone versions in one go.

I also decided that I wanted to create a platformer (mostly because I haven’t made one before and also because I didn’t want to create a top-down game where you move something in 4 directions and shoot stuff). The day before the actual theme was announced, I did jot down a couple of ideas based on some of the themes that made it to the final round of voting (although I didn’t actually have an initial idea for the one that eventually chosen). After the theme was announced however, it took me some time to think of a core mechanic that would fit it (To be honest, I didn’t really like the theme although ironically, due to the primary mechanics, my last Ludum Dare game would have been an absolute perfect fit for it). Eventually, I decided to interpret “You Only Get One”  as being able to do something that you can normally do many times only once. In the case of a platformer, the primary mechanic is jumping hence the main objective of my game: To simply reach the exit but being only able to jump once per level (which led to some rather strange and interesting level design)

What went right:

• Planning and Time Management: Compared to my last entry, I actually made much better use of my time thanks to the Unity workflow and managed to submit my entry in time for the competition.
• Levels: A common complaint with my last entry was that there were too few levels (about 4/5). Thanks to Unity, I was able to rapidly prototype levels in the editor without having to recompile and restart the game and created around 8 levels for my entry.
• Mechanics: Initially, I thought that being only able to jump once was too gimmicky (trying to design levels based on that mechanic was pretty hard as well as I wanted to make the player use their only jump at the right moment). In the end however, I was pretty satisfied with the end result.

What went wrong:

• Graphics: I’m not a very good artist so I decided to use simple shapes again for my entry. Unfortunately, I didn’t have enough time to change those shapes into something more plausible (but still somewhat crude).
• Lack of background audio: I initially created a small audio loop for my entry but I wasn’t able to get it to loop properly in Unity.
• General Platformer Physics: Although the game generally worked, some of the primary platforming mechanics were a bit buggy (having to create some momentum in order to jump, unintended wall sticking etc.). Some platforming elements such as the moving platforms didn’t work as much as I had hoped.

Initial Feedback:

Feedback for my game so far has been fairly ok (and better than I had originally anticipated) with level design being praised the most and some platformer physics/controls being the main criticism.

Overall Experience and What I’ll do in the Future:

Compared to my last entry, I didn’t enjoy this one as much as I’d hoped (mainly because of the theme) even though I managed to submit something in time for the compo. I did have a fun time however and if there was anything new that I’ve learnt during that time, it’s that I shouldn’t be afraid of submitting to the jam instead (rather than treat it as a place where I didn’t submit my compo entry in time): if my entry needs one more day of polish then I should take advantage of that extra day. During the period of time before the next dare, I will try to make at least some improvement with my graphics skills (or failing that, just collab with an artist friend for the jam instead).

Tags: LD28, post-mortem, postmortem, unity