Ludum Dare 35
Coming April 15th-18th Weekend

Ludum Dare 34 Results

Posts Tagged ‘post-mortem’

Grow Your Love Postmortem

Posted by (twitter: @ddrkirbyisq)
Thursday, January 14th, 2016 2:00 am

It’s postmortem time!

Grow Your Love

If you haven’t yet played Grow Your Love, you can do so here:
http://ludumdare.com/compo/ludum-dare-34/?action=preview&uid=7285

You can also download the official soundtrack here:
https://ddrkirbyisq.bandcamp.com/album/grow-your-love-original-soundtrack

This was my first time doing a jam entry with my trusty partner-in-crime Kat Jia since waayyy back in Ludum Dare 28 when we made Match Girl (and took 2nd place!).  That was two years ago, and since then, the number of jam entries has more than doubled, going from 780 to 1,638.  Wow!

This time around, we managed to take 3rd place in Audio, 13th place in Fun, and 13th place Overall.  Not bad at all! 😀

My personal goals going into the project were:

  • Don’t make another rhythm game
  • Work on pixel art together
  • Have fun!
  • (Maybe) treat iOS and Android porting as first-class

Humorously enough, I actually did very poorly on most of these. xD  While I didn’t REALLY make another rhythm game, one of our seven minigames was a simple dance game (haha).  Kat ended up doing 90% of the art as I had no time at all to work on any of the graphics…I drew the shooting stars and some of the UI elements like the arrows in the kniting minigame, but that was it =X.  And iOS and Android porting, pfffttt, come on, we both saw it coming from a mile away that that would get dropped.

Fortunately, the most important goal of having fun was a huge success; this game was definitely very enjoyable to make!

As always, let’s see what went well and what didn’t go so well.

Dancing

What went well

Concept, mood, feel, and overall vision

Probably the most common comment we got about our game was that it was really cute and adorable, which was great!  When we set out to decide what kind of game we were going to make, we weren’t trying to make something that was super innovative or challenging or anything — we really just wanted to make something fun and cute; something that would fit in with our Cocoa Moss label.  We had a really good and light-hearted energy bouncing ideas back and forth for the different parts of the game, and I think it reflects in the overall end product.  Kat did an especially great job with the dancing animations, and I tried to write out the Letter and Texting dialogue in a way to match the same style as well.  It all ended up coming together very well, and I think the game is much more about enjoying a cute story than about the actual scoring of the minigames itself, which is perfect!

 

Making smart code architecture decisions

Having SEVEN different minigames to make meant that code reuse was at a premium, and I found myself super-grateful to myself that I had enough foresight to plan well for it.  There was no way I would have finished all seven games in time if I had to create entirely separate logic for each of them.  Sharing most of the common logic for the tutorial demos, starting and ending the game, etc. saved me heaps of time and even though there were lots of hacks and messiness throughout the codebase (as always), it ended up working out really well.

 

Slamming out music faster than ever before

Holy crap.  I know I’m known in some circles for my speed-composing abilities, but I even outdid myself this time by writing the entire 10-song soundtrack in less than 5 hours total. O_O  FL Studio saves your project working times automatically; here was the breakdown of how long I spent on each track:

Lovers’ Rave: 32 minutes
Watch Carefully: 15 minutes
Hope You’re Not Asleep: 34 minutes
Stargazing: 20 minutes
Love Sprout: 3 minutes
Grow Your Love: 1 hour 6 minutes
Wiggly: 31 minutes
Our Love Has Grown: 46 minutes
From Me to You: 17 minutes
Rainbows of Yarn: 20 minutes

Total: 4 hours 44 minutes

Aside from the title theme I basically wrote each song in 20-30 minutes, which was kind of insane.  Of course, these were shorter songs, so it makes sense that I was able to churn them out at a faster pace, but I was surprised at how well I was able to work under pressure here while still remaining creative, especially given that some of the songs are not of my usual style.  I was under MASSIVE time pressure as I started doing the bulk of the soundtrack work, so I really had no choice but to do it quickly.  Ironically, this might have =helped= my creativity by giving me no choice but to go with my first gut instinct.  I’m especially happy with “Wiggly”, which was ridiculously fun to write.

You can read more of my comments on the individual songs in the in-game jukebox if you’d like — there are some interesting notes in there since a lot of the songs were repurposed from what they were originally intended for.  To be honest, neither me nor Kat were planning for the mood of the game to play out exactly how it did; it sort of evolved as things went.  I had to rethink how I was doing the music to reflect the shift in mood that ended up happening, but luckily I didn’t have any wasted work as a result.  I do have to say that the full hour I spent on the main Grow Your Love theme was well worth it; it’s now my favorite track of the entire soundtrack and I think it really gives a lovely first impression.  You’ll notice that I centered all of the songs around a shared motif — it’s a great technique I’ve used over and over again that really brings cohesion to a soundtrack. :)

Stargazing

What didn’t go so well

People not getting the menu controls

Sadness.  Perhaps I was going too deep with the “two button controls” theme, but I thought that in order to really be complete the menu of the game should use two button controls as well.  Of course, it’s hard to make menu controls using only two buttons, so I looked to DiveKick for how they did it and figured that I would do the same thing.  Apparently it wasn’t obvious to most people as they just gave the screen a blank stare and wondered why pressing left or right separately didn’t do anything, so in the post-compo version I made it painfully obvious by putting big flashing indicators on the screen and highlighting the text, press LEFT + RIGHT TOGETHER.  Sigh.  It’s always the little things that you assume that bite you in the foot later on…

 

Not testing on the release platform until later on

