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!
Our experience in previous jams has taught us that with the short time frame you need to streamline workflows and divide up tasks. During the planning phase of Luminess we made it a goal of ours to create a way to make levels so that Evan did not have to hardcode them all. This would allow him to focus on coding the game and allow Jason and me to design the levels.
So, how do you get sweet visuals like this and be able to make a bunch of levels? Evan’s code loads an image that Jason or I create and checks every pixel for specific colors. Those colors correspond to specific types of walls. Generic walls that do no damage are in RGB Grey=100,100,100. The red kill walls seen here at the right are RGB Red=100,0,0.
Besides walls, the code also scans for certain pixels and places, PlayerSpawn, FinishSpawn, ColorOrbs, and Enemies. Enemies are drawn into the current levels, their spawns will turn on in an upcoming version. To the left is the drawn image of the level above. The little ‘P’ is where the player spawns and the ‘E’ is to spawn the end portal.
The workflow for level creation is this. We made a template in Pyxel Edit with the precise colors. Solid block tiles for various walls and icons for the spawns. The level is designed and output 8x the size. Evans code currently requires each pixel to be 8-bit, so we open the PNG in Gimp and Image>Mode>Indexed>Convert the image.
We will be making more levels, and adding enemies. I will make a guide on how you can make levels and maybe we will add them to the game! So check back often to play the newer version! Look forward to reading iiechapman’s post on the Pixel Scanning code with SDL_GetRGB(). Also, darfnagel’s posts on his experience with level design and music production.
Check out Luminess!
DISCLAIMER: I strongly suggest you to play the game before reading this. This is going to get spoiler-heavy at some point and also I heard the game is pretty cool and you should play it?
yeeeeeah. Here it is.
DISCLAIMER II: When I go rambling about ideas and design, it’s all my mind pre-implementation and it talks about what I wanted and what I thought at the moment, not directly correlated to what actually ended up being the game. Aspiring thoughts of a young artist?
Come forth fellow developers and players! Come closer to the light, and let me tell you the tale of when I joined this joyful crusade named Ludum Dare!
This right here is going to be a long and detailed post about many a things.
For one, you’ll read about my thought process regarding getting the idea and the whole game design.
You’ll also read about its implementation and what went right and wrong during that time.
And, at the end, you’ll get the resume of things I will we working on for now.
This all you’ll read, unless you prefer to skip certain parts, which no prideful adventure is said to do.
- “Where It All Begun” or “Getting The Idea”
- “That’s The Theory, Anyways” or “Designing The Game”
- “Down The Rabbit’s Hole” or “Developing The Game”
- “Side Effects” or “And Then What Happened?”
- “What Now?” or “A Blink To The Future”
1. “Where It All Began” or “Getting The Idea”
It was one hour before the theme got chosen. At the time, I thought I wasn’t going to participate. A few weeks earlier, I had a team with which we were going to Jam, but for one reason or the other, they couldn’t take part this time around. Mind you, it was going to be our first time joining a Ludum Dare and their first time attempting to make a game.
So when the theme was revealed, I decided that If I couldn’t think of a good idea before midnight (the theme was revealed at 11pm my time), I’d go to sleep and forget about it.
“You Only Get One.”
Okay! Let’s see… You Only Get One Life? Hm… A roguelike of sorts? A hardcore game?
You Only Get One Bullet! Hm… or perhaps, You Only Get One Dollar!
No, no. All those are really obvious, everybody is going to do that.
(point proven, I played at least 7 games where you only had one bullet/cannonball/arrow/rocket. Not that there’s anything bad with that, in fact, one of the best games I’ve played so far this LD was based around that concept: Titan Souls)
I quickly Google’d for a random noun generator and went ham on it.
You Only Get One Profit.
You Only Get One Bucket.
You Only Get One Partner.
You Only Get One Venezuela.
You Only Get One Potato.
“Alright, let’s try a different approach”, I said as I started to try to analyze what this LD ‘s Theme really meant.
“So, when someone tells you that you will only get one of X, what does that person usually mean or imply with that?”
“Well, I guess it means that whatever they’re giving to you it’s important. Or, at the very least, that you should take care of it, because there’s not going to be any more of it.“
“So like, when your mother bought you a new toy, that’s what she usually said.”
Alright, I had a clear idea of what I wanted to do:
I wanted to give the player something they need to protect. Because once it’s gone, it’s gone: You Only Get One.
Right, but how do I do that? And more importantly, What do I do for the player to not want to lose it. I know! if you don’t protect it, game over!
No. That’s boring and meaningless.
I want the player to realize they failed to protect something. I want them to continue playing without having that X when they lose it and see how it changes the game.
2. “That’s The Theory, Anyways” or “Designing The Game”
Yes! I really like the idea! Okay, but what do I give the player to protect?
Some kind of item? Like an amulet of sorts? No, How would that affect the game, anyways?
A weapon perhaps? Yeah, that’d be cool, if you lose your weapon, now you can’t defend yourself. That’s a mechanic change that’d show you that you Only Really Had One and You Lost It.
I like it, but it’s lacking something.
And so, I looked back at the noun generator:
You Only Get One Profit.
You Only Get One Bucket.
You Only Get One Partner.
You Only Get One Venezuela.
You Only Get One Potato.
It all clicked in my mind: You get a AI partner that you must protect. It can do something you can’t. If you lose it, it’s like losing an ability. But you don’t simply become weaker you lose “someone” and not “something”.
I believe it’s easier for a player to feel when something is gone if that something was a representation of a human rather than a object.
Going good so far!
Although it presented a clear challenged. The AI would have to be good. Or at the very least, not suck. If it sucks, the player would feel thankful when it’s gone and it’d ruin the whole point.
I only have two days, though.
Okay, let’s try to make it not suck.
I came back to the idea of the gun and thought: What if you can’t shoot? Your partner can, though. And when it’s gone, you only really get to avoid enemies, making the game harder.
At this point I had been discussing all of this with my friend. He had told me about making a platformer many times before, and I was always reluctant: I don’t really like platformers (Because I suck at them, but don’t tell anyone).
One thing I like, though, is procedural generation. I believe it adds replayability and since I’m really lazy and don’t believe in my ability to design proper levels yet, that’s kinda helpful.
So to this point, we were debating how the game should play. I thought programming a random level generator for a platformer would be fun and I really liked the idea.
But then I realized, programming a good AI that would be able to go through this randomly generated level was going to be hard.
“Maybe it shouldn’t be a platformer.”
That was a close one. Good thing I figured out another solution!
I don’t know what I was doing that remind me of a game I played long ago: One of the enemies was a tank that you could blow up the upper part of. Doing this removed the cannon and disallowed it to shoot. It could still run you down, though!
You control the legs and the AI does the shooting. Since it’s a platformer, and a randomly generated one, just being able to run and jump should be enough “fun” for this genre, I thought.
Okay, but how do I separate this? I can make you a human where you can lose your arms? That’d be a bit weird …and strangely funny.
You’re carrying the AI.
Yeah that makes sense: You can’t shoot because you’re using your hands to carry the AI, so it must shoot for you instead.
The movie Monsters Inc. came to mind, and I took inspiration from there to design the two characters: A big fluffy teddy-bear carrying a little girl. (Sullivan and Boo, anyone?)
Right, the shooting. Forgot about the shooting.
The only logical way to do the shooting was to give the girl a slingshot, right? Yes. Okay. Cool.
But what’s the shooting for?
Well of course there’s going to be monsters in here! I quickly drew a little dark-purple ghost with red eyes. Perfect!
…Wait, what do they do?
They shoot, of course. They shoot you things. Big, slow and cool-looking Things.
(As you can see, the thought process of the enemy design was pretty vague)
Alright, so, how do you protect the girl?
Well, you protect her from the enemy projectiles. Since she can’t move, you’re responsible for her not getting hurt. Of course she will try to protect you too by throwing rocks at the ghosts and eventually hitting one of their projectiles in the way.
And since the girl is on top of you, you can have different hitboxes.
Oh, and since you’re big dude you have more hitpoints than her. Yeah that makes sense.
Oh, oh! and since you get more hitpoints than her, that opens the chance for you to intentionally take hits in order to protect her! That is, hits that you couldn’t avoid and were going to hit her otherwise.
I can give the girl Only One hitpoint for good measure, too!
Okay, now there’s something I really value quite high in everything I make, play, read or watch and that is the ending. I’m from the belief that the ending to something is paramount and can make or break any story.
“But urs is just a gaem what story r u talken bout????”
Oh, my friend! Well, there’s something else I do love and that is something only games can do: To tell a story without explicitly telling it to you.
So I thought about an ending and come with what I deemed a really good idea (maybe it wasn’t, you tell me!)
And it was… HOLD ON A SECOND. Now this is one heavy spoiler. Okay, you’ve been warned now. Ready? Let’s continue:
The girl was in a coma the whole time and the game was actually a dreamy fantasy of hers. And if you reach the end with her, she wakes up from the coma. Consequently, If you reach it without her, she really just dies.
Holy mother of cliques!
And so, that’s why the end of the level is passing through some rays of light. You know, light at the end of the tunnel and that sort of things.
Agh, this is getting pretty corny!
Okay, we’re pretty much done with the design:
You’re a bear carrying a girl through a randomly generated platformer to wake the girl from the coma because…
Oh, dang it. I forgot: There’s no purpose! Not for the player unaware of the actual ending, at least. Why is there a bear? Why is he carrying the girl? Why are they running from those little monster than can be killed on collision anyways! Why! This make no sense!
These questions would haunt me until the last couple of hours of the second day, when I added that Intro cutscene where everything sort of makes sense. Sort of.
Oh also, before we’re done with this part, let me clear something up: I intentionally left every bit of the story as vague as I could. At first, it was because I like it when people have to find out the story themselves, I don’t want to read them the whole deal upfront. Movies and books and even comics are better at that than games, in my honest opinion.
However, a wonderful byproduct of how vague it all was done, was something I didn’t realize until people started voting and leaving me the most awesome comments ever: They were finding their own meanings to my story, they were telling their own tales with it and identifying themselves and their loved ones in my vague story and crafting their own with it.
Dayum. I can’t stress how happy that made me, and it was a complete accident!
3. “Down The Rabbit’s Hole” or “Developing The Game”
Friday night I went to sleep a couple of hours after the theme was revealed, with most of the game ideas having been thinked through, a awfully vague design document written down, the stencyl project started and the git repository setted up.
Oh, here’s a list of the tools I used and why:
- Stencyl – I made the game with this. I’ve been tinkering around with it for a couple of weeks from beforehand and It allowed to make games really fast. I’m actually a programmer, that’s my daily job too, but I quickly realize that making something Really well, with C++ and OpenGL is nice and all for a finished product, but it just wasn’t going to cut it for a Ludum Dare. (Because I produce significantly slower with it and wasn’t going to be able to get a Web Build out)
- GIMP – To make the art and animate. Because I can’t afford photoshop. And also, I’m on Linux for reasons that’d be too long to explain right now (And this is getting full of words pretty quickly)
- Git – Mostly because it’s a good habit, but also because You Only Get two days, and time is extremely valuable. Git saves you time a whole bunch when you have to scrap things out, or if something terrible happens.
- Dropbox – Used it to share the builds I was getting out to my awesome friend who lend me a hand testing them and to the genius that is the person who made the music.
Oh, right. Let’s talk about that for a moment.
I was going to go solo on this, initially. I talked about the friend who did the moral support before, but I want to properly introduce him. He’s on the Special Thanks section of the Readme file after all!
Aytuğ Ergün is a wonderful person that totally didn’t ask me to say this.
He was the second opinion for this game, I discussed everything with him and he helped me test the games. Eventually, he’d come with crazy good ideas that’d be impossible for me to add in time (Like some of the features you will see in the map generator for the polished version).
He also got me in contact with the amazing person that did the music for the game.
I personally can do many things, but music is my weakest “skill”. I usually do music by just trial and error and have no knowledge of music theory whatsoever. I knew music was going to be important for this game and I knew it was going to take most of my time.
Thankfully, a Saviour appeared. This new friend made the music for the game and he’s a goddamn genius.
Just having someone to do it for me was good enough, but he did that and more: The music is amazing! I cannot stress enough how thankful I am for his help.
Oh yeah, that was also the reason I had to submit to Jam instead of Compo. Sadly, I had to work on Monday, so I couldn’t really use those extra hours.
On Saturday I woke up, turned on the computer, got me a coffee and went right into it.
Thanks to Stencyl pre-made stuff I had a the basics for a platformer in no time.
In less than an hour I coded the map generation. Which actually has a bug: The idea was to code the distance between the platforms to consider platform height and distance in order to make all the platforms reachable, but somehow it doubled, and since I already had the double jump working, I left it in because it created more variety (And some cool leaps of faith style jumps) and all the platforms are still reachable if you time the second jump properly. I also had to do some modifications to the default Stencyl airjump behaviour that introduced a lot of bugs that’d haunt me until the last hours of the second day.
I Added a character that’d always set itself to your character’s position, and have it not collide with you, and I got the girl that way.
Added some default “Enemy Shoots at player” that stencyl provided and coded some quick movement AI, and those were the enemies.
The I stole and modified that behavior and gave it to the girl, every couple of seconds, she’d choose the closest target and shoot at it.
And I made a bunch of art and started receiving the music samples from the Anonymous Hero.
Added lifebars and a Timer that stopped when you reached the end of the level. Initially it was created to check how long the game was in terms of time, but I left it there because I thought people that like platformers might like it to test their runs? I don’t know about platformers and I suck at them but I thought that was a good idea, heh.
On Sunday, I made the lifebars good for something and made it that the bullets damage you. I also made it so anything that is not their bullets or the tiles banishes the little ghosts that I started to call shadelings. That way you can headbutt them to death and the girls’ rocks did something.
Then I made the hardest part of the game to code (which actually wasn’t that hard): The world-changing mechanics when the girl died.
And after that I started polishing everything up. Added the two endings, added an intro screen and got the idea for the comic strip at the beginning that would give a little “fake” meaning to the game at first. I also got the ambient sounds for the “dark” world from the Masterful Music Person and also that ripples sound when the transition occurs.
And then, I submitted it. It took me four hours to submit it because I didn’t know I had to do so many things! (readme, screenshots, testing, last minute bugfixing, hosting, etc)
4. “Side Effects” or “And Then What Happened?”
And then I went to sleep because I was dead tired.
And after that, I started rating other people’s games because that’s what Mr. Ludum Dare told me to do.
And a couple of hours after that I started receiving comments.
The most beautiful comments I’ve read in my life so far.
Mostly because it was people I didn’t know, acknowledging all my hard work and telling me about their experiences with it.
And holy hell it was rewarding. The entire event was worth it alone because of what some people said to me in those comments.
I’m so happy of having being a part of this. This is the cherry at the top of my kinda lame cake of a year. I finally got to finish a game! And people liked it!
Okay, okay. Enough corniness for now. It wasn’t all fun and giggles. So let’s go with what went wrong:
- I’m really fond of little details and I couldn’t fit all the things I wanted in, due to time restraints.
The animations are really rough, the comic strips feel rushed and the main screen is ugly as my dog. (my dog is really ugly looking by the way)
- Mechanically, the game didn’t have the impact I wanted.
You don’t really notice Zoe that much. Probably because a lack of sound effects and hit pauses when she does things.
- The map generator needs a ton of work. I have a lot of ideas to make it better gameplay and visuals-wise. And also the things my good friend suggested.
- The difficulty is linear.
I got the chance to watch a couple of different people play my game and learned a lot from it.
I noticed how much can the skill of a player vary.
It took my little sister around an hour to finally be able to beat the game once. She got the full experience for it, though.
But it shouldn’t have been that hard for people with that skill level, not right away, at least. (luckily I stole the instant respawn idea from games like Hotline Miami, which made it really addicting for her, so she kept on going and going until she finally got to the ending).
Then I got to see other people way more skilled than my sister and probably even more skilled than me. They got to ending after maybe two tries, but the thing was, Zoe never died in their playthroughs. That’s kind of a problem, all things considered. And that is probably also because of how short the game is.
- But its shortness is okay for it’s content, that I know: I realize my game doesn’t have enough variety to just extend the level size and not add any new enemy type or feature or mechanic alongside it.
- Level design: Let’s be honest, there’s none. I hate having to tell the players the controls the way I did: in the main screen. It feels really wrong. I’d have liked to have an intro level, specifically designed to teach the controls and the mechanics before you jump in the random generation.
- The controls were iffy. Or were they? I really don’t know, you tell me!
I spent so much time playing it, that I can’t tell how difficult it is or isn’t, neither can I tell whether the controls are bad or good, I’m just too used to them. That was also the reason why the difficulty is weird.
- Oh yeah, remember when I mentioned level design to teach mechanics? Well, there’s a kneel mechanic in the game, that is intended for you to use it to cover the girl with your body and you lose the ability to move while doing so.
I put that in because I thought of the possibility of at some point (due to the randomness of everything) you won’t have a chance but to get the girl defeated.
This wasn’t right, you are supposed to be able to protect her.
I like my games hard but not impossible!
This mechanic wasn’t clear at all, most people either forget about it or don’t understand what is it for. Or think is just a crouch move that is never used because the level doesn’t generate any small corridor you need to duck through.
Because it’s not a duck at all, your collision remains the same, what happens is that Zoe moves down and further away from you a little, and your animation changes.
- I also suck at marketing my game. I feel like I’m annoying people whenever I try to tell them to play it.
So I usually avoid doing it.
Which is a problem, because going by some people’s comment, it’s an o.k. enough game to not be a complete waste of time.
Or is it?
Maybe you should play it and tell me *wink* *wink* *nudge* *nudge*
5. “What Now?” or “A Blink To The Future”
Now I really want to polish this up. As you can see, there are many things that were left in a precarious state. And I don’t really like that, so I will work on that.
I will try to fix all the problems I listed and add even more polish to it.
And then, I will release it on Itch.Io, most likely.
It will be free!
I might add an option to donate to me and/or to the Marvelous Musician, you know, if you’re into that kinda stuff.
That’s pretty much it, I guess.
Oh yeah, I almost forgot.
Thank you for reading and if you played my game Thank you for that.
I try to thank each comment individually because they really mean a lot to me.
Hope you enjoyed the reading and/or the game.
See you in a couple of months/weeks when the polished version is released!
Hey all! I’ve been enjoying a lot of games from this Ludum Dare, and I hope you all have to. I participated myself in the jam, collaborating with another indie game dev known as Code_Assassin. However, through details I’ll explain below, we didn’t finish. While we did submit an entry, it wasn’t a finished game like we hoped, and after a day of thought, we requested the entry to be taken down, and the game removed from Newgrounds.
Our game originally started off with a premise of finding a mob boss out of a group of people, the levels and the clues would be random each time, but you only had one chance at killing the boss. We agreed on using Flixel as our framework due to its ease of use, my experience from using it in last year’s Ludum Dare and CA’s experience with Actionscript3, and that we could upload it to the web. We got a Git repository set up and we were hyped up and ready to go!
What went right
My ability to react:
Actually this was not the theme I expected (the ideal would have been “Death is useful”), but once I learned to adapt quickly to circumstances and had an acceptable idea after thinking for a few hours. From what I read on IRC, many people had no idea what to do until we were already in the final hours of the jam, so I think in that area I can consider myself lucky.
Thanks to the simplicity of my idea I did not have to use several of the tools that I announced in my entry post.
This allowed me to save a lot of time and I could focus on the KISS principle.
I think the game is pretty fun, or at least entertaining. It is challenging without being frustrating and can give you some minutes of fun. Not bad considering that the idea is pretty simple.
This time I was able to spend more time on IRC.
And you are fantastic. All of you.
What went bad:
THE SHIPS ARE FLYING SUBMARINES!
And are supposed to be spaceships!
In this postmortem, there are a bunch of things that I want to hit upon. First I’ll give a description of the game. Then I’m going to talk about the theme of the game vs. the theme of the competition. Then I’m going to go into what I couldn’t do due to time running out, and what I couldn’t do due to lack of skill. Finally, I’ll talk about my general experience making Follow the Sun. Suffice it to say this postmortem will ruin part of the game for you if you haven’t played it. If you don’t want to get story-spoiled, play it first before reading on!
About Follow the Sun
Follow the Sun is a short, 3D game where the player controls a child charged with rescuing the king. At the start of the game, the main character, a child named Kayin, sees the face of the king in the sun, asking Kayin to save him from the corruption that has befallen the land. To do this, the king uses the last of his strength to grant Kayin a power to cleanse the corruption, but it will only last until night falls. The implied goal is to make your way to the king, killing the red corruption along the way by using the granted power.
Mama is Sick can be played here:
My first Ludum Dare! And my second game jam ever.
This post will cover what mine and @GarrickWinter (Guerric Haché)’s game is about, a summary of the process we went about making it and the top 3 things done well and the top 3 things we could improve on.
Quick description of our game (taken from the instructions screen):
“Mama is Sick” is a resource-management, hard-times simulation game.
YOU ONLY GET ONE DOLLAR A DAY to look after your family (thanks to a generous family from overseas) while papa is away and mama is sick.
Buy food and water to make sure the food, water and health bars of you and your family don’t reach zero or death will occur.
If your education bar reaches zero, you won’t graduate high school.
You have to last 50 days until papa comes back. Will you manage to graduate? Will everyone survive?
You can work in a clothing factory to earn 50c a day, but be careful not to miss too much school. You also need to study at least three days a week or risk not being able to graduate.
As soon as the theme was announced, Guerric and I decided to make a list of 10 game ideas based on the idea. This is always a useful exercise, jam or no jam, because it means you get to think up a few ‘less-inspired’ ideas, throw them out, then go with a better one.
We ended up with a list of 12 items:
- Menopause (This was my favourite until we settled on #9)
- Child (This started a conversation about China’s one-child policy, but we decided that since it was recently overturned, the issue would be dated in a game)
As soon as Guerric said ‘dollar’, we both knew it was what we wanted to do, and we started spouting off the potential things we could do with it.
Both Guerric and I are passionate about social activism, with my particular interest lying in feminism, so whenever we design together, we try to use mechanics to explore a social issue.
We also knew that given the time-frame, we had to design a game that would play to our strengths.
Guerric is basically a wizard programmer, but neither of us had worked with Unity properly in a few months (we both attend Vancouver Film School, studying game design).
Meanwhile, one of my goals is to be a narrative designer. Neither of us are artists, although my basic photoshop skills do tend to outshine Guerric’s adorably shoddy programmer art :P.
So we knew we weren’t going to do an open-world 3D game.
After settling on the ‘Only Get $1 a Day to Look After Your Family’ mechanic, the rest flowed pretty easily. We knew that interface design was going to be one of the most important things to get right for our game, so that was the first thing I worked on.
We worked on our mechanics for the first day and a half before I even got around to touching the narrative, which I did by writing a few pages of character design, then writing out the interactions I thought family members would have with each other.
Guerric, in the meantime, was busy figuring out how to optimise the GUI elements I had given him to work with.
We started putting in audio on day 3, leaving us with a full day to play-test, fix bugs and working on extra polish.
THINGS DONE WELL:
1. Planning and Documentation:
I wrote nearly 8000 words of documentation in total during the jam, with classic document titles such as ‘Audio To-Do List’, ‘Halved Numbered Narrative’ and ‘Guerric’s To-Do-List’. If you want polish for your game, make lists! Plan! Think ahead! We utilized Google Docs during the jam, meaning when I was play-testing, I could quickly point out a bug, add it to the list, then Guerric could cross it off the list when done.
Synergy! Just kidding. But seriously. The last time I had a working relationship this good was when I was in a band and my singing partner and I could improvise in harmony.
When you work with people who are interested in similar mechanics, passionate about similar issues – productivity triples. You don’t waste time arguing about meaningless items.
Guerric and I think of ‘Mama is Sick’ as our game. Not mine, not his. Even though elements of it were tasked to one person responsibility-wise, we still communicated everything we did to each other, constantly asking for feedback. Guerric proof-read my narrative and reminded me of elements to include in the GUI, I helped him think of programming solutions – synergy!
3. Play-Testing (and Scope)
On the second night of the jam, Guerric sent off a half-finished prototype to our friend Danilo. Even though it was nowhere near ready, this proved invaluable as it helped answer some questions that Guerric and I had been asking ourselves, such as, ‘Are the character stats bars enough? Does the player also need numerical values displayed?’ This helped relieve some of the worry we had. On the flip side, it also gave us confirmation for changes that needed to be made.
Furthermore, I was able to play-test the narrative 3 times – and would you believe that at one point, our game ran 90 days long instead of 50? On my first play-through, I reached day 56 when I realised, hang on. I don’t want to do this anymore. This is getting tiresome. Shit. I need to cut the narrative in half!
But none of this play-testing would have been possible without proper scoping. We knew our abilities, we knew the time restraints, and we knew what we had to do.
THINGS FOR IMPROVEMENT:
I feel like this is something that can almost never be done perfectly, as you’ll always have that one player who gets confused about something you hadn’t considered.
During the ’Girls Like Robots’ post-mortem presentation at Unite this year, designer Ziba Scott mentioned that the tutorial should always be made first, and that by following this principle, he discovered that he had already made a third of the game.
In the past day of playing other Ludum Dare games, I’ve found that the most common gripe people have is that they don’t understand how to play the game – whether that be confusion with the interface, what the goal is or the controls. And it’s a huge barrier for getting people to properly play-test and rate your game.
So although we spent a good few extra hours putting in things like hover-text explanations of GUI elements and an instructions screen, we definitely could do more – like an animated opening tutorial day (that would take a better artist than me to implement).
2. Don’t Learn the Engine on the Day
Although Guerric and I both have experience with Unity, we only took a brief period of time the day before the jam started to familiarise ourselves with the latest version.
This leads to precious minutes being spent learning how to use certain elements of the engine during the jam that could be spent otherwise.
It also leads to mistakes that can’t easily be fixed.
For example, I made all the GUI elements 300 dpi for a 800 x 600 game, when I should have made them 72 dpi. This led to an unnecessary decrease in picture quality, that was somewhat circumvented by a fix one of my old teachers recommended.
3. GET AN ARTIST
Oh boy. So yeah. I’m not an artist. All the GUI photoshop work I did could have been done better, in a shorter period of time, by an artist, had we had the foresight to bring one onto our team. That would have also freed me up to do things I’m more passionate about, like narrative and mechanical design.
Overall, I’m super glad that Guerric asked me to do this jam with him. I’ve had an amazing time, learnt lots, and am proud of the game that we’ve produced.
For me, the most rewarding part has been reading the comments that the community has left us, and I’ve certainly learnt a lot through playing the games of others, and the amount of talent and creativity crammed into this weekend by thousands of fellow designers awes me to no end.
Mama is Sick can be played here: