After 3 weeks of judging here are the results!
This was my first Ludum Dare ever and i couldn’t be more astonished, i can totally say i had a BLAST ^.^! I think i did pretty well with Earth Defender, i’m so happy my game has got these results. Now i’m ready to do better in the next LD… YEAH!
Congratulations to all the participants, and thanks to everyone who rated my game!

Give it another play!
And Sign in HelkeGames’ official website for updates and other projects!

See you in another LD!

Ratings

	Coolness	100%
#253	Humor(Jam)	2.24
#380	Graphics(Jam)	2.81
#391	Fun(Jam)	2.57
#396	Audio(Jam)	2.19
#427	Theme(Jam)	2.77
#434	Overall(Jam)	2.72
#448	Mood(Jam)	2.37
#527	Innovation(Jam)	1.94

The technology behind

This Ludum Dare I only could spend one day for making a game and I wanted to try out a new technology (HaxePunk). Usually that’s not a good idea for a time restricted jam, especially with restricting oneself even further.

Working with a new language and library worked surprisingly well. Tuning down the scope of my game probably helped, but Haxe seems to be quite a convenient language to work with. The HaxePunk library was a great addition to have quick results, as most of the basic engine stuff necessary for my game was already in there.

For creating some ambient background sound for my game I had a nice idea: As it is finally spring now in Germany, I wanted to record some spring sounds, like birds. I did this with my phone, which worked pretty well. Unfortunately transferring the file into Audacity did something very strange to the sound and it was too late to figure out how to solve it. That is the reasons the bird sounds seem more like from a jungle than a mid-European garden.

What’s that game about

As mentioned, I didn’t have the full 48 hours, so I had to come up with something really simple. The basic idea has some resemblance to my LD23 game Bottlecolonies, but this time with free placement and only two different colors. This makes the gameplay probably a little boring quite soon.

Can you spot the similar concept?

The idea is, that with each new planted flower, the existing ones will grow through different stages. If there are negative influences around (potatoes, mushrooms, different kind of plant) and surpass the positive ones (same kind of plants) the plant will decay. Additionally, a feature implemented quite late, the mushrooms will spread for a while. So goal and strategy of the game is to place the same kind of plants close to each other, block spreading of mushrooms and avoid the negative stuff around your seedlings. The rhythm as how the two different plants are seeded is quite simple. Each three plants it will change. You will win the game if there are enough grown plants and will lose if there are too many decayed ones.

What went right

• Getting the idea (I already had this idea in my mind for OneGameAMonth for the theme “spring” and it also fits the LD theme)
• Fast progress with a new tech (I’m surprised by myself how well I got into HaxePunk)
• Making a Flash game (a lot more plays than usually with a Windows standalone)
• Finish in time (was a long evening, but I did cut the features early enough)

What went wrong

• Making the background sounds (as mentioned above, and took me some time to mix the few recorded sounds to not be to repetitive)
• Player feedback in the game (A lot of people mentioned it: an indicator for the placing position and some feedback what will seed next would be great; I agree)

So all in all I’m quite happy with my entry.

Go play and rate

So, minimalism turned out to be a great theme for me. I’d already been thinking about the idea of just doing a simple, fun game to relax after all of the hard work I’d been doing on my other game, so everything worked out. But not before a sidetrip through the insanity of development that was just a little bit more insane than usual.

I decided to take a well-known genre and pare it down to the core experience. Hence, a bullet-hell shooter with no shooting. The player doesn’t even have to click on anything–the click at the start is just to make sure your web browser is focused. While the art style references De Stijl, I felt that for a game the essence was in the mechanics, not the visuals, so I avoided the visual minimalism of horizontal and vertical lines in favor of an interactive minimalism of a handful of actors and the tightly defined but emergent relationship between them.

Despite everything in the game being a square, you can pretty much instantly tell how they relate to each other just but how they move and interact. I like how that turned out.

You can play the game here: http://www.ludumdare.com/compo/ludum-dare-26/?action=preview&uid=12047

What Went Wrong

Time

Technically this didn’t go wrong so much as I knew going in that this was going to be an issue. I had a major paper due the week of Ludum Dare, so there was no way I would be able to devote the full time to the game, or even very much of it. I actually wasn’t sure if I was going to participate at all until a late evening conversation on Saturday made me realize that I had to get this idea out of my head. I always make a point of sleeping properly and not disrupting my usual routines, so even though I had deadlines about to steamroll me I ended up putting in about three hours on the game Saturday night and picking development back up at about ten or so on Sunday. In total, I probably spent about twelve to fifteen hours on the game.

Audio

I knew I wanted to get audio into the game, but a bug earlier in the day had put me behind, so I ended up with three hours to go, no audio–and no idea how to add it, because Processing.js doesn’t natively do audio. I had to learn HTML5 audio and make the sounds in three hours or less. Preferably less, because I like to leave some extra time at the end of Ludum Dare for breathing room. It worked in the end, but I’d have liked to have a bit more attention to the audio–but not to add much, because the minimalistic effects that are currently a part of the game do fit the theme. Just be glad my screeching temp sounds got replaced.

Testing

The procedural generator I wrote is fairly clever, given the time constraints. It divides the different possible features a wave can have into buckets and then uses Perlin noise to select a subset of those features to use. But it needs a bit more tuning than it has. I was the only one testing it, so I knew the ins and outs of the generator, but other people take a bit of time to figure it out and mostly die when the difficulty curve ramps up really sharply at the fifth level.

If I had been able to watch other people play the game I probably would have been able to avoid the other big problem, which is that there’s no “Game Over” screen. I didn’t need it while I was testing, and I didn’t care what my score was, so I didn’t notice that it was missing. But having one turns out to be really important for the game. Adding it in was a simple 26-line change, and the post-comp version has it, but I feel that if I had other people test it during primary development the game would have ended up even better than it is now.

What Went Right

Processing

Processing was a great platform to work with. I had to implement my own collisions, but that wasn’t a problem since I already knew how. I was able to use a lot of programming tricks that are technically feasible anywhere, like adding easing to most of the movement, but Processing’s immediate feedback let me fine-tune to get the exact feel that I wanted. And feel is a huge part of a game like this. Processing.js was easy to get working once I figured out which PVector functions weren’t implemented yet–in fact, it was so easy that I switched to make the web version of the game the primary one for the competition release.

Scope

I gave myself permission to not do everything. That is, the game wasn’t going to be the best graphics, the best sound, the most innovative concept–I was going to focus on making a game, not starting a revolution. Minimalism turned out to help with that, since it let me make a game that is deliberately about the most basic expression of a core idea.

No Feature Creep

Speaking of which, minimalism gave me an excuse for avoiding feature creep. Every time I had an awesome idea for something that would be an awesome addition to the game, I could just say, “Nope. Minimalism,” and go on my way.

Source Code Control

I took a few minutes on Sunday to set up a git repository for the game. I never ended up needing it, but it let me experiment, knowing that there was always going to be a mostly-working version of the game that I could go back to. I can, right now, jump back to the compo-version or forward to the post-comp changes with no trouble at all. If you aren’t using source code control, take a few minutes to learn how. You won’t regret it.

Conclusions

Keeping yourself healthy is important, even during a crazy crunch situation like this. I made a point to sleep and eat–and that really helped when I needed the energy and concentration to learn a completely new thing three hours before the deadline.

Finally, the community is a big part of why I participate. I make a point of rating a bunch of games–nowhere near all of them, but as many as I can find the time to do. I’ve already incorporated some of the suggestions I’ve received into the post-comp version I’m working on. I try to leave feedback that will help make the games better and I encourage you to do the same.

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

Ooops, we did it again

Ludum Dare 26 was a great chance to make something different and step out of our comform zone once again. This time the chosen theme was “Minimalism” and we tried to make a “minimalist stealth game”. Well…sort of