This one was a smaller point, but for most of development I was testing on Haxe’s Neko VM instead of actually testing the Flash compile.  This was fine, except halfway through development when I tried the flash build and ran into a crisis.  You see, most of the graphics in the game are upscaled by 4x, so I had set the camera zoom at 4.  But the text was way too big at 4x, so I had the text sized 50% smaller, so overall the text would be upscaled by 2x.  Setting the text scales to 50% worked fine in neko and everything was perfectly happy.  Well, as it turns out, in Flash with the buffer rendering flow, you actually can’t draw pixels with a size less than the current camera zoom, so instead of the text being nice and crispy at a 50% scale compared to everything else it was actually just unreadable.  Oops.  Luckily I was able to jury-rig a fix by hacking at the haxepunk code, so that was a major crisis averted.  The hack was pretty ugly — I set the camera zoom to 2 instead of 4 and then edited the image class so that every image in the game would be scaled up by 2, etc — but hey, you gotta do what you gotta do.  Managed to dodge the bullet on that one, phew!

 

Balance and scoring

Ugh, this is probably my number one regret with the game.  The scoring formulas and balancing of the minigames is pretty terrible and I really didn’t test them very much.  In particular the dance game seems to get people a lot — like rhythm tengoku/rhythm heaven, it’s grading you not only on whether you memorize the sequence correctly, but how on-beat you are.  Of course, I had no time to make sure the lag calibration was spot-on, so it’s not perfect at all. =(  In the compo version, some players also misunderstood the goal of the Letter writing game (do it as fast as possible), and players also tried to figure out which word made grammatical sense in the Texting minigame, instead of realizing that you just needed to tap on the YELLOW highlighted word.  In the post-compo version I tried to be much more explicit with the directions for those games, and made the tutorial overlay display across the entire screen because people were probably skipping the text due to being distracted.  Some people also got confused with the Stargazing game in the compo version by pointing to where the star was going rather than which side the star was on.  In the post-compo version I solved this issue by getting rid of the stars that start on one side and travel towards the opposite side, to make it more obvious.  We also made some tweaks to the dance minigame during development to make it more clear.  Clarity in instruction is always super hard to get right, I guess…

Initially I had planned on rebalancing the game and even adding an “Expert Mode” where each minigame gets harder (e.g. harder rhythms for dancing, longer letter and text, more arrows for knitting), but in the end I realized that Grow Your Love really isn’t =about= the challenge and the scoring anyways, so it’s not that important to have Expert Mode or anything like that.

Not enough time (as always)

Some of the issues with balance and scoring were a direct result of me having almost zero time to properly test and play through the game, as I was still working on core features like the main menu.

Several things accounted for the time pressure:

  • Making seven separate minigames just takes a lot of work, period.
  • There was a nontrivial amount of work put into making a horizontally-scrolling menu workable; I couldn’t just copy the vertical menus that I usually put into all of my other games.
  • Certain aspects such as Free Play mode ended up not being that important to the overall experience but still took time to implement and get right.
  • Did I mention making seven different games?

Overall there was just a LOT of stuff to get done; not only did I have the 7 games to program, but there was the menu, jukebox, liner notes in the jukebox, free play mode, scoring algorithms, the intro scene, record saving, tutorials, tutorial skipping, and don’t forget the ending scene!  This was probably the most hours I ever worked for an LD, and I felt =exhausted= afterwards, jeez!  Even after submission, I was still finding stupid bugs that I needed to patch up (at this point I still  hadn’t ever had time to actually play through the entire game).  I don’t know if there was really anything that could have been done about this, aside from maybe not worrying about Free Play mode…perhaps we could have gone down to 5 minigames, but I really think 7 is a good number and that we like all of the ones that managed to make it in.  Honestly I think we just did the best that we could have! =P

 

All in all, Grow Your Love was great fun to make and I hope you guys enjoyed playing through it as well.  As always, we learned a lot, and in the future we probably won’t try doing a warioware-style collection of minigames again.  I know that it worked well this time around, but it was just too much work!  It also caused an issue in that it took a long while before we had a single one of the minigames completely finished, as we were sort of working towards a lot of them at the same time.  One of these days, I’d like to have a LD where I actually finish the work for the main game EARLY instead of scrambling at the last minute!  (Melody Muncher was sort of close…).

 

Thanks for playing and reading about our game! :)

Revolver Post-Mortem

Posted by
Monday, January 4th, 2016 3:55 pm

gameplay

With the final hours ticking down before scores are revealed, I thought I’d fill the time by doing a post-mortem for my LD48 compo entry. Revolver is an action puzzle game about growing plants by rotating the planet toward favorable weather conditions.  You can play it here!

What Went Right

A:\> Let’s build a time machine!

Time management. Unlike most other jams, the first time ever I felt in control of my time. I didn’t get in everything I wanted to, but I delivered the key elements I needed to. I chose an idea with core mechanic that was design-complete. The idea hit both theme targets. By the end of Saturday, the sandbox prototype was playable, which is a target I don’t always hit. I did a really good job of “layering” my needs, ensuring that every element of the game had a placeholder first, before several iterations of refinement. I don’t just mean art, I also mean text, sound, and code. In this way, as time became short, I could say “you know, that placeholder here is good enough” and polish where it is more needed.

Challenge. I tweaked the levels to be tough on the timer, particularly the last 3-4 levels. While this got some users cursing at me, most said it was on the good side of challenging.

B:\> I’m not looking for judgement, just a yes or no — can you assimilate a giraffe?

Unity. I entered previous compos using Flaxen, which is built on HaxePunk using Haxe. It’s great stuff, but I’ve been wanting to get more experience with a game engine that has 3D, a lighting model, and a proper scene graph.  (Hopefully, HaxePunk 3.0 will have these things.) I had a really good time using Unity. I’m not so much of a Microsoftie so was I  surprised to enjoy many of C#’s features. I mean I’m never going to love capitalized function names, and Unity/MonoDevelop makes it excruciating to use third party libraries (see how haxelib does it), but overall it was smooth.

