Posts Tagged ‘post-mortem’
So the Mini Ludum Dare #53 was my first ever LD, and all I can say is that it was fantastic! Great people, game development, and an excuse to geek out and rapidly destroy my health over the period of 48 hours. I entered the jam as a solo participant (because I don’t have any game developer friends in real life) and spent the weekend in the solitude of my study. It was an experience that definitely opened my eyes to quite a few things.
A Cruel World was my attempt to express my artistic side a bit. I don’t have time to do art anymore, and even though I’m terrible at digital art (I’m more comfortable with a good ol’ pencil and paper) it was a great learning experience for me. Although the atmosphere may have been a little wishy-washy, it was meant to be a depressing exploration game covering the topics of corruption and greed, self-image issues, deforestation, animal cruelty, and over-reliance on religion. This was my take on ‘The Future Is Now’ theme – because these are problems that we face today, that will only worsen as time goes by.
The atmosphere I aimed for was heavy, with anthropomorphic character designs that matched each NPCs character (such as the wolf being the greedy salesman, and the sheep being the religious figure). I would have loved to have had more time to build a more complete world and to iron out many of the bugs, but alas it didn’t work out this way.
The Development Process
With only 48 hours to complete the game, I used my own libGDX-based framework (with already implemented input, render, debugging, and audio controller classes). From here, it was a simple matter of creating the world-space, drawing the art, coding the logic, and slapping in some audio for good measure. I started with a notebook and pencil for all my designs (all concepts, artwork, algorithms, and level layouts) and subsequently implemented my designs as I went.
Although I have developed a few small games, I have explored quite a lot of new territory this time around. For instance, I have never written a free-roaming game with separate levels, so this was an interesting endeavor to implement dedicated classes, each with their own self-contained logic, for each world-space. An inventory system (although extremely basic) was another thing that I had never touched on.
The fact that I had an extremely tight schedule and clear deadline definitely helped me set aside my uncertainty and simply slap together code to make it all work. I tend to be overly pedantic when it comes to programming, always considering optimal memory/CPU usage, neatness, code commenting, and so on. There is no time for this in LD however, and this really helped me overcome my care and simply MAKE THINGS WORK (albeit only adopting this strategy nearly half-way through the compo).
What I Took Away
All in all, I was quite happy with the result. It may be slightly buggy, and perhaps I could have been clearer about where to go and what to do, but then again it is an exploration game. I would have changed a few things if I could however, but as I said I had run out of time.
First things first, I realize now that programming is my absolute favorite part of the game development process. The labyrinth of flowing code is an intoxicating mind-game to me – a way to lose myself in complicated algorithms and hierarchical visibility. I loved the art side of things as well, but I found it became somewhat tedious (and anyone who has played my game may see how the quality of art declines the further you get.) This may have been the problem of hand-drawn art taking so damn long to make, and this coupled with the deadline put me off. Who knows?
Secondly, I learned that an exploration game is not the best approach to compo with such a short deadline. It has almost zero replay-ability, the slightest bugs come out glaring like a car’s headlights in the dead of night and utterly ruin the experience, and you simply do not have enough time to create an expansive and interesting world that will offer a lengthily play-through.
On the game front, I definitely would have approached some problems differently. I relied too heavily on boolean control variables for inter-class communication, which could have been replaced by a much more, much simpler system if I simply based actions on player position, instead of an activation button while the player stands at a specific position. It’s a minor thing, but this simply change would have saved me an hour or two of debugging which could have been used far more productively. Good knowledge for next time then.
All in all however (as I said), I am pleased with what I accomplished. The purpose of these jams is to extend your knowledge and experience, and this is exactly what I managed to do. I explored new territory with A Cruel World, and enjoyed every sleep-deprived second of it. I’ll definitely be more confident, prepared, and efficient at the next Ludum Dare. I will also take what I have learnt in the mere 48 hours of development and funnel it into my current Android game - a project I hope to complete soon and release on the Play Store.
To end off this post, I have uploaded the time-lapse video of the development process for anyone who likes to stare at low-framerate, illegible windows:
Just another note: I haven’t had the chance to play through any other games as of yet. I’ve been out of town, and operating only by smartphone for the last couple of days. Last night I returned, and I’m off again tomorrow morning. Perhaps next week I will have a gap in order to melt my mind with some of your guy’s lovely creativity. Until then, have good one!
This Ludum Dare I made SnakeFormer, a short puzzle game combining Snake with pseudo-physics platformer mechanics.
If you’d like to, you can play it here.
Like just about every game, some lessons were learnt, and I thought I’d write a small piece about them. It’s 12 hours before the judging ends, and nobody has time to read through a novel, so I’ll keep this short!
Game & Level Design
If a level has the right difficulty for you, it’ll be too hard for everybody else.
I swear I’ll remember this lesson one day, haha. That doesn’t necessarily mean “make it easier”, because in a level-based game, there is another approach:
When in doubt, make more levels.
Easier levels, preferably. I should’ve spent a lot less time on the menu and instead made more transition levels. Which brings me to:
Don’t introduce more than one mechanic per level.
Level 2 introduces: Lava, falling stones AND growing the snake. That’s, uh, a bit too much.
Even if you think the goal is clear, it might be not.
So – better make it clearer. The goal in my game is to exit the screen to the right, like in most platformers. Some people thought that they had to eat the whole level though, which is a more Snake-like goal.
Put instructions in the first level.
Some players don’t read the instructions before starting the game – but once they are confused inside the game, make it as easy as possible to re-read them.
Art, Sound & Music
Glow is freakin’ cool.
Homemade sound effects can be quite entertaining.
Any game needs sound effects, and since I’m no good at making them digitally, I tried to use my mouth for most. Turns out that’s a lot of fun to listen to, and I actually had a few people praise my sound design, especially the eating- and the end-of-level-sounds.
Abundant Music (music generator) + GXSCC (a MIDI chiptunes-like renderer) are the best team.
I’m no musician, so I had to use generated stuff. Those two are PERFECT. It still took very long to find songs that sound well together, but that definitly was time well spent.
Cheery music for hard and punishing gameplay.
Gnhihihihi. So much fun while watching streamers.
Trust in the process and stay open for new ideas.
The concept I started out was a lot more boring, but then I asked myself “Okay, so those stones fall – what if gravity affects the snake too?” – and then SnakeFormer was born. So even if your initial idea isn’t perfect, go for it anyway instead of giving up, it might evolve into something great later on!
If your idea comes late, don’t worry! There’s still time!
I started development 12 hours after the start of the compo – 8 hours sleep, 4 hours pondering. Contrary to all expectations, I’m still alive and the game is playable.
ToDo lists are great to maintain focus.
Always use a ToDo list so you won’t lose track of your next tasks. Workflowy works best for me.
Thanks a lot for reading! I hope you enjoyed it as much as I enjoyed writing it.
Maybe I made you a bit curious about my game too? If you want to, you can play SnakeFormer here – and I don’t think I have to mention how much I like comments and ratings, do I?
Not so much a post mortem about the game, but about my goals: Same as last time (LD#27) i wanted to use this oportunity to learn, to get to know PHPStorm and to make my first Phaser.js game using TypeScript.
Well, i have to admit, i am very happy with the outcome. Not that my game Beneath the surface with Sir Walter Wuffington is so great and enjoyable that i am utterly sattisfied with it as a game per se, but i achieved my goal of finishing my first Phaser.js game and i got know PHPStorm a bit. On the TypeScript side i have to admit that i had a hard time to adapt the way i code JS to the TS style and paradigms, but these things can’t be achieved over night so to speak.
Which JS Gameengine to use? After wrestling with my bare hands (i.e. without any game engine) last time around, i decided that it is time to try one of those nice geme engieenes everybody was talking about. After doing some research Phaser.js caught my eye for being relatively new (i.e. supposedly not filled with obsolete clutter and paradigms), which seemed to have a relatively active community and responsive developers (rich hangs around a lot over at the html5gamedev forums) and mobile performance is one of their main focal points. Now, after implementing my first game with it, i am a convert. Try it out for yourself, there are tons of examples and tutorials, and on top of all that it has TypeScript bindings too
Is TypeScript really that much better than CoffeScript or just plain JS? No idea! Looks good though. I have to admit that even with all my motivation, i simply lacked the time to really make use of TS’s advantages. I managed to write my game in TS (well, TS compliant) but it is basically plain JS with a coating of TS to make it compile. After all the time i spent setting up the whole TS / PHPStorm / Phaser.js shebang, there was not that much time left to worry about elegant coding, sth. that i normally value very highly (although i am more an average programmer solutions that are generally more interesting and than elegant).
I found my new personal favourite IDE: for everyone out there pondering the question of which IDE to use for all their JS / PHP / HTML5 coding, i can give you a warm recommendation: PHPStorm (or WebStorm if you don’t need the PHP part, PHPStorm is WebStorm + PHP) After using Texteditors, KDevelop, Eclipse, Aptana for over a decade for all my WebDevelopment, i have found my new IDE of choice. The code completion, existing templates (jQuery, Drupal, WordPress, …) JS Debugging, the ease with which it integrates with other libraries absolutely convinced me, after being disapointed with the slow improvements and overal buggyness of Aptana.
Expectations: As i mentioned before, due to the time constraint and my high expectations i had to the game itself, it is not as good as it could have been, but that was to be expected. As i spent probably two thirds of my time figuring out how to do stuff in Phaser.js, TS and PHPStorm, there was not that much time i could invest into the actual game making. I am still pretty content with the result, this time i even have some sounds (two to be exact, but it is a start). If i continue at this pace and stay with the current toolchain, i might produce sth. halfway decent around LD#31
I was still expecting too much from my game i guess, as i wanted to learn all that stuff but at the same time couldn’t bring myself to tone down my ideas for the game, as it would have felt even emptier / more boring than without the second view. It might be worth to scrap that second part and add some juicyness instead, but who knows, next time around i’ll probably have enough time for both as i will be more proficient in using my current toolchain.
As always it was amazing to see how much can be achieved in such a short time. For myself i am happy about the work / learning i did in just 48h, and it is always stunning to see what other ppl can come up with in just 48h / 72h.
The fact that there are others like me out there that just love making games, creating stuff, seeing their ideas come to life and being (more or less ) enjoyed by others warms my heart.
I can’t wait till next time, till then
goeth forth and codeth
p.s: But please, don’t let my ramblings keep you from trying my game :
[My name is Carlos Leituga, I'm a Game Designer, and once again I joined the Make A Game team to create a game in 72 hours for Ludum Dare #29.]
We were a smaller team this time: two programmers, one artist and myself in the same room, while another artist was about 1 thousand Kilometers in a straight line from us, and we could only talk to our musician through email. We couldn’t afford to be too ambitious so… no pressure.
It’s been a while since I did any game design from the ground up. With the exception of two months doing freelance work at the start of this year, I’ve been unemployed for more than a year now and I felt a bit rusty. My focus lately has been shifting from completing older design docs, to learning Game Maker Studio, and then deciding that I should read up more on logical thinking for programming, and at the same time spruce up my memory on an easy to learn language that I was still familiar with, Processing.
This led into choosing Game Maker Studio as our framework, besides the other three local team members having some experience with it, during any design downtime I could jump into the sprite or level editor and help them out. Hell, I could even help search for solutions if we’d get stumped by some of the different ways GMS does things, I can say I’m way too experienced in that.
This being my third Ludum Dare I had a decent idea of what I was getting myself into. These game jams are really a great way of practicing on actually making something from start to finish. I think that is what many of us really need to get better at, I know I for one have put tons of time into other bigger projects which never see the light of day, maybe because they are simply too big of projects. Here are some quick tips which I’ve learned from previous mistakes and could be good for newcomers entering into a ludum dare, for starting any new game project I guess.
- Start with making something really simple and make sure the “fun factor” is there early on, the rest is polish!
- Don’t explore some new technology while trying to complete a game.
- Give each aspect (design, planning, code, graphics, audio, testing, etc) enough time each. Don’t spend the first day and a half coding and get the rest done in a few hours.
- Make sure the game is done well before the deadline so you have time for playtesting, bugfixing and polish.
- The most important thing is to complete a game from start to finish, not that it’s the most feature packed perfect game.
So I’ve been playing unhealthy amounts of Spelunky lately and I wanted to make a platformer with a bit of the same vibe, and I’m a huge space fan so I went for that. When the theme got decided I thought I’d make a underground platformer. Since I love the jetpack in spelunky and don’t get it often enough, I thought I’d make a game with a similar feel as the jetpack in Spelunky. I also wanted to make a simple and addicting game with online highscore, so I played around with the idea until I ended up with what the game is now. It could still get a lot better, but I’m quite happy with the end result in just two days work.
Warmup & Making Music
I’m especially happy with having produced music for in the game, and am even quite happy with the end result. Truth is I’ve wanted to learn how to make music for a while now, and started various tutorials but never got very far. The day before Ludum dare I made a warmup game called Space Survivor. It took me about 2 hours to make, and looking at the highscore stats I can say that it’s probably the game I’ve made with best time coded vs time played ratio ever.. which is a bit depressing. Anyway, the cool thing is I also decided I was going to make music for the game. I opened a a music program called SunVox, which is the first music program where I actually like the UI, and decided I’m going to make a song from start to end, it doesn’t matter how crappy it is, but it’s going to be finished. My first song. Instead of trying to learn each aspect of music and mastering it before I even make a song, this technique really taught me how to make music and I put it in the game! And I’m so happy for it! The day after Ludum dare started and I made another track and put it in my Ludum Dare entry, and it turned out quite nice for my second track ever!
For the first time I felt that I was done enough for the deadline. Overall I’m very happy with the end result, here are some points which I’m happy with
- I had a nice balance of time spent coding, making art, making sound, making music, testing, bugfixing and polishing which made all areas good enough!
- I actually made music for my game and learned how to make it in the process!
- I had online highscores – this is something that really makes some games so much more fun!
- The game feels like a complete game and is polished
- I invited two friends over for a little Jam-Lan-Party, this made the whole thing event more fun and I think we made better games because of it!
Although I’m very happy with the end result, there were a few hickups.
- About half way in on day two I began writing ugly code to make things rapidly. This made the final code quite cluddered and just makes it harder to update and improve the game further. I will have to spend a day just to cleanup the code later!
- Lesson: Things don’t have to be perfectly coded, but alteast keep it clean and organized at all times!
- Some MySQL issues have made the online highscores slow/unresponsive sometimes, which results in a lot of statistics/scores have gotten lost. This is really a shame because I wanted to present cool playstats here for you!
- Lesson: Brush up MySQL skills for next time for better highscores/stats!
- I’ve got about 60 ratings to my game and I’ve done 120 on others, so I can’t complain. Still somehow I feel it’s very hard to get people to try my game. I believe this is in large part because I don’t have a web version. I know the feeling when testing games, if you gotta download it, let alone run a seperate redist install, it’s hard to want to try it! I really do think this is a shame, I think games feel better when not played in a browser. And c#/xna is awesome!
- Lesson: Consider using a web-platform next time or accept low play stats. (HTML5, Unity, etc)
- The title. To be honest I suck at titles. It was never really my intention that the game would be named Gravity. I sort of just wrote something while designing the graphics/menu to get the style right. In the end time was running out and I hadn’t thought of a better title and then I forgot. I thought of the George Clooney film and just added a random subtitle since I thought that looked cool too.
- Lesson: Titles can be important, decide on a good one early on and roll with it. It’s hard to think up a good name at the last minute!
Some play stats!
With each play being registered in an online highscore, I can also calculate some play stats from them. Sadly my MySQL skills weren’t good enough in time, so a lot of the stats got lost because of a query taking very long time to load sometimes.. But here are some fun play stats at the time of writing!
Disclamer: Sadly up to approx 50% of plays may be missing, so stats below could probably be doubled, but this is what I’ve got! (Any new stats should be recorded correctly I believe)
- Total number of unique players: 82
- Total number of plays: 6617
- Avarage plays per player: 80
- Total play time all players: 35 hours 1 min 55 seconds
- Avarage time played per player: 25 minutes
- Player with most plays
- Diamonde: 718
- Rebecca: 595
- Tobias-PC: 587
- Maxime: 549
- Anebo: 517
Check out the timelapse of making Gravity! May contain spoilers!
Lastly, I would really appreciate if you
Good luck in the final results all!
WHAT WENT RIGHT
1. It’s pretty! I wanted a very beautiful game and I think that went well. There’s a ton of art in this thing. As usual, I create new assets as needed. I ended up with two large photoshop files: an overworld sea where you navigate the ocean in your pirate ship, and a battle screen, where I made all battle sprites and animations. What this lets me do is keep a consistent color palette and style across the whole project, and essentially replaces the concept art stage that a normal game goes through. I used amazing references like Legend of Zelda Windwaker and Breath of Fire IV.
2. I learnt tons of stuff! I used cinema4D and my nonexistent 3D skills to make a fast and loose 8-direction ship with minimal effort. I tried my hand at procedural generation: all islands are generated randomly within certain limitations, to keep the level solvable and the sea traversable. I had a stroke of genius at the last moment and created a “miner” entity that swims through the level and places gold coins wherever it goes, at runtime. This was to ensure an interesting curving path through the level, so players would want to explore it.
3. It’s a complete adventure, my storytelling skills were also, I thought, nonexistent, but the story of Sunny and Cod just flowed through me like I was on fire. It’s got a beginning, middle and end, it’s got obstacles and emotions. I usually end up making a very unfulfilling game. This time I feel I made a difference.
4. it has a branching storyline. Well, ok, a few tiny branches. Such as when you are defeated by the 3 blacktopuses you get a different message to the one you get if you clear them. Or when Sunny tells you you need the fast sail if you don’t have it, but acknowledges if you’ve already bought it. But that’s still a lot of work. I have a much better grasp of how to implement a dialogue system.
5. it has a turn-based battle system: implemented from scratch. Boring and barebones, yes. But it gets the job done.
6. I get to develop it further. I’m dedicating the next 6 months to this game. I started a new devlog here
WHAT WENT WRONG
1. No sound I didn’t have the time
2. Button-mashing battles the battle system is uninteresting. That’s ok, and it’s all I had time for, but if I’m going to make this a full-fledged RPG, I need a good battle system. Feel free to send me ideas. Grandia and Child of Light are obviously lovely choices, where the result of a battle can be spectacularly overturned. Also Persona 3 and Fallout 2 have good battle systems. Since you’re spending half the game in battle, I owe it to myself to fix the button-mashing boringness.
3. Time management. Well I don’t know, I did a lot for three days. But it’s not as fun as a more complete experience such as the amazing SCUBA BEAR (go check it out NOW). On the other hand, I like to follow through with my ideas for Ludum Dare, instead of making a smaller game just because of time constraints.
Here’s my Timelapse video:
And thanks to everyone who commented, everyone who played my game, everyone who made a game for us to play. I love Ludum Dare, I want to never stop making games.
Until next time,
A little late to the reflections party this time, even though it is my favorite kind of party. My game: http://www.ludumdare.com/compo/ludum-dare-29/?action=preview&uid=27032
A bunch of things went very well this time, and I made a both subjectively and objectively better game this time than last LD in August. People seem to generally like it, although commenters on this site are notoriously horrible at voicing critique. I’d wish more people actually told people what’s wrong with their games, but that’s for another post.
Right now, here’s one of them lists the kids dig.
Where I Rocked
- Was stubborn at trying to find a good idea. I instantly discarded all ideas that included going under a surface of water or ground, since those were the most obvious ideas, and I was going for something unique. So I used at least an hour thinking about different ways to use the theme in a way that combines mechanics and story, and ended up with an idea that I was confident would work.
- Time management! The only things I was not able to implement because of Not Enough Time were an end boss (which a lot of people wouldn’t have seen anyway) and another lover. The game did not suffer very much from lacking any of those two, and I managed to put in lots of other stuff: passable story, good sound, decent graphics, unique game-play.
- Had all tools set up, and I knew the main tool (Game Maker: Studio) very well. This is a big one, since I wasted almost no time with trying to make them work.
- Abundant-music.com! Seriously! USE THIS! I got a lot of compliments for having music in my game, and it only took me like one or two hours to get a fitting soundtrack. Just make sure to also look at how SynthFont works before the jam (it’s a bit complicated), because otherwise you’ll end up with boring midi files.
- Tried my hand at things I had never tried before, like designing color palettes and making sound effects, which was a lot of fun and a great experience. It also went well, and I ended up getting a lot of compliments for sound and graphics, which are things that I’ve formerly jumped over lightly or completely ignored.
Where I Sucked
- Although I had a good idea from the start, the story wasn’t fully worked out from the beginning, which just resulted in a very vague and not extremely tight story. The majority of my writing happened at 10 pm – 3 am (deadline) between Sunday and Monday, and it suffered accordingly.
- Difficulty: I don’t actually think that the game is too hard, but it was definitely too hard for a LD game, because people play the games in a very cursory way, and if the game is too hard, people don’t see much of the game.
- Communicating a crucial part of the mechanic (the fact that when your lover shoots enemies, they are stunned) was not good enough. This is something I always struggle with, because I often try to create new experimental mechanics.
- I did not solve the problem of telling the story in a satisfying way. This is obviously a huge design problem to be solved in games, and I think I did it better than in many games, but it was definitely too hard to read, because it was told during action.
All in all, I am very satisfied with the game, even though some things could have been better. I cannot wait to see the results.
See you all next Ludum Dare!
Only the voting remains, and if you haven’t had a chance too, go check out my game Curse in the Depths. It was a lot of fun to make and I’m loving all the feedback i’m getting.
Time Management – Time is always one of the hardest things to deal with. It’s the main challenge. My time management was much better then my previous LDs I was organized and knew what I was doing the moment I had an idea.
Work Habits - This LD I prepared better for the long work hours by making sure I had plenty of water and soda handy so I didn’t need to take so many breaks and it made focusing easier
Breaks - This one was HUGE because the problem is what kind of breaks I would take, this time I took slightly longer breaks then previous LDs but I also did activities that were very stress free and didn’t require thought. Video game breaks, TV, and Movies, or YouTube were replaced with Walks, Showers, and Naps, overall I felt more refreshed when I came back to working on the code.
Library Choice - Slick2D I have used multiple times, and I am very familiar with the inner workings. My Problem was that I made the Decision early to not use JBox2D making my collision and combat much harder to program later in the development cycle. This was mostly due to not fully understanding JBox2D, but hindsight is 20/20 and I realize now that I might have been better off using it.
Sleeping - I overslept on Sunday due to overworking on saturday(Sat@4AM to Sun@3AM with an hour long nap in between) and missed around 4 or 5 hours that I had planned a lot of time for artwork. This lead me to only be able to finish the background, the sprite and the HUD in the 2 hours I had left. This meant less content then I had originally anticipated, another enemy and 2 more attacks were in the works but they were left unfinished as I realized I had more pressing features to figure out.
Rewriting – I have spent the last week or so going over most of the engine and figuring out how to use JBox2D. We are currently deciding exactly where to go(Continue with Java, port to C++ for better cross compatability, what libraries to use, etc.)
Overall my 3rd Experience with LD has gone pretty smooth, and I am so happy with the outcome of the game that I am going to continue work on it, and the way it is going, it will see the light of day as a fully fledged indie game!
Hey there! DDRKirby(ISQ) here with my post-mortem writeup for my chiptune rhythm game, Ripple Runner! Please check it out if you haven’t already done so!
This is already my 7th time entering Ludum Dare…I’m really getting to be an old veteran now! Last time around I teamed up with my artist friend xellaya and made a puzzle platformer called Match Girl for LD28. You can read the post-mortem for Match Girl here, if you want to see how that turned out.
This time I ended up working by myself and entered the 48hr division. I came up with an 8-bit styled (more like 9-bit, really) musical runner game, with a lot of similarities to Bit.Trip Runner. (Imagine what Canabalt would be like if it were a rhythm game) I’m really happy with the result, and it seems like other people are too! Here’s what the game looks like in action:
Without further ado, let’s dive right into what went well and what didn’t go so well.
What went well:
Workflow and Experience
I feel like I’ve been saying this ever since Hyper Furball, but the process of taking a game from start to finish has gotten really streamlined now, and now that I’ve got all of the basics down pat, I get to spend most of my work time on implementing the cool awesome things that are specific to the individual game, as opposed to writing lots of boilerplate code and worrying about menus, collision detection, how to recycle entities, particle emitters, screen flashes, etc. Ever since Hyper Furball, I’ve sort of had the same basic formula for the intro, title screen/menu, and jukebox as well, and I think that’s been working fantastically. Not only is it really easy to reuse the code from before and just adjust the menu slightly (as well as put in the appropriate background elements), but it also ties my works together aesthetically. Having the intro there (complete with shrot musical ditty) really gives it a sense of polish, and I’m really beginning to enjoy how I have it for each game I make.
The one downside for this is that since I’ve been copying code from my previous LD projects, all of it has a bunch of random hacks and terrible coding that I did in the 11th hour when all you care about is tweaking one thing or fixing one issue. So far this has been harmless, but if I continue to do it without cleaning any of it up, I’m bound to run into issues sooner or later. One example: I have a variable for a “blackImage” that I used for fading the screen in/out to black from Match Girl and Hyper Furball, but I decided that I wanted screenfades to white for Ripple Runner, so now my “blackImage” variable points to…a white image. Which, of course, is totally fine, because that image is only used in the title screen and it was much easier to just keep the variable name but switch the content rather than having to actually rename the variable and catch all of the places where it was used, etc etc. Anyways, sometime in the future it would be ideal if I could avoid copying over all the hacks from existing projects…
Concept and Brainstorming
This is my favorite idea that I’ve ever had for an LD game, and I was actually REALLY excited when it all started coming together and I could see that it was going to work out. Because of various factors (which I’ll talk more about later), I actually spent quite a lot of time brainstorming different ideas for the theme this time (“Beneath the Surface”) and coming up with a bunch of different ideas, including a FEZ-like game that focused on water reflections, an extreme fishing game, a rhythm-based digging game, and a sort of 2D platformer version of Minesweeper (think Mr. Driller meets Minesweeper). In the end I think I was inspired to create a rhythm game by stumbling upon Rhythm Doctor in the few days leading up to LD, as I was brainstorming what kinds of games I would want to make this time around. Seeing that someone else had successfully made a music game using flashpunk was actually really encouraging–I now knew that it was possible! If I hadn’t seen that, I probably would have shied away from the concept, as music games are notoriously hard to really get right (I know–I’ve worked on one in the past as well).
Because I had so much time to brainstorm, I actually had almost the entire gameplay visualized in my head (and on my scratch paper) before I even started working. I had it all thought out, including questions such as “do I want to make the tempo stay constant or speed up throughout a song?”, “how exactly do I want to handle syncing the gameplay to the audio?” (easy–I simply mapped the player’s x position to the current sound position and placed everything else accordingly), “what art style do i want?”, and “how exactly do I want the musical cues to be integrated?” I knew that the idea was fairly interesting, and relatively simple to implement assuming my few basic assumptions about the flashpunk audio engine would work out (they did). Here’s what an early development screenshot looked like:
As you can see, it’s actually not too far off from the final product! I even already knew I was going to do the watery displacement effect for the reflected half of the screen, so that was already in there at this point. I hadn’t yet thought of the spike concept, but even with just jumping and swapping it was already becoming apparent to me that the game was gonna be a success. It’s also good to note that this was probably my simplest LD idea yet in terms of execution complexity, which definitely helped out. (I finally hit my goal of not trying to bite off more than I should chew!)
I think the in-game tutorial was one of the best gameplay design decisions as well, and definitely beats all of my other games in terms of easing new players into the game mechanics.
At some point during my concepting, I decided that I was going to try out using a 4-color palette for the game. I knew I wanted something that would look good, yet also be relatively easy for me to do, since I’m pretty far from proficient in my art and pixeling skills. This turned out to be a great decision, as all of the graphics in the game were really simple for me to draw, yet the end result looked really great! Kudos to Plant Cat: First Blossom by flashygoodness and friends for getting me inspired to try this art style out. I also decided to go with a greenish hue, as a throwback to the good old days of the original Game Boy. This also made it easy for me do the hue-shifting effect that happens at certain checkpoints.
Dirt simple! All I had to do was draw a solid shape with some variations at the top edge and make sure that it wrapped around nicely, repeat it for another shade, and then draw some super simple pixel clouds. The parallax scrolling effect is very simple to do in Flashpunk as well, by just making each image into an automatically-wrapping Backdrop that scrolls at a different rate.
Then I just had to add a layer for the water, which only shows in the bottom half:
If you’re paying close attention during the game or at the title screen, you’ll notice that the white lines and dots on the surface of the water actually move, sort of imitating the bubbles and lighting that the surface of water makes in real life. I actually used two separate layers of white lines for this and made them scroll at different rates, so that it looks dynamic, as opposed to seeming like just a single image that’s scrolling.
I implemented the wavy water reflection effect by modifying the “Glitch” filter in punk.fx to be based on a sin function instead of shifting lines at random. It’s a simple displacement effect that just shifts each horizontal line of pixels by a different amount, but it works really well!
Finally, I used a hue shift effect for the different sections of music, also provided by punk.fx. Here’s another example of the final result:
I’m really pleased with how the running animation turned out for my little guy too, despite being not confident at all that I could get that right. I had no idea what I wanted to make my character look like at first, and I actually still don’t know quite what it is (some kind of squid-like aquatic being??), but it ended up working out perfectly.
I should note that even though I said I’m using a 4-color pallete, the final visual result of the game isn’t really constrained to that, because of the reflection effects and transparency and all that. Hence, the visual style of the game is very much “9-bit”, just like my music is–in other words, it’s derived from old 8-bit games, but doesn’t emulate them perfectly, and instead allows for some extra capabilities.
Music and Audio
Well, I don’t really know what I can say about this at this point, as making soundtracks like this is standard fare for me nowadays. This game in particular was REALLY fun for me to compose for, since I got to have fun involving the player in the song as well. I really enjoyed it, and it was helpful to write it as I was coding the game, keeping in mind the spaces where I wanted to have tutorials and checkpoints and whatnot. People are really digging the music already, it seems
Be sure to check out the soundtrack at my bandcamp site, too! http://ddrkirbyisq.bandcamp.com/album/ripple-runner-original-soundtrack
What didn’t go so well:
RL Stuff Eating into LD Time
This certainly isn’t the first time that I’ve had real life issues distract me or come into conflict with Ludum Dare, so it’s not like this was any surprise to me, but sheesh…just once I’d like to just do a Ludum Dare without getting sick or being mentally exhausted or having my timeslot screwed over in some way. This time around I left my Friday dance event early so that I could have a bit more time to focus on LD (I was too distracted to really think about anything else anyways), but as luck would have it I needed to go perform for something on Saturday at around noon, so that ate up the first half of my Saturday. I brought myself a pen and paper so that I could spend my downtime brainstorming ideas and concepts for the game, which actually ended up working out pretty nicely, but in the end I didn’t get to sit down at my computer and start working until 4:30PM on Saturday, which is over 20 hours into the 48 hour timeframe. Soooo yeah, I kind of got screwed over in terms of time. On the plus side, having all my ideas planned out as well as being all anxious from having lost out on a half-day of work made me blaze through the initial dev work and I had the basic game up and running very quickly (after a few hours of work), so it wasn’t the end of the world…but I’m pretty sure I would have been able to program more content and make more songs if it wasn’t for me having lost out on all of those potential work hours.
Here is a good time to note that I actually didn’t implement the spike mechanic until preeettty late into development (At t-minus 5 hours or something like that). After making the first two stages, I was thinking to myself that it would really be nice if I had a third mechanic, as only having jumping and swapping was fun but also not quite that interesting from a gameplay perspective. Three is kind of the magic number for having different things to concentrate on, as I know from playing Puzzlejuice, so I was looking for something different to do. In the end I came up with two different ideas–one was the spike/flip upside-down mechanic that I ended up implementing, and the other was that I was going to have the Jump button do an attack or kick of some sort if you pressed it in midair, so that you’d have to press jump twice in quick succession to get past certain obstacles (breakable walls or something). I wanted to implement both, but in the end didn’t have time, so I just went with only the spikes. I knew that that was the better of the two mechanics anyways, because holding a button down is a different feeling than the button presses for jump and ripple, both mentally and from a tactile sense too. The jump-kick idea would let me introduce more eighth-note rhythms into my songs, but I already kind of had that idea going with the jump-ripple combo, so it didn’t -really- introduce anything new.
Not Enough Content
Like I mentioned above, a direct corollary of having less time was only being able to make 3 songs for the game, even though I had definitely wanted to make more. Programming in the actual stages was actually quite time-consuming, as I had to make sure all of the platforms and obstacles were mapped to the appropriate times in the music, as well as placing special events such as checkpoints, hue shifts, changes in scrolling speed, and tutorials.
A Weird FlashDevelop Issue
Thankfully this wasn’t actually -too- bad, but every once in a while (typically when I went to import a source file from Match Girl or something and was trying to rip out all of the Match Girl-specific parts), FD would have problems with the compile process–it would either fail to detect changes, or just tell you that the compile succeeded and then try to run the resulting binary, when in actuality the compile was supposed to fail (because of a missing import or something). Again, this happened only once or twice, and I had some workarounds, but it was a bit of an annoyance when it did happen. Other than that, my development was actually really smooth this time around, with no real surprises anywhere. I remember having issues trying to get the ripple particle effects working properly, but I ended up figuring that out without too much pain.
Overall, Ripple Runner was a huge success, personally, and I’m really looking forward to what you all think of it as well. Again, please play and rate if you haven’t done so already!
I’m also definitely looking into working on a post-compo version of Ripple Runner, cleaning up a few things like adding the ability to pause the game, etc. Mostly, though, I just want to add more songs, because 3 just isn’t enough! I also want to give songs that have a wider difficulty range…the 3rd song isn’t nearly hard enough to give players a *real* challenge. Stay tuned for news on the post-compo version–I’m hoping to work on it over the next couple weeks!
I threw my hat into the ring for the second time as a solo entrant in the 48-hour competition, and here is a breakdown of how it all went developing my entry Darkness Shines Through. I realize this is a bit late, but it’s been a hectic week for me, and I didn’t have the time or the drive to do this until today. Ludum Dare takes a lot out of me, and trying to rate a large number of games to get widespread exposure is almost more work than making the game in the first place. Almost.
Man against machine
If you’ve followed this blog at all, you know I’ve been making games for a long, long time, as a hobby. I was content to put my prototypes out to my friends and family and leave it at that. A while back that all changed, and I decided to try and go public with my work. After making a moderately popular Minecraft mod that took almost two years to write, I decided to go much smaller scale to save my sanity and have a better chance at finishing something cohesive. I tried to make an RPG, but I bit off a bit more than I could chew at the time, and when Ludum Dare 27 came around, I decided I would give it a go. I’ve always thought it was a fun idea, and that seemed as good a time as any to give it a try. It went pretty well, I turned that game into my first commercial product and earned my first dollars through making games. The feeling was incredible, though the project was a bit underwhelming as it didn’t exactly target the broadest of audiences. I finished up the final touches on the last patch for that game a mere week before this round started; the timing couldn’t have been better.
About a week before the contest started, I decided I was going to try and use Unity this time around. Despite the few hiccups I ran into, I largely enjoyed my experience with LibGDX, but I would like to branch out into the console market, and Unity provides me an easy way to do that while still making small PC games in the interim. I only had a few days to try and learn how to use Unity, and that simply wasn’t enough time. I’m a programmer, I write code, it’s what I like to do, it’s how my brain works. I was not able to easily adapt to the much-more-visual style of development that Unity presents, so at the last minute I scrapped the idea and went back to LibGDX.
I also thought this would be the perfect time to give this whole game development streaming thing a go. I’ve seen it around quite a bit, and while it really didn’t sound like a good time to me, I’ve been working on breaking out of my comfort zone to get my name out there. After a few snags with that, I finally got things up and running. Sort of. For whatever reason, Twitch would not update my status from offline, no matter how online I got. Others could view my stream, it was up and running, but I was listed as offline which meant nobody could find me; I didn’t show up in the Ludum Dare list of streams. In getting set up I had to switch my account from being a Justin.tv account to a Twitch.tv account, so I assumed it was because of that, and declared myself ready.
Man against theme
As soon as I knew I would have the time to enter, I started looking at the theme voting. There were some great themes, some that were mediocre, and some that I could do naught but roll my eyes at. As the list narrowed down to the final twenty, my brain went into overdrive. Every theme I read, my mind would flood with ideas of how I could possibly interpret that theme in a way that wouldn’t be overdone, and wouldn’t be out of the reach of my capability. I jotted down the best ideas that came to mind; nothing more than an elevator pitch and maybe a title, but it helped me not go crazy in the days leading up to the event. In the end I think I wrote down about 15 different ideas, each able to be tweaked to fit one of a couple of themes depending on what the actual theme was. I even tried to give myself a leg up by looking at the voting stats for the first four rounds to get a best guess at what it would be. Don’t do this, kids, it doesn’t work and it’s not a good use of time. When the theme was announced, I looked at what I had for that theme and realized I hated it.
I took parts from what I had written down; it was a platformer, the surface I was delving beneath was the facade of a small town of cult members, and there would be no combat. Outside of that it was back to the drawing board. In the first hour after the theme was announced, I started up my Twitch stream and started brainstorming. I decided to go with stealth as the conflict mechanic to replace combat, and to go with a horror-game feel. Making a stealth game in 48 hours that feels satisfying is no easy feat, so I decided to downplay that aspect in favor of a metroidvania-style of exploration. The stealth would still be there, but instead of being an epic struggle like Mark of the Ninja, it would be something more along the lines of blasting away Skree bats in Super Metroid. Something to get in the way and maybe slow you down a bit, but not really the focus. I came up with a list of must-have features, should-have features, and nice extras to add if I had time to spare. I felt good about it.
Man against time
By the end of the first night I had a simple platformer up and running. No graphics, no sound, just boxes jumping around and going through doors. The last time I did this, I had a horrible method for getting level content into the game, it took forever, and I nearly didn’t finish as a result, so one of the first things I set up was a streamlined process for getting levels from Tiled into my game. That turned out to be a crucial feature later on, so I’m glad I nailed that down early. My other biggest shortcomings last time were a lack of good audio, and the fact that the game was insanely hard. Audio was easy, I just had to prioritize it higher, and to address the second issue I pulled a page from the Bioshock playbook and made death a non-issue. I simply teleported the player back to the start of the map if they got caught. No loss of upgrades or progress, just a small inconvenience, and one that was easily avoided by entering a door. Going into day two I had a plan and felt on track.
I had convinced a friend of mine, the one with whom I am currently building a ping pong table, to try his hand at the solo competition for the first time. On Saturday he came over and set his laptop up across from me, with the idea that we could bounce ideas off of each other, and when the time came we would have easy and quick access to a playtester. This also gave us the opportunity to try and finish painting our table. None of those things ended up happening, but it was nice to not be locked in solitude for the entire event. I am seriously considering trying to find a local gathering for the next one, the extra human interaction was a bit distracting at times, but it helped stave off panic in a big way. What didn’t help was the fact that trying to stream was causing performance issues and eventually crashed my computer. Being behind didn’t help either.
By the end of day two, the panic had set in. I felt like I had over scoped, I felt like there was no way I could finish, and my mind was going at full speed when I tried to go to sleep the first time. I had fully animated, randomly assembled characters, tiled graphics loading from the map, and all of the music complete, but the gameplay was still missing a fair bit of what I had originally listed in the mandatory category, and I hadn’t even started on the level design. I tried to think back to where I was the last time, but my memory was hazy, I was tired, and I felt mentally drained. After kicking around in bed for about thirty minutes with no sleep in sight, against my better judgement I went back to my office and sat down for some more programming. I managed to get a buggy version of one of the planned platforming moves up and running in about twenty minutes, and while it wasn’t a huge milestone, it set my mind at ease that all of my architecture up to this point had put me in a good place. It seemed like a lot, but it would go quickly.
Man against self
On the final day, I was all drive. I became hyper focused and started chewing through features like a programming wizard. Within the first few hours I had all of the movement upgrades I had on my mandatory list implemented with only a few bugs that I waved away as being a casualty of speed. Stealth was working, the enemies would spot and react to the player. I wanted the whole town to react to the player being spotted, like invasion of the body snatchers, they would point and scream, and some flying cultist would come in and knock you out. Instead I went with a simple screen fade and called it a day. With about four hours left, I had all of my must-haves but two put in, and after deciding that I had time for neither of them, looked at the list of cool extras. I really wanted to add windows to the buildings, have them react to the sound of the player and open with a short delay. They would spot you just like the cultists, and the result would be the same, it just added an extra dimension to the game. I started drawing, got the graphics for them ready, got the code for how they would react written up, and with about three hours left, realized I didn’t have time to tweak the level editor and loading code to put them into the game.
I got pretty upset with myself for wasting that time. It was time I should have been using to finish the level map. Then it hit me. I hadn’t even started the level map. I panicked hard. I wanted backtracking and exploration, how could I design all of that in just a couple of hours? Fortunately, the pipeline I had set up for myself at the start saved me. The process was so streamlined I didn’t even have to close the game to load in the new map. With the editor on one screen and the game running on another, I was throwing down tiles like a fiend. After the first hour I was probably a quarter done with what I had initially envisioned. Instead of trying to finish that goal, I started throwing upgrades into existing places on the map. I added a few ledges to make the tops of building accessible with the right upgrades and stashed things all over. It changed the feel from what I wanted, no more sprawling exploration, instead a densely packed town with a collectible around every corner. The town was done, all I had left was to design the final area of the map, the church, and slap it into the game. Then I looked at the clock.
I had minutes left. Less than ten of them. I had lost track of time completely, but at least the town was done enough to play. After taking a deep breath, I made a giant empty room and put it into the game. I coded up the triggers for that map, which didn’t end up working anyway, threw in the entrance and exit, and then checked the time again. Five minutes. In a frenzy I played through the game one last time to make sure it could be beaten. With just two minutes to spare I saw the ending screen, threw my hands up and called it done.
Man against society
After I finished, worked through a stupid compatibility issue with the web version and got both versions uploaded, I took a break. I watched a movie with my oh-so-patient wife who was crucial to me not breaking down and quitting, ate some food, and just let the experience wash over me. I had done it again. Sure I didn’t get everything I wanted, or even felt I needed, in the game, but it was a product you could play from start to finish. I felt accomplished. After talking with my wife about it, she reminded me that it was just as last-minute and hectic the previous time, so at least I didn’t get worse. The game was done, but now the real challenge began. Trying to get people to care about my game.
Ludum Dare is nice in that you can steer a lot of people to your game just by voting on the entries of others. So I did that. I did that a lot. To date I have rated almost a hundred and fifty entries, which has consumed almost all of my spare time for the past week. The feedback this time around is much more positive than last time. The only glaring issues seem to be the occasional glitch in collision that results from how I handled the crouching, and the lack of a coherent introductory period in the game. Nobody seems to think it’s too hard or not fun, so I’m feeling pretty good this time around. In particular, the audio seems to be getting high praises, and since that was my worst score last time, I can’t wait to see how it turns out this time.
There are a lot of good entries this time around. Some make me feel inadequate and awful, some show a lot of promise but have a few design flaws, and some make me feel like other people don’t take this event quite as seriously as I do. It’s hard to be fair and impartial when judging, and often times the description can alter that in drastic ways. Some people didn’t get started right away, so I can understand why their game feel incomplete even for a dare entry. Should that mean they get a better score for a less complete game? I’m awful at dealing with people, so rating entries is a taxing process for me. I try to leave constructive feedback on every entry I rate, and while it makes me feel more like I’m part of the community, I think my blunt nature has left a sour taste in more than a few mouths. I try to state both the positive and the negative, but when there’s not a lot of positive, it can be hard to seem sincere with coming off as being negative.
Initially I was going to list my favorite entries I had played so far, but since this article is already way longer than I wanted it to be, it will have to wait for another day.
With the weather being so nice outside last weekend, it was really hard to get psyched about sitting in front of the computer all weekend to make a game. However, I’ve participated in every Ludum Dare and mini-Ludum Dare since #26, so I felt compelled to make something even if it was really simple. I really didn’t have any good ideas for “Beneath the Surface”, so I decided to create a treasure hunting game. For my LD29 warmup, I made a simple MineSweeper game, so I thought it would be neat to expand on the basic concepts of that game. Instead of avoiding mines, you are trying to find buried treasure in a three dimensional world.
At first I just got the hidden treasure pieces to randomly populate on the game world, which are the items you must find. The digging unit was the first that I created, which I renamed “excavator” since it sounds fancier. He just uncovers whatever is hidden at his location. However, randomly adding excavators to the map really didn’t seem challenging.
Then I got the idea to allow the player to “ping” the map to get a general idea of the treasure location. This reminded me of the news stories about crews using scanning devices to find the missing Malaysian airplane off the coast of Australia. I originally wanted to have a heat map showing the pinged locations and the amount of treasure in the area. However, I had to settle for just colored circle areas on the ground representing the amount of treasure in the area. It was fitting that this is very similar to the job that an archaeological surveyor does, so I created a “surveyor” unit specifically for this job.
Finally, an excavator only knows about digging, and only a true expert would know the value of a lost treasure. Therefore, I created the “appraiser” unit to determine the value of each discovered treasure. The inspiration of this unit came from shows like Pawn Stars and American Pickers, where they will call in an expert to determine the value of a given “piece”.
I had plenty of more ideas which had to be cut. There was going to be rocks on the game world and an explosives expert unit which would destroy the rocks so that the excavator could dig. I also did a little research on some of the most famous lost archaeological artifacts from around the world, which I wanted to include in my game. However, I just had enough time to include one treasure piece which looks like a golden chalice. I also got suggestions to add adversaries like spiders, floods, and diseases which could eliminate units, but I didn’t have time to include any of those.
For this game, I wasn’t too worried about creating the best looking game ever. In my previous Ludum Dare entries, I spent much more time polishing, but it never seemed to have much of an impact on my ratings. I’m much less concerned about ratings this time, and more focused on learning new things. For example, this time I got fully functional map controls working with the mouse, including zoom in/out with the mouse wheel. I figured out how to create a unit on the game world at the position where the player clicks. When implementing that feature, I got stuck when trying to cast a ray from the camera to the plane on the ground. For some reason, none of the camera API calls were working. I thought my Unity libraries may have gotten hosed or there was some issue with the compiler. After taking a break and coming back to it, I realized that on the title screen I had created a script called “Camera” for moving the title camera. All calls to camera were referring to that script, which explained why I could not access any of the Camera API methods. Changing the name of my title camera script resolved that problem.
Another issue was with the appraisers. Since the player could add an appraiser at any location in the world, the appraiser would need to walk to the nearest treasure. I did learn that I can access all of the Treasure objects by tagging them with “treasure” and then calling the GameObject.GetObjectsWithTag method. This also resolves a Unity problem that I was never able to figure out, which is referencing game world objects (in the Hierarchy) from a Prefab.
I will admit that there are some things that I’ve done so many times when creating a Unity game, that it just isn’t fun anymore. One of those things is creating human models. Unfortunately, in the 48 hour compo pre-existing assets are not allowed, so I had to create a human model from scratch again. I guess it’s good for the Blender practice. I used one model for the three different units, but used a different texture and animation for each unit. I originally started by creating the excavator with a shovel, but I found that it was going to be way too difficult to animate the character with the object, so the shovel was removed.
In the end, I got most of the basics working but it really didn’t look like a completed game. There was a bug which sometimes prevented the appraisers from collecting treasures. After looking into it some more, I found that this was because I thought that code execution stopped when Destroy was called on a gameObject. Actually, the script attached to a gameObject will continue until the Update method finishes. In my code, the appraiser was targeting the next treasure after Destroy was called, so that no other appraisers could target the treasure and appraise it. That was a simple one line fix to solve.
The biggest mistake that I think I made in this Ludum Dare was spending to much time basically re-inventing the wheel. I really don’t like the default Unity GUI buttons, so I decided to make my own. However, the process of making custom buttons is not a trivial one and is time consuming. Before the next Ludum Dare, I would like to have my own personal Unity library for things like graphical toggle buttons, menus, camera controls, font outlines, and dialog boxes. That way I could spend more time making the game, rather than trying to get a button to illuminate.
I liked the concept of this game, because I haven’t seen it done before. Therefore, I spent a little time this weekend making some changes for the Post-Compo version. I looked into how to modify the Unity terrain at run-time, so now when the excavators dig, it actually makes a dip in the terrain which is what I had originally envisioned. The biggest problem I ran into is that the terrain map starts at 0 height, so there was no way to make the terrain go any lower. Setting the base terrain level to 300 fixed this problem, and I just subtract 0.005 from the terrain height where the excavator digs. It took me a little while to figure out that the height array is from 0 to 1, not actual world units.
Overall, I’m happy with the results of this game. It definitely isn’t as visually impressive as my previous Ludum Dare entries, but I think the gameplay is much deeper. Adding adversaries to the game would probably make it much more exciting. If there is enough interest, I would be willing to port it to other platforms, since I think it would make a great mobile game. Online features such as leaderboards would also be nice to have. If I ever felt really ambitious, I could have an online server containing treasure data for everyone playing the game, so everyone is excavating from the same online world.
New Dawn was the first Ludum Dare entry for both members of our team, and the first game jam/compo of any sort that we’ve done. We went in with little preparation and an overdose of optimism, but overall it came out pretty well! We weren’t able to do as much as we’d hoped – that probably goes for everyone here – but we finished in 72 hours and still came up with a solid little game.
We had a general idea of what we wanted to make before LD started: some kind of mini-RPG or adventure game. We couldn’t help brainstorming as we were voting on themes, and we really liked the idea of setting the game in a dystopia. A few of the themes could’ve made that setting difficult, but luckily for us,“Beneath the Surface” fit really well. It led to an interesting post-apocalyptic setting where the action takes place underground because the surface is no longer habitable. Plus, a dystopian setting was perfect for adding layers of secrets and false pretenses, which meant we could interpret the theme both literally and figuratively. We didn’t get to do as much of the latter as we originally planned, but we think it still comes through pretty well.
Although we started with the idea of a “mini-RPG,” we knew we probably wouldn’t have time to add many RPG elements. As it turned out, we ended up just sticking to a point-and-click adventure game. In order to have time to code extra RPG features, like a combat system, we would’ve had to spend less time on art and the dialogue system. That would have led to a very different kind of game, not necessarily a bad one, but we felt New Dawn would be better served by focusing on the story and the atmosphere. Having a better dialogue system and more detailed art helped to strengthen the story and atmosphere, whereas RPG mechanics wouldn’t really add as much in that sense. That said, if we had more time, we would have liked to add those as well.
Stefan (Coding, Art, Concept/Gameplay Design): Going in I knew I was going to use Unity (and C#), along with 2D Toolkit. I had laid out a basic plan which was to try to implement all the features by the end of the first 24 hours, then all the art by the end of the second 24 hours, and leave the third day for testing, bugfixing, and polish. I did this because I know that games always take longer than you expect, so this gave us some room to work with and helped curb our ambitions and expectations. As it turned out, this was a great idea, because although I did finish all the crucial features in the first 24 hours, the art ended up taking much longer and wasn’t done until well into the third day (and I didn’t sleep at all Sunday night either!).
Ultimately I’m a programmer, not an artist, so I’m not very efficient at that stuff because I haven’t done it much. However another big reason it took so long is that while 2D Toolkit is very convenient, it has some very tedious interface problems that require manually doing repetitive actions over and over, which really should be automated. These actions can be automated by script, but at the time I wasn’t sure if the amount of time it would take to write those scripts would be less than the time it takes to do the stuff manually. In retrospect, I think for the amount of art we had it probably wouldn’t have saved us that much. However, if I could do it over again, I would have set up those automation extensions to 2D Toolkit before LD started, because that definitely would have saved a lot of time.
The art itself also took a lot of time because I chose to put a lot of detail into it, despite it being very low-res pixel art. The details are largely in the shading, which ate up a lot of time, especially for the tilesets which required many different versions of each wall tile in order for the shading to match up. This also meant more work for Olivia when placing the tiles to build out the levels. The shading, especially on the tiles, is a very subtle effect, which I don’t think most people would notice unless they’re familiar with how tilesets work and are specifically thinking about it (which you usually don’t do when you play a game even if you are familiar with how it works). However, I still think it was worth it to spend this extra time, because although most people won’t consciously recognize that the shading is there, when it isn’t there it really stands out and looks noticeably worse. In particular, I think the atmosphere of the game was really well served by the extra shading detail. After drawing the basic shape and applying the shading, I also applied a noise filter to all except the character sprites to give them a bit of extra grit which I think fits the setting well.
On the third day, once the art was finally completed, we only had a few hours left before the submission deadline. At this point I implemented a few extra features that I didn’t consider crucial, most notably the ability for NPCs to move. At this point it struck me that the ending we were planning was going to be very anticlimactic; so I decided to spend the rest of the time quickly building out an additional final level to provide a more climactic ending, while Olivia was finishing up the penultimate level. I think this was definitely a good decision in the end, however it was risky, because we ended up cutting it very close; if it wasn’t for the submission grace period we would have missed the deadline. But overall it definitely makes the game feel much more satisfying when you finish it, so I’m glad I made that choice.
Olivia (Writing, World/Level Design, Music): We knew the general kind of story we wanted to tell before LD started, so once the theme was announced I started hashing out the details. I spent most of the first day planning the overall plot, with input from Stefan, and writing descriptions/dialogue for generic NPCs and a few items. Though I didn’t implement them that day, all of those descriptions made it into the game, and really helped the world feel more inhabited. I also wrote text for an intro screen which eventually turned into our game page’s description.
Saturday and Sunday were mostly spent setting up levels: I’m pretty new to level design, and that turned into a huge, unexpected time sink. One of the original “exterior” areas I’d made was close to the size of a real city block – way more space than we had time to fill with interesting stuff! That time would’ve been much better spent populating the existing areas and doing additional writing, but…lesson learned. I said goodbye to my hopes of having all the levels finished by midday Sunday, and had to cut a plot branch and simplify the remaining ones to make sure I’d have time to finish the story.
Monday was mostly a rush to implement the last of the plot. Thankfully I’d planned it all and written some of it beforehand. The penultimate level, two crucial dialogue trees, and two optional but pretty significant NPCs didn’t exist in-game until late Monday afternoon. I also wrote the second (and shortest) part of our music that day, since I wanted at least a little variety. In our rush to submit, there wasn’t time to put the intro text on a starting screen, but that’s something I definitely plan to fix post-comp.
There were a few things I’d hoped to fit in, even with the deadline looming, that didn’t make it. The main one was a set of PA speaker announcements (in the form of text dialogue) which would’ve given more backstory and context to the world. I also wanted to implement sound effects – we’d made a bunch in bfxr – and additional music. My next priority would probably have been adding waypoints so generic NPCs can move and putting more decorations and ambient descriptions throughout the world. In spite of all those cuts, though, we still managed to tell a complete story in 72 hours, and I’m pretty happy with it.
What We Learned:
After we submitted the game, we got a lot of great feedback from commenters. Several people had problems with the click-to-move interface, and since we didn’t anticipate that we hadn’t put in any alternate control schemes (though our post-LD update lets you click and hold, which should alleviate much of the problem). We also made the main quest a little easier to figure out in some post-LD tweaks, since several people were getting stuck. Additionally, given the amount of content we had to cut due to the time limit, some of the areas ended up feeling a little empty. They probably should’ve been shrunk down. On the whole, though, the story and art that we had came together really well, and we ended up with a short but atmospheric adventure game.
LD was a great experience, and it really motivated us to make a game of our own from start to finish. We might do something totally different next time around, but we’ll definitely be there!
Our game, StromnetZ, is a pipe-esque game with bombs, vaults and other fine things. The idea for a pipe game dawned on us almost instantly and we worked on the game for the whole 72 hours (minus the time spent sleeping and eating).
Without boring you anymore: the good, the bad and the ugly… Actually no ugly.
+ We focused on the essential stuff first -> we managed to do everything we wanted
+ We managed to include some extra features, like the leaderboard!
+ Semi balanced scoring system
+ Nice difficulty curve
+ Already had some stuff ready from LD28 so we didn’t waste time learning new technologies (highscores was new and required some effort though) or creating the basics of the game.
+ Explosion animation is brilliant
- No dinosaur skeletons in the background images
- The cross pipe and the over-under pipe are hard to differentiate
- Still no musician (music is royalty free from incompetech.com)
- UI is like that of a real power plant: bland and dull
- Not enough juice! https://www.youtube.com/watch?v=Fy0aCDmgnxg
This post will contain spoilers about the game, so be sure to play it first!
Now let’s get to it. First I’d like to get the traditional stuff out of the way, so here’s what went right/wrong with development:
What went right
- I achieved my vision! I’m starting to actually have visions of how I want my games to be, and it’s nice to have it work out as I planned it.
- Graphics went without a hitch. Sure, they could’ve been better. Considering the fact that I made them, and the short amount of time it took me, they look pretty OK. The important thing is- they function as they should.
What went wrong
- As people have said in the comments, the game could use some music. Next time, I’ll be sure to just pick something if I don’t have someone to make it. This proved to be more important than I could have foresaw, as people seem to react a certain way to the game, and this could very well be amplified with some evocative music.
- I struggled with the theme (again). I’ll go into detail about this now.
Last time, I had serious problems with getting ideas for the theme. In fact, I didn’t have any idea of a game I wanted to make, never mind the theme. I ended up working on a tech thing unrelated to the competition.
I had a similar problem this time. I didn’t start working on the game until about 8 hours before the end of the compo. So, I looked at some of the themes before the compo began, and I was excited for ‘Time does not exist’. I had an excellent idea for it. In a philosophy lesson a few months ago, I had this idea that time is in fact a spatial dimension, and that all existence is static. Basically, there are infinite frames of the universe coexisting in the time dimension. In one, we all have some parameters. In another, those parameters are slightly altered. Each version constantly experiences one infinitely small time frame of existence; and so, we experience time linearly.
This was my idea for the time theme. I didn’t have any gameplay planned for it, it was just something that came to my mind.
Come the day of the competition, I had no idea what to make! I started to panic, so my dad told me to just make a game that I want to make, and find some connection to the theme, later on (as it turns out, Notch’s interpretation of the theme is apparently very similar to my own).
I told my friend about my idea of a time game, and as I was telling him about it, the whole thing with managing time frames of a person’s life just flowed out of my mouth, seemingly out of nowhere. It was fantastic! I went home and set out to make the game.
Now, if you’ll look at my sketches for the game, you’ll see that I had some ideas beyond the ‘Be happy’ task, which didn’t make the game (they suck anyway). The thing is, I wasn’t too enthused about the game by the end of the competition, and I just wanted to submit it and go to sleep. I completely forgot about ‘Be happy’, which renders the original version of the game worthless and boring.
With ‘Be happy’ in the post-compo version, I got some nice feedback. I didn’t realize the potential of the game until I watched DanielSND (InfectionTeam) and TimTipGames playing my game in their streams. I started getting amazing responses such as these
“I think this is the most interesting experimental game in this jam. Thanks!” – Maniulo
“It felt like a puzzle, and at first I thought ‘oh, maybe I can solve it…’, but I couldn’t; that was the ‘aha!’ moment when it clicked in my head. That’s not an easy thing to accomplish as a game designer, so well done!” – cageinabird
and many more. Thank you, LD community! And thank you, everyone who’s played my game!