Ludum Dare 36
The Theme is:
Ancient Technology

The Compo ends in
Solo, from scratch, with source, in 48 hours.

The Jam ends in
Solo and Teams, relaxed, 72 hours.

Posts Tagged ‘postmortem’

Turned my Ludum Dare game into full game launched on Steam! :)

Posted by (twitter: @BPOutlaws)
Saturday, July 23rd, 2016 10:54 am

Hey everyone! If you played my dragon game back in Ludum Dare 33:

I kept working on it and turned it into a full game, and just launched it on Steam! Figured it could be good inspiration for people participating in LDJAMs to keep working on their entry if they come up with a cool mechanic/idea…who knows, you might be able to to turn it into a full game!

Here’s the trailer:

Grab it on Steam here:


http://store.steampowered.com/app/498190

My next game is ALSO going to be based of my LDJAM entry from Ludum Dare 35:

https://bulletproofoutlaws.itch.io/shootinggamething

Hope this inspires some people to take their games beyond their Game Jam entries if they think they’ve stumbled across something fun! With a few more months of work you might be able to turn it into an awesome game you might be able to pay your rent with! 😉

Follow me on Twitter at @BPOutlaws, I use it as a devBlog lol

– Jeff

Hexshaper Postmortem

Posted by (twitter: @excaliburjs)
Sunday, May 8th, 2016 11:02 pm

Hexshaper gif

Play the LD version of Hexshaper

Ludum Dare 35 is the fourth in the series for the ExcaliburJS team. We piled five to seven people into one room for four days to make another game.

What went well

Workflow and Toolset

We’ve continued to refine and improve the way we build games for jams. It’s important that everything “just works” as much as possible. We maintained the same continuous deployment process that we’ve used before to push to a live site, so it could be tested and played within a minute of being checked in. We also used a watch-and-compile task in Visual Studio Code to gain the same benefit while developing locally.

Art & Sound

Hexshaper art asset samples

We had four people putting together art assets on and off throughout the weekend, and it turned out great. We used bfxr to create the sound effects, and a set of littleBits components to compose the background music. Once we had settled on the theming for the game, everything fell into place.

littleBit setup

Event Scripting

We initially had a grand plan for introducing elements of Hexshaper, and as usual we had to set that aside and come up with a more practical solution that could be completed in the time remaining. We ended up pausing the game and moving the camera over to each portal as it opened and as the player successfully closed it, which ended up providing most of what we wanted.

Bugs

We only encountered a few bugs in Excalibur this time around, and they were all relatively straightforward to test and fix. It feels better to use the engine each time we do a game jam.

What didn’t go so well

Minimum Viable Game

ship

The game on Saturday

 

We didn’t have a very clear vision of what we wanted the game to be this time around. Uncertainty translated into not really having a playable game until Monday. This delay was a stark departure from the last couple of games we’ve made, where we made a point to have something relatively complete by Saturday evening so we could iterate on it through the rest of the weekend.

Animations

There were a number of things that made interacting with the Excalibur animations API painful. Luckily, we didn’t lose too much time to them, and we now have an opportunity to improve that experience for future users.

Conclusions

  • Build a playable game as soon as possible
  • Look for alternative solutions that create most of what you want for much less work

Special thanks to all of the people who worked hard to make this game possible!

View post on imgur.com

Check out Aether Crypt!

Posted by (twitter: @tselmek)
Saturday, May 7th, 2016 10:54 am

Everything’s in the title, feel free to check it out if you haven’t had the opportunity to do so. There’s also a posmortem about it if you’ve got an additionnal couple of minutes to spare.

PLAY IT HERE

POSTMORTEM HERE

Post Mortem: A Mazeshift Title

Posted by
Friday, May 6th, 2016 9:57 am

Hi everyone,

This was my second Ludum Dare. Once again I had a fantastic time participating, and playing the other entries is a great source of pleasure and inspiration. I wrote a post mortem for my game A Mazeshift Title, which you can play here (Unity WebGL version available).

 

Screenshot1A Mazeshift Title

The Game

A Mazeshift Title is a 2D puzzle game where the player must construct a route between two endpoints using a collection of shapes organised in a grid. These shapes are manipulated by shifting entire rows horizontally, or columns vertically. It could easily be compared with a 2D version of a Rubik’s cube, with a pattern that must be completed. The game contains 7 individual levels, and each one is procedurally generated to provide a degree of replayability.

Development

The idea for the game was originally conceived from thinking about shifting bits in computer registers, but using shapes instead. A good three hours on the Saturday morning were spent settling on a design. I felt it was important to take the extra time at this stage to ensure the concept was both interesting and achievable. By the time I had stopped on the Saturday night, the game consisted of a single feature-complete level.

The focus of Sunday was polish: after creating some menus and finishing the transitions between different levels, I moved onto audio. I ended up spending many hours fighting with multiple software packages, and eventually only managed to produce three sound effects. I had initially anticipated having enough time to produce a simple ambient background music track, but this no longer seemed feasible. Some visual polish feature had also been planned, such as sliding the grid tiles when they are shifted, but sadly these also had to be cut.

The Good

  • Procedurally generated puzzles.
  • The mechanics are explained non-verbally using a trivial first level.
  • I followed my plan: the core mechanics were implemented by Saturday night, Sunday was spent polishing the game.

The Bad

  • No music.
  • Tiles don’t slide when shifted.

Thanks for reading, see you all next time!

ShipShift PostMortem

Posted by (twitter: @DeadBodyOutline)
Thursday, May 5th, 2016 11:12 am

A little late, but here is it!

go play

Yayy

What is the game about

This game is about a spaceship that can change its shape. Each one has unique abilities, and you must use them to save the universe in the year of 2344.

It’s a endless bullet-hell like game, where you confront increasing waves of enemies. Btw, what is your score??

Ideas and process

We had just some ideas until we get this one. One of them was a puzzle game where you had to move as quick as possible onto some cell next to you that has the same shape of the player’s current shape (the red rectangle from the image below). We discarded this, as we do not find so much fun on it :p

lol

wat

So we got the idea of a bullet-hell game, using only geometrical forms (as it can be easily generated using SFML lol), so we started the development and we get…. Some shapes on screen

meh
mehh

it’s… something

Of course, this was one of the first steps on having a game. A little more effort we got some enemies on screen and started testing the ship movements, including awsd controls, asteroid-like moving through the edges of the screen and, finally, a follow the mouse approach.

asteroid uh?
dafuq

huehuehue