“Design choices” or “72 hours to find the fun”

The Ludum Dare Jam rules have an hard constraint: you only have 72 hours to create an original and playable game! This forced us to use a very practical approach to game development and many design choices were influenced by it.

Here’s what the game is about: it’s an online multiplayer game about two teams, the Guards and the Thieves, fighting to win the match.

Same level, different visuals: Guards (left), Thieves (right)

Thieves goal
When the match begins the Thieves receive a message specifing what is the object to steal, and they win the match when the stole it and then escape from one of the exit points. Thieves have only little HP but they have “night vision” goggles, so it’s easy to hide in the shadows (or inside a bush) where the guards can’t see you.

Guards goal
The Guards have to defend the objects in the map for 5 minutes to win the match, but they don’t know which object is the real target of the Thieves. These poor guards doesn’t have fancy night vision goggles, all they got is a cheap flashlight but their armor gives them more than double HP than the Thieves.

Did I mentioned, that both teams have guns? Yeah, shooting is always fun but beware of friendly fire

Also, the key to win a match is to strategically use the level to your advantage, like switching the room lights on/off or if you’re a thief planning to outsmart the Guards patrol routes trying to pass through windows.

Art and level design

Artistically we choose to keep all the 3d models fairly lowpoly and use a really simple texturing to maximise the amount of models that a single human being can create in 72 hours.

3D Models! Lots of small models!

The same approach was used to create all the 3d models for the environment like walls and floors. All these models were created in a modular fashion (think Lego blocks) so that we can assemble and test a map in a few minutes of works inside Unity.

Top view of the map. Unlit (left), lighted (right)

What went right

• We completed it in 72 hours!
• Spotlights with dynamic shadows in a dark environment are always a win
• Unity networking worked great for this kind of game, with player hosted games handling up to 8 players without any serious issues
• We received a lot of good feedback about the game and we had fun playing it with random people online as well as with friends

What went wrong

• We run out of time before starting to create the animated characters
• We didn’t find the time to include different sets of weapons or gadgets
• Player firewalls sometimes prevent people to host games
• Without dedicated and persistent servers isn’t easy to find people to play a match.

The future

So, is this prototype going to be the starting point for a future full game? Absolutely!

What’s missing?

• Characters models, because a shooting capsule isn’t really that cool.
• Dedicated 24/7 servers: because it’s easier to find a quick match and will have a better network connection than your home broadband (less lag!)
• New maps: because…well, you know…
• More gadgets for both sides: placeable proximity sensor with alarm (guards), stun weapons (thieves), etc…
• Guard bots: because sometimes you have the urge to team-up with your friends in a co-op match and just assault a bank having lots of guards to outsmart or kill. Like to good old days!

Try it!

You can play and rate “Of Guards and Thieves” here: http://www.ludumdare.com/compo/ludum-dare-26/?action=preview&uid=14628

I know, a lot of people propose to start with a playable prototype and set up proper gameplay as fast as possible, but I noticed something during the last jams…
(more…)

my entry for this LD

click this to view my entry

this game is about shooting a jumping apple with limited bullet every stages, in the first few stage, you will only just see some apple jumping. after that you will begin see some purple triangle that can bounce your bullet. in some level, you have to bounce your bullet to shoot the apple. another thing to consider when playing this, is that combo mechanic. you will get a message showing like ” X combo!!” when you shoot more than one apple with one bullet. this message mean to encourage player to try shooting all apple in one shoot.

enough about the game, now I want to write about how I get into making this game.

ludum dar compo consist of 48 hour or two days. in my country, ludum dare always start in saturday morning, around 9 am. so usually I know the theme just several minutes after the anouncement. for this ludum dare, I spent a whole day thinking and brainstorming about idea and mechanic of the game with minimalism in mind. what I had in mind other than minimalism, is that I want to make game that only controlled by mouse. this kind of my own goal that I haven’t reach that time. so for a whole day thinking about that and there’s no idea come out. actually I try to code some idea I have in mind, but stopped because I think it’s unfinish and still need more thinking to make a concerete game mechanic. what I want to implement about minimalism is in game mechanic. I want to make it simple but still enjoyable and maybe can bring more depth in gameplay. sunday started and I still struggling with idea, I fear that maybe I can’t make it in time. and than around maybe 10-11 am, I got the idea about shooting some object that bounce or jumping, first I’m thinking about rabbit but ended up with apple, I don’t know why. after the arrival of my idea, I rushed to my laptop and start coding. after the core mechanic done, and creating a few level. I need to add more mechanic to enhance the gameplay. that’s when I got the idea of bouncing bullet. actually this idea is a bit hard to implement for me, because I  don’t know how to simulate a real bouncing physic and I got a deadline just few hours ahead of me. so I make those triangle thingie to somehow fix the angle of bouncing and somewhat make some sense and easy to understand. after that, it’s time to make a levels. after all those coding, this is the hardest part when you make a game that based on stages or levels like angry bird, cut the rope, etc… I need to make every stages challenging but not too hard. because all my games before this ended up too hard. and even it’s not challenging I too like stages that refreshing, like maybe you can shoot all those apples in one shoot and the bullet bouncing through all corner of the stages.

monday morning, I wake up and remember that I’ve submit my entry last night. if I’m thinking how it ended up like this considered that I nearly frustrated in the first day, but I kinda like how my game turn out, comparing to my two others entry ld 24 & 25, this time my game feel more complete but still not polised. maybe I need to thanks to onegameamonth & mcfunkypants. because all those experience I got when making games every month really help me in this LD. I hope my game for this month 1GAM turn out great too.

sorry for my english XD

This was my first participation to Ludum Dare and to a Game Jam.
I played games from previous jam, but this time “I’was in”.

About the theme

I’m a fan of clean manga and “bandes dessinées” (ligne claire), of “minimalist” web design “minimalist”.
Daily I work on a game vdrones with minimal gfx (triangle, cube, plan), sound, …

So I should do something different.

"Google Search" page is a famous example of "minimalism" web design. So start on a game with a visual like it.
+ An other place where we use minimum keystroke : chat, forum, coding,... via abbreviations and acronyms
+ gamefication (try to include fun and juicy)
----------------------------------------
= AbbrevsMaster

What wrong ?

about game:

• I prepared some stuff (atmosphere, color palette, libs of code, …), I nearly use nothing
• poor abbrevs’database
  • not tune, simple copy / paste from some web page
  • the random selection in list should need to integrate a popularity weight of term
  • I failed to read data from a wiki page (github) due to security issue, spend too many time to try
  • I didn’t find an online service that allow to request by category
• No introduction (instruction, credits screen)
• Not enough funny juicy animations when traduction are crunched (quantity, quality)
  I could not fix a bug in css 3d transformation.
• The fun is hidden, the game is hard
• no time to provide an Assistant
• not enough gameplay tuning
• It’s not the kind of game I enjoy to play
• Not enough time to provide a way to share score

misc :

• not enough reuse
  • I didn’t reuse all the code (lib, framework) I prepared during previous week
• very short night
• I didn’t post progression, I was not aware of others participants.
• I failed my timelapse recording (glapse has no pause).
• Not enough preparation, I didn’t follow my pre-roadmap
• Last hour on a stupid bug in audio
• Stack email, news, … during 2 days
• I found the name (title) when I filled the submit form.
• Crappy code (and image) lot of places for improvements

What Right ?