In-editor configuration. As much as possible, I exposed all level data and configuration to the editor. Each level was a prefab that I dragged to the Level Manager array in the order I wanted them. This made it easy to tweak and change the levels and messages. Unity does have a really ugly built-in array management with no drag and drop reordering, but it’s passable, and you can customize the inspector view to some extent with a little more time. The configuration for the item types were also fully exposed.

C:\> Good job doing basically nothing

In-game tutorial. Not only did I fit several levels, I also worked in a couple tutorial levels to explain the controls and concepts. I was very pleased to fit this in.

Unfiltered sarcasm. Because I layered my time, I used placeholders everywhere first, and this included the level message texts. The requirement for a placeholder is BUILD IT FAST, so I did what comes to me naturally. That is, I was a sarcastic and obnoxious ass. As time wound down, other things took up my time, and I never went back to the level text. As it happened, however, my sarcasm turned out to be a popular aspect of the game. So yay me and my immaturity!

What Went Wrong

D:\> Please, sir? Can we have some more, please?

Moar levels. I put in just enough levels to introduce the three types of atmospherics (rain, snow and tornado) and three plants (smirkflower, smeggplant, and flurp trees).  Barely enough time to dip your toes in.

Less samey. I envisioned a more complex dynamic between the atmospherics and plants. Although I exposed a lot of the configuration to the editor, I didn’t tweak them much. In the end, each plant had an atmosphere it grew 4X as fast in, and an atmosphere that stunted it’s growth completely to 0X. These values could have been tweaked to be more interesting, but with as few levels as I had in there, it would be an underused subtlety.

Moar items. I also pictured two other atmospherics (flock of birds, swarm of bees) that could move around the planet – this would have looked cool! It would have also fed into new asexual and sexual plants which spread via seeds and/or pollen, and were endangered by birds.

Moar animations. My biggest regret on the art side was not making time for a better plant-growth effect. It just scales out along the length, which kind of looks like growth, and kind of looks like it’s rising from a deep bow. What I really wanted was a dynamic art that could support a tweakable growth pattern. If I did that, maybe I could have fit in more plants.

Moar UI. The level transitions were very minimalist. The font was hard to read on some levels if there was foul weather near the south pole.

Overall I had a great time this Ludum Dare. My feedback has been largely positive. Regardless of my scores, I’m still very pleased with the result.

Cultivate Post-Mortem (and Favorites!)

Posted by (twitter: @kmakai)
Sunday, January 3rd, 2016 11:36 am

Hello there! With just over a day remaining in the voting period, it seemed like a great time to finally write up a post-mortem for my experience this time around. I’ve included my favorites/recommendations of the entries that I’ve played so far at the end of this post.

Of course, if you haven’t played the game yet I would love to get your feedback! Visit the game page here:

Cultivate is an adventure/visual-novel-like game about a day of high school.

Cultivate is an adventure/visual-novel-like game about a day of high school.

Overview

This was a really interesting Ludum Dare for me — the second I’ve completed an entry for (and the fourth or fifth that I’ve actively attempted.) The idea of an adventure game with binary choices that lead to branching paths seemed like it might easily get out of hand and too ambitious for the compo, but I wanted to attempt it anyway. If nothing else, it would be an exercise in limiting scope — something I usually struggle with in game design.

Ultimately I ended up with an entry that I’m really proud of: despite a few issues it feels reasonably complete (though I would have been pleased to add music!), and represents the original concept well.

(more…)

Continuing My LD:34 Compo Entry

Posted by
Saturday, January 2nd, 2016 1:28 pm