Long story short, we had some nice ideas for different abilities for each shape, but as the deadline was coming, we just simplified them to get a minimum viable product. See the abilities breakdown:


Triangle (weak, quick)

Attack: quick laser shot

Alt attack: nova (was guided missile)


Rectangle (strong, slow)

Attack: nope (was melee)

Alt attack: melee (was timed invincibility/time warp)


Circle (normal, medium)

Attack: nothing (was mine deployment)

Alt attack: absorbs enemy shots with its shield (was reflective shield)


Also, we did not make any sound for the game. Sorry

¯\_(ツ)_/¯
damnit

not today!

What Went Well

  • We did a game!
  • Learnt some new cool things on SFML
  • Valuable feedback from the community (yay, you!)
  • A more finished game the our last entry
  • Linux, OSX and Windows builds
  • A really cool HUD 😉

What Went Wrong

  • No music
  • No joystick support
  • No shaders :/

Future

Now we will try to finish the game, add some missing features, improve the code quality (generic classes will belong to our “bootstrap” code, helping on future projects), a better collision detection, evaluate game balancing, create some badass audio, all of this considering all your advices <3

nice

ffmpeg FTW!

So go play our game (the jam version, we didn’t worked on improvements yet, but take a look on the code on our github page), follow us on twitter/facebook and have lots of fun!

Nyamo’s Adventure In-Depth Post-Mortem

Posted by (twitter: @ddrkirbyisq)
Thursday, May 5th, 2016 1:31 am

There’s still time!  Play and rate Nyamo’s Adventure now!

screenshot1

Nyamo’s Adventure is our Jam entry for LD35 — made by yours truly in association with my trusty artist Kat.  It’s a 2D “Metroidvania”-style platformer game with shapeshifting abilities, multiple worlds to explore, and collectibles scattered about!  We’re releasing it as part of our “Cocoa Moss” collection of games.

Overall, Nyamo’s Adventure was a blast to make!  This is perhaps our most solid LD showing to date as a team, and it’s really awesome thinking about how far we’ve come since we made Match Girl way back in LD28.  Match Girl was a solid game itself, and was very well-received (2nd place overall!), but just the sheer amount of content and different things that we were able to create this time around for Nyamo’s Adventure is really impressive in comparison.

I had 4 “goals” (ish) this time around for LD, and they were:

  1. Successfully use Unity
  2. Have fun
  3. Finish on time
  4. Make some awesome music :)

I’m happy to report that we managed to hit all four of those pretty well!  #2 was a little rough at times (more on that later) but overall things were great!

screenshot3

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

What went well:

Unity

Wow!  Color me impressed — Unity really overperformed as a dev environment and editor tool.  Now, I’ve used Unity in the past, so I’m well-familiar with both what it’s capable of as well as the little tricks of the trade that you pick up along the way as you work with the quirks of the engine, but I think I still underestimated just how much it allowed me to do when compared with my standard suite of tools (HaxePunk).  As much as I’d like to be a hipster and jump on the bandwagon, I can’t really argue with what it allowed me to achieve this LD.  Having the visual editor around for both editing and debugging was truly invaluable and saved precious precious iteration cycle time when I was trying to design levels, get mechanics working, etc.  Here’s the entirety of world 3 in Unity’s scene view, for instance:

Screenshot 2016-05-04 21.37.02

Being able to put the levels, UI, etc. together like this made things so much easier!

 

Level design and Tiled2Unity

Nyamo’s Adventure is a huuuge game compared to some of my other ones.  5 different worlds, each with a bunch of different screens, and the different rooms all fit together in a cohesive way.  I spent a LOT of time on level design — easily more than I actually spent on coding, which was quite surprising at first.  Although I’ve had some experience with platformer level design from the work I did for Match Girl, I had never quite exercised my designer mind like this before.  I made sure to read up on some Metroidvania design articles as I was first starting out (which proved helpful), and made sure to really plan out the first few screens of the game in a specific way to introduce the different concepts (moving, jumping, collectibles, the final temple door).  I’m actually really happy with how the level design ended up panning out, and how I was able to properly execute the Metroidvania feel.  Of course, it’s very simplistic and if you really look at it the different worlds are very similar in terms of how they lead you down a linear path to an ability and then use that ability to shortcut back to the beginning.  But I think it still works just fine, and designing the rooms themselves was also great thanks to Tiled being a wonderful tool:

Screenshot 2016-05-04 21.38.05

One of the first things I did after we decided on our game concept was to figure out how to integrate Tiled with Unity (something I hadn’t done before).  Luckily, Tiled2Unity exists, and was very straightforward to set up.  Besides a few snafus with our tilesets changing mid-design (was annoying to resolve but was certainly doable), it was pretty straightfoward and just worked pretty much the way I needed it to.  Awesome!

 

Animations, tilesets, and world design

Can we take a moment to appreciate how beautiful the art is in this game?

Screenshot 2016-04-18 19.06.17

Would you believe me if I told you that this is the first time Kat has worked on tilesets? (besides the single set from Match Girl, which doesn’t even count)  She really did an amazing job with everything, and it was awesome getting to pull the tiles that she drew into Tiled and using them to build out the different worlds, each with their own palette and feel.

 

Music

The soundtrack took around ~5 hours in total to write.  It was a blast!  Nothing really new here — just standard jamming out like usual.  Everything was pretty straightforward, with the notable exception of the Temple theme which was basically my attempt to make something ambient and atmospheric in as little time as possible (11 minutes).  It’s kind of uninspired, BUT at the same time, I think it’s nice that it sounds totally different than the rest of the soundtrack because it helps to communicate the fact that it’s a special area.

It’s worth noting that I didn’t put much focus this time on reusing a shared motif throughout the entire soundtrack — there’s hints of it, but nothing you would really notice unless you’re really looking out for it.

Something I realized as I was making this soundtrack was that giving yourself a jumping off point in terms of atmosphere, tempo, or feel really helps in getting things started.  I think I started each composition with a very small idea of how I wanted to differentiate it from the others and that helped me get things started.  For example, for Autumn Colors I knew that the first world was going to be the “hub” of the adventure and was also going to be an outdoor world, so I wanted something that felt more “open” as well as relaxed.  Musically, that translated to a slower tempo, with a laid-back drum beat, and using chords similar to major 7ths.  For Take to the Skies, the spring world, I knew it was going to be the first “stage” that you explored after the hub, so I wanted it to contrast with the outdoor hub music, and also wanted it to be more upbeat and driving as you’re now getting into the “meat” of the game.  Musically, this meant a faster tempo, with more complex breakbeat-type drums.  I also knew that the world was going to have an “underwater” palette, so I used some specific instruments to evoke that feeling.  (Compare it to Song of the Sea from Melody Muncher to see what I mean)  Anyways, the point is that having that starting point allowed me to lay out the tempo and maybe even a drum loop right away, which really worked to get things started (often the hardest part about writing a song).

Soundtrack can be downloaded at https://ddrkirbyisq.bandcamp.com/album/nyamos-adventure-original-soundtrack.

 

 

Spikes, knives, and other level elements

I almost feel like this one was luck because of how well it ended up coming together…

So, when I was first thinking of the design of the different worlds, I knew I wanted them to look different, and each feature a slightly different focus on the different abilities that you unlock as you go through the game.  For example, the puddle world (the dark one with spiders) was specifically constructed to be more closed-off and cave-like because there would be many places to make use of the puddle ability and it made sense to have tighter corridors.

However, there were no plans initially to have a different “gimmick” in each level.  That one just sort of happened through development, and I’m glad it did!  The disappearing megaman-style blocks (the first thing that I came up with), the spiders, and the knives really did well to differentiate each area and made the level design more interesting than just having different tilesets that were functionally equivalent.  I’m especially happy with how the spiders and the knives ended up interacting with the abilities that you find in the respective worlds — in world 3 you’re forced to use the puddle ability to avoid spiders that you can’t get past otherwise, and in world 4 you have to use the balloon ability to get past these long rows of knives shown in the screenshot below:

Screenshot 2016-05-04 22.21.15

Funny story about the spikes at the bottom of the pits you have to jump over — for a long time through development I was planning for them to be water or some kind of liquid, as you can see in A Kitty Dream and The Valley Rule (both wonderful references for this type of game, by the way).  But throughout development we never got around to putting in the graphics for the water (I had already coded an element that triggers death and a respawn when you touch it), and more importantly, I had no idea how we were going to animate it.  In the end we ended up coming up with the idea of using spikes instead and it was a simple, elegant, clearcut solution to the problem that I’m glad we stumbled upon.

 

What didn’t go so well:

2D platformer collision detection

Ugh.  I had done a warmup project with Unity to play around with their new 2D features (much improved since the last time I had used them) and to write myself some starter code (for doing basic things like playing sounds, fading the screen, etc.).  During that I had done some extremely basic testing to make sure that I could test “collision” (as in, detect when two objects touch/collide and do something), but for some reason I didn’t actually bother checking to see whether I could easily implement actual 2D platformer physics.  You know, moving and stopping flush to obstacles, jumping and landing on the ground, etc.  I have my own set of functions that I used to do all of this in HaxePunk (they are very scrappy but WORK very well at what they need to do), but I didn’t have any of that set up in Unity.

So, for the first couple of hours of development I was busy trying to wrestle Unity’s engine to get it to do what I wanted it to do…I already knew coming in that the Character Controller / etc stuff was probably NOT what I wanted, yet I also wanted to be able to hook into the built-in collision detection / etc. and leverage that.  I did NOT want to have to implement all this stuff from scratch, as that would just be ridiculous.  Fortunately I was able to jury-rig together something which worked very nicely, essentially just doing a handful of raycasts on a rectangle as described here.  That was pretty much the only major technical hurdle I ran into over the course of the project, but I wish that I had prepared for it earlier.  On the plus side, I now get to start building out my set of utility scripts, functions, and prefabs for Unity games, just as I did for HaxePunk, so hopefully this won’t be a problem in the future.

 

Stress

Ugh!  I was not in great mental or emotional shape through the weekend and there were some points when I was really not feeling too positive about the project, and in general worried that it just wouldn’t come together.  This wasn’t necessarily due to us being in bad shape, and more just due to me being tired and stressed out due to other RL things (was trying to pack for moving out of my apartment, not enough sleep, etc.)  Sometimes this just happens — unlucky that LD happened to coincide with a weekend when I wasn’t fully up to snuff mentally.  I also had some congestion in the eustachian tube of my left ear which can be really aggravating when it comes to mixing music.  Luckily it all ended up being fine in the en and we made it okay…phew!  Was really glad when we finally hit the submit button (and went out for a nice hearty dinner).

screenshot2

Sound design

Kind of a minor point here, but this project taught me that although my music skills are really on point, my sound design skills are not.  It was actually pretty difficult for me to come up with good sounds for Nyamo’s movement/etc. and I ended up having to redo some of them.  The collectible sound also ended up getting changed in the post-compo version to something that didn’t clash as much with the background music.  Labchirp is nice but sometimes you have sounds that are just tricky to figure out.  It’s something I need to be conscious of and try to research a bit more.

Unused graphical elements

Kat had some other graphics (like additional background and foreground elements) that she drew up that never ended up making it into the final product.  I really didn’t have any time to put them in at the time because I was busy scrambling to finish all of the different rooms, but even afterwards for the post-compo version they ended up not really fitting in and looking a bit out of place.  You can see in the post-compo version that there are more leaf decorations in the puddle world, but that’s the extent of how they worked out.  So, not the end of the world, but we probably could have designed some other way of adding some graphical accents to the levels.  I think we wouldn’t have had this issue so much if we had been working more slowly (i.e. not in a 72-hour game jam) and had time to step back and see what the overall look and feel was going to be like.

screenshot4

That’s about all I have to say about Nyamo’s Adventure!  It was an awesome experience to make, and I hope you all enjoy it as much as we did! :)

Mythic Morph postmortem and postcompo

Posted by
Sunday, May 1st, 2016 7:44 am

Loveapple Games proudly announce our entry: Mythic Morph, and a Postcompo version!

Contributors: Boris van Schooten (game concept, programming, graphics), Val Jones (game concept, graphics, audio), Athena Norcia of Norcia Muziek (violin parts).

>>> Play the game here <<<

grab1-sm mythicmorph-postcompo

The game was developed while being on vacation in Seville, which was an interesting challenge in itself!

It included some epic distractions, like the Spring Fair (Feria de Abril).

ld35vacation2
ld35vacation1-finalfireworks1-final

We weren’t exactly well tooled up… All programming and some graphics and audio processing were done on a tiny netbook that was too slow to actually play the game, so the game was tested on a tablet! We used the hotel room and tapas bars as development studios.

Other graphics and audio processing were done on an ancient Macbook Air. For audio capture we used a Cowon Z2 mp3/mp4 player running Android 2 – it still works great apart from the Korean interface (good if you speak Korean; we don’t). Audio review and playback was on a cheap capsule speaker.

ld35gamedev1-final ld25gamedev2

Musical and other audio effects created in Spain were done using local equipment: a bidet, toilet, washbasin, wet flannel, flapping T-shirt, squeaky bathroom door, various beer cans and glasses from the hotel minibar struck with the courtesy razor, the human voice… to mention but a few.

Gamedev food included Spanish bread and guacamole (we used the courtesy toothbrush as a knife), iced coffee, chorizo, and melon sweets. Epic vacation!!!

ld35foodphoto1

ShiftyBalls Postmortem

Posted by (twitter: @aaghgames)
Saturday, April 30th, 2016 9:01 pm

Here is our ShiftyBalls postmortem. It’s a little on the long side, but we hope that you enjoy it. If you want to try our game, ShiftyBalls, you can do so right here. Thank you, by the way, to everyone who has rated ShiftyBalls and provided feedback!

Day One:

When the theme was announced at 9 PM Friday night, Floata (our musician/level designer) immediately suggested an exploration/treasure hunting game where the player had to shift elemental form to survive hazards. Sounded straight forward enough, so off we went. I (Budaniel) do the programming and art, and shortly after we got the movement in, I moved on to try and create a humanoid avatar. The issue is that I’m primarily a 2D artist, and our game was going to be 3D. The resulting 3D model wasn’t bad. The rigging and animation, on the other hand, became the stuff of nightmares.

sb-3dgonewrong

So, with that horror set aside, I made what was intended to be a temporary avatar – a smiling red ball. We liked it enough, though, to keep it and build the rest of the game around it. We added ice-, fire- and rock-based forms and tied them into the game play: ice freezes water, fire is fast but dies in water, and rock can survive trips through lava. At this point I forwarded Floata the game and he built our first level.

sb-level1

The level, once completed worked well as a tutorial to introduce the basic mechanics to the player. The hardest part, surprisingly, was getting the block to rise out of the lava. For whatever reason, we fought that one piece for almost an hour. We could have worked around it, we could have removed it, we could have come back later, but nope – we had to finish it right now, darn it. We did eventually finish it so we could move on with a clear conscience.

We eventually finished up laying out level one and half of level two before day one drew to a close Saturday night. Our vision was coming together, and we still had 48 hours before the deadline.

sb-unfinished

Day Two:

I began day two by working on key graphics. Specifically, I made the key for unlocking the gate in the levels. For all my desire to learn 3D graphics, I’m still not really there, so thankfully a key isn’t too hard to make.

sb-key

Once that was completed we moved to complete the design on level one (we’d left the end point unfinished earlier). Floata wanted the level to finish on a sailing ship, but I failed at making a serviceable sailing ship, so that ship sailed and we went a simpler route. It was about this time that I noticed a bug in our player movement.

Apparently I had set the player to detect as being on the ground if their vertical velocity was less than zero. What that meant was that as long as the player was falling they could jump again, resulting in the ability to bounce through the air. How on earth we got this far without noticing that is beyond me, but it was quickly fixed – fun as it was, it kind of ruined any challenge the game had.

sb-fly

Taking a break from level design, work began on the title screen, which meant we needed a name for the game. After some deliberation we settled on ShiftyBalls. It may be kind of juvenile, but we’re ok with that. While I was posting a progress post on the Ludum Dare site, the tagline of the game came to me like an epiphany.

sb-logo

With that out of the way we went to work on level three. Working as a team over Skype went well and the level came together in no time. We had originally intended for this to be a large, multi-path level but we pared it back down after a discussion as to its relationship in scale to the rest of the game.

We had been discussing up this point adding indicators for the various forms and a timer of sorts, so when better than now to add them? I toyed with various styles and settled on an seriously boring “colored circle with a number in it” look after failing at multiple flashier variations. Looking back, I wish I’d used pics of the ball in its various forms for the buttons, but I am not a very smart person sometimes.

The timer turned out to be the biggest headache so far, as tying it to the forms and their transformations turns out to be a little harder than I’d expected. The problem was as simple as me misunderstanding how to use a single line of code (InvokeRepeating, to be exact), but it delayed progress for over an hour. That led into the evening, and the end of day two.

Day Three:

Most everything we’d aimed for was in the game now. We had three levels (more is always better, but we liked the three we had) so day three was bug-fixing and graphics-polishing day. The first order of business was doing away with the gray boxes that had stood in for textures throughout the game. Originally intended to look like tiled flooring, the way it got stretched all over the place gave it a really chintzy, low-res look. We opted to go for a simple two-piece approach, with a darker body of the surfaces with a shiny, lighter top surface. While this meant I basically had to go back and double up every single surface in the game, the results (combined with a starfield skybox) were a positive step.

sb-gettingbetter

We tested the hell out of it in the morning, but one issue stuck out: the ice kept blinking back to water for a half second while you were freezing it. This began a small odyssey that nearly derailed the entire project.

I told Floata I would fix the issue, and then sat down on my own to do just that. I figured it would take 30 minutes, tops, but in trying to isolate the problem, I broke the freezing mechanic entirely. We were only about 6 hours until deadline and I had just destroyed a core part of our game. I tried to put it back together, but in doing so, it didn’t work anymore. Panic and stress began to set in, knowing that I had to find and fix the problem right now. Here’s a small rundown of the events as it went all wrong.

  1. The water stopped freezing on contact
  2. The water froze on contact, but then immediately unfroze
  3. The water started as ice and became water instead of vice versa
  4. The water froze as soon as I turned to ice, even if I wasn’t touching it
  5. The water froze but never unfroze
  6. The water turned to ice but didn’t become solid
  7. The water rapidly blinked frozen/unfrozen

None of these were ideal. It took me probably two hours or so, but not only did I get it working again (the issued turned out to be three different, conflicting scripts all trying to do the same thing), I also fixed the original issue in the process. Hooray for success! I’m glad that I fixed it and I didn’t have to be guilty of ruining our game at the last minute.

With deadline rapidly approaching, we ran the game through its paces a few more times and finally posted it, and now its fate is in the hands of you fine people for judgement.

Aether Crypt postmortem

Posted by (twitter: @tselmek)
Saturday, April 30th, 2016 12:02 pm

Howdy fellow jammers, it’s postmortem time! If you haven’t played our entry, feel free to give it a try HERE.

Let’s recap the hell out of this!

  • The unfinished prototype

Before settling on an idea with Dave, my teammate, I had been working on a « just-in-case » shoot ’em up game called Chicken Fuel at the time, here’s what it looked like when it was left very early into the jam.

View post on imgur.com

  • The mechanics