• I submit a playable version (80% finished) (last deployement at H – 30 min)
• I was able to reuse audio code (, build code from other project
• I toke time for my friends and familly (saturday afternoon)
• Using a kanban (Trello) vs todo file.
• I successfully try freemarker as css preprocessor (day 2, I should use it day 1)
• Very stimulating
• Good wife’support (Thank you Darling)

Next time

• Prepare better (real project skeleton, timelapse recorder, video capture)
• Try to improve and to enjoy

AbbrevsMaster

An now it’s time to explore LD games (to play … to rate)

Here is a run-through of what went right and what went wrong in the creation of my game entry, Minima.

Minima is a simple game of dodging fast-moving enemy spaceships with the cursor or W, A, S, and D keys.  The original game was made for Windows using C# and SDL.NET.  It has since been ported to Flash for the web.

The Good

This was my first time competing in Ludum Dare.  Two days is an incredibly limited amount of time to produce anything game related, so I’m glad I finished it at all.  The contest was fun, and I now have something to add to my game development portfolio.

I felt well prepared for the challenge, partly because I’ve been writing business software for many years and I’m accustomed to scope management and tight deadlines.  But I also got a lot of good advice from a Ludum Dare survival guide, most of which I followed.  I got plenty of sleep, ate sensibly, and didn’t overdo the caffeine or sugar.  I took frequent breaks and went outside occasionally for sun and fresh air.  In some ways I lived more healthily than I do on most other weekends.

I resisted the urge to refactor, optimize, or maintain clean code.  This goes against every instinct I have as a developer, but 48-hour dev contests are the exception to the rule.  When you’re the sole programmer on a project this small (and a deadline so short), you can keep everything in your head.  As far as I can tell, Minima is relatively stable and bug-free.

The Bad

I decided to address the “minimalism” theme with a specific game feature, and that was my first mistake.  Games made in two days can’t have “features”.  For the most part the core game mechanic is the feature, and everything else gets cut.  As a result, my game is somewhat bland and uninspired.

Going into this, I thought I knew my toolset pretty well.  I use Visual Studio and C# every day.  The problem is that game libraries are just as important as the core language.  A lot of time was burned reading the SDL.NET docs and generally stumbling around the library.

I didn’t really think people would mind downloading an executable and double-clicking on it, but it turns out that when you’re trying to rate dozens of games, downloading stuff is annoying and gets in the way.  Therefore, I learned Flixel and ActionScript and ported Minima to Flash as quickly as possible.

One almost-disastrous mistake was waiting to test on a non-dev machine until last minute.  Of course, when I tried it the first time the game crashed immediately, and I spent the last two hours of the contest figuring out which files were missing from the package.

I wasn’t prepared at all to create a soundtrack for the game, which is funny because I’ve composed a lot of electronic music in the past.  I downloaded some sequencing software and fiddled with some samples, but it just wasn’t coming together.  In the end I wound up downloading a free sample loop and playing it repeatedly in the background.  The effect is decent.  Next time I will be far better prepared.

Overall, I enjoyed my weekend and I’m inspired to create more.  Thanks to everyone who makes Ludum Dare possible.

Play the game!

I considered calling this post a postmortem… but I believe my LD entry My Little Robo is pretty successful for a first timer so “postmortem” would sound too pessimistic. Hence “after action report” – sounds way more upbeat, doesn’t it? Later I will also prepare a sort of “pre compo checklist” based around my experiences.

What went wrong?

• Integrating physics engine with cocos2d-x html5 – I was foolish enough to assume that if I would need physics engine I would figure out how to use it as I go along. How difficult could it be? It turns out that engines are not that difficult, but oh the documentation. It might not references the same API version as yours. It might not be written with Javascript in mind. It might turn out some stuff is not mentioned at all (like the namespaces). Figuring it all out I wasted several hours I could have used for other things.
• Javascript can make you cry – I am used to programming in C++ and encountering certain bugs like a mistaken variable name, or a lost comma in class definition at runtime was a bit nerve wrecking, especially combined with cryptic error messages.
• No sounds or music – I really hoped I will have time to make some music and sounds for the game, but because of physics engine integration problem I did not have time to do that.
• Physics instability – getting real time physics simulations to be stable can be difficult, especially when using physics to create gameplay – again something I could have done better if I did not waste time setting up the engine.
• Submission – Screenshots? I need my own place to host the zip file? Oh shit. I’ve got a shared server but I couldn’t find an option to upload anything to it, dropbox for some reason couldn’t finish uploads because my bloody ISP was apparently doing some late night infrastructure repairs. After a while I remembered that my wordpress blog allows uploading a zip file and used that, but that was about 5 minutes before the deadline.

What went right?

• Picking an innovative and extendable game idea – I’ve spent about 2 hours considering various ideas before I settled on the minimalistic robot. Compared to other options it was a bit more ambitious and risky, but the risks totally payed off. Judging by the comments, LD crowd likes innovation even if it is not perfectly executed and being praised for an original idea feels awesome.  Also LD judging can be considered a “free focus group”. And it showed me that, yes, my idea is worthy of a longer game. Which is exactly what I plan to do now – have I picked a simpler idea or made a demake expanding would be more problematic.
• Using a web based platform – Javascript might be a bit difficult to get used to, but making a web based game was the right choice. Judging other entries I’ve quickly noticed that I am always relieved to see the web option. Also this should make it easier to publish the improved game later on.
• Javascript – While Javascript is irritating at times, it allows for quick iterations, debugging tools are nice and Javascript platform forces open source code. This last thing was a life saver, since it allowed me to dive in and debug inside the engine and to get to the bottom of the issues faster.
• Detailed running TODO list – this is a technique I’ve developed long time ago for dealing with having to code fast under a lot of stress and fatigue. I first write down the features, then break them down into essential implementation steps. If during development I get any idea of extra check that I should make, or another place in code where something should be changed – I add this to the list. It all works like a charm – frees up the short term memory, prevents forgetting important details and crossing out stuff that’s done is a great morale boost.
• Source control – a pretty obvious thing. More than once I was really grateful I took those few extra seconds to setup mercurial before starting coding. Also frequent checkins should be practiced – you never know when your tired brain will fsck something up.
• Precooking – cooking a lot of food before the compo that can be later reheated. It turned out to be a really good idea, eating a proper tasty lunch or dinner is a great morale and energy booster when you are programming for 8 hours straight. I should have secured  stash of some healthy snacks too.
• Taking part – this was overall the best idea of all. Even though my submission was not as polished as I would like it to be, still many people enjoyed it and I very much needed such a confidence booster.

(Play it here )

Hello everyone! I’ve received a few questions about my process when making this game, so here goes my postato-mortem:

The Theme

Yeah, so the theme was alright. I didn’t vote for it, but whatever.  Actually, I probably wouldn’t have reached the level of completeness in the game that I did without the theme forcing me to keep things minimal.

I assumed that most people were going to go minimal in graphics and game play, so I set out to interpret the theme a little differently. I decided on making a game that was minimal in goal, time, and information. I wanted it to be deceptive in its apparent simplicity and, more importantly, make people laugh. Oh and it also needed a potato. So almost immediately after deciding on these constraints, Get The Potato was born in my head.

Audio

So a lot of people have commented positively about the audio in the game. I was surprised at how well it came together, as I am not a sound designer by any stretch. I’ve been asked about my recording setup, as well as how I synced the audio to the lighting, so I will address those quickly.

For recording the announcer voice, I screamed into a CAD U37 USB Microphone and a pop filter. Nothing too fancy.

Then, using Audacity (one of the best pieces of software ever made), I’d drop the pitch by 2 or 3 half-notes and apply a robotty effect I learned from this tutorial a few LD’s back. I didn’t want the sound to be too robotty, so I adjusted the delay settings slightly, which can be seen here:

You should definitely try this effect out. It’s fun!

As for syncing the audio with the light, I found some fancy code by a gentleman named aldonaletto that allows you to get at all of the sample data of an AudioSource in Unity while the sound is playing. All I needed was the RMS value, which is a float value between 0.0 and 1.0 (making it perfect for scaling and whatnot), so my implementation ended up looking like this:

(Just stick that on a GameObject with an AudioSource attached and you’re good to go!)

I then applied the RMS value to the range of my main point light, and also to its red and green values to give it that transition from yellow to red.

Game Play (**SPOILERS**)

I wanted players to have the feeling of being thrust into a strange situation on no information other than that for some reason they needed to get a potato, and I think I achieved that, for the most part. I found that people who regularly play FPSes on PC were at a distinct advantage. For everyone else, WASD controls are really awkward, and they soon found themselves stuck on just the third level in the game.

With this level I was trying to recreate that moment in Super Meat Boy when Bandage Girl is *just* out of reach and the only way to reach her is to know about the sprint button. I, admittedly, was stuck on that level for quite a while until my triumphant and face-palmy discovery of said button. In the case of Get The Potato, the potato is only reachable if the player uses the sprint [SPOILER](Left shift)[/SPOILER] key. This was an easy discovery for seasoned FPSers, but many people did get stuck on this level and promptly gave up, which is sad and entirely my fault

This brings us to the next major roadblock in the game. Level 5:

I would say that a vast majority of people gave up at this level. It was intended to be confusing, but it didn’t help that I failed to implement this level properly at release time. It was supposed to be a simple introduction to these mysterious purple cuboids [SPOILER]that you can walk through when they’re off screen[/SPOILER], but many people were able to air control around this one (which was NOT supposed to be possible), causing that discovery to be completely lost to them and adversely affecting their ability to complete the later levels. The best (worst) part is that the cuboids make shrinking and expanding noises when they go off and on screen, but the music drowns them out, rendering them useless!

Ok, this is getting long.

What Went Right

I’d say my decision to use Unity this time around really helped out the most. It just took a lot of the stress out of the weekend, allowing me to focus on my priorities which were implementing humor and game play.

As I said earlier, the audio worked out better than expected. This was my first time using this microphone for an LD. Oh and I have to give a big shout out to LazerBlade on YouTube for his Music Hacker series. Taught me everything I know about working with LMMS.

Overall, the greatest achievement of this Ludum Dare for me was the plot twist (or “potato twist” as someone coined in twitch.tv chat) I was able to implement at the end of the game. I don’t want to brag, but it really puts Mr. Shyamalan to shame. You really should beat the game now. Beat it for humanity.

What Went Wrong

The only thing that really went wrong was that I waited until the last couple of hours to start making levels. This forced me into making last-second changes to the ground/air control code to adjust to the new levels, which in turn exposed holes in other levels. The control code in the final version is kind of a duct-taped mess.

Thanks

Firstly, thanks to everyone that played and rated my game. You didn’t have to get the potato, but you did. You did get the potato :’)

