Posts Tagged ‘postmortem’
LD26 Summary!
This Ludum Dare was a great one, and I have to thank everyone who participated and rated my entry!
This time around I made a First Person Shooter called Complexity.
TIMELAPSE:
Here’s the post-mortem for a summary of how I spent my time!
From Potatos to the final moments, the competition was astounding in every way! And now… the results:
| #230 | Humor | 2.81 |
| #374 | Audio | 3.00 |
| #581 | Fun | 2.96 |
| #664 | Overall | 3.07 |
| #770 | Graphics | 2.75 |
| #790 | Innovation | 2.82 |
| #816 | Mood | 2.62 |
| #831 | Theme | 3.25 |
| #1411 | Coolness | 45% |
Alright, so apparently my game was… funny. Well the end boss was pretty funny… and it has…
I mean seriously… I didn’t even bother to draw a parachute on the character… so you kinda just… land.
Anyways next best was audio. I did work hard on the music and sound effects, but I don’t really think they were as unique as some of my other sounds. Now “fun” was the thing I was trying to achieve most on this one, just like most of my LD’s. I really tried to make movement and animations as smooth as possible and rewards for hitting the enemies. I realize the game is a little difficult at points… mainly because of spawning issues… but the quick respawns and the fact that advancing in the level is pretty easy make the game easy to enjoy. Skipping overall and going straight to graphics, I think this was another problem I had in my other games. I always use basic shapes for my enemies and levels (which probably won’t change due to the amount of time given) but this time I wanted the enemies to look a little more… animated… than previously. I really tried, but failed to make the game look as good my LD23 entry, Invasion Of The Trivials. I know why I failed to accomplish this: I didn’t have enough time due to places I had to be during the weekend. Regrets aside, I can safely say the results are pretty accurate, except for maybe humor…
Thanks again for everything, you guys rock!
Happy gaming, Ludum Dare! <3
I’m honored… i guess
how did my game manage to get top 100 for “fun”
even i think it’s boring.
How I made X=3-1 (Jam Theme winner)
The first thing I said to myself before the start of the Jam was this : “I will do my best to respect the theme in every aspect of interpretation or development.” Then the theme was announced : “Minimalism“. I was very frustrated because I knew that obeying THAT theme would kill almost every fragment of creativity I have could put into it my game. I wasn’t creating a personal game anymore, but a thing resulting of the maximum extrapolation of an invasive theme.
My thoughts are a battlefield with Conformism (C) against Anticonformism (A).
I do hate the C part, but it’s keeping me sane. This is how I proceed, talking to myself :
- A : What is the Minimal in a Game?
C : Interactivity. Without interactivity, it’s just a show.
A : But is a show a real game with unconscious inputs and inexplicit outputs?
C : Don’t mix show and game or people won’t understand. - A : What is the Minimal in Interactivity?
C : An input, an output.
A : It seems to be true with 2 people (considering Player and Game). - A : What is the Minimal Input or Output?
C : A click and displaying a pixel I think.
A : Where are your arguments?
C : In common games you just have to click and pixels are small and light.
C : Remember, people need to understand.
A : MAN, stop attacking your liberty of thinking by using understandability as a filter.
C : Do a game for your yourself if you want BUT UNDERSTAND that shareability is primordial in LD.
A : Go **** ******** C!
– Cerebral Meltdown –
I’m not going to show you everything, because it took hours.
And my head hurts.
- A : So… what’s the minimal game engine?
C : Notepad.
A : LOL, are you trying to mimic me? You’re bad at this, you know.C : It was a serious answer.
A : It was unoriginal originality, around 10 people will have the same idea.
C : So what’s your idea?
A : No game engine.
C : WHAT???!! We are NOT going to make a game??
C : GOOD JOB, YOU’RE RIGHT : 0 octets, that’s Minimal!
C : Who won? Everyone who did NOT submit a game.
C : You’re going to be hated for that.
– Conformism ragequit — Long wait — Conformism comeback –
- A : Bro, try to understand me,
A : I was saying : no “standard” game engine.
A : Let’s use Ludum Dare website as a game engine.
A : One possibility : Title = Question ; Download links = Answers.
A : Let’s minimize everything
C : Wow, you’re a genius, no kiddin, but can we?
A : It’s not forbidden, I think. Let’s submit in “Jam”. In case of.
- C : So, what’s the minimal question for you?A : “How are you?”
C : Answer links : “Fine, thank you” and “Not so well”?
A : I don’t like this, the question must be more challenging.
A : What about “X = 3 – 1“, btw : weird name, easy to see.
C : That’s not challenging at all.
A : Well, it looks challenging so people UNDERSTAND where the game is.
A : Remember, there’s no downloadable game, no Flash, no HTML5!
C : Why not “48÷2(9+3) = ?“, we will get more points in fun.
A : Too hard, and minimalism has a difficulty interpretation.
A : Note : We must do minimalism in the most diverse field of interpretations! - C : Where the “download” links are going to redirect?
A : Maybe to wikipedia, to the true or false page.
C : I like the “true” or “false” idea, it’s very “game-like”.
C : However, some people will not understand that wikipedia is a part of the game.
C : They will say “the link is broken” or something else.
C : I will write “you need a web browser” so people don’t search a “physical” game.
C : And it’s funny at the same time. - A : Good idea, hhmm, for the links I will write true or false in images.
A : I will then upload the images and use their direct links.
A : It’s important to lure people into thinking we spent minimal time and skill.
C : I think you’re right.
A : Haha.
C : Be careful, some people will look at the URL, so upload the false image several times.
And that’s roughly how I got this :
![]() |
Theme(Jam) | 4.65 |
![]() |
Humor(Jam) | 4.40 |
7 LDs and finally…
I made a cool graph thing showing how I did in all 7 LDs I participated:
https://docs.google.com/spreadsheet/ccc?key=0Ar-33qvLZBHXdHgtV3RmTUFtTGxPV3dQbXZfa0dXc0E&usp=sharing
And here’s a summary of them all. If you’re new to LD, I hope you can find some kind of wisdom somewhere in there.
My first LD, #19: Worked my ass off, and my game was really buggy and unbalanced. The graphics were very tiny pixel art, but I’m glad people liked it. Here I learned that having a clear goal is important, and that the main mechanics should be worked on first (as obvious as this might sound)
LD#20: Remembering how I got tired after LD#19, I said I wouldn’t work as much and do something simpler, so I made a puzzle. It holds most of my worse scores… That’s what going into LD with no enthusiasm looks like.
LD#22: Now trying to find a middle ground, I decided to take part in the Jam and just get my game polished and not buggy. I was really satisfied by the end product and the ratings. I don’t take pride on the audio score since I used free music for it (which is what I usually do)
LD#23: This time I worked in a group. It was as fun as it was stressful, me being the project coordinator and the programmer. We aimed a bit higher than we should, so the game lacked in the level design department, and there were a few glitches.
LD#24: Again with the same team, we decided to go with an idea that didn’t involve intricate puzzles or graphics. The game was simple enough to work on, and the team did a great job working on the assets. Only problem was a lack of decision-making, resulting in a lot of confusion and last minute rush.
LD#25: Working by myself again, I decided to try different ideas (no platformers or shooters). I enjoyed making the game, and take pride in the end result. Problem is, there was a lack of good documentation making planning and debugging a mess in the long run, and resulting in the game being confusing, with unclear goals and feedback.
LD#26: Zero hour hit, and people were mad about the theme. I wasn’t. To me it was a great opportunity to try to think outside of the box. I remember explicitly saying “with this theme, few good ideas with shine” (and they did!). And some of the games were amazing.
So I had my idea of making an interactive adventure where you could switch between two worlds to solve puzzles. I quickly saw a need to simplify this idea, so I made it a point and click game, which would have simpler graphics and mechanics.
The idea of having two game windows that connected to each other came when I went to bed (like most ideas
) but I was not sure it would be possible.
So I spent pretty much the whole first day making sure it worked, and the entire time praying it wouldn’t break the last minute >_<
I’m glad I could figure something out that was unique and fun to do, even if I didn’t work as much in it as I wanted (had to cut a good 1/3 of the game…)
Then results are out and I see a golden medal next to one of the scores. It took 7 LDs (and a couple MiniLDs) and I couldn’t be happier!
See you in august
Tessitron by team RADMARS – Last-minute Postmortem & Extras!

Adhesion from team RADMARS here, with extensive battle reports for this fateful compo from all of our trusty team members. We all have grizzled war stories from the development of our entry Tessitron, a 3D, minimal music game – play here! http://www.ludumdare.com/compo/ludum-dare-26/?action=preview&uid=18627 – but first I will entice you with a screen timelapse and the entire (single-track) soundtrack from our entry:
http://adhesion.mu/sic/Adhesion-Tessitron.mp3
And up first we have tokken’s postmortem:
It’s pretty incredible to be a part of a group that meshes so well and yet our ways of thinking contrast yet compliment one another. Although we’re all able to come up with off the wall bizarre ideas, it’s the way we think that’s pretty special. Spacemars is really good with generating nuggets of ideas; I tend to build off and branch from those. Adhesion has great depth as well as the analytical aspects that help ground ideas. Eugene is usually quiet but when he puts something out there it’s generally to lay down something important. Brendon has a great way of conceptualizing play and teasing out interesting mechanics from our vague notions.
This time around, although we weren’t entirely certain how we were going to apply the theme of minimalism, we had some basic constructs we wanted to adhere too. With three games under the Radmars belt we looked at our history and pondered where we were going and where we wanted to go. Two of the Three games had been 2D pixelated sidescrollers, with the third being a 2D pixelated top down adventure game. Although a theme was never intended, one was starting to appear; partially due to ease and speed of development. Between Spacemars and I, we had some fairly substantial 3D chops if we ever wanted to go in that direction.
Previously, Spacemars and I would generally do the brunt of the graphics work which placed much of the development onto Adhesion and Eugene. The secret sauce for Radmars has always been the great music Adhesion produced (also the dark humor imbued in each game). When he’s loaded down with code, music was pushed off to near last minute or at a lessened capacity.
This time around there was a definite consensus amongst the group to embark on a different journey from the previous games. We wanted to utilize our broad skill set without losing any piece that was vital to our current dynamic. We looked at each other and evaluated how to potentially build something that played off our individual strengths while compensating for each’s weaknesses.
Spacemars is a Jack of Most Trades Master of More Than Should Be Possible. He’s foremost a great developer, with serious pixel skills, 3D abilities to rival my own, and an eye for design. He’s also one of the most dedicated on the team and probably dumps the most time into the projects. His major weakness is time; he can’t do it all. Luckily with a team like ours he’s super malleable and is able to pick up any aspect that needs assistance. Certainly the cornerstone of Radmars.
Adhesion is Spacemars’ right hand man. His greatest asset is his mind and depth of thought; he certainly has a head on him that allows for quick concepting and speedy explanations; his dry sense of humor meshes perfectly with the team. Oh, and he’s a bad ass music man.
Brendon certainly has an eye for design and a great ear for music. Maybe his most important asset is the thoughtfulness he brings to our game designing. He has a very analytical thought process that allows him, and by extension us, to break down games and gameplay into more compelling pieces. His ability to find and create mechanics is something that always boggles my mind.
Eugene is a quiet thunder that weighs in on ideas and directions while being a heavy lifter on development. Unfortunately he is also somewhat mysterious, like a ghost that haunts your brains and whispers genius into your ear.
Myself, I have a robust working knowledge of Cinema 4D, texture and matte painting, and am a UI / web designer. My skills in development are limited to some as3 and Unityscript. My biggest flaw was my parsed time allotment.
At this point you may be wondering what all this BS has to do with the actual game, but I assure you this was not just some ego horse shit. Knowing each person and what they bring to the table helped us shape Tessitron…
Night of the living post mortems
Monday, May 20th, 2013 6:02 amTime for a little post-mortemy thing. I suspect nobody reads them, but in a few years, I’ll go through my old posts and find it and have a good laugh. Let’s use a chronological format for a change!
Before the jam
As usual I didn’t practice for it, I didn’t do any gamedev or graphics or anything related since the previous LD :/ So I was rusty. At the end of last year, I had some time in between jobs to learn new ZBrush skills but I didn’t know how much I had lost since then. Three ludum dare per year is just not enough practice.
The theme is revealed!
Of all the themes in the preliminary rounds, there was only one I really hated, yup: minimalism.
I hate it because all LD games are already minimalistic by necessity. The whole point of participating in a Ludum Dare is to see how much you can do in a limited time. Choosing minimalism as the theme, is basically giving up before you even start. In my opinion, there are already too many minimalistic games in a regular LD. Games where the author instead of trying to work on all aspects of a game decides that colored squares placeholders are good enough. This isn’t about how good your skills are, it’s about at least giving it a try and learning in the process. Don’t aim for minimalism, aim big! It’s better to fail gloriously than to not even try!
Day 1: Anti-minimalism 3rd person shooter
After recovering from discovering that terrible theme, my first idea was to make an anti-minimalism game, I thought about a few ideas like destroying minimalist paintings and finally I chose to do a 3rd person shooter where you fight alien invaders trying to impose their minimalistic philosophy on Earth. I’ve never made a LD game where you can shoot stuff, my games tend to be peaceful, so this might have been the occasion to change that?
I spent half the first day working on the shooter mechanics and enemies and for the second half I worked on my main character.
Day 2: New game idea
After waking up, I realized that I was not very far along with my shooter game. The shooting part wasn’t really fun and I realized I would need a ton of custom animations for it to work with my character. And while I had some ideas to create a funny world, they didn’t really all fit together with the gameplay and I had no clear vision of what the game would actually be like.
At this point, I had implemented a way to push the aliens bodies once they are killed. And I realized it’s actually quite fun to just play with that and try to move them around. How about a game where you just have to push a ball around with physics?
So I already had my main character, the gameplay only required a trivial amount of work, the rest of the day was spent working on a few levels. At the end of the 48h I had something I could have released in the compo category if I rushed the final hours but I wanted to use the extra day to make the game a little bit better.
Day 3: Polish!
For the first time in a LD, I started the final day knowing I already had something that I could finish and release any time I wanted. Things I did that day:
Prettified the levels with some props and alternative textures and I added two more levels with a bit more elaborate mechanics (unfortunately the one with the bridge has a bit of a nasty bug, I didn’t notice it in my testing due to being biased as to how I expected the level to be solved. It wasn’t even a code bug, I just forgot a two-clicks setting in Unity
How annoying!).
I tried to improve my character’s animation (without much success, animation is something I’ve never really spent time learning, I just fake it during game jams. I’ll work on that for the next LD).
I spent a bit more time than usual on the sounds, and even though the music is a randomly generated .mid file, I did spend some time in Reason choosing instruments and mixing it for a little extra.
In the end, I even had time to turn the code I had written for the minimalistic aliens into butterflies. A poetic way to end the conversion of what started as a shooting game in to a totally non-violent one
After the jam
I’m really glad I got lots of feedback this time. Over a hundred people played and rated my game, that was most likely due to getting an extra bit of spotlight thanks to my video compilation project but it’s nice to have my audience expand like that. That’s one good thing about making a game for a LD, you are pretty much guaranteed actual players!
Also thanks to the wonders of Twitch technology, I was able to see two people play my game in real time. I don’t usually see anybody play my games at all and that was really interesting as both did unexpected things.
For next time
- Animation has to be my priority. I have improved my character creation skills so now the animation has to follow or it looks a bit weird.
- Try to work on at least another game to avoid getting too rusty in between LDs
LD26 Summary (Aka Post Mortem)
Finally, I get to write a Post-Mortem about my Game “Escape the Minimalism” that I made during LD26, my first LD. Here is my first short summary of my LD.
I’m not totally happy with how it turned out, but it still turned out better than I thought it would.
So I think I will give this whole Post-Mortem thing a twist and do it a little bit different:
What went worse than expected:
- The THEME: From all the possibilities, why would it have to be Minimalism, and it struck me extra hard, because I think I’m not totally irresponsible for this. Well, at least we can all learn from our mistakes.
- The Motivation has been quite low at some times, partly because of the theme, partly because I got up at 4:00 AM to start working and kept working for a whole of 22 hours. Taking breaks and drinking a lot is essential to keep healthy, stay motivated and avoid dehydration.
- Being sick for one day is not awfully productive. I had food poisoning and spent the second day in bed and on the toilet. So be careful and watch what you eat, but eat something, because you need the nutrients for your brain.
- I didn’t even got the core mechanics ready after the first day, and I only started making levels after the second half of the last day, so I didn’t have enough time for smart level design. But I shouldn’t have skipped on letting others playtest it, because this really helps finding the balance in level difficulties and to get valuable feedback.
- Working in a team was not working out as I wanted, because of the theme I didn’t have a plan for a long time and still didn’t have a concrete one when I started working. Some of my friends didn’t have much time, and I was ill the second day. The last day I was already giving up on making a polished game, and just decided to push it through and get at least something playable out of this.
What went better than expected:
- The Feedback for my game has been surprisingly positive, I personally didn’t think at first, that people other than myself could actually enjoy it.
- The weather was perfect, it was cold and it has been raining a lot, so I didn’t have to come up with excuses why I wouldn’t leave my room.
- I was able to create my first game with Slick2D and I learned Tiled also along the way. This weekend had been more of an extensive learning session than a game jam, because I didn’t really know my tools beforehand.
What went like expected:
- As hoped I didn’t die from this extreme challenge or dehydration, but I nearly thought I would at some point over the weekend.
- I wasn’t able to create a complete polished game within 72 hours, but at least I made something playable and finish-able. But that’s okay, maybe next time I’ll use tools I’m already familiar with.
So my first LD made a lot of fun, and it motivated me to get at least something done. I will for sure create a more “finished” verison, fixing all the bugs and creating some better levels. And I think I will participate in the next one for sure.
Now when you go play my game, I would be happy if you left some constructive criticism, because I can’t believe that my game got so much positive feedback.
Postmortem: Nothing Left
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
Of Guards And Thieves – Postmortem
Monday, May 13th, 2013 9:31 amOoops, 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.
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.
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.
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
The Ethereal Stage – Postmortem
Ah, the satisfaction of doing something that actually makes you proud. I learned this the hard way, when I attempted a more complex game with Ludum Dare 25. I was not in a mood for it and already after day one, I was considering tossing the towel into the ring. But I carried on and delivered a broken prototype, that left a nasty feeling in my gut that I just wasted a weekend for nothing.
However, lessons were learned from that, and thus this time I made sure I would only make things I truly enjoy and that are focused on my strongest sets of skills. I wanted to aim for something rich in mood and story, that had a cinematic feeling to it, or as it turned out in this case, a sense of theater play. So a quick rundown of how the weekend went about.
Day 1:
Got up to read the theme. Thought about it for a while, and the remembered an old idea that I have had before. Started setting up a base template to work upon for an hour. Then I went out into the nice sun and weather, since we were having a spring cleaning that weekend. Then in the afternoon, I started working on the game. My main goal was to set up all the game mechanics within the first day, so that the second day would be focused entirely on content, which really payed off.
Day 2:
By somewhere around afternoon I guess, all mechanics, graphics and music had been wired up. For the music, I know from previously Ludum Dare that it is not my cup of tea, so I put something together with www.jamwithchrome.com and left it at that in order to save time for creating content.So now it was time to create the actual game and storyline. It hit me as brickwall and I didn’t know where to start. Luckily I did what would turn out to be the best choice I could have made. I sat down and wrote a walkthrough.
Yes, that is correct, before the game was even made, there was a walkthrough for it. But this was going to serve as great reference when I started coding the logic for the game and knowing what would happen at every sequence. So I made a silent placeholder dialog consisting of “…” that could be invoked of every character. And I then began to code all the logic with the goal of matching it completely with the walkthrough and all the scenes that was supposed to happen.
Having it then done, a writing marathon began, as I wrote lines of dialog for 4-6 hours straight. The code structure made it really simple to add in dialog and replace the placeholder. So it was quite a magic moment when I first played through the game, now that all the dialog had been added. It took me 20 minutes just to get through and proofread everything. So the game was more or less complete with 3 hours to go. I used another half hour or so for some final tweaking and then it was finally done and ready for the compo!
———————–
So that is how the weekend went about. Now, before I do a quick summary of what went good and what went bad, I would like to talk about a few things.
One thing that I put great emphasis on, was to make the game and story completely free of any gender and racial bias. That is, you can not tell anything about the characters besides their manners and personality. This made some of the sentences tricky, but nothing that couldn’t be worked around. Why I did this, was that I felt it was necessary in order to prevent any form of stereotypes and prejudices. Otherwise, there would be a high chance that it would have turned out a white male (as I am) or perhaps a white female. By conceling the characters, they would be guarded from any type of preconception from my side.
I also made sure to heigthen the words that was important to the game world as a way to enforce them and give them a more heavy weight to the player. By repeating them over and over in a sort of honory manner, they will eventually start to live as a higher concept. This also came about, as all the actors and probs had a static place and associated Hymn, further rooting the very nature of the game for the player.
Lastly, everything was intentionaly but in a high abstract form. My idea was that this game should be able to translate completely into a real life theater play. And thus, for example the name of the characters sounds something you would read of a theater program where they list the cast. It also gives more power to the player, as they will have to use their own imagination of what the different concepts mean and what is going on.
So to round off this postmortem, let’s do the traditional list of good and bad.
What went good:
- Making something that were in my right domain, focusing on my strongest skills
- Complete game mechanics day 1, only make content and minor logic day 2
- Having a complete design document, in my case a walkthrough. This made it possible to write all the logic without worrying how it all would fit together. Also it made me focus better, since it made me ignore any branching paths and other things that I was planning for at first.
- Working with Html and Js, as I could find bugs and both fix them in the code and at runtime. Otherwise I would have to start all over with the playthrough every time a blocking bug showed up. Now I could just hotfix it in the DOM and Js and just carry on.
- Using bitly to get nice statistics of how many have clicked the link to my game =)
What went bad:
- Since I was using css3 for animations, there was some trouble timing it with the javascript. Which in turn made the pacing for the game a lot slower than it should have been. Since it was such a long game, it was hard to get the flow and pacing right, as I was mostly busy patting myself on the back for a good job this time =P
- Did not use the remaining time to polish the game more. This includes the timing as I mentioned, but also to add some sound effects and animated movement that could have helped set the mood even more.
- Missed putting the toggle button for the music at first, which I knew from the beginning that I should have done.
All in all, I am extremely happy with this entry. It makes me look forward to how much I can improve next time =)
Check out the game here:
http://www.ludumdare.com/compo/ludum-dare-26/?action=preview&uid=13137
Curiosity
Friday, May 10th, 2013 5:23 amAbout time I got around to writing a post mortem for my entry, here goes!
Curiosity is a little ambient exploration game written in the ooc programming language. You can play the game here if you’re interested.
The Idea
In the UK, Ludum Dare starts and ends at 3AM. I decided to stay up into the early hours of Saturday, and fell asleep with minimalism floating around in my head. I think I had a dream about a game idea, but unfortunately I couldn’t remember it.
I thought about a game that starts of super minimalistic, and gets progressively more detailed and lush as the player progresses. Of course, this was silly and vague. In such a short space of time just having a finished project is a challenge, but I hope the game resembles my intentions a little.
I admit I didn’t really like the theme at first – any game made in 48 hours is going to be minimal, so minimalism seemed to be a wildcard. I changed my mind once I got started.
Design
My graphics software hasn’t changed since the last time I entered. Even though I’m 5 major versions behind now, and running it 2 operating systems ahead of what it was developed for, Fireworks is still my general purpose graphics editor of choice. Having .png as the native project format is really handy, along with the variety of non-destructive image processing options.
I’d heard good things about Ogmo Editor, and watched a tutorial on using it in FlashPunk. Considering this was my first time using it in a project, it worked amazingly! When designing the world, I tried to make sure there was more than one way to solve each challenge (though not everyone who played the game noticed this). Some people said the game reminds them of the Knytt series, which is very cool to hear! Nifflas was certainly a source of inspiration for me.
A few people found the game too difficult, but I don’t think there were any major flaws in my level design this time. My old entry for LD21 had lots of blind jumps, no checkpoints, and you could fall off the world by going left. I’ve definitely improved in that respect! Personally I thought the difficulty level was fine, especially after playing some other awesome yet insanely hard entries.
Programming
My choice of language, ooc, served me incredibly well! It’s a modern object-oriented language that compiles into C99, and therefore works on any platform with pthreads and a C compiler. I picked it up in the last few months, created quite a lot of bindings to existing C libraries, and have been working on a FlashPunk inspired game engine called Vamos using SDL 2.0′s hardware accelerated rendering API, which I used to create this entry.
The majority of development issues were all tackled before the compo started, so I had a pretty smooth ride on my own framework. The day before, I bound a small XML library (MiniXML) to ooc, so I was able to parse Ogmo Editor’s level data. On the first day I remembered I still hadn’t implemented depth-sorted rendering, and that ate up a little bit of time, but was quite painless.
The main problem was that my game engine didn’t have sound effects. I’d been trying to write my own audio mixer before the compo (without relying on SDL_mixer), but it had huge latency and I couldn’t figure out how to avoid sounds being synchronized to the buffer size. The music playback (which uses stb-vorbis for decoding) was working fine, and I found a hacky solution last-minute to create smooth crossfades between tracks. That hopefully compensated for the lack of sfx.
Music
This has always been a strong point for me. I wanted to include just as much musical content as last time, which meant I had to make 4 tracks! In my last entry, my soundtrack was ruined for some people by streaming/stuttering issues. That wasn’t a problem this time, because I was making a desktop game.
I’m primarily a Renoise user now (though SunVox is still awesome, and I highly recommend it if you’re looking for a free music program). I’ve got a nice collection of free VSTs and samples and had fun creating some ambient songs and soundscapes. It gave me a nice break from the intense coding!
Overall
I’m really happy with how this turned out! I’ve since made some Linux binaries, and it also runs nicely on OSX (though I don’t have a mac to test or package it). I’d love to develop Vamos further and make some more ooc games in the future.
I’d also like to thank everyone for their encouraging feedback so far. Thanks guys, and well done on all your finished projects!
Postmorten : AbbrevsMaster
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
An now it’s time to explore LD games (to play … to rate)
My Little Robo – after action report
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.
A deeper and more honest postmortem
Wednesday, May 8th, 2013 10:53 amIt’s been more than a week since Ludum Dare ended (at least the “making a game” part) and though I made a postmortem I’ve decided to do it again. Quick reminder, English is not my native language and I’m translating and adapting a text I previously wrote in Spanish for my personal blog.
This is an auto-review, I tried to be fair and honest.
First of all, I must say I’m not happy at all with my game, in fact I haven’t opened it since I finished. This is the kind of things you shouldn’t say about your project, you should be encouraging people to play it and give it a high rating instead of saying that you don’t really believe in your own game; the thing is that I care more about having fun and learning that I do about obtaining a better rating.
I’m very proud of participating on my first Ludum Dare and finishing in time, it was quite hard, but I feel like I didn’t accomplish my basic objectives.
I really like to ponder about game designing theory, I keep track of every speech Jonathan Blow and other people like him post on Youtube, I find them very inspiring and interesting, I also think they are a must-watch for developers because they try to make you think out of the box and create things that matter. I wanted to achieve something with my entry and I ended up with a couple of half-baked ideas glued together; I don’t know if I wasn’t ready, it was the pressure or what, it doesn’t really matter, but my idea and planning had many mistakes from the beginning.
When I try to analyze my own game what I do is breaking it into parts. The graphics are just acceptable (taking into account that the theme was minimalism), the music is unexisting and the only sound you hear is when you jump and when you discover a new block (which is kind of irritating after a while). So, what we have left are the gameplay/core mechanics and how you affect the player.
- The core mechanic is pretty simple. The stage is invisible and you have to discover it walking from one corner to the other. Ok, it’s a bit original, but nothing great. It’s a totally unfair system without any type of challenge. You are given two paths, you don’t know which is the right one, the one that looks shorter is probably going to be blocked, sometimes the developer will block the long path so you don’t always skip the short one; but that’s all, choose one randomly and if it doesn’t work go back and choose the other. That mechanic is OK for one level, it gets boring with many levels and it makes no sense to use it on a full game. This is the kind of things I wish I had realized before.
- In the game there is also a “being” who writes messages, in the beginning it was gonna be something that gave the player inspiring messages about life and tried to encourage the player, it turned itself into a jerk who messes with the player, I think that was a good decision. It’s kind of funny, makes a few jokes and hopefully made someone smile while playing the game. But then again it’s a half-baked idea of unclear purpose and glued to the rest of the game.
I’ve failed to communicate with the player and make the experience worthy, maybe because I wasn’t sure about what I wanted to express. My entry is kind of soulless and distanced from the original theme. I spent a lot of time trying to design new levels thinking that it was gonna fix it without realizing that it wasn’t the solution. Some friends told me that they wanted me to keep on developing the game and making new levels because they enjoyed the current version, but I don’t think I could, maybe I’m being a bit tough but I really think I’m just being realistic and honest.
The fact that I kind of hate my entry doesn’t mean I’m giving up, probably it’s the opposite, I’m more motivated to keep making games. I already started a new project, nothing big right now, I just have some basic graphics (I’m keeping the guy I designed for the compo) and some pages full of ideas, I’ll see where it takes me.
My friends liked my entry, I’m really glad they had a good time with it because I worked hard but I want to make something I can be proud of. I won’t be participating on the next Ludum Dare ( exams
) but I won’t miss the one after that. I had a lot of fun participating and I think I learnt a few things. Thank everyone for this!
Amish Brothers Post Mortem Kombat
It all started on a rainy Friday night. Ludum Dare. He wasn’t your typical programming competition like your Google Code Jams or your Top Coders. He was a loner that walked to the beat of a different drum. Now old Ludum Dare has been around these parts twenty-six times, and each time he brings along a different theme. This time his theme of choice was “Minimalism”. Ludum Dare walked into the bar and stared down all grizzled patrons, and challenges all to match his theme. Many men have tried and failed, only to return to a life of sorrow and desolation.
So when I heard that the theme for this years Ludum Dare was Minimalism, I immediately thought of an episode of the radio show Coast to Coast AM with Art Bell, where the episode was on minimalist societies. There are many who follow the minimalist lifestyle today, by using only the bare necessities to get by in life. However, the original practitioners of the minimalist lifestyle are the Amish. I started thinking and realized there has never been a video game about the Amish before, at least as far as I’m aware. Then I remembered the 90′s classic song Amish Paradise by Weird Al Yankovic. This could actually be an interesting premise for a game.
An Amish that would save the world using only the bare necessities. The next question is how would he save the world. Obviously an Amish would not want to hurt or kill anyone, so I decided narrow the grandiose premise of the game. Instead of the protagonist attacking others, he would be helpful.
For Ludum Dare, I knew that web is the platform that could reach the most players, so Unity was the best environment to develop a game for this competition. Not knowing anything about Unity, I started watching as many tutorial videos I could the night before the competition to give me a basic feel for using the tool. Even though I’m not a Unity guru, I’ve been programming games in my spare time since around 1995. My first epic game was Mystic Sword written in QBasic on my 386. Since then I have written games using libraries such as ClanLib, SDL, and most recently XNA for XBox Live Indie Games. Last year I released my first published game called Resistor to the masses on the XBox Live Indie Game platform. While it was praised by many XBox Indie review sites, I failed to make any monetary return since it didn’t sell enough copies to get the minimum payout. I decided to start working on a new game called Blasting Bits, which would appeal to more gamers. I worked on this platformer in my spare time for about six months, then an unexpected event occurred in my life, which made me lose my enthusiasm of developing games. However, I knew I still wanted to do the Ludum Dare competition this time, since I’ve never done it before and it seemed like it would be fun.
So after my crash course in Unity, I knew enough to move an object around and how to detect an event when that object collided with another object. Hey, that sounds like enough to make a game! Not enough to make a deep and sophisticated game, but enough to make a simple collectible game. Then I decided that the hero, who I named Brother Jebidiah, would collect sheep… because sheep are cute. After sleeping on it for a night, I thought of a simple story about the farmyard animals escaping the barn. I had planned to include other animals such as chickens, cows, and goats, which would have unique characteristics and travel patterns, but I didn’t have enough time to implement those so I stuck with sheep. I also considered adding powerups such as a butter churn to make the player run faster, but that idea got left on the cutting room floor for the sake of completing the game on time.
I added some simple boxes to the screen that represented the player and the sheep. Then I developed a method for automatically generating the sheep, using the Prefab technique that I learned in the Unity tutorial. Next I started working on the model assets. I’ve been modeling simple objects in Blender for over ten years, so I knew I could make a player model and sheep model for this competition. The only problem was adding the models into Unity was something I had never done before. I’ve gotten animated models working in XNA before by exporting to FBX, but I never had the ability to change animation sequences. I was delighted to discover that importing models into Unity is as simple as dragging the .blend file into the Unity project. Unfortunately, my models were not animating in Unity, which had me pulling out my hair for awhile. After some searching on the Internet, I found that the Animation Type must be set to “Legacy” on the Rig tab for animations to work. Then I created a simple barn, trees, and fence to add to the scenery. Finally, I rendered a stack of potatoes as a small Easter egg, which can be seen on the left side of the farm.
For the audio, I recorded myself reading the introduction story using Audacity. I also made a “baa” sound, which I sped up and raised the pitch in Audacity to make it sound more like a sheep. Finally, I needed some music so I recorded myself playing “Old MacDonald” and “Baa Baa Black Sheep” on the guitar. I thought those songs fit the atmosphere of my game perfectly.
The level design was really simplistic, as I just increased the number of sheep for each level. Some have expressed dissatisfaction due to the lack of a lose state. However, not all games have lose states. In a racing game, you can just sit in your car forever and never reach the finish line. I feel my game is a lot like bubble wrap. You just keep popping bubbles until they’re all gone. Adding enemies such as snakes and obstacles like briars did cross my mind, but I envisioned this being a game for the entire family, so I wanted to avoid having the main character get killed. I also wanted to make mazes out of the fence, but I knew I wouldn’t be able to compete that within 48 hours. Finally, I made a victory screen and congratulations message for when the player completes all ten levels.
So that’s Amish Brothers in a nutshell. I would like to expand the game a little more to make it more interesting, but I also have a few ideas for other games I would like to start making with Unity as well.
Follow me on Twitter at @GaTechGrad or visit my website www.levidsmith.com for my other projects.
Only One Shot – A Post-Mortem + Experiences of Completing my First Ludum Dare
Tuesday, May 7th, 2013 4:13 pmI 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.”
Erase : post mortem
A bit late, but here’s the postmortem of our 3rd jam game together: Erase
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.
Broken 1 Postmortem
This week has been hands off tragic for me with multiple parents having cancer, and an old friend dying… life is rough… Broken 1 has morphed into this project: http://www.indiegogo.com/projects/a-tale-of-persephone-and-hades/x/2513003#share
And combines with this adult artbook: http://goingclassical.deviantart.com/
And more I cannot bear to write up. Stay tuned…
Complexity Post-Mortem!
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:
- Gameplay
- Mechanics
- Boss Battle
- Story
- Animations
- Sound
What went wrong:
- Graphics
- Textures
- User Interface
- Incomplete side-objectives
- Goal of game
Why don’t you PLAY THE GAME?
Happy Gaming, Ludum Dare! <3
Ginnungagap post-mortem
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:
- Finish the game.
- Have AI that interacts with the world somewhat immersively independent of player input
- 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!






