Then came the idea of a molecule-based game. We didn’t yet know what to do but the take on the theme was inspiring to the both of us and so we brainstormed from there. That’s when the idea of a « Moleculevania » came up, we threw a couple of possible mechanics for it on a paper and that was the idea that sounded the most feasible in the remaining time. It doesn’t sound like it, but this process took us the whole first 24 hours.

View post on imgur.com

We wished we could go far enough to make a little boss battle based on radioactive elements such as Plutonium or Uranium but that sadly didn’t happen.

  • The level design

So now, we had a couple of transformations with a feature each and we needed to head onto the metroidvania part of the game, that is to say the level design. I wanted to allow for some exploration without too much struggle for the non-fans of this style of gameplay. The sketch below was the first draft of the general idea for the level layout, from there improvisation took the lead.

Level design draft

Level design draft

  • The audio

I was very panicked when I didn’t see the audio coming 2 hours before the deadline, so I decided to rush and implement some sounds made with chiptone myself. I did well because Dave only provided music but holy crap is it good. If you’re a fan of ambient stuff, you’re at the right place. You can check out his stuff HERE

  • The ambience (and the darkness)

The ambience was surely something we decided to bet on for the mood of the game. The dark environement was part of the mood and the gameplay. It seemed the darkness was too intense for some players but that makes for some finer exploration game, doesn’t it? 😛

  • The minimalism

One of my personnal goal was also to make something very minimalistic, that’s why I tried to put as few texts and as few graphical details as possible. I also tried to make a very simple but effective GUI, the display of the number of electrons and keys collected was rather straigt forward but it took me some time to figure out a way to tell the player how the transformation system worked without any text output.

Minimalistic GUI stuff

  • The experimentations

This Ludum Dare was an experience for me for some parts of the programming. Indeed, this time I messed with something new to me which is surfaces (and occasionnaly blend modes). Their use was necessary for the implementation of the lighting system.

  • Conclusion

Overall, I’m really proud of this entry. Despite the level design I wish I had taken more time to fiddle around with, I think the game came out as a tiny little polished experience package ready to nom a handful of minutes from the players’ life. I expected the game to be less welcome than my previous entries because of the huge difference of genre, going from intense arcade games to a very mood exploration one, but the reactions went against my expectations and I was positively surprised how it was welcomed.

That’s about it, thanks for reading through this little beast of a postmortem, I hope you enjoyed it.

Thanks everyone for all the great comments and feedbacks on the game so far!

Tselmek out.

I came to stay

Posted by (twitter: @josemwarrior)
Thursday, April 28th, 2016 11:27 pm

 

This is what I thought on Monday, right after I finished my first Ludumdare and completed an old task. You can read this post in spanish here.

I’ve finished my first game and I’ve named it “Booba Loomba“. It is a name that I already had in mind for previous game which also had small “balls” but finally I decided to use it for this game. It is true that it was a stressful (really stressful) weekend. There were moments when I didn’t know if I was going to be able to finish it or at least to submit something. I had to figure out the whole game in just one morning – Saturday morning. I’ll explain it below in further details. This is my game:

Click in the following link to play the game.

 

PLAY IT HERE

 

 


This is a gameplay by Marta Jones

khkjbl
Another gameplay by Alice “Buttons”, it starts at 1:02:05

 

Booba Loomba
Booba Loomba

 

 
 

THEME.

 
Let’s get started, the theme of the competition that was announced on Friday at 03:00 a.m. (Spain) was “shapeshifting“. At first, I did not like the theme because of the complexity of shifting something’s shape (even though you can do many things including shape shifting, changing something visually is the first thing that comes to your mind). I stayed awake until 03:00 a.m. to see what was it about and then going to sleep in order to be ready for the following day but I couldn’t do it. I was thinking about games that included changing shapes. After thinking about them, I got stuck with two:
 

  • World of goo (PC): You have to make a structure with the characters to reach a certain point of the map. Sometimes you have to switch your shape to reach the goal.

 
world-of-goo-40
 

     

  • Locoroco (PSP): You have to rotate the screen to move your character and absorb “friends” to reach the goal with them. When you absorb any friend, you will grow physically and sometimes you have to split yourself to get through different parts of the stage.

 
maxresdefault
 
 

I really liked Locoroco as a source of inspiration! Now that I finally sorted out some things, I went to sleep. I organized my timeline as it follows:

SQUEME1

 

CONCEPT.

 
All right, as planned, on Satudary morning I invented the game’s mechanics:

  • “You are a ball and to move yourself through the stage you have to rotate the screen and play with gravity. You do not move the character neither the stage; you can only control gravity.

afdadfa

  • “To clear every level, you have to reach the goal

afdadfasfd

  • “To achieve it you have to find all your “friends”. There are two kinds of friends, fruit (they can’t move) and other balls (they can move). Any time you roll over a fruit it turns into a friend, to catch friends you have to press the A button.

asgsag

  • “You have to reach the goal as big as you can. To achieve it you have to divide yourself to go through narrow spaces and then absorb your friends again. To split yourself you have to press the spacebar.

adfasdfdsaf

  • “You cannot lose in the game. There is no “game over”. The only thing you can lose is time.”

 

DEVELOPMENT.

 
I chose Game Maker because it is really fast to start a game with it. However, it was a long time since I last used Game Maker, return to global variables, the style of working with arrays, it seemed a little complicated because I had been working with Libgdx months ago. But don’t misunderstand me, I highly recommend Game Maker to make games.
 
I started with the default collide system of the software.
 
asdfasda
It worked, kind of, but it was not what I was looking for. I observed how the ball got stuck sometimes and did not drop as I wanted.
Then I discovered that Game Maker uses a physics engine based on Box2d and “Liquid Fun open source” that I had never worked with.

 

ballz

 

I hadn’t time enough to learn how to use it but it gave me pretty neat results.

 

afdafdasd

 

Then I prepared the script that made the ball join other balls and split itself.

 

asdfasdf
 

The next thing was to include the items, “fruit” and the “goal”.

 
afdadfasfasf

 

The “Friends” parameter was named greatness before. I thought that it was a good idea since “You are greater with more friends”. I finished the prototype on Saturday night but…

 

It isn’t a bug, it is a feature.

 
… Nothing turned out as I expected. Game maker gave me more than one problem. On Sunday morning I discovered a bug that made me waste all the day trying to solve it. Because of this, I had to upload my game to the jam (72 hours) instead of to the compo (48 hours). This was the bug:

 

hfuHVph

 