Thanks to everyone that made games for LD 26. YOU F******ING ROCK.

And finally, thanks to Mike and Phil for their efforts in running this thing. You also F************ING ROCK.

That’s it! See you all at LD 27!

I usually don’t know how to write these kind of things but I figure I try and write as much as I can about how my game turned out and what it was like taking part in and actually completing my first Ludum Dare.

Long story short, Only One Shot is a game where you must shoot all the enemy squares to complete the level. However, the game adds a twist where you must do this with one bullet otherwise you fail the level (Hence the game title). But how do you kill more than one enemy with just one bullet (especially when the enemies are spread quite far apart)? This is where the reflector blocks that are placed around each level come in. When a bullet hits a reflector, the reflector will spawn a bullet from each side apart from the side that it was hit on. In levels containing more than one reflector, the game almost feels like a Rube Goldberg machine where one bullet starts up a long chain reaction just to kill some enemies in one go.

What went right:

• The Graphics: Having minimalism as a theme meant that I didn’t have to worry about the art (since I can’t draw to save my life XD) and sort of essentially get away with simple (if somewhat crude) shapes.
• The Gameplay: Trying to interpret minimalism in terms of gameplay mechanics was a bit difficult. Whilst I could have made a simple one button game, I wanted to convey minimalism in the sense that the simplest of things (either one or nothing) are only needed to start a huge reaction hence the one bullet rule of my game. From this core concept, I managed to create a game with simple, yet deep mechanics.
• Having a Plan (and mostly sticking to it): Once I had decided on the core idea of my game as well as figured out the type of game I wanted to make, I decided to flesh my idea out a bit further by brainstorming and jotting down notes on a pad before I get started on doing some actual coding. Although some features I had planned in my notes did not make it into the final version of the game that was submitted, doing this really helped in two ways: Firstly, having a plan to stick to meant that I was able to get most of the essential concepts of my game done in time without the distraction of bloating up my game with unnecessary features and secondly, having a plan meant that I would have a concrete idea of what to code without the risk of suffering mental blocks (if I had decided to just jump in and start coding without one).

What went wrong:

• Time Management: This was probably by far the biggest fault I had with the game. Originally, I had planned to get the game completed and submitted in time for the compo but overall, I wasn’t really making full use of my time as I was either too distracted to work or taking too long on one task (The collision code for my game between the player/enemy and the walls took one long tedious Sunday afternoon to do and most of it was wasted on trying to work out which parts of the collision boxes have overlapped before I eventually realised that I could just use the direction vector of the player/enemy and use that instead whenever the two collision boxes interect and reposition accordingly). Having to work on a Monday didn’t exactly help either which meant that I was only able to work on the game during the evening but fortunately, my game was nearly done and luckily I managed to submit it in time for the game instead (despite the fact
• The reflectors: Although the basic function of the reflectors worked out pretty well (spawn additional bullets when hit), there were a few glaring bugs in the overall functionality which meant that they didn’t work out exactly as I had envisioned. The most obvious bug was when a reflector would spawn bullets when it wasn’t recently hit. During early playtesting, an endless stream of bullets would sometimes spawn from a reflector for no reason causing the game to unfortunately slow down and crash. Although the bug still persists, I managed to work my way around it by adding an extra flag in the logic that checks for a game over condition.

Initial Feedback:

To my own actual surprise, the initial feedback for my game so far was really nice with most saying that they loved the overall concept of the game (with some saying that they would love to play more levels) whilst criticising the fact that the player moved too slow and that there was no way to tell which way the player was facing (a fault of my own in trying to keep the art as simple as possible).

Post-Compo Version? :

Due to the positive feedback that I have received, I am considering making a post-compo(post-jam?) version of my game (depending if I have time) fixing all the bugs I wasn’t able to fix during the 2/3 days of development as well as tweak the game based on feedback (i.e. a faster player and a way to work out where it’s facing) plus add some extra functionality whilst keeping the core mechanics and art the same (although I may consider adding some extra polish to the art as well). To keep things fair however, I would only consider starting work on this version once the judging period so that way I can take all the feedback and work out what needs to be changed.

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

For me, taking part in my first Ludum Dare and actually completing it was a rather scary yet fun experience and despite the fact that some things didn’t go exactly as planned, I feel that my gamedev skills have improved (a bit I think) further. For the next Dare however, I will be working much harder to ensure that I am able to submit something for the compo rather than the jam by working hard to improve on my graphics skills (which I find terribly lacking) so that I don’t have to make something rather crude and simple (unless it’s actually better to go that way). I might use another engine for the next Dare (I’ve used Unity before) or perhaps learn a new one (I’m looking at you LOVE). After all, there’s only roughly 3 more months I have left to start improving my skills until August

And now for a selection of some of the nice comments that I have received for my game…

“Really cool concept. Would have loved to play more levels ”

“Cool bullet splitting mechanic! Work on this, you have a neat puzzle game idea on your hands ”

“Great game, I loved the concept.”

“Simple, challenging, awesome. Simple, yet smart design.”

A bit late, but here’s the postmortem of our 3rd jam game together: Erase

Play and rate It here !

Foreword:

Sorry for the bad English, we are French.

Design vs Code :

The major problem with our team is that nobody has high knowledge in coding, the game designer has had to take on the programming task. In addition to making something in accordance with the subject, we had two limiting objectives.

The first one was to do something you can do. Obviously, the topic was an open door to an abstract gameplay. The problem is that even though we have the ability to imagine it, it was impossible to code it. We have chosen a simple base (a platform game) as the foundation of our game / topic interpretation. The platform game advantage is also that it’s known by all of us, and allows a rapid progression in the subject.

The second challenge was to make a game really Gamee. We don’t like things auto-claimed Indie in which players are completely inactive. We love indie games, but we love the game over all, and it’s important for us to produce something with a challenge to both brain and skill.

If the game is only a reflexive object, we don’t need to do it in video game (a card or board game is the same) which is why the address aspect is important for us, it’s a unique component of digital game. Conversely, if the game is just a skills game, it no longer carries the whole topic.

Theme :

Among the list of potential topics, Minimalist was the one we liked the least (more relevant to the compo than for the jam we think). A priori, minimalism is a trend to remove all of the work that isn’t necessary to the core idea in avoiding unnecessary emotional or sensitive element.

Quickly, we’re start on the idea of staging the iterative removal of unnecessary elements of the game. The idea was to realize a platform game composed of a series of little level /puzzle with several features and decorative elements that the players have to destroy in order to solve the riddle. However, it was easier to find the idea than to done it, and the concept of clean-up the asset at maximum curlicue was actually very difficult to achieve.

In addition, the theme interpretation makes sense when the game is done as a whole and when you arrive to the final level without assets, with few sounds and a character without features.

Realization:

The first night served to the basis codec implementation (the character and features, feature deletion, camera, collisions etc.). As we used Construct 2, this implementation was pretty fast. Meanwhile Mathilde and Alexandre were able to reflect the visual and audio aspect of the game.

Unfortunately, the game design work couldn’t be done quickly (efforts was concentrated on the code) and thus clear explanation of the game principle documents was missing, and therefore until the second day, the creation been difficult. Therefore the following days were more devoted to the creation of assets, levels and integration.

From a graphic design point of view, for a long time the results weren’t enough satisfactory and concepts were thrown away or converted without success. It was difficult to find a graphic charter in agreement with the theme, graphic and minimalist, which has evolved through the levels to represent the character life cycle and depending on the level design. For reasons of time constraint we had to start to make assets without being satisfied with the result and the guideline was found while the levels integration had already begun.

In the initial audio concept, was to form melodies which are decomposed over the levels outcome; however it was rather difficult to achieve an atmosphere both pleasant and minimalist. Communication between the sound aspect and the rest of the game for more than half the Ludum dare was almost nonexistent, which gave us a too late visibility of the total project, due to poor organization. Thus, inspired by Steve Reich on “Music for 18 musicians”, the audio is a music track that mix evolves through the levels. The sound integration hasty made at the Ludum Dare end, which didn’t allow us to do something up to our ambitions (a number of songs weren’t included).

From the game design point of view, there were a lot of things to balance without having the time to do it (notably find a compelling collision box for the triangle character). It was paramount for us that Character is pleasant to manipulate (as Easy-fun sense). It was important to gain momentum (especially the jump), and Dash feature inspired by Rockman X or Sonic in which the feature isn’t fundamental for finish the level but brings dynamism in control, the goal is to push the player to use the exhilarating but dangerous non-core features (the dash is required just in Level 4). But the fundamental interests of the number of features comes with the Erasing and self-Erasing feature. As a first step the player clears level elements to solve the riddle, but from level 5, player has to self-destruct its own features (Jump, Dash or Shoot) to finish the level which requiring a strategic choice in the level course.

Where we failed to use the self-destruct feature is because we don’t have enough levels to a slow difficulty progression and establish levels in which the destruction choice is a real dilemma. In other words the time devoted to the level design was too short and therefore the level is far below the potential that allows the erasing and self-erasing features combined with the three features.

Conclusion:

This is the 3rd jam that we did with the same team and we met some difficulties we had never encountered before such strangely more stress and lack of sleep than in GGJ for example. Nevertheless we are happy to have finished on time a version of our game, a game that far from being perfect, who despite the lack of polish, shows anyway few good ideas and quality realization.

What went right?

1. Mechanics coding: construct is a powerful tool for jam.
2. Graphics: Because lot of people congratulated Mathilde’s graphic design.
3. Game is realized in time (but with few bugs), and it looks nice.
4. The erasing and self-erasing mechanics could be used through lot of level, the idea could be developed with better (and harder) level design.

What went wrong ?

1. The theme was pretty hard for a team with a graphic designer and without a real coder.
2. Coordination on the theme interpretation
3. Resource integration time.
4. Graphic research, it was difficult to realize different assets for the different levels, keep a graphic style and represent the life evolution of the character with abstract shape.
5. Time devolved to Level design.
6. Not enough time to test.

We took our time, but we finally made it! So here it is:

What went right?

- The creative process

We did some brainstorming friday night on “minimalism”, called it a day and returned to discuss some of our ideas early on Saturday morning. As we stated before, we love alliteration (“the occurrence of the same letter or sound at the beginning of adjacent or closely connected words”) so we decided to take a shot at minigolf (some minimalistic minigolf). We thought about the constituent elements of minigolf (a ball, a hole, some obstacles and a swing) and wonder: how can we make this even “simpler”?

- Control mechanic
Control mechanic is a core part of lots of games. Some time ago, we interviewed Simon from Simogo (a great game studio!) and he told us: “We usually start out with some control mechanic, and then build a game around that.” Well, we did that and started our “minigolf simplification process” by thinking about a “minimalistic swing” that includes only a radius as a golf club. With this mechanic, we achieved to reduce two inputs (power and direction) into only one action: drawing a radius. Player would draw a radius holding the mouse click (or the swipe, as we intend to port it to iOs & Android!) and when released it would rotate anticlockwise in order to hit the ball. The more it rotates, the harder the hit! So power and direction all-in-one control scheme!

A nice video we watched:

- Some early marketing ideas
Happy with this control mechanic, we started thinking about marketing (it’s never too early for some crazy marketing ideas!). We chose a name: “Radius minigolf”. Sounds good, doesn’t it? It had certain je ne sais quoi and it would be easy to remember. So we bought the .com and made some banners.

- Framework
We love Unity!

- Betatesting
We made some awesome shots testing the game. Thanks to Vine you can watch them!

Nice shots! #radiusminigolf #ludumdare vine.co/v/bQrLKuPP25Y

— Nico Saraintaris (@NicoSaraintaris) May 7, 2013

What went wrong?

- Game mode
Due to the timeframe, we decided to go for just one mode: a time mode. We know it was not the best for our game, but it surely was the fastest to develop.

- Level Design
Time again. We did not have enough of it to design each level, so we generated them randomly using the same set of numbers.

What’s next?

- Mobile versions (iOs & Android)
- Different game modes (18 holes, 9 holes, free mode, time mode, etc.)
- It would be nice to have an integrated level editor, and some kind of community driven system to share levels.
- Experiment with some changes in the pov and camera movements. Actually we have a fixed camera, and giving a little movement would make the game much more attractive!

And last but not least: PLAY AND RATE THE GAME!

Cheers, people!

Preparation

There’s no real way of preparing for a Ludum Dare. The theme on which people make games on is only revealed once the event starts.

So, in the week leading upto LD, I focused on finalizing the tools I’ll be using. I had previously used GameMaker,XNA and Stencyl in varying measures but Unity had always been my ultimate target. Besides Unreal Engine, it is the only top-tier, professional-grade game engine available for hobbyists and indie developers.

Since I had never worked in Unity before, I set myself a task to atleast get a basic feel of its’ features. It was more difficult than I thought. It took me some time to wrap my head around its’ coordinate system, scripting of main camera, particle system and I had to even brush up some of the high-school physics and math concepts.

It was fun and challenging to learn but I knew the real challenge lay ahead.

Challenges Ahead

It was never going to be easy. In that very week, I had THREE back-to-back practical exams. So, I spent Wednesday,Thursday and Friday on them. Also on the day LD was going to start (with the announcement of the theme) I had to give my Senior Year project seminar in the college. So chances were that I was already going to start a good 8 hours later than everyone. Plus, I had a birthday lunch I was obligated to attend to on Sunday and I couldn’t excuse myself out of it.

It only got worse.  My Internet provider called up saying the maintenance of Internet would mean it would be down till Sunday morning. Just great. 

Basically, if I was planning to aim for the 48-hour deadline, I was already going to have to work with 10 hours less and without Internet to help me. Not a good start for things. I told myself that even if I wasn’t able to finish it, I’ll learn something.

With that positive mentality (hear O Pro-Life Preachers!) I went into the weekend.

Theme

When I woke up on Saturday morning, I immediately checked the site and found that the theme was “minimalism”. Since I had a project seminar in few hours, I had to get ready for that but I kept thinking about the theme and what ideas I could adopt into a proper game that is fairly unique but not too difficult to make.

Surprisingly by the time I reached my college at 9, I already had charted a rough concept and I wrote it down. By the time I was done with the project seminar (which was delayed no thanks to the lovely professors of our college) and I had returned home, it was 2. I took a short nap and began at 3.

Timeline

I had decided on a dynamic rhythm game with simplistic two-control scheme that had a rather deep underlying concept but absolutely no exposition.  Dynamic in the sense, the players could adjust difficulty of the game through their own actions. Create/destroy musical objects which repeat to form a pattern imitating one’s daily routine.

With the basic premise on paper, I began getting the setup ready. The LD’s “Compo” rules state that all the content — code,art and music needs to be made within those 48 hours. It took me a 4-hour sitting to get the engine set up exactly how I wanted for my game.

I then began coding the individual behaviour of the player “cube” and it was around 10, I could finally start working on the chief concept of the game — recycling objects. This required creating a custom module. Something which a newbie to Unity like me obviously suffered to do.

Unable to find solutions, I decided to plug in my MIDI keyboard and create some tunes in the meantime. A rhythm game needs to have some good tunes after all. I stuck with ambient music as the background soundscape as I felt it was minimalistic and sparse enough to suit the theme.

I used FL Studio for the beats. I really liked the simplistic interface and how easily one could mix. For the MIDI, I used the typical MAGIX Music Maker and stuck with the traditional play-record-mix-master technique to get the appropriate sounds. I liked how I could imitate sounds of a flute and of a violin using a low-pass filter applied onto lower keys of the keyboard.

While I was doing this, I was constantly trying to rack my mind to solve the issue  I was stuck on. It was around 3:30AM when the migraines started creeping in and I finally gave up for the night and went to sleep.

New Day, Late Beginnings

I had set my alarm at 6. I snoozed it.

When I next woke up, it was 7:30AM. Ugh.

Within 10 minutes, I was back to work. And tell you what, it took me just 10 minutes to crack the problem that was plaguing me for almost 4 hours last night. Just ten minutes.

Over the next three hours, I was on a roll speeding through the lost time last night. If this were the popular Kairosoft’s Game Dev Story, I would be a programmer “on fire”.

Unfortunately, my mean streak came to an end when I had to go for the birthday lunch. I came back at around 2PM and graciously avoided the comforts of an afternoon nap and set back to doing. I had been feeling weirdly confident since morning. As if, despite all the odds that had been stacked up against me, I was going to do it. At the same time, I was a little wary of being like a hare in the Hare and Tortoise and not getting too overconfident of where I was.

So, I continued working without a break. More tunes were created by 4PM, some of which were recorded live using my iPad and SoundCloud app on it.

Then I set aside everything to work on my primary weakness – art. I believe I have a decent visual aesthetic sense, but when it comes to creating them I’m no good. There’s this inherent phobia that drawing instills in me which seems to sap all the confidence I generally have for other things.

So, I got onto it. Using Inkscape and Photoshop, I created simple designs that described the type of instruments each track was imitating and keeping the color palette fairly simple.

I did not believe that minimalism = black & white. In my opinion, minimalism is something which conveys a deep concept through limited usage of aesthetics and exposition(if used in a narrative context).

So, as you can see the colours I used were a lot more vibrant than what most of the others used for their games.

It was about 8PM when I was done with art and sound. So, I started implementing them into the engine one by one. Surprisingly, art didn’t result in any obstacles. It was Unity’s sound design which gave me trouble as I couldn’t wrap my head around how I should use it to fit the purpose of my own game.

I tried to look up at the Internet.

Still no internet.

I was seeing visions of yesterday, where I was stuck on a problem and without help from the Unity forums, I wouldn’t be able to get past them. But somehow, a few workarounds later, the sounds worked pretty much like how I wanted. I guess that is an important aspect of design as well. “Trying to adapt things as much as possible”.

Late Run 

Around 10PM, I had this crazy idea. An idea that could certainly have a positive effect. Now, I despite this being my first time in any game jam, you need not tell me that even entertaining these ideas was basically signing a death certificate. Given the time constraints, you had to stick with the idea you had originally thought. I had managed to do it thus far — but this idea seemed too delicious to not implement it.

So,leaving all my scheduled plan for the game aside, I started focusing on this. It was not before 2AM when I had finally finished this. With the deadline date, just a mere 5 hours away, I decided I needed to wrap up ASAP.

So, as I was finally getting the win/lose conditions implemented, I realized something.

I had not even made the Main Menu.

Again chucking everything out of the window, I frantically set to making the Main Menu, the “How to Play” screen as well as the Win and Lose screens. This took art and some new scene scripting to implement but I finally did it.

The GUI needed tweaking, so I set on doing that.

It wasn’t until 6AM when I was finally done. But then I just recalled that I could make the background music vary according to different “phases of life” or the progress bar atop.

So, I spent another hour doing that. Then, almost frantically, I baked the native version (Windows) of it and quickly set about uploading it on Dropbox. It was just around 7:10AM (the deadline was 7:30AM) that I logged onto the Ludum Dare site and filled up the submission form, describing my game and uploading various screenshots.

I had made it on my first Ludum Dare. I had finished making my first “complete” game and that too within the 48-hour Compo deadline as I had initially aimed. Despite all those obstacles that the world threw at me, I managed to do it.

Post-Mortem

In retrospect, I am rather proud of myself. Not because of the game. But because of the dedication I never knew I had within me. I don’t recall ever waking up for the entire night for something I was working on. On occasions, when I have done that, I’ve done it if I was reading a really interesting novel (The Wind-Up Bird Chronicle),watching a really interesting TV series(Twin Peaks) or playing an addicting game(too many to name).

But never for something related to work or even a hobby. Something where I wasn’t getting entertained. I lost motivation while developing a number of times before and this time I had plenty of opportunities where I could have table-flipped and just quit. But I didn’t. I stuck to my target and that makes me really proud of myself. This past year has been great for a number of reasons and I think I might have found another good reason for that.

What’s better is that the game has received some really good praise from fellow LD-ers and their comments both on the game page and my Twitter were really encouraging. Even the criticism has been helpful since I apparently had messed up on a number of small factors(resolutions on Web browser etc) but it’s all cool.

The best part besides finally having a “finished” game? THE MOTIVATION! I have loads of it now. I had heard people say how a finished game helps and now I am experiencing it first-hand. I’ve already made plans on reviving some of my older “ideas” and seeing if I could implement them. All while implementing some features I left out of the LD48 game due to the time constraints.

So expect to hear more of this “new” side of the old Ansh in the coming weeks.

Of course, here is the game page on the Ludum Dare site. Currently, I’ve managed to port it on all versions — Windows/Mac/Linux as well as Web through Unity without any major issues. I explain the underlying concept and the mechanics much better there. So,it’ll be better if I keep it simple here.

Any feedback is appreciated. I’m new to this and I’ll take any words — praise or criticism alike with a pinch of salt and take it as part of my learning process.

That is all for now.

–Ansh

EDIT: Indie Game Mag featured my game as their “Indie of the Day”

This was my 4th Ludum Dare, and for it I made a game called Complexity, a first person shooter/platformer in Unity3d! Timelapse:

From the start I knew it would be some sort of first person game. In LD24 I had made a puzzle game, which surprised me. After LD24 I tried working on some more action-based mechanics: I had begun work on a 3rd person shooter adventure game and spaceship simulation game.

So with my newfound curiosity of the action genre I wanted to make a game that would prove my profound knowledge of fun mechanics. Like most of my games, it started looking like this:

After the basic movement was achieved I started thinking of a plot. From the beginning I knew there had to be a bad guy, because without a bad guy there would be no purpose to shooting things up! And with the theme Minimalism, I decided early on that you were trying to stop some sort of bad guy from making things too simple. From there I came up with a weapon to counter his efforts — the complexity gun.

Alright, so now I had a weapon. After working on putting some basic shapes together I started a simple AI script. From this I had my enemy. If there was one thing I learned from LD23 it was that the more the character interacts with the level the better — basically keeping the immersion. So I came up with a second purpose for the complexity gun – what if it could shoot objects and make them more complex too? Then I tied this into a gameplay perspective — doors that could only be opened by making them more complex. With these new mechanics I pieced together a level.

Audio and music are pretty self-explanatory, if you want to see exactly how I spent my time on them check the timelapse above!

After working on more important game mechanics such as health and enemy lasers, it was time to work on the final boss! Obviously you all know what it had to be:

Sorry to whoever worked long and hard on that animation

Anyways to add story to the game I quickly came up with a splash screen and tutorial section and after that it was done!

What went right:

1. Gameplay
2. Mechanics
3. Boss Battle
4. Story
5. Animations
6. Sound

What went wrong:

1. Graphics
2. Textures
3. User Interface
4. Incomplete side-objectives
5. Goal of game

Why don’t you PLAY THE GAME?

Happy Gaming, Ludum Dare! <3

After making two post-compo releases of my Ludum Dare 26 entry, I think time has come to take a step back and have a long, hard look at the fruits of my labour. It’s kinda hard for me to be sure what went right or not and where, so I’m just going to list some stuff I did and didn’t do and let you be the judge!

What I did

ihavenoideawhatimdoing_dog.jpg

Use familiar tools

This is my second game jam. First one was Global Game Jam, where my team made a puzzle platformer about E.T. type of dude who could suck the energy out of things and use it elsewhere and there were dead animals… Oh, just check it out if you’re least bit interested, I’ll wait. It’s pretty short and ends in a cliffhanger. I was the programmer, and with no game making experience of any kind I quickly decided to use the program I had heard was friendly to beginners: Game Maker.

It really was an eye opener. Suddenly the little JavaScript and C I had teached myself over the years (but never enough to start a career in web development) became immensely useful, since GML is pretty much based around them. The finished product has it’s quirks, but it mostly works as intended and I was incredibly proud of managing to program it.

So there really was no competition. I’ve dabbled with Unity, but found it dense and since I was going to make 2D game anyway, I thought that time spent learning it’s ins and outs could be better spent elsewhere.

Looks like city building to me!

Have a set of goals

They were simple, but they were there:

1. Finish the game.
2. Have AI that interacts with the world somewhat immersively independent of player input
3. Some kind of city builder would be nice!

It’s pretty debatable if I achieved any of these goals, but they shaped the decisions I made during the compo from the start.

The key

Work with what I got

So, about those goals. It became clear pretty quickly (about that time when I had spent six hours trying to get little dudes to stay inside their huts at night) that I wouldn’t be able to make an engaging strategy experience in the timeframe given. That goal had to go. But I had no time to start from scratch, so I had to do something with the stuff I already had – somewhat working villager AI, handful of sprites depicting said villagers and their environments. There was some element missing.

It was only when I first drew that crude monster sprite I realized what this game could be about: stalking villagers and snatching them in the night. That felt… right. Like I had worked towards it all the time. All design became about making that experience more true, more fun, more varied: bigger levels, staying still (and later moving slowly) to be invisible, speed boost for panicking villagers, towns springing up overnight, hunters and their traps…

This is truly a game that wouldn’t exist if it weren’t for Ludum Dare. The idea didn’t even occur to me until I was halfway through building another game!

“If you ask me, this game could do with a bit more pant pant grr woof”

Get feedback early

I’m privileged to have a friend (not pictured, though you can see the actual chat window on the screen!) that tirelessly tests and gives feedback on anything I might be working on. The game would most likely be unplayable, unoptimized mess if they hadn’t pointed my attention towards stuff that simply didn’t work.

Also I am lousy at naming projects. Current title was my friend’s suggestion, and it stuck. Still, now I’m kind of vexed that I didn’t think of using the classic Finnish shareware game naming practice. Mörkö Metsä (Spook Forest) would have been a glorious title.

Alas, poor Yorick!

Kill my darlings

This goes hand in hand with previous item. In it’s earlier incarnations game featured wind, which changed the speed of tree animations, and tracks, which villagers left behind everywhere they went. Both were poison to performance.

I think the original idea with the tracks was that you could follow them back to the villager’s home and go full fox-in-the-hen-house, but since it was already pretty fast to scout the whole level, it became purely cosmetic. Wind was also just fancy way of adding some variety to visuals but it was so pretty! Yet when my tester started to complain about frequent slowdowns they both went. I miss them dearly.

What I didn’t do

Text file where you try to decipher the code you wrote a couple of hours ago probably doesn’t count.

Have programming planned beforehand

Making AI is hard. It’s especially hard if you have no idea what your long term plan with it is. Currently villager needs a host of functions, alarms and other objects to make it behave as intended. I feel that this is needlessly complicated and could be written exponentially simpler, if planned ahead. This is where I feel that making a simple map of all actions any given NPC can take could have saved time and made the game run much smoother in the long run.

Then again… when I started making the AI I really had no concrete idea where I was going with the game. Some stuff became apparent only when I thought I had finished it and started on working with other aspects of the game. It’s a feedback loop. Perhaps the only way to make a good AI is to make a full game featuring a shitty AI, and then rewrite the AI.

Bonus points if you can make out what songs I skip outright.

Set priorities and schedules

Towards the end of compo I chose the way I spent the time poorly. I implemented ambient wind sounds for the latest release without much effort and what a difference it made for the mood! I could have easily made them during the compo and leave the still hopelessly broken villager AI as is.

They are completely right, of course.

Have variables exposed to player

Balancing the difficulty is a daunting task, and it cannot be done without a large amount of varied player feedback. The few testers that I could muster did their best, but the real trial by fire only came when submissions ended and rating started. The game was way too easy, and by then it was too late to do anything about it. However… if I had left a players some way to change the variables that controlled the aspects contributing to game’s difficulty (enemy spawning rate, health, amount of healing, day length, villager speed…) maybe they would have found it a bit more engaging?

Next time I’m participating in a game jam I’ll put all the variables that make any sense to modify into an ini-file that can be adjusted to suit player’s needs.

Conclusion

Wow, word count totally spiraled out of control! I didn’t plan at all to write this long post. I’ll at least end it quickly: I’m still planning on expanding the game, but for the next update I’m writing the AI system completely from scratch. It can take a while! I’ll be posting any updates on Ginnungagap’s Game Jolt page and my twitter, so if you’re at all interested on seeing how this develops, check them out once in a while.

And if you have not yet rated my entry, please do!

Hey, everyone! Green Pixel’s artist here! Ludum Dare 26 was a blast and we came up with our Jam entry: Eternal Journey

If you’ve played it and rated it, thank you so much for your feedback! If you haven’t, check it out here and we’d appreciate your thoughts!

We made Eternal Journey with mobile devices in mind (as we have released an iOS title in the past) and we’re happy to read that a lot of the feedback seems to welcome the game – albeit a more finished version – on smartphones

This was our second LD Jam and one thing I realized from LD25 was that I didn’t really learn much artistically – besides learning how fast I could work under a time constraint. So, this time around, I decided to experiment. Why not, right? When I heard that the theme was Minimalism, I thought of triangles and, inspired by games like Vlambeer’s Ridiculous Fishing, I came up with the art for Eternal Journey. Below is a handy screenshot if you don’t have time to play the game

Triangles galore, eh? Now that we’re going ahead with the fully-featured version of the game (that we’re hoping to release before the next LD ), I’m wondering if I should continue with this triangle-istic style. As a game artist, I’ve only really ever worked with pixel art and it’s the most comfortable style for me. I whipped up a quick mockup of what the mobile, pixel art version would look like (note that the background is largely unfinished ), seen below:

See the huge difference? Gameplay aside, which style would you prefer? Do you think pixel art still appeals to the masses or is it played out? Would the semi-abstract triangles fare better in the world of apps?

I’d love to hear your thoughts! Thanks and happy gaming!

I wanted to wait some time before making this post. Mostly to get some feedback from players and also to take more time to look back at that week-end.

What I prepared

First, this wasn’t my first game jam but it was my first Ludum Dare et my first solo jam. I’m a programmer and I suck at pretty much everything else (including level design). I mostly make HTML5 games and I’m used to build my games from nothing. So I don’t use mapping tools nor I use canvas libraries.

So before the weekend, I wanted to make my own warmup and check out some tools. I took a look at Construct 2 following the two first tutorials. I found it nice and quite useful for prototyping. One reason I tried it was Rytlock’s Critter Rampage made by ArenaNet as a side retro game to one of their in game event in Guild Wars 2. It’s made with Construct 2 so I saw what could be made with it. Though, the free version seems to be way too much limited to make a complex game.

I also took a look at Tiled. I’ve tried this tool before but never used it for games I’ve made because i didn’t like working with XML. This time I asked myself if there was a way to make a JSON exporter until I found out that this feature was there out of the box. That was a good point.

Finally, I brainstormed a bit on what game to do. I wanted to make a stickman fight game, so either a beat’em all, a platformer or a vs fighting game. The main problem was I wanted a stickman engine to render it in real time and not use sprites. A bit too big for a 48h game with my experience. So i thought about a platformer with stickman sprites.

How went the weekend

For the weekend, I wanted to be up for most time. I know sleep is important so I planed good nights of sleep and even cleaned my appartement and prepared better food/drinks than usual. Being in CEST timezone, LD started at 4:00 am. I woke up at 4:30 after a good 9 hours sleep. At first I wasn’t inspired by the theme. But then I remembered my platformer idea and went for a simpler form : take a square. How to move it ? Make it roll. Not quite efficient, circles are better at that. Oh, why the square wouldn’t be jealous of the circles and make it beat them all ? That’s how went my brainstorming phase.

With that idea, I first wanted to see how it would look and if it was any good so I went for a prototype with Construct 2. I made the sprites with GraphicsGale (first time with it) and then imported them. The prototype was ready in 30 minutes and it was looking good. Great occasion to post it already as my entry. As there was a low number of entries, it had a guaranted visibility. Thanks to it I had some early feedback so I knew the idea was good enough.

Then went some long hours on reaching the prototype status with everything coded by myself. Took me most of saturday. I used Tiled to make a test level and see how i could use all the parameters present in the JSON object. That was quick and it took me no time to get the level displayed.

After a not so long night of sleep, sunday brought all the game mechanics implementations, some bug fixing (not much done finally) and all the polishing. The final version was uploaded nearly 30 minutes before the end of the 48 hours. By the way, I didn’t know about the 1 extra hour for submission so I really thought i had to be all set at the end of the 48 hours. Now I know for next Ludum Dare.

And there it is, ^2 is published, with it’s bunch of bugs but I quite enjoy what I’ve made.

The good points

Now, the good parts of the week-end.

First I learned well about tools. It made me want to use more Construct 2 or any other game building tool to prototype games. It’s really efficient with only basic knowledge of the tool. And now i think I’ll mostly use Tiled for mapping when the map type allows it. I might check out other mapping tools but I quite like this one. Also I made my first decent sprites and animations (though it was only b&w and basic shapes) and made me discover the tools to make then.

I had the healthiest weekend for a long time. I’ve been doing much more for me than I usually do so I didn’t have to think about it during the jam. It has also been a great time. I didn’t paticipate over IRC but it was nice to read the discusions there and how everyone was progressing.

As for code learning, I’ve found new ways to implement efficiently animations and game state management. Something profitable for my next games.

Finally, as for the game itself, I want to really finish it by fixing the collision bugs, add sfx and music and add some levels. After that, I even have ideas for at least two sequels. I think I’ll try to allocate myself some time to make them. It might even make me start learning about 3D.

The bad points

But not everything was perfect. Some things I could improve.

First, I should have taken more active pauses. I think I spent something like 35 hours in front of my computer during the LD. I’d say at least for 10 to 15 hour I wasn’t focused on making the game. In these 15 hours, some were dedicated to playing games, reading IRC or else. And I’d say at least 5 hours were dedicated to nothing. Really. Just not knowing what to do. I think in these times I should have just left for a walk or a nap or anything else not taking place in front of the computer.

The second bad point was bug fixing. I postponed it too much. In fact, I made a first rough version which was designed for a specific type of tiles (I didn’t have any roof at first for exemple, so I didn’t bother to make collisions for them). I kept telling myself to fix those bugs but I ended up doing this between midnight and 4:00 am in the night between sunday and monday. I finished by having something but not any better than what I already had so I chose to keep what I had. But now from user feedback, I see a lot of people are facing those bugs and end up in impossible scenarios as then don’t know what to do to get out of the bug. So from now on I’ll add “fix it early” as high priority on my todo-lists.

Last, I’m a bad level designer. One recurrent comment in player feedback is how the level is difficult (starting with the first jump and the first ennemy). I know I tend to be nasty with players when it comes to level design so I’ll try to make it smoother for next games.

And I think that’s all.

To conclude

Overall, it was a great week-end and I’m very happy with what I ended up doing. That’s one more game developped . I’ve been wanting to participate in LD for some editions now, maybe 2 years. But every time I had something else scheduled on the LD week-ends. I’ll try to keep free spots for the next ones.

I’ve also made a walkthrough video of ^2. As many player can’t go through first ennemy or get stuck in the first trap, I thought it could help to see how the level can be achieved or at least how the game looks like.

TL;DR

First LD but not first game jam. I’ve been enjoying this week-end and I’m happy with what I did. I learned to use new tools (Construct 2, Tiled, GraphicsGale) and I now know the benefits of prototyping with a tool making it simple (Construct 2). I was organized enough but should have made more real pauses (not being in front of my computer while take them). I should fix bugs way earlier, postponing it ended up in a buggy game. And don’t be too nasty when level designing.

Entry page : http://www.ludumdare.com/compo/ludum-dare-26/?action=preview&uid=21322

Game link (web) : http://maxgun.fr/ld26/

Source on github : https://github.com/MaxguN/ld26-square

PLAY :: RATE :: TIMELAPSE :: WALKTHROUGH

Minimalism exposes the essence of a subject, through eliminating all non-essential forms…

Vote here

My game is a minimalistic puzzle game where we tell a history of a little boy called Ted, trying to make a better world around him with the imagination.

We receive in our page great reviews, and the most good thing is the surprise of the game be so polished. It’s because we fix in the idea that the game have to be something minimalistic at all, not only in the graphics, but also in the gameplay, and even in the story.

(more…)