So this was my very first game jam, and while I really enjoyed the accelerated development period, there was a lot I wanted to clean up or add to the game “Safe or Sorry” ( http://ludumdare.com/compo/ludum-dare-34/?action=preview&uid=62158 ). So now that it’s over I’ve decided to do just that. It was nice to watch “let’s plays” of my game and streams. It showed me a lot of areas where there were things I needed to fix. So far my fix list includes:

  • A redesign of the games monster
  • Smoothed monster’s movement
  • Fixed bug with monster’s vision not being consistent
  • Fixed scoring issues so hiding is not beneficial
  • Cleaned up levels, added some details like skirting boards
  • Fixed game end screens
  • Fixed hit box for the buttons so they are easier to hit.

Below are screens showing the games monster before and after the redesign. On the left is the original on the right is the new one.

Front View

Side View

Rear View

If you are interested in following my development as I turn this into a real game you can follow me @JimmothySanchez. Thanks for reading!

Grow Trees… Or Something – Post Mortem

Posted by (twitter: @gamepopper)
Saturday, December 26th, 2015 10:57 am

So this is something I didn’t expect to happen, around two weeks ago was Ludum Dare, where we all had only 48 hours (or 72 for jams) to develop a game, however because I had plans to go to a party that was some distance from home, I had much less time. Despite that I still managed to finish something, although honestly was disappointed I didn’t have much to show, so I could go and vote on other entries.

Voting

What surprises me is that I’ve had some nice and positive comments from many people so far, obviously I wasn’t expecting overwhelmingly positive comments of people thinking a game about planting trees, letting them grow and chopping them down with no time and a limited amount of space was the best they’ve ever played, however I was surprised to see many people saying how nice and calming it is, how it’s very peaceful and relaxing it was to play. Among that, most people said they were impressed that I managed to produce this in around six hours.

Concept

Originally, I was going to team up with an artist that I work with in my full time job as a programmer. When the themes were announced, we were hoping the winning theme was going to be non-violent combat, and had an idea for combating enemies with dancing. I cannot recall why we didn’t go ahead with that one, but we did also have ideas that involved growing trees, so when growing became one of the themes we ended up agreeing to it.

Development

After recalling the development stages, I’m not entirely sure if I did only work on the game for less than six hours. After the theme was announced at 1:30 am on Saturday, I went to sleep. I didn’t start working until around 10am when I got on the train to London, where I did at most 1 1/2 hours (see above). Because of the party, I didn’t do any work until Sunday afternoon when I got back home (around 4pm), and even then I had stopped to discuss any chance of salvaging what time we had left to work on the project with an artist. Once it got late enough I decided to call it quits and try for Monday.

After getting back from work on the Monday, I quickly finished the last of the art work, added in some audio from freesound.org and uploaded it, so judging by the timestamps and when I took breaks, it’d be more accurate to say I took around 6-8 hours of the game.

In Conclusion

Regardless of how long I actually took, what’s clear was that I honestly should have planned my time better, either by cancelling my invite to London or not take part in the games jam entirely. By having more time, I could’ve made a more complete and fulfilling game entry, and probably kept both myself and my artist motivated to working together. Instead I went on an assumption that because I managed to create games in shorter times in the past, that it would be fine this time around.

Thank you to all those who have voted, I have been enjoying all the entries that I have seen so far. I’ll be interested in what the final scores will be.

Rolla Grolla Arena Post Mortem

Posted by (twitter: @xanjos)
Saturday, December 26th, 2015 10:21 am

Hey Everyone!!

I hope you all had a nice Christmas. Anyway, I’ve recently written up a post mortem for my LD34 game Rolla Grolla Arena which you can view on my blog.

ld34funny

There’s still time to play/rate my game before judging ends so click here to give it a try. Also, I’m looking for more games to play/rate so click here to submit your entry and I’ll get to it as soon as possible.

Finally I’ve included a video clip taken from a Twitch stream last weekend where a group of people played and rated my game (which appears in the first few seconds).

Happy Holidays!!

Extra Oxygene

Posted by
Friday, December 25th, 2015 10:57 am

scr1_thumb

So I made Neo Oxygene this LD. It looks something like that. (I still haven’t taken other representative screenshots, heh.)

I gotta say this is one of the most fun LDs I had. I didn’t feel stressed about whether it’ll meet some standards. I just sort of twiddled some variables around until there was a functional enough game on the screen. Most of what I chose to work on was the fun parts in my idea of gamedev.

It’s a system that you can interact with. Especially in game jams, I often like to make abstract things, systems that have creative output for your input. I guess my games tend to lack a human element. People feel disconnected from my games because of that. But that’s just the kind of guy I am.

Consequently, I don’t expect a game like Neo Oxygene to end up on “best of” lists. It’s an experiment, more of a toy than a game, and I’m glad to see a bunch of people have found it interesting to play with regardless. Ratings aside, I’d personally say it’s 80% of the way like I envisioned it. If anything, it lacks a feedback loop between the two screens. Once you get good at it, you’ll basically just keep going endlessly, and the high score thing to compensate for a lack of measurable progress is just laziness on my part. So just taking this content further, in a nutshell – not inventing an entirely different system.

I’ve stopped counting exactly how many game jams I’ve participated in, but 20 is in the right ballpark. Some years back, it would’ve seemed so distant that I could just whip up a solid system like this for a jam, without entirely straining myself. I mean compared to back when I didn’t know better than to program almost all game logic inside a huge main function. When adding a new transition would break everything for hours. Now I can intuitively think in states and scripts and handle a whole bunch of design concepts with a handwave.

It’s good to have that bit of perspective now and then; that sudden realization of how making something that’s a game is actually really cool in itself. That during some weekend, thousands of people are tasked to write a bunch of symbols in a text file, put some pixels and sounds together, and many of the results of this great randomizer are actually very unique and high-quality experiences – or at least promising soil for later growth.

It’s too easy to forget about the coolness of game development when you’re lost in your web of technicalities, or when you think you know what you’re doing and fall into lazy patterns. There’s something endlessly rewarding about mentally placing yourself back in the primal inspiration of your novice days. Like thinking about what kinds of games you *would have wanted to make* back when you were just fumbling to put some pieces together.

Probably many of you people are in that phase where you don’t really know what you’re doing, and you’re uncertain about even being able to finish something for a game jam… let alone taking crazy creative risks. You might have a critic’s sense of what good gameplay is like, but you don’t know how to inject that into your games, either technically or design-wise. I don’t know what to say to that, except: just keep pushing.

Last Chance To Green – Post Mortem.

Posted by
Thursday, December 24th, 2015 7:11 pm

Almost every Ludum Dare we’re spending the first day arguing about the game idea… And this time was not an exception.
First idea was about little toy growing in the water, which you have to observe one hour in real time hoping something will happen (sort of arthouse game), but it seemed a bit unplayable and we’ve put it aside.
Second one was a bit better: nuclear wasteland and little sprout which is taken care of by little clumzy robot on the tracks. But the game seemed a bit complex in terms of graphics and we would have to call it “Wall-e” to put everything in place.

_n7_85aq8z0
And the third idea didn’t exist. So we had to think of something.

w0HzZ07TzcA

On the second day graphics and drafts of gameplay were born. Every team member had their business to do irl, which interfered in the development process.
doc15786221_437116503

And on the third day we’ve discovered that all the code should be made from scratch, graphics can’t be made as we’ve planned, and the gameplay wasn’t thought over really much… It was made during the process of the final polishing.
doc77701574_437121837

The only thing which was coming out smooth and without critical changes was music. Composer hit the spot.

Overall, every Ludum is a challenge for us, but that only makes it interesting.

 

Want to see more?

Play it.

 

 

The Tournament – Post Mortem

Posted by (twitter: @FilipLoster)
Thursday, December 24th, 2015 6:22 am

With the Christmas break starting, we finally got the time to write proper post-mortem and finish the post-LD version with improved graphics for our LD34 game “The Tournament”. You can check it out here. We also uploaded the source code if you are interested to take a look.

The game was designed to be an arena manager simulator, where you manage team of robots to get as many victories as possible. You don’t have the direct impact on the fights (as you are just the coach – not the gladiator), but you can choose the fate of the defeated opponents, suggest tactics to your fighters and choose who shall face each opponent.

What went good:

  • Team communication: With the team of 6: 3 programmers, 1 graphic artist, 1 music artist and 1 UML guy, this could easily become a nightmare. Fortunately using trello turned out to be a pretty awesome solution for our needs.
  • Splitting into prefabs: Our game is written in unity, and it’s known for being a little bit problematic when working with teams of programmers. But since from the very begging we decided to split every bit of functionality into separate prefab we did not had a single merge issue during the whole jam.
  • Paying attention to the audio: I have to admit, that for me personally audio was always the thing I paid the least attention during the game jams. But oh boy was I wrong. Without the awesome soundtrack, the game would not feel even slightly as complete as it turned out to be.
  • Creating mock-ups: It seemed like a waste of time, but they highlighted UI issues we would otherwise discover very late and with the final assets ready. It also greatly simplified the work of the graphic artist and allowed him to focus on delivering the best assets he possibly could without having to worry about the details.

What went wrong:

  • Starting late: We had the idea for the game since saturday morning, but assembled the team and started working on it sunday at 12:00. This turned out to not be a great idea and resulted in less amount of sleep than we would like to.
  • Too many features: Our initial plan was to deliver almost twice what we were able to finish in the time we had. Cutting features late was really hard and if we had started with the more humble plan at the begging we would still had a lot of time for balance and polish at the end.

Overall though, the Jam experience was a blast for the whole team. We learned a lot and had a great deal of fun :) Can’t wait for the next LD 😀

PS. Our music artist uploaded the Full OST to the soundcloud. It’s pretty sweet:

Learning to Dance — PostMortem

Posted by (twitter: @wetdesertrock)
Wednesday, December 23rd, 2015 5:10 pm

Banner

This was probably the first Ludum Dare in which I was actually almost completely happy with the end product. What I amount that happiness to is the personal goals I set for myself. Instead of having my goal be about making a complete game at the end, I made it about having a game full of music and art that I was happy with. Another goal I had was to try to make another story-based game. I wanted a cohesive experience that used art, and music to help the story telling. My last goal was to not get bogged down by programming. I didn’t want something difficult, I wanted something simple that I could whip out. I knew that programming was the one aspect of LD that (at least in recent times) has bogged me down and de-motivated me to the point where I was not happy with my product. Don’t get me wrong, I love programming, but gamedev programming has been hard for me recently and I wanted to continue my break from it. I also had a bonus goal, which was this: Live record my music. Instead of using all of the software instruments to create my music, I wanted to record it myself. At least a little bit. I succeeded.

With these goals in mind, I knew there was a high likely hood that my success hinged on the theme. So I decided that if a theme was chosen that I didn’t like, I would go with my own theme (I choose the theme “Isolation” for this). A lot of people wouldn’t agree with this, however this time around I didn’t want the theme to be the challenging factor, I wanted it to be a guiding factor. Sometimes if I make a game based off of a a theme I don’t like, I’ll produce a loveless game. Luckily there were two themes for me, which worked out super well. I think that the dual theme was a great point about this LD, many games were produced that were fantastic, as well as a good variety of games.

What follows is a day by day account of my process.

(more…)

Xtreme Crop Duster Simulator ’82 – The Two-Camera Setup

Posted by (twitter: @rjhelms)
Monday, December 21st, 2015 11:58 am

After writing up my post-mortem for Xtreme Crop Duster Simulator ’82, I had a comment from pkenney asking about how the two-camera setup I created in Unity worked, and how I used Unity’s built-in shaders to achieve the graphical style of the game. A lot of the positive feedback I’ve received about the game makes reference to the graphical style, so I was already mulling the idea of a post about exactly that – the comment spurred me to actually write it up.

Lots of text and graphics to follow, which likely isn’t be applicable outside of Unity and may only be of interest to people keen on this sort of graphical style, so the real meat of the article follows the break. But as a teaser:

Before and after

Before and after

The challenge, which I had run into in previous Ludum Dares, is that square pixels are a relatively recent innovation. The Commodore 64’s multicolor low-resolution mode which I emulated in this game had a resolution of 160×200, displayed on a 4:3 television. This means that the pixels, once rendered, are 1.6 times as wide as they are tall – not a nice ratio to deal with. In my LD32 entry, Red Threat, I handwaved the problem away by drawing the sprites with 2:1 pixels, and scaling the whole thing up 2x to 640×400. It worked, but the effect was graphics that were noticeably stretched if you’re familiar with the real hardware.

This time around, I wanted to do better.

(more…)

Post-thingum

Posted by (twitter: @charlottegore)
Monday, December 21st, 2015 6:19 am

So mostly I write these post-mortem things as little letters to my future self in the hopes that next time I can do better.

What I Made:

Possibly the dumbest game I could possibly have made. A two button beat em up. Things coming at you from the left? Press left. Things coming at you from the right? Press right. Behold 48h Compo entry, Super Lefty Garden Fighty. And lo, it was stupid. The Earth has been ruined: the world’s trees have been consumed by a race of Cauliflower monsters. Luckily, if you kill enough of them, a tree come back. That’s the backstory.

Super Lefty Garden Fighty

Super Lefty Garden Fighty

What Was I Thinking

I was thinking that if I made a really really really simple game that required no level design, no tricky mechanics I could get all the programming done really quickly and then polish it… TO DEATH.

I wanted it to be beautiful. And lo, it was beautiful… and empty.

Like a Tim Burton film.

Turns out though this mechanic was slightly more complex than I initially thought. I needed to control the behaviour of the baddies to make sure that they didn’t clump up together, but I couldn’t quite fix the thing where it’s actually pretty hard to avoid getting kicked to death by a single baddy. Oh, who am I kidding? This is totally noddy.

What Went Badly

Well, once again, I panicked when trying to come up with a game idea and did the wrong thing. I never give myself enough time. The game is, once you get into it, pretty fun for a short while, but it doesn’t have enough depth or variety to have any long term playability. The difficulty maxes out after a few minutes but most people should find that fairly easy to handle.

What Went Well

I’m pretty chuffed with the art, the animations (especially the tree growing animation) and the graphics in general. The game engine and editor also performed really well this time – I didn’t need to add any features or fix any bugs, nothing went particularly wrong. The whole build was actually surprisingly smooth.

Because I had so much time I was able to do a proper UI for this. Indicators for score, for progress on tree making and also feedback information about hit streaks (and also hopefully explain how to play the game). Little touches like that go a long way to making the game feel like it’s paying attention to what you’re doing, and give the player secondary objectives in addition to chasing a high score.

Next time, Gadget. Next time.

So next time I want to do something intelligent. This was too dumb.

Way too dumb. Like P.E. Teacher* dumb.

I look at some of the fantastic and surprisingly deep games that have been made this time and I realise I need to challenge myself to make different types of games now.

Time lapsed.

I did a timelapse!

*”P.E. Teachers”, also known as “Phys Ed Teachers”, or “Gym Teachers” or “Coach” but universally recognised that when you have 100 of them together, you have a collective IQ of exactly 100.

Mount FuJ Post Mortem – LD34

Posted by (twitter: @roaringcatgames)
Sunday, December 20th, 2015 6:31 pm

 

The Game

http://ludumdare.com/compo/ludum-dare-34/?action=preview&uid=58120

Mount FuJ is a take on tower defense, or defend the castle style games. You play as an active volcano trying to protect the village that has popped up just below at your base. The village is under siege from an unknown enemy that is sending wave after wave of pikemen and horsemen units. The village will fight back, but it is no match for the army. You must use your volcanic ways to rain down lava balls on the enemy before all of the buildings are destroyed.

[Features that didn’t make it: If you are successful, the village will flourish and grow. However, as the village grows, it begins to spread into the range of your lava, so you have to be very careful to do more protecting than damaging.]

mountfj

Background

Zoe Blackwell – Music and SFX
Loi LeMix – Art
Barry Rowe – Programming

The Team

Left to Right: Loi, Barry, Zoe

This was Zoe’s first game jam, and first game related project. Loi and Myself have been working together since Ludum Dare 30, and have formed Roaring Cat Games under which we publish our work. Our team formed as we were brainstorming at the live Ludum Dare meetup with GameDevLou. This was the first time that Loi and I have worked with a dedicated musician and sound designer (which was awesome).

Tooling

Zoe used Logic Pro to record, mix, and compose music. She user her Casio Privia PX-160 keyboard as a midi controller to write the segments needed for composition.

Loi used his usual package of Adobe products but heavily worked in Photoshop to generate the art assets. However, this jam, he added a new tool into the mix with Spriter2D. Spriter really let him focus on the art and fluidity of the animations when during previous jams he was having to worry more about manually framing animation sizes and pivot points.

I chose to go with libGDX for this game jam as it is the framework I have the most experience with for games. While I’ve been doing some 3D work and learning unity since Ludum Dare 33, we knew we wanted to go with a 2D game for this jam, and I wanted to eliminate engine knowledge as a possible roadblock. We always like to challenge ourselves in some way with our projects though, so I did decide to throw Ashley ECS into the mix. I had used it for LD33, but only sort of embraced the ECS approach. For tooling I used: IntelliJ as an IDE, GIMP for placeholder art, and Git for version control.

Location

We worked the entire Jam at the Game Dev Lou “real-world gathering” working alongside at least 8 other teams. (See all of the GameDevLou games here: http://gamedevlou.org/our-ludum-dare-34-games/)

real-world-meetup

We presented a less finished version of the game as the real-world Jam wound down on Sunday about 7PM:

Brainstorming

Our brainstorm session was a bit longer than usual this time around. The existence of two possible themes really seemed to throw a wrench in our creative process. We kept falling into the trap of trying to force both themes into the game rather than focusing on one theme and discarding the other. Loi and I had also discussed trying our best to find a hack’n’slash to fit the theme, so I think that had us always coming back to “is this better than just building a hack’n’slash?” In no particular order, and with no further explanation, here is a list of some of our ideas:

  • Auto-run with Attack, Duck, and Jump all in two buttons
  • Snake/Centipede style game
  • Save the iceberg
  • Ninja absorbing souls into an ever-growing sword
  • Volcano Game
  • One-punch man training simulator (w/ boss fight)
  • Planet Building
  • Tree vs. Lumberjacks Survival game
  • Avoid the expanding Objects
  • Dark Maze Puzzler
  • Grow and Shrink objects to get out Puzzler
  • TRex growing up
  • Lion hunt and roar

When we got to the end, our top 3 ideas were between a Growing Sword hack’n’slash, One-Punch Main Training Sim, and a combo of Volcano and Protect the Iceberg.

brainstorming-sketch

As a whole we were most interested in the One-Punch Man game, as it had the opportunity for lots of humor, and working with a story/world we all enjoyed. However, as we started designing out how the game would play, we realized that the mini-games were fun as a concept, but boring in actual gameplay. We came to the conclusion that we couldn’t make the game fun enough to move forward on.

Next in line was the Hack’n’Slash with a growing sword. We discussed it, and the game play was going to be pretty simple and fun, and the environment had a lot of potential for interesting visuals and sound. Unfortunately, once we started looking at some of the features that would need to be implemented and the number of animations and art assets required to match our vision, we realized that the scope was just a bit too much. I personally had some major concerns that I wouldn’t be able to figure out how to implement the sword mechanics we wanted in code. I kind of regret giving into that fear looking back, but it was probably the right call. Loi can blame me for dashing his Hack’n’Slash dreams until the next jam.

As we began finalizing our third choice, the volcano game, we all kind of realized it might fit our strengths really well. Zoe seemed confident that she could produce the tense, dramatic soundscape we were designing toward. Loi found the concept might lend itself to a painted style he’d been wanting to try out. I felt there were some interesting challenges in the code, especially with only my second project using Ashley ECS, but was all doable in a Jam time-frame. On top of this, once we all got on board, we began expanding some of the possible mechanics, and the game was sounding pretty fun.

Process

Our process for building out the game was straightforward.

  1. Work up a list of all the known assets (art and sound) we would need
  2. Work up a list of all the programming features we need
  3. Task out the features in order
  4. Build each feature to implementation
  5. Repeat 3 and 4 until the Jam ends

Check out this timelapse of the programming effort over 3 days:

While there was no intention this jam of keeping Loi and Zoe from playing the game until the end of the jam…it still happened. Due to the development tools, having the game up and running where we can all play it isn’t as simple as I’d like it to be. This means that unless everyone on the team sets up their machine for development, the only way to play is to jump on my machine.

I think we should have done more small 5 to 15 minute breaks where we all get together to test a mechanic, listen to a piece of music, or analyze an animation or set of art assets as a group. This is something that was missing from our process this Jam, and I think it did limit what we accomplished.

What Went Well

The art and music for the game turned out fantastic. Zoe and Loi nailed it, and I love the feel of the game with them in combination. The soundtrack is nice and tense, with a subtle yet still noticeable buildup of urgency. Combined with the SFX and the lava animations, it makes for a very cacophonous battlefield scene. Yet, somehow with all the explosions and battlefield tension, there is a soothing calm to the experience as well. About halfway through the jam I could see that the music and art were going to need to take the main focus of the game.

The collaboration between the team went smoothly. We were each able to spend the majority of our time in our own tasks but were able to stop and discuss next steps/changes as needed without any issues. I think being in the same location really helped with that, and I can’t recommend enough that you try to join a real-world meetup if possible.

Coming together on Monday after our day jobs, we were able to pull off a lot of work right at the end. Sunday at the end of our day, we barely had a game. The wave system didn’t work, there were no sound effects, there was no balance to the enemies, and worst of all the game didn’t do anything to highlight the great soundtrack. On Monday we were able to take a step back, prioritize the features to make it a game, and knock them out with just a few minutes to spare for submission. This final crunch period went really well, and it was very satisfying to see how quickly we could get things accomplished under pressure.

What Didn’t Go Well

Coming up with a damn name for the game… This is the first jam I feel like we never had a clue what to call the game. If anyone has any great ideas for what this game should be called leave it in the comments below. We were just drawing blanks the whole time.

I feel like I was the weak link in this jam. I’m not sure what happened, but between saturday about lunch all the way through sunday about 10am, I just couldn’t get anything going. I was writing code, but it was all non-essential background placement or environment building code that I could have (and should have) knocked out towards the last few hours. I think I was dealing with a rough combination of:

  • Exhaustion (I had not been sleeping enough all week prior to the Jam)
  • Doubting my abilities to implement features
  • Lack of clarity on how some of the mechanics needed to work
  • Worry that I may have talked the team into a game that just isn’t fun

I definitely should have started working on having the lava destroy enemies much sooner as that is the key mechanic of the game. I had the lava-firing and charging really quick, and it then just didn’t do anything with it for almost 24 hours. I made the mistake of not building the basic mechanic up front so we have time to tweak and make it fun. On the plus side, I’ve learned that lesson (for at least the second time now! :)) and will be able to remember this instance to hopefully keep it in my mind going forward.

What’s Next

In the end, we feel our game has a pretty fun mechanic hidden inside of it. We’d like to tweak some of the known issues (spamming lava is an auto-win, no visual indicator to know how charged up your lava is) and add touch controls. This would allow us to release the game out for mobile devices as a little time sink. We’ll definitely need a scoring system, and a way to indicate that fun you’ve lost. The win sequence needs some work as well.

Team Thoughts

Barry:

“I was very excited for this Jam and challenging myself with Ashley ECS. While I’m disappointed in my output for the Jam, I was able to build out some pretty generic Systems and Components that will be useful for games in the future, and I plan to clean them up so I can open source them as an additional library for other libGDX developers. I’m very proud of the work our team produced, and I hope the shift in focus on Art and Sound comes across for those playing our game. It was an exhausting, humbling, stressful jam for me, but as always I’ve learned a ton and am even more ready to jump into our next projects.”

Loi:

“So, the whole week leading up to Ludum Dare 34, I was filled with excitement! Excited to create something new! Excited to take a break from RCG’s personal 3D project and get back into designing 2D characters and environments again. In the days leading up to the Jam, I started playing around in Spriter 2D (an animation creation and management program that I had been wanting to learn since the last Ludum Dare), because I was looking forward to making a hack and slash. Spriter 2D would have been perfect for animating action frames, as one of its unique features is bone-rigging and attaching them body parts and objects. Spriter 2D was very productive; it saved me a lot of time with image file management, ease of exporting animated frames, and having a simpler, yet more extensive, animating options that were non-existent in Photoshop. It allowed me to focus more on content creation rather than spending a lot of time on filename and manual frames export, which can be tedious and time-consuming when you trying to create a smooth animation sequence.

As always, I wanted to challenge myself to a new art style every Jam. This time, it was watercoloring in Photoshop. I haven’t used watercolor paint since I was a wee-lad, and picking it back up again felt a bit strange, especially now that I am doing it digitally and my paint brush is my tablet pen. The hardest part in the beginning for me was getting the brush settings just right to give it that wet outer-edge water-effect look. Below is my custom brush settings that I used throughout the Jam (works best with a drawing tablet, as it emulates brush pressure and strokes). It was nice to use watercolor inside of photoshop without the mess to clean up afterwards”.

BrushSettings

 

Thanks for reading, Thanks for playing,

–Barry, Roaring Cat Games

 

Box ‘N Bash Post Mortem

Posted by (twitter: @aaghgames)
Sunday, December 20th, 2015 8:41 am

This is the post mortem of Box ‘N Bash, as told by Budaniel (me), the programmer an artist for AAGH Games. Box ‘N Bash is the first Ludum Dare we did not livestream, which was a little unusual feeling but it was a conscious decision because were trying something new this time.

Box 'N Bash logo

We had been aiming to start on 3D game development using Unity and decided that making a working game in 72 hours was the perfect time to figure it out. Aside from some tinkering around, I didn’t have any experience in C# or 3D graphics, which is a bad start seeing as both of those fall under my jurisdiction. My concerns were alleviated when a working prototype came together early on, and we finished on time, despite some last-minute bug fixing.

 

Box 'N Base EvolutionThe evolution of Box ‘N Bash

The good:

  • Learning a new (to us) engine in 72 hours
  • Finishing our game on time is always a good thing
  • We got a little bit of our trademark humor into the game

The bad:

  • We left a number of incidental elements on the cutting room floor, such as the doors opening when the Box Goblins came out, as well as already-recorded sound effects and voiceovers
  • The balance might be off, but everybody testing it had different opinions on its difficulty level so we just had to wing it and hope for the best

The WTF:

  • The voiceovers didn’t come out as clear as they probably should have

The Future:

  • We plan on producing a WebGL version this for the AAGH Game Center, our game portal site.

Well that’s all for this post mortem. If you haven’t yet, give Box ‘N Bash a look.

We’ll see everyone again next LD!

SAAAM – Post Mortem

Posted by
Sunday, December 20th, 2015 7:45 am

Ludum Dare 34 has ended and it’s time to present our game and think about what went right and what went wrong. This was our fourth Ludum Dare, but second with a bigger team. As always it was an amazing experience for us and we had a lot of fun and a little time to sleep. 😀 We are really happy with the amount of work done and how polished the game turned out to be. The themes for this edition weren’t bad and we came up with an idea pretty fast. We’ve created a game called SAAAM.

 

SAAAM

In our game you play as a Crewmember 341. He wakes up in his cryo-stasis pod on a vessel called Trieste. He’s a mechanic and his job is to maintain the vessel assisted by S.A.A.A.M. which stands for System Automation, Assistance, and Analysis Matrix. The player is faced with a series of choices whether to listen to S.A.A.A.M. or to disobey. The game features three different endings based on the choices you make. Will you be obedient? Will you do what S.A.A.A.M. wants you too?

What went right?

SAAAM - Final Room - Fireline Games

SAAAM – Final Room

SAAAM - The Vessel - Fireline Games

SAAAM – The Vessel

  • Art – The game turned out to be a visual feast. We’ve really tried to focus on consistency of art in the game and it turned out great for us.
  • Script – Funny and creepy at the same time. It created a very unique, comedy-horror atmosphere. A lot of players were expecting a jump scare somewhere along the way. 😀
  • Polish – We’ve finished the level design pretty soon and that gave us a lot of time to polish the game. Make sure every little thing makes sound, every light is tweaked properly, every corridor is interesting and unique etc.
  • Voice Acting – Once again we’ve cooperated with Elijah and he did an awesome job as always.

 

 

 

 

What went wrong?

SAAAM - Starting Room - Fireline Games

SAAAM – Starting Room

  • Slow pacing – A lot of players mentioned the game’s slow pacing. It would be good, if we had more narration and choices.
  • Lack of option to skip dialogues – If you want to discover all of the three endings, you’ll have to listen to S.A.A.A.M’s initial talk three times. And this is a lot. We had an option to skip dialogues in the dev menu, but it didn’t make to the full game because it wasn’t release ready.

 

What’s next for S.A.A.A.M.?

We’re now working on a Post Jam version. It will include all of the things that you, the players, suggested and much more! The Post Jam version will feature one additional ending, bug and glitch fixes, faster doors, skipping dialogues and many more. You can expect it to come out in the last week of voting. And what we do after that, will be based on the results.

In conclusion, we think that this game has a lot of potential. We strongly feel that this is an interesting concept and turned into a full game it would be a lot of fun. But for now, we have to focus on a Post Jam version of S.A.A.A.M.

 

Go play the game here

 

If you liked the game please leave feedback in the comments for us. We really appreciate this.

Fireline Games

Posted by (twitter: @GaTechGrad)
Sunday, December 20th, 2015 4:34 am

I’ve finished writing my post-mortem for Mutant Veggie Arena.

Read it on my site: http://levidsmith.com/mutant-veggie-arena#post-mortem

Or click the “Read the rest…” link below.

(more…)

[cache: storing page]