If you grew in narrow spaces you got yourself stuck. I stayed all Sunday trying to find an efficient way of pre-calculating if the space was enough before growing and if it wasn’t enough it won’t let you do it.

 
need more space to grow
 

I was trying a lot of possibilities but when I thought I had found it, it completely broke the game (especially in the HTML5 version 😀 ). Sometimes I thought that I couldn’t solve it because this bug had destroyed the gameplay. Later on Sunday, I thought about the same thing applied to an imaginary machine. If it had more gears, it is easier to break it, so I got stuck with the KISS principle and to the “it is not a bug, it is a feature” principle. To solve it I showed a message telling the player that “It is impossible to continue, you have to split yourself.”:

 
YOU NEED SPLIT
 

This lead to some changes in my timeline, that resulted into this:

 
SQUEME 2
 

FINAL STAGE.

 
This is what Ludumdare is about. It makes you change and remove things to the maximum; it makes you release a game that in other way you wouldn’t.
On the third day, I made the level design, graphics and music without any major problem. I work hard on the tutorial. I wanted it to explain the game itself and to get the player hooked to the game from the very first moment. People told me that those things were perfect so I felt relieved. The third day was the toughest because I was holding enough stress and I was really tired.
 
I am very thankful to Erik Sanchez G., who translate this awesome post into English.
 
Now I would actually like you to play the game and give me an honest opinion 😀
 
 

PLAY IT HERE IF YOU DIDN’T

 
 

Shape Quest Post Mortem

Posted by (twitter: @GaTechGrad)
Thursday, April 28th, 2016 9:43 pm

Originally posted at http://levidsmith.com/shape-quest/

Shape Quest title

Ludum Dare 35 was my tenth time participating in the full Ludum Dare 48 hour game development competition. The theme this time was “shapeshift”. I knew fairly early that I wanted to make a game with controllable shape characters. My original idea was to have three shapes that you could switch between, and each shape would have a unique ability or power. I had envisioned having three playable shapes, which were the square, triangle, and circle. The gameplay was going to be similar to Trine, where the player would need to switch between the three to solve puzzles.

(more…)

SHAPE☆SHIFT: What I learned from Ludum Dare 35 is…

Posted by (twitter: @KaiClavier)
Thursday, April 28th, 2016 4:52 pm

Play SHAPE☆SHIFT here!

Screen Shot 2016-04-18 at 8.07.12 PM

Ludum Dare 35 was a huge learning experience for me, so I thought I’d write up a postmortem or whatever!

 

1. Making a puzzle-platformer for a game jam, and you

The first thing I did was write down a bunch of ideas that came to mind with the theme, and settled on this one. I immediately came up with a few good ideas for puzzles I could do with the gimmick, but I wish I came up with more as the last puzzle in the game is embarrassingly easy! I had this big puzzle involving moving from the one side of the screen to the other planned out, but ran out of time and submitted it as-is.

Using polymorphism for the blocks saved me a TON of time. The player and the blocks all inherit from the same class, and the “floaty thing” object has a variable for which one it’s currently controlling. I’m very glad I happened to brush up on this before the jam.

By the last day of the jam, I more or less had everything implemented coding-wise, and ran into a level design panic. Many things that I wrote down on paper didn’t get put in the game, despite the code being there. One puzzle desperately needed a ceiling, another needed a door that closes behind you, a conveyer belt needed to be just a bit longer, a certain flagpole didn’t have to be there. The “unpossessable” enemies also needed some kind of indicator on the overworld that they couldn’t be possessed, besides not having a “core” when you try to take control. All of these things I actually had written down, but just never got around to doing them!

At first I thought that the solution to this would be coming up with 100% of the game within the first 8 hours and spending the rest of the jam making that game. I soon realized that this would make the game just feel… stale, and drew connections between this and the lesson on keyframing in “The Animator’s Survival Kit”. What I just described is similar to the “pose-to-pose” method of animating, drawing out each keyframe, and then adding inbetweens until it’s smooth enough. This gets an animation done on time, but where’s the fun in it? Another method of animating is the “straight-ahead” method, which is the way that you would animate in a flipbook. The problem with this animation method is that it might not stay consistent throughout, so you might not end up with something nice at the end. Finally, the “combination of pose-to-pose and straight ahead” method is usually the best way to animate. You draw out your keyframes, then animate straight-ahead between them. You know what needs to go between these keyframes, but have the freedom to do them however you want.

The same lesson can be applied to making jam games, just replace “keyframes” with “game systems”! That said, any method is fine for doing a game jam, just know what you’re getting into with each one. I mostly planned out my systems, but just wasn’t very good at coming up with additional puzzles under pressure, tbh.

 

2. Take 5 minutes to give yourself cheat codes

Honestly I must have lost hours to this. Every time I wanted to test out a later puzzle, I’d have to manually drag the player character there, collecting the “floaty thing” along the way. It would have taken me 5 minutes to write code that disables collision, lets me fly, and increases my speed by 10. So… do this, especially if you’re making a puzzle game where everything is in one scene!

On this note, I soon after found a plugin for unity that keeps objects locked to the grid, without holding down command. This would have saved me a lot of time if I had it. Editor cheat codes!

 

3. Polish is important, but playability is more important.

Some polish can be needed to make a game playable, as I cover below when I talk about floaty controls. What I’m talking about here is that if you’re running out of time and you still need levels designed and tested, mayyybe you shouldn’t spend 2 hours trying to get particles working?

I desperately wanted the player to have dust particles when they walked and landed, but ran into some problems with shuriken, Unity’s particle system, that I’ve never had before. I’m not sure what caused it, but hopefully I can get that working in a post-jam version.

This was my first time using Unity’s surface effectors, and they’re really weird! I lost an hour or two trying to get those conveyor belts feeling good, and discovered it’s /kinda/ impossible.

 

4. What makes controls, “floaty”?

This was something I spent a lot of time after the jam thinking about, and asked some friends for their opinions on this. (Thanks, Managore!) It’s sort of a weird topic, since even in the post-jam build I’m working on right now, I /still/ haven’t gotten the player feeling exactly like I want, but the problem seems to be more about horizontal movement, rather than vertical.

Increasing the gravity actually didn’t do too much, just shortened the amount of time the player stays in the air. Having a jump last from 0.3s to 1s seems to be a good range, but in my game, the jump already lasted 0.8s!

Faster acceleration and higher max speed so far seem to be the biggest contribution factor to removing that “floaty” feeling. Acceleration especially helped, making the player come to a quick stop after walking made it feel much snappier. That said, I think giving the player /less/ control of their velocity midair might also help! In Super Mario Bros, if you make a jump at full speed, then try to reverse that mid-air, it’s possible but takes a lot to do it! In my game you could just glide wherever, and it feels bad.

