Posts Tagged ‘post-mortem’
Thoughts on this Ludum Dare -
- I’m kinda disappointed, but the results seem fair.
- Best ranking: 50th for humor.
- I didn’t focus on a concept and the theme enough.
- My concept was you have 1 arm but multiple tools, you have to find ways to carry tools without your arm.
- Didn’t have enough time to do that!
- Instead I spent time on other things:
- I wanted to include palette swapping and NPCs.
- I’m happy I included them, but I should’ve focused more on a concept.
- I coded everything from scratch, which made things take longer. I’m happy I did that though.
- I received a lot of nice comments
- Thanks to the 71 people who rated my game!
- If you haven’t played it, check out The Visitor.
Thoughts on previous Ludum Dares -
- My best Entry is Mondrianism, doing well in everything except humor.
- Second best would be my first entry, The Good Ship Higgs Boson.
- Super Space Goat Thief Standoff!! is definitely my worst entry, but I only spent a few hours on that.
- My best category has been different every time, interestingly.
- As you can see, there’s a clear trend of… um… well…
See you next Ludum Dare!
It’s maybe too late but I feel like I’m missing something if I don’t write a post mortem for my first LD entry – Tough. Post mortem is a kind of new term for me when I join this community, hope that I can make it correctly. I will prepare timelapse for my next LD entry too.
Joining this LD was an awesome experience for me. I didn’t like this theme. I think it’s too wide because most games can be explained that they fit the theme. But in the end, I think this theme worked out pretty well. A lot of games did take on this theme with their very innovative ways.
What went well:
- Finished the game in time. It’s the best thing since making this game was a new challenge for me.
- Picked a simple idea and built a game around it: a platformer with unexpected ending. Everything was in a reasonable scope for my first game jam.
- Did follow the theme and made a good twist: You only get one life, but the goal is not to keep it.
- Had a fun first day making the game. Even though I were working on the game until 6am of the next day, I felt no stress.
- Learned the first game framework engine (Phaser). I’m just a web developer and a gamer. This was a very motivative way to help me become a game maker too :).
What went wrong:
- Too much time lost on making assets. But in the end, it’s still completely not as I imagined on my head. I intended to make a Franstenken-like character and some brutal wolves.
- Did not use the remaining time to polish up the game.
- The fun was hidden because of the vague gameplay.
- No sounds or music either.
- Did not pay enough attention to the rules. I were using assets of Phaser framework for some background of the game. I felt really bad about this and replaced them all one week later.
- With the lack of experience with basic game design and game framework usage, I got some troubles with the camera, didn’t know how to use tile map, failed to make an endless map generation and made a lot of hacky things.
- The source code of the game was really bad base on my own standards.
What is next:
I’m satisfied with this game. I hope it will be a good starting point for me. I will stay with this idea and make it a clearer goal and a smaller map. The mechanic will be the simplest one for platformer so I can try to create a same game with a lot of game frameworks quickly. And of course, this game is an open source project.
Ah, the ol’ post-mortem… where you retrace your steps and try to figure out what went wrong and what went right. But what if nothing went ‘wrong’? What if I’m totally satisfied with what I ended up with? Well, that’s the case… and not because my game is amazing or ground-breaking or technically flawless… but because I finally ‘beat’ Ludum Dare. Let me explain.
This was my 10th LD, and since I first started, I’ve learned so much about myself, my limitations, my weaknesses, my strengths, how to work under pressure, etc, etc etc. What I also learned during all of those compos is that Ludum Dare is not about what you didn’t accomplish in the time limit. So often we are bombarded with comments about where our games could be improved and we write post-mortems about what didn’t go as planned, but I just simply want to see more celebration about what is actually being accomplished. To me, Ludum Dare is about what you WANTED to do versus what you were ABLE to do. And in the case of LD28, I did 100 percent of what I wanted to do. Sure, I can point out flaws in my game and there are infinite ways in which I can expand on my idea, refine it, and make it better. It was the first time that I made a list of what I wanted to accomplish and was able to check every one of them off before hitting the ‘submit’ button. Yes, Ludum Dare is about learning… it’s about pushing yourself… it’s about improving… but when I say that I finally ‘beat’ Ludum Dare… I mean that I finally reached a point where I can grab the theme, stay on target, and limit myself to the core essentials. This was always my biggest weakness, and with LD28, I was triumphant. Just like my first Ludum Dare when I didn’t save time for audio. I was unsure of my ability to make quality audio in the time limit, so I pushed it further and further back until it was too late. I was very disappointed in myself, so I made a strong effort to practice audio and I made it a larger focus. I then went on to capture two gold medals in the audio category, something I never would’ve imagined after my first LD. So now with LD28, I feel like I turned another corner in actually being able to stop myself from attempting such a hugely impossible list of features in such a short amount of time. Instead of being stressed about finishing, I was able to relax and do experiments. I was able to try new methods, use new tools, and learn new things without having to deal too much with the clock ticking away. And that brings it all back to the original purpose of Ludum Dare: to learn and grow by challenging yourself.
So what was the end result of my LD28?
A pattern and timing-based score attack game where you have one bullet to shoot zombie kids in the face.
Save One For The Kids by SonnyBone
The concept is nothing special. There is no story or no explanation for what’s happening. There doesn’t need to be. I wanted to make a game that could be ‘perfected’ with enough practice and memorization. There is literally a max score that can be earned if you play every stage perfectly. But good luck doing that… it’s not easy, and you can’t immediately replay stages to find the perfect solution. It’s kind of like Kirby’s Dream Course in that regard… one of my favorite games. You can get a hole in one on the first 3 holes, but then if hole 4 throws you for a loop, you have to replay the first 3 holes to try number 4 again. What you end up with is a situation where things that were once difficult become very simple, but if you get too frustrated, things that were once simple start becoming difficult. It’s one of the most common phenomenas in gaming. My friends and I once created the term “gamer’s hand” while playing Tony Hawk 2. It’s when your mind shuts off and your eyes go still but your hands move on their own as you attempt the perfect run and keep hitting ‘restart’ in the pause menu. That pattern of memorization, reflexes, and reactions mixed with your brain’s stupid desire to see bigger numbers at the end of the run. That’s what I wanted to create… a very simple puzzle game that a very specific type of gamer would want to play over and over in order to get the best score.
I wanted to try something new with art. I wanted to go for a hand-drawn look while testing out some new animation methods.
The main player has no animation. I messed around with the idea of clothes blowing in the wind, recoil from the gun, or starting the stage with the player actually going from standing to crouched and then aiming the gun. I immediately realized that it would simply take too long, and that the focus should be on the moving enemies, not the player. I also decided early on that player aiming or player movement would make the number of shot possibilities go up exponentially, making the game infinitely more difficult and unpredictable. That would’ve gone against my idea of a ‘perfect’ solution that’s not too impossible to figure out (both for myself, and for the player… because I had to design the stages to be beatable and be able to calculate the lowest and highest possible scores).
The main enemy is where all the animation went.
I was watching Home Improvement while waiting for the theme announcement, so I think my enemy ended up being Mark Taylor by accident.
I’m not sure why I decided to make a game about killing zombie kids, but I think I remember having an idea about them being crazy Minecraft fans that desperately wanted more Minecraft clones and were going around killing anyone not currently developing one.
The enemy consists of several different parts that were tweened and occasionally swapped out with other sprites:
If I had another 2 hours to work on the game, I probably would’ve spent the time redrawing the feet and making some palette swaps for variety.
That’s pretty much it right there. You hit spacebar at the right time, everything freezes, and your bullet rips through a line of enemies. Your goal is to kill everything on the screen with one shot, but it’s best to get the same kind of shot in a row to get extra points. Killing everything on the screen gives you a MURDERTALITY BONUS that dramatically increases your score based on how many enemies you killed. You get 250 pts for leg shots, 500 for torso shots, and 1000 for headshots. If you land three headshots in a row, for example, the first is worth 1000, the second is 2000, and the third is 3000. If you killed everything on the screen, then that total gets multiplied by an amount that I can’t remember… lol.
At the end of the stage, you are presented with a medal for your performance. Yes, it is possible to clear every enemy in the game and get a gold medal on every stage. I have only done it once, but I kind of cheated to do it. The closest I’ve been able to get without cheating is 8 perfect stages and 2 silver stages.
I went with a very subdued soundtrack. The Wintry setting, the jumping kiddies, the holiday cheer… I kind of wanted something that would be relaxing to help you focus. I spent more time on the ‘slo mo’ bullet sound effect, the head splatters, and the dumb-ass voice samples for earning medals. I created some really goofy little voice that is almost out of place but somehow… works. I love it… especially when I get a “silllvah” medal. And then the voice at the end telling you how much you suck. There are 3 possible ‘endings’ with your overall rank/score.
I had a crapload of fun. I made what I wanted to make. I learned a lot. I’m happy. SUCCESS!
And this will be my last LD for a while as I keep working on my first commercial game. I haven’t officially announced it yet, but I will someday. I think 10 LDs is enough for now. I’ll come back after my first ‘real’ game is a huge flop. If you wanna stay in the loop, my site is HERE and my Twitter.
Since there’s less than a day left until ratings are finished and I haven’t gotten around to doing it yet, I figure I might do a little post-mortem of my LD28 Entry One Jump (not to be confused with a couple of other entries with the same name). This was my 2nd Ludum Dare game but the first submitted for the 48 hour compo.
My primary aim during the weekend was to avoid some of the mistakes I did in my last entry (such as time management) and submit something playable in time for the 48 hour compo. Prior to the competition, I decided I wanted to use Unity (specifically the new 2D tools) for a couple of reasons:
- Familiarity (I’ve used Unity before but not for a Ludum Dare entry) instead of trying to learn a new language/engine in 1/2 weeks
- More widespread deployment: Compared to my last entry (which used XNA), using Unity meant that I could easily deploy my entry to the web as well as create standalone versions in one go.
I also decided that I wanted to create a platformer (mostly because I haven’t made one before and also because I didn’t want to create a top-down game where you move something in 4 directions and shoot stuff). The day before the actual theme was announced, I did jot down a couple of ideas based on some of the themes that made it to the final round of voting (although I didn’t actually have an initial idea for the one that eventually chosen). After the theme was announced however, it took me some time to think of a core mechanic that would fit it (To be honest, I didn’t really like the theme although ironically, due to the primary mechanics, my last Ludum Dare game would have been an absolute perfect fit for it). Eventually, I decided to interpret “You Only Get One” as being able to do something that you can normally do many times only once. In the case of a platformer, the primary mechanic is jumping hence the main objective of my game: To simply reach the exit but being only able to jump once per level (which led to some rather strange and interesting level design)
What went right:
- Planning and Time Management: Compared to my last entry, I actually made much better use of my time thanks to the Unity workflow and managed to submit my entry in time for the competition.
- Levels: A common complaint with my last entry was that there were too few levels (about 4/5). Thanks to Unity, I was able to rapidly prototype levels in the editor without having to recompile and restart the game and created around 8 levels for my entry.
- Mechanics: Initially, I thought that being only able to jump once was too gimmicky (trying to design levels based on that mechanic was pretty hard as well as I wanted to make the player use their only jump at the right moment). In the end however, I was pretty satisfied with the end result.
What went wrong:
- Graphics: I’m not a very good artist so I decided to use simple shapes again for my entry. Unfortunately, I didn’t have enough time to change those shapes into something more plausible (but still somewhat crude).
- Lack of background audio: I initially created a small audio loop for my entry but I wasn’t able to get it to loop properly in Unity.
- General Platformer Physics: Although the game generally worked, some of the primary platforming mechanics were a bit buggy (having to create some momentum in order to jump, unintended wall sticking etc.). Some platforming elements such as the moving platforms didn’t work as much as I had hoped.
Feedback for my game so far has been fairly ok (and better than I had originally anticipated) with level design being praised the most and some platformer physics/controls being the main criticism.
Overall Experience and What I’ll do in the Future:
Compared to my last entry, I didn’t enjoy this one as much as I’d hoped (mainly because of the theme) even though I managed to submit something in time for the compo. I did have a fun time however and if there was anything new that I’ve learnt during that time, it’s that I shouldn’t be afraid of submitting to the jam instead (rather than treat it as a place where I didn’t submit my compo entry in time): if my entry needs one more day of polish then I should take advantage of that extra day. During the period of time before the next dare, I will try to make at least some improvement with my graphics skills (or failing that, just collab with an artist friend for the jam instead).
Note: this is a post by lonely2012, made using team account.
Out of Mind is a turn-based tactical hallucinogenic cyberpunk action game, made mostly by two Eastern European guys in a single room, with some great help from our teammates all over the world, including the same room.
I guess we could have made it outside, but it was rather cold.
It started as a perfectly standard turn-based crawler with perfectly generic progression through entirely typical level. But things rarely go the way we plan them. So about half-way into production things turned out a little bit bonkers, especially on my end. Which happens to be art, level, and overall gameplay design. On the bright side, that’s how the game got it’s name, it works, it’s entirely completable and sorta really fun. At least to me it is. Especially post-ld re-balanced version, aka the ode to my giant overcompensating ego. With actual end-game challenge. And patched map. You should totally check it out.
My partner’s coding stuff went surprisingly well though, aside from one rarely and randomly occurring gamebreaking bug. And about one and a half out of seven pick-ups don’t really work the way the way they were written on paper. However they do work, and it’s a good thing.
One notable difference of this LD to all six of our previous ones is that this time we were eating less, and made objectively more playable game. Perhaps in the future we should stop consuming human food and make something brilliant.
Also here is a player death image that was censored out of the game by my partner on account of him being too squeamish:
If you don’t play the game yet, please, play it before read this post-mortem. It only takes 2 minutes.
Brainstorming (Saturday 8:00 - 11:00 GMT +1)
We met at 8:00 and started to generate ideas. We rejected some of those ideas because they were unviable, boring, or absurd.
We decided to use the point’n’click game mechanic. The main character awakes bewildered and locked in a room. He only gets one object at a time and he can interact with the scenery objects to escape from there.
Finally, we decided that the main character will never survive and his life will always end by a shoot. Nevertheless, in the end we gave more variety to the game and we decided to add different deaths. With this, the user gets addicted to the game, trying to save Wilhelm from his fatal destiny, making a 2 minute game so much longer.
Pre-production (Saturday 11:00 – 15:00 GMT +1)
Once we chose the mechanic and the details of the gameplay we started to develop the idea and we planed it in different tasks.
- Marina & Juanlu (designers) split their work in stage and main character. They used Spine (Esoteric Software) to make all the animations.
- Chema & Carlos (programmers) worked with LibGDX (Java/LWJGL). Chema worked in front-end (graphics and cool things) and Carlos worked in back-end (state machine and controllers)
- Ricardo started to work in music and sfx.
Production & Testing (Saturday 15:00 – Tuesday 3:00 GMT +1)
At this stage we developed all the stuff that we decided before. But we had to make some changes due to the short time.
In the beginning all the deaths had its own animation, but this was unviable, because of that we decided that only the original death (The shoot one) would have animation. The final solution was that the light turned off, the character died and then the light turned on again; showing to the player the corpse of Wilhelm. This is why we decided that the main character use the Wilhelm scream, and gave that name to the main character.
We decided that all the action and reaction would have their sound effect to represent the unseen deaths. The ambient sound was wind, rain, thunders and our lovely neighbour dog. In addition we recorded some nonsense speaking lines.
During the develop of Wilhelm’s Escape:
- A Spanish Omelette died.
- A few campero sandwiches were devoured (an spanish sandwich)
- Poor quality chinese food.
- 5 litres of coffee
- 1.6 litres of energy drink
- 2 litres of beer
- 1 kg of pasta
- A couple of pizzas
- A lot of hours of music
- No dog was harmed.
Hi guys and fellow devs,
Just wanted to hop in the postmortem wagon and let you learn a bit more about how I worked on “One”, my LD28 entry. English isn’t my mother tongue, so be ready to read approximate french-glish.
If you’re interested, you can first test my game here.
When I heard about the theme, I got a little disappointed because I voted against it, for the simple reason it didn’t inspire me that much. I almost gave up on participating. My first idea was to make a game about getting only one seed in an arid world, but it was too complicated and, in my opinion, not original enough.
I was a bit depressed that saturday, the sky was dark. Thinking about the LD smoking my cigarette outside, I suddenly decided to cheer myself up by cheering other up, and I decided to make the happiest and cutest game I was able to do in 48h.
With that in mind, I thought about the theme again and remembered that one dream I used to have which filled me with happiness. In this dream I wasn’t flying but jumping so high, and falling so hard ! It was fun and magic. I decided to turn that into a small game.
For those who didn’t play the game, the game is about a little child who learn to jump up to the stars. Little light balls help you to get higher and higher.
I’m what you could call a experienced dev, with more than 20 games released in my career, and 4-5 game jams. After several years, I’m now experienced with scoping a game. My advice is to always go for the simplest idea you can have. Because during the course of development, either for a full game or a jam, you’ll always spend twice the time you planned on small things like researching, debugging, adding signs and feedback, etc. We always tend to underestimate the details, so focusing on the simplest idea and growing from there is often the best solution.
I used Flixel, which is, in my experience, one of the best technology for game jams, for two reasons : it’s perfect to create very small projects in a very short time, and it’s meant to be distributed online, as it’s Flash based. The second is useful for LD because people tend to test games with Web version more (it’s far from being enough to get a lot of ratings, but it helps a bit).
My idea for One was so simple I managed to tackle gameplay code in a couple of hours. I love when it goes that way, because I know I can use plenty of time to make art, music and moreover add signs & feedbacks.
Several people have been surprised, playing One, that there isn’t any instruction. Well it’s been a choice. I love to do game jams to experiment with ergonomics. Having no instruction is a risky challenge. If it’s done right it helps immersion and focusing on the message of the game. If done wrong, it simply ruins the whole experience. So far, I don’t think anybody really got stuck in the game, so I would say I’ve done it right this time !
Here are a non-exhaustive list of simple things I implemented to make sure players learn how to play by themselves :
- Control scheme : as intuitive as possible, only three buttons (left, right and up). Duplicated on ZQD and QWD
- At least one bonus is visible on screen at start, encouraging to reach it and learn to jump and move.
- Audio feedback when touching bonus and also when reaching the current max altitude, hinting a bit on what to do.
- Midgame, my texts help a bit, by notifying that there’s more to discover upward.
I’ve worked with Photoshop. I’ve made backgrounds mainly using a brush to get this cloudy aspect. I didn’t want to spend too much time on animation so I made only a few poses of the character, mixing pixel art and painting techniques.
Surprisingly, I spent most of my time on music, with at least 4 hours spent on it. I must say I got a little carried I really enjoyed making it, so I wasn’t able to stop until I was satisfied with that small piece.
What went right
This LD went really well, for the main reason I did a game with a message and an intention in mind, I think. Working with the purpose of sharing a bit of love and poetry is wonderful. I managed to do a little something I’m proud of in far less than 48h because I didn’t get too ambitious and managed to focus on a simple idea and make the best I could of it.
What went wrong
The game was a bit oversized, and loaded from a website it discouraged some of my early testers. They complained it wasn’t working because I forgot to add a preloader : the page showed a blank page for around a minute. I hope those early testers didn’t rate the game too bad. I also stupidly forgot to proof-read my texts and let a small typo in the game (which I corrected later, as I learned it was allowed).
Make game with love, message and passion, focus on a simple idea but don’t forget about the little details ! Happy new year everyone, and let 2014 be filled with hope, love and plenty of wonderful games ! I think games can help the world be a better place, so keep going guys, I love you all.
You can reach me at contact [at] cuvegames.com if you have any question or feedback which I would love to have.
KERNEL is an action game about left-hand right-hand coordination.
You can play and rate it Here.
How I made it
- Idea Generation: “You only get one” is a rather general theme. It can fit into nearly every established genre. So, I decide not to care too much about the theme and just make a game that I want to play. I usually design games by asking “what if”s, “What will happen if you only get one player with a 2-player co-op game?” Will it be fun? I don’t know, so let’s prototype it quick and dirty, and see if its fun.
- Tech: I use Unity 3D 4.3 because I want to try it’s new 2d features and learn more about Unity. I found it quite neat, but it has no tile-map support, and the default sprite shader did not support lighting.
- Collision detection/response: IMO one of the most confusing part of Unity is its physic engine. In Unity, if you want your gameObject to be handled by physic engine, you must attach a rigid-body component to it, or the OnTriggerXXX() will not be triggered. But what if I just want to detect collisions, and I want my objects’s motion controlled by my own code instead of controlled by the physic engine? You still have to add a RigidBody component to your gameObject, and set gravity, drag…etc to zero. Enabling the “IsKinematic” will make your game object outside the physic pipeline, so those OnTriggerXXX() event callbacks will not trigger. It’s useless to me, so I decide to implement my own collision detection/response scheme using Unity’s built-in functions. Since I decide to make a rectangle-based, non-tile-mapped level, I should only implement rectangle to rectangle collision. I used the “Linecaster” in Unity to approximate the 4 edges of a rectangle. See pictures below:
The blue thin lines are where collision detection happens. To prevent double collision at one side, I made the lines shorter.
- Level Editing:
Since I have no mood for opening photoshop and draw some thing, I decide to make the level solely by primitives in Unity.
And because of the collision detection, I must only use rectangles! So, everything in this world is consist of rectangles, including characters and texts.
The resulting level looks like this:
Somewhat like a snake, isn’t it?
In order to make the graphics more pleasing, I use a bloom post-effects provide by FXLabs plugins (I have to use it since Unity Free does not support RenderToTexture.)
Here is a before-after picture showing the “neon-cubes”:
What went right?
- The Gameplay: The gameplay mechanics shows some potential and IMO it’s quite fun.
After the compo many new design ideas emerge in my head based on this double-control scheme. I will polish more and put them in a new version if I have time.
- Graphic style: The “neon-cube” style works quite well as I expected.
- Level design: I think the length of the entire stage is quite suitable for this compo. It last about 3 minutes and a half if you did not die any once in this game. And personally I like how I present the title : )
- Amazing feedbacks: People here are really awesome, they give constructive feedbacks! I really thanks anyone playing my game and commenting on it! For example, one person point out that this game is natively co-op, and if you play this game with your friend, it will be fun too! I like this comment very much : )
What went wrong?
- Control: The control is a bit floaty, the friction is too low. It made this game very hard to do precise movement.
- Difficulty: Because of the control, easy stages became really difficult.
Details: There are still many bugs and improvement I have no time to solve or polish in this compo session:
1.After death, the collision is not well handled because of state switching. This will make the players happens outside the wall.
2.The ending part is not complete, it will looping levels.
3.Visuals are not polished enough.
4.Did not complete the narrative part:
Initially there’s a story of this game. The main character is called “KERNEL”, on the contrary the level itself is called “SHELL”, it’s a huge spaceship. The gaming process is to control the kernel to reach the core part of the SHELL and injecting the control program to it’s core. In the end, the level will transform into a huge snake like spaceship and fly away into far galaxy…blah blah. Anyway, I did not complete that : (
- Learning a Engine during compo session: Frankly speaking I did not use Unity very frequently and I think I still not familiar with it enough. Next time I must ensure that I know all the basics of Unity before participating in a game jam!
This is my first time writing such a long post in English. Thank you everyone for tolerating some grammar/spelling or collocation error in my post. During this LD I learned very much and I really enjoy this. See you next time : )
This Ludum was chiefly a social experiment:
Could I bully some of my friends to come here to our house and have them make a game with me?
Given that some would show up, most of them not programmers and those that are… they code in different languages and are hard to coax into new platforms.
I had decided, though I put if forward as something that could be discussed, that we’d use Unity’s new 2D mode.
The art-style was sort of set on the Friday. In an attempt at harvesting everyone’s talent the most, we decided that all content be made IRL and no CGI trickery allowed. I also expected this would make our game stand out, which is extremely important when there are so many entries.
So we went to sleep and woke up to the worst theme we could have imagined.
We had a meeting, but I can’t say we ever got to a clear “You only get one”, so instead we had many weaker “one friend”, “one direction” (camera was not supposed to allow backtracking as in old Mario games), “one inventory”.
We never got around to formulating any strong connection with the theme, that’s the first thing that went wrong.
The IRL department sat out taking photos of things and tediously magic wanding and lassoing away their backgrounds:
In parallel I was coding behaviors with colored blocks feeling very professional:
I had a novice Unity assistant working on animating the main character (his first experience of Unity) which saved me several hours.
How did it all work out?
What went wrong
- Character controller is a bit funky, we’ll try to fix that soon.
- Time ran out for me, so all animations and effects were not included
- There’s a bug: If some items are picked up and dropped they become very very small
- There’s another bug making the hearts not affected by gravity (one could also miss the meat-heart and right now there’s only one crane-flight)
What went right
- The graphics! The atmosphere!
- The characters way of movement
- Some of the puzzles were quite awesome
But most of all, I proved to my friends that we’re a game making team. I got several of them hooked, and some that missed this time I’m expecting will join next.
Finally, we set out to make a game with no violence and no sexism in it. We stayed pretty much true to the no violence, though one ending can be interpreted as such, the game itself is very non-violent. As for sexism, there should be absolutely none in this game.
Try our game, many find it scary. We’re just proud that we did it: The Turmeric Jam Jar’s No-Name Game
1) Keep it simple, no gravity, no physics.
2) Think of new patterns, learn more about engine.
2) Test content pipeline for full-HD graphics.
4) Have fun.
And i broke the first rule almost immediately after i started working.
At first i wasn’t quite sure if one limb mechanics is going to work, so i spent about 2 hours experimenting with physics model configuration, character mass and different approaches to moving the limb until i hit the fun combination. After that i started adding variants to basic grabbing and moving mechanics.
The pistol was the first thing i did (because GUNS):
But it didn’t get into the Jam-build, as i didn’t have enough time to make bullets and shooting mechanics. Controls in the game are hard to master, so i had to slowly introduce player to the motion and physics. First few level were going to be just “acrobatic”, and i only managed to make 3 levels.
I used the free Unity with the new Box2D physics, and my library of Unity classes with all kind of maths, utilities, and base objects (that’s why i’m doing jam, i can’t work without an extensive library of functions, mad props to everybody who can use bare minimum and do all the math from scratch in 2 days).
I have my own free-transform thingie:
I know, unity now has default 2d-transform, but this one works in 3d as well as in 2d, allows to transform all meshes and physics objects (not just 2d sprites in 2d), has shortcuts for depth and also does all the stuff that default transform does (including multiple object transforming). It saved me so much time on level editing. Also not using default 2d graphics.
I used my animation editor and playback system again:
There’s not much animation in this game though.
And here’s a tip:
If you are working with Unity, i suggest you to make an editor-window like this and put there all the frequently used functions. This one allows me to quickly lock background/foreground, add shapes/sprites/bodies to objects and bunch of other useful stuff.
I did a lot of drawing this time. There are total of 70 sprites:
I spent a lot of time choosing color scheme, and then cutting all the platforms, but it was fun.
What went right
1) I spent most of the time working on mechanics, graphics and level design instead of code.
2) Engine didn’t break down, all the custom tools worked as planned, so i didn’t waste any time debugging tools.
3) All graphics were made to look crispy in resolutions up to FullHD.
4) It was fun XD
What went wrong
1) Didn’t manage to implement some of the mechanics i wanted, and didn’t make enough levels.
2) The game becomes too hard too soon, again, could be solved with more levels and more gentle difficulty slope.
3) No sounds, no music. I didn’t think about it, but i should have chosen some free music before the jam.
And the links:
Thanks to everybody who participated, having a lot of fun playing your games!
I wasn’t 100% satisfied with my game Charon (you can still play/rate the compo version here.) made during the LD (not so Speccy-looking, there was an obvious lack of sound FX), so I added Attribute Clash FX and CRT filter to emulate the old look of the ZX Spectrum games. These FX could be deactivate/activate by pressing CTRL if you want.
Version 2.0 available here: https://dl.dropboxusercontent.com/u/12598037/Charon2/index.html + (map here with spoilers).
I also added several sound FX made with Beepola. By the way, if you want to create raw chiptunes, “1-bit music” , this is light, simple software
I know I failed to create an interesting 2D-labyrinth, but I think I managed to make a successful gloomy atmosphere anyway. There is no “death” or Game Over in the game because I followed the #NoKill challenge (part of the #OneGameAMonth challenge).
Overall, I wasn’t be thrilled by the theme, that’s why the theme is kinda missing in this game :/
In general, it’s clear to me that my coding skills have improved since last time. So now for a breakdown, bullet list style.
This LD has been great, so far every game I’ve played has been awesome!
Since everyone is posting these post mortems I thought it couldn’t hurt to post mine as well.
It’s more an explanation of design choices than anything but I do cover things I’ll attempt to do again in the next LD.
Firstly, if you’d like to play Javel-ein before reading on (there aren’t any spoilers below, but it might make for a better experience to play the game before going into the analysis), please visit my page. The updated version has a few nice improvements such as a boss, slightly improved sound, small level tweaks and a timer, but it was made afterwards. You can also find a short video of the first few levels here.
My take on this Ludum Dare’s theme was that You Only Get One Javelin. You can throw it to kill an enemy, but then you have to pick it up again. As a result you have to be careful when aiming to not just hit the enemy, but have the javelin easy to retrieve afterwards. My goal was to have a fun, fast, action-filled platformer with a plethora of levels exploring the mechanic to its full extent. I’m super happy with how it turned out but there are still things which could have gone better.
I should warn you that most of what I talk about in this post mortem is obvious stuff: falling (or not falling) for bad design/programming/planning habits.
Taking Time To Think
Before doing any coding or graphical assets, I went for a walk and gave myself plenty of time to come up with an idea. I reasoned there was no point spending the weekend making a game I wouldn’t enjoying making, or wouldn’t enjoy playing. Really cliché but also really important.
Deciding On A Style
Straight away I decided on a very particular style and stuck with it: Low color count pixel art with large blocks of the same color. No outlines, no dithering. No wasting time endlessly redoing graphical assets because I decided to completely change the style (this happens a lot). I quickly went with a color palette I’ve been eyeing for a while, and which I really hope to use again, DB’s 16 Color Palette. Immediately I started work on the tiles and the hero. My first hero designs were… not the best.
Not the best at all.
From there I built up all the art assets focusing mostly on keeping everything cohesive and I think things turned out pretty nicely in the end.
Testing Levels, THEN Tiling
This is really obvious but it’s something I’ve always done wrong in the past. Instead of:
- make a level using featureless blocks
- test it thoroughly
- add tiles, features and flourishes
I will often end up doing the following:
- make a level using featureless blocks
- add tiles, features and flourishes (wow, the level looks so good!)
- realize the level has huge problems and will need to be heavily reworked (oh.)
Like I said, really obvious. I managed to (mostly) get the order right this time.
I guess, for me at least, this is the big one.
When I began designing levels I focused mostly on exploring the mechanic of having to retrieve the javelin after each throw. I wanted to promote situations where the player would take out one enemy with the javelin, leap over a second enemy and reclaim the javelin moments before being attacked by a third enemy. While this does happen occasionally (especially in some of the later levels and the boss level), most of the time the best course of action is to aim at the enemy’s feet and quickly pick the javelin up afterwards. This led to combat being more methodical (think: jump throw kill grab jump throw kill grab) and less free form, which is what I was originally hoping for.
One solution I thought of much too late was to implement platforms through which the javelin could pass (jump-through platforms, or grates, or something similar), since having enemies on these platforms would mean the player couldn’t always simply aim at the floor underneath the enemy.
Heavily related to combat is something else I had to leave out: more interesting enemies and traps. I had originally wanted to include enemies that shot at the player, as it would be tempting to pick them off from a distance but this would mean having a hard to retrieve javelin. I also would have liked to include reactive traps, ones that shot arrows or released an enemy when you triggered them.
Not much to say here except I need much more practice and experience when it comes to producing sound effects and music. Some players (quite rightly) found the sound effects unbalanced and others found them too harsh. Creating the sound effects earlier and getting feedback on them would have been very useful. As for the music, well, there isn’t any. And its absence is deafening. I spent a good deal of time trying to create appropriately ambient music with no success, and this is something I very badly need to work on.
In some ways this point sums up the previous two. Over the entire weekend, I wrote up only one list. Here it is, reproduced:
My goals for the next few hours are (in order of urgency):
- Create ground based monsters that chase after you.
- Create and refine a plethora of levels, without tiles.
- Tile the levels and add thematic features.
- Create a better jumping animation.
- Create a title screen.
- Add sound effects.
- Add music.
Let’s see how well this plan fares.
What’s great is that I managed to get through the first six points in this list! What isn’t as great is that there were dozens of smaller things I wanted to do or should have done, but forgot or set aside because I never had them written down anywhere. I would have benefited greatly from a constantly updating list of priorities.
Overall I had a great (yet sleep deprived) time creating Javel-ein and am really happy with how things went. The points I addressed are things I plan to keep in mind for the next Ludum Dare.
Thank you so much for reading this! I hoped you enjoyed it and perhaps even found it marginally useful somehow. If you give Javel-ein a go I would love to know what you think of it!