Another big contributor are things that one might consider polish, but turned out to be essential for making a jump be more satisfying:

Jump cancelling. At first, I had this implemented, but removed it due to a bug with the “jump on enemy multiple times” puzzle. After the jam, I was able to fix this in about 10 minutes, and it made the jumping feel much snappier.

Dust upon landing. As I mentioned above, I just couldn’t get shuriken working in time for the jam. But adding a small effect like this to a jump can make it feel way better! You want it to feel like the player slammed into the ground, not like they decided to stop falling for some reason.

Audio! Adding walking sounds would have made the character feel more like they were really there, and absolutely not gliding. The player also had a jump sound, but no landing sound. This stacks with what I said with dust upon landing.

Different jump sprite for going up & coming down. This could have been as little as moving the character’s pupils, but it would have “sold” the jump more if the player looked up while jumping up, and looked down only when falling.

Toss in some cheap sprite scaling. I could go on even more about animation, but pretty much just look up “squash & stretch” and “anticipation”. (Those are just the first two principles of animation, but brushing up on all of them will be helpful!) You can mess around with sprite scaling during jump animations, which can usually get the job done in selling a jump.

 

5. Be nice to your artists

Without Rev, my game wouldn’t look anything like it currently does, and I would have surely ran out of time. My main character was still just a hexagon at the start of day 3! I’d like to take this time to promo him:

https://twitter.com/IMPLODINGORACLE

https://twitter.com/IMPLODINGORACLE

https://twitter.com/IMPLODINGORACLE

When you’re getting assets from an artist, come up with a list of exactly what you need to be done, and what kind of feeling you’re going for. And let them know early! And be nice to them!! Jeez!!! Also, the conveyor belt graphic in the game was still my temp-art, and we ran out of time to swap it out with something better.

 

Conclusion

Making games is cool, you learn a lot!! Make sure to write down what you learn, so you can… learn from it.

The game needed more ways to explore the main mechanic, and better ways to introduce it to the player.

I’ll probably post an updated version of the game after judging. I’ve already done some control tweaks, mechanics tweaks, fixed problems with puzzles, and worked on fixing the floatiness mentioned above. Updating that right now wouldn’t be fair, so I’ll be waiting til after to consider posting that.

Thanks for reading!

 

Play SHAPE☆SHIFT here!

Robot Escape – Post-Mortem

Posted by (twitter: @rjhelms)
Wednesday, April 27th, 2016 4:47 pm

We did it again, folks! I’m buried in a mountain of great games, and figured I’d take a few minutes from trying to dig my way out to write up a post-mortem for my Ludum Dare 35 entry, Robot Escape.

title screen fullsize

This was my 5th Ludum Dare, and all-in-all I think things went pretty well. After finishing in time for the compo in LD34, I really wanted to do so again, but circumstances conspired against me this time around – oh well. I’ll explain in the “What went poorly” section.

What went well

  • First and foremost, I had fun, and made something I’m pretty proud of.
  • The core mechanics of the game – restricted lines of sight, and reconfiguring yourself to get around different obstacles – worked out really well, both on their own and together.
  • I’m getting really comfortable with my Ludum Dare tool-chain. In the past I’ve always lost some time farting about with Unity’s quirks, but this time everything went pretty darn smoothly.
  • In the same vein, a lot of what I spent time on in LD34 served me well as techniques I was able to reuse this time – in particular, I was able to just drop in the two-camera setup for an “authentic” retro feel I developed that time, and (as predicted) my level loader from that time around was clean enough to reuse – although my level-loading needs were a lot simpler this time around.
  • I experimented with keeping my code a bit cleaner by having a lot of my entities be pure C#, with only a handful of MonoBehaviours responsible for interacting with Unity. I’m not sure I did it well enough to be a reusable approach, but for a game like this it worked really well.

What went poorly

  • I started really late. I have the nasty flaw of being a gigging musician, and the band always seems to find ways to need my time during Ludum Dare. This time around, we were playing a gig out of town on Friday, so I completely missed the theme reveal and didn’t make it home until about 4am. I took a look at the theme as soon as I got home, but didn’t seriously start the clock, so to speak, until around 11am on Saturday. (The gig went really well – it’s only a “went poorly” item from a Ludum Dare perspective.)
  • I lost another two hours to a power outage on Saturday evening. Thankfully, I didn’t lose any work as I’ve got a UPS for my computer. It wasn’t a total loss, however, as I took some time to do a bit of planning on pen and paper by candlelight.
  • I didn’t get the controls right. This seems to be the biggest pain point people raise in the comments on the game, and I agree – I had planned to take some time to tweak them, at minimum, and ideally make them configurable, but I didn’t make it there before the deadline.
  • I wanted more/tougher enemy types, but only had time for two. Similarly, it would have been nice to have a bit clearer feedback about when the enemies were firing on/hit the player.
  • It took a concerning about of time for this game to actually be fun – any beginner’s guide to Ludum Dare tells you to make sure your core idea is fun as quickly as possible, but mine didn’t really get there until pretty late on Sunday.

A more detailed run down of the jam follows below the break – but if you don’t want to read that, why, you could always give the game a try and let me know what you think!

(more…)

Soulshifter Post-Mortem

Posted by (twitter: @ToastedGames)
Tuesday, April 26th, 2016 11:44 am

(I had to look up what “Post-Mortem” meant because I was so confused at all the blog posts with it in the title. You better be grateful!)

Soulshifter is a game about killing enemies and stealing their forms (sounds morbid, I know). The enemies come in waves out of portals, and you must survive a set amount of waves (based on difficulty) to win. But that’s not all Soulshifter is. Soulshifter is a game about competition, about teamwork, about challenges, and about new experiences.

Me, Erik and Justin worked harder on Soulshifter than on any other game we’ve ever made. I programmed things that I had no clue how to program before we started. Justin made fantastic art in a style he had never tried before we started. Erik learned he was a way better musician than he ever thought he was before we started. We learned that we were a better team than we thought we would be before we started. Soulshifter, and by extension, Ludum Dare did and meant so much more to us than we ever thought it would.

Of course, we didn’t get everything we wanted into the game, but when has anyone ever began a Ludum Dare and finished with everything he wanted originally plus all the things he thought up along the way? We got a game we were happy with in the end, a solid base that could, and will be easily expanded in the future. We got a game that we were proud of, too.

The feedback we’ve gotten has been so wonderful, and everyone  has been so nice. We honestly can’t thank you all enough. Even if you left us a bad score, you will have shown us what we need to improve on next time, and we’re just as grateful to you too. We’ve had so much fun playing other people’s games, also, and it’s just made us feel even stronger that Ludum Dare is a great community of people that we want to meet and compete with every single time it runs.

TL;DR: (What a nasty word, how about this:) To summarize, our time last weekend and the following days after was amazing, we all enjoyed the competition, and all of you, the community. We’re happy with what our game became, and you’ll definitely see us next year. Happy game design,

– Ben, and everyone else at Toasted Games.

Spirits of the Forest – Post Mortem

Posted by (twitter: @DivitosGD)
Monday, April 25th, 2016 1:12 pm

Over last weekend I worked with Wesley Devore and Hisan Iwo to create Spirits of The Forest, a precision platforming game where you must deliver an urgent message for the spirits, and in return they grant you the ability to shape-shift into different animal forms giving you different abilities to conquer the 25+ levels.

Play and Rate The Game Here

Post Mortem

I knew since last December that I was going to be making a game for Ludum Dare 35, but up until a few days before the start, I thought I was going to be doing it alone. I was approached by Wesley Devore asking if I needed music and sound for Ludum Dare. Always eager to gain new friends and have new experiences, I said yes. We both decided that since we had to do the jam anyways, we might as well find an artist. After a bit of searching, we ended up finding Hisan Iwo (couldn’t of found anyone better suited in my opinion), and just like that I had gone from believing I was going to do it alone to working in a three person team.
We started off the weekend without any real idea of what kind of game we were going to be making, other than we knew it was going to be 2D.  After a fairly short brainstorming session we decided on making a platformer (although originally we had planned on making it a puzzle platformer instead of a precision platformer). Without all of the particulars in place we began working. While Hisan worked on the character art and Wesley worked on the music, I programmed the base platforming system and worked out the rest of the design and story for the game.

Early Mockup

While day one didn’t yield much material progress, day two saw the game shift from an idea to a tangible, although rough, game. By the end of it all of the character and world art was done, the music was finished and ready to be implemented, and all of the levels, tiling, and dialogue was done (although dialogue would later have to be rewritten the next day). At the end of the day I could tell the game was going to be brutally hard and tried all I could to lessen the cruelty, but I couldn’t afford the time to redesign the entire world again (especially since I already had to once). I could also tell that the game was going to have an amazing atmosphere to it and that this was going to be the strongest point of the game.

Day three was spent finishing and adding in sound, music, and the remaining art to complete the feel of the game. I didn’t get all of my goals I had written from the previous day done because while I had intended to spend the majority of day three polishing the game, implementing the remaining assets ended up taking the vast majority of the day leaving me little time to polish. This definitely took a lot away from the game since it left rough hitboxes and some parts that could be considered brutal in an already brutal game world, but overall I was still happy with the game.

Screenshot of Finished Game

I’ll admit that I wasn’t sure how working with a new team was going to be, but they both did amazing and it was a fun experience. The only areas that I felt were lacking in the game were things I was responsible for. It’s apparent I’m still not the best at level design, for instance, but if you compare this game to my previous game, you can tell instantly it’s a big step up. The game in its current state is somewhat incomplete, which is why I’m working on a post-compo version that fixes many of the glaring issues before uploading it to Gamejolt and Itch.io.

The Good

  • The art of the game turned out amazing. Individually the assets looked a little bit odd, but they came together to form a really charming look. Combine that with the amazing music and sound design, and you get what I think is by far the best game I’ve ever worked on in terms of atmosphere.
  • I ended up spending about half of the time on level design, so the game ended up pretty long (25-30+ levels depending on how you count them).
  • I learned a LOT about level design. I consider the levels of Akashic Records (a platforming game I did for a game jam last month) to be absolutely horrendous. While they were still really hard here, they’re definitely a big step up.
  • I liked the story we came up with, and considering this was my first time trying to implement dialogue into a platformer, I think it went well.
  • As always I learned a lot more about the engine I was working with, particularly I discovered the cause of a lag that has plagued most of my previous games with a scrolling view (though it was never nearly as bad as it got here, I simply had no choice but to pinpoint the cause of the lag and fix it, and my future games are going to be much better for it).
  • This marks 4 months down so far for 1 Game A Month! 😀

The Bad

  • It ended up being HARD. It wasn’t just casual occasional road bump hard, it was teeth grinding fight for every inch you advanced hard. This isn’t always a bad thing if you apply it right in the game, but I was going for a bit more casual feeling platformer and had to rush through meaning I didn’t have time to conceptualize all the easier challenges I could have done with the mechanics. This makes the game feel a bit disjointed at times (particularly in the not so tight controls that would work fine in a casual platformer, but leaves you a bit frustrated at times here).
  • I didn’t have time left to do as much polish as I would have liked to, so some things (the hitboxes being the most obvious and unfortunate example) are left rough. I also would have liked to get some particles and other VFX in there to really complete the feel of the game.
  • There was a few strange bugs left in the game that I had absolutely no idea why they were happening and didn’t have the time left to look investigate them. These bugs and the lack of polish and VFX are the biggest drawback by far, which is why I’m fixing them all and adding in the polish I wanted to from the start in a post-compo version for Gamejolt and Itch.io.
  • There was still a few times when you’d experience an abrupt lag spike, but it never seemed to last for more than a split second.
  • The ending was a bit dissatisfying, but it did end on a good cliff-hanger that allows us room to expand it into a full confrontation, or possibly even make a sequel (of sorts) so we can do the story the justice it deserves.

Final Thoughts

Though I could have done my part quite a bit better, I learned a lot and came out with a game to show for it. Like every other game you do (especially games that are made for game jams), it’s not always the final game, but rather the experience you gain from it that really matters. While you and everyone else are likely to forget about your game jam game, the experience you have and the lessons you learn ripple throughout time and creep into every one of your future endeavors, and that’s what truly matters.

Aether Crypt – postmortem coming soon

Posted by (twitter: @tselmek)
Monday, April 25th, 2016 10:39 am

Howdy fellow jammers,

While I’m at work on cooking up a postmortem post for you to feast upon, you can check out and rate Aether Crypt if you haven’t already. If you’re fond of ambient stuff, a big fan of metroivania style games, a platformer addict or a chemistry nerd, you might enjoy giving it a try. Here’s a couple of screenshots to give you a taste of what you’re in for.

Menu goodness
Feel the Carbon
Neon enlightens my nights

Have a good one!

Tselmek out.

[cache: storing page]