Ludum Dare 36
Coming August 26th-29th Weekend

Suggest a theme!
Theme suggestions for LD36 now open

Posts Tagged ‘post-mortem’

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

cover

So I made this game, ShmupShifter.

It was really complicated compared to what I’ve done for the compo in the past, so there were a few odd choices, and in addition to that some elements of the game are only useful very late in the game.

Consider this a postmortem. Maybe.

The Inspiration

I was inspired to make this mechanic by Radiant Silvergun.  I, lacking an Xbox 360 or Sega Saturn (and 700 bucks), have never played the game, but it seems awesome so whatever. Have some gameplay:

You have access to seven weapons which you can change to at any time. I thought the gameplay possibilities from this would be excellent, and in addition it fit the theme well.

The Main Mechanic

The shape-shifting in the game isn’t necessary in many situations until the second stage, which many players never got too. That’s kind of an issue. In the late game it is essential to use all ships in order to avoid the need to dodge patterns altogether. The ability to move around enemies means that in some cases you never need to come close to bullets, as you can herd them in any direction you want.

A lot of people did not seem to notice the importance of the speed differences of the ships, but when you get better at the game you start thinking about using ships that may not have the best fire for the situation, but that you need to move as accurately or as quickly as you need to.

Play the video to see what I mean with the stage 2-1 boss, which you can dodge above with the fast green ship.

The Purple Ship

One of the three usable ships seemed to be pretty useless to, well, everybody. This ship had:

  • Slow movement
  • Hard to use, weak weapon.

Because people do not see the later moments of the game, both of these traits seem a detriment. The slow movement is actually an essential part of the gameplay later on. When fire become dense, especially in the second loop of the game’s stages, it is almost impossible to weave through with the red or green, fast ships.

The weak fire is designed to prevent players from staying in the purple mode for a long time, as the combination of fine control and normal fire would make it far too powerful in later stages.

Here is an example of using the purple ship to dodge a dense pattern. The second use in the clip is what I’m talking about, when the spread firing enemy comes in from the right. You’ll notice that I die soon after I, in panic of being stuck,  switch to the red ship.

Impossible Patterns

Some people complained about some patterns being impossible. This was, believe it or not, by design. It is always (or at least, 99% of the time) possible to get the upperhand in the situation by exploiting the games mechanics, such as the ability to harmlessly go through enemies, move quickly with the green ship, and fire from all angles. The patterns which may be impossible if you approach them like a typical shmup become easily beatable if you utilize the mechanics.

The Root Cause of the Issues

The biggest issue I had with this game was that I made it for people who were into shmups, not for an average Ludum Dare player. This led me to go way overboard with the difficulty, and make stages ludicrously difficult if you don’t think them through and play repeatedly, which many people wouldn’t. Next time I’ll include a normal mode, which would be easier than this game, and an arcade mode, which would be like this game is.

Here’s just some gameplay starting from the second loop to demonstrate how insane the difficulty can get in this game. (of few of the early deaths are intentional to reduce the difficulty. Or at least that’s what I tell myself :P)

Thanks for reading my needlessly defensive explanations of all of my game’s issues! Remember to try ShmupShifter!


A Challenge:

Beat ShmupShifter and be awarded with the TerraCottaFrog’s ld35 True Shmupper Trophy!

trophy

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!

Cat Tidying: the post-mortem

Posted by (twitter: @mahalis)
Thursday, May 5th, 2016 8:03 am

Neko Katadzukeru is a puzzle game where you take delivery of an endless assortment of contortionist cats and must package them neatly to send them on their way. It’s my fourth compo entry (see the previous ones here), and the first one where I actually had the whole weekend to work on it; here are some tales of its development and bits of advice.

Screen Shot 2016-04-17 at 6.14 p

Things what went good

  • Sleep. Seriously, I know the jam tradition is to grind late into the night and hypercaffeinate and so on, but in my experience that results in making sillier and sillier mistakes as the weekend goes on, and being totally burned out in the last couple of hours which are the most critical for finishing things up. I aimed for ~7 hours a night, and while I did have to keep working down to the last few minutes of the deadline, I spent way less time staring blankly at weird bugs and wondering where my life’d gone wrong than I would have otherwise.
  • Early ideas. It’s really important not to spend too much time agonizing over finding the Perfect Idea that is Definitely Better Than All The Other Ideas. Think of as much as you can as quickly as you can, pick one, and go. I typically look over the list of theme finalists on Friday and try to brainstorm at least one or two possibilities for each one. Another thing that’s helpful for this: not just staring at your computer trying to think of something. Go outside; take half an hour to wander around and mull things over. Brains are really good at taking random stimuli and building ideas out of them; the more stimuli you’re exposed to, the better your chances of finding a good idea.
  • Hand-drawn art. A lot of people go for a pixel-art style in the compo. When that’s done well, it can look really cool, but it’s hard to stand out unless you are a pixel wizard (in which case I hope you are enjoying Pixel Hogwarts—bet it’s rad). Somewhat less common is a hand-drawn look, which, even if you’re not great at drawing, instantly gives your game a unique character. You don’t need a scanner—take as straight-on a photo with your phone as you can, then use Photoshop or similar to make the image grayscale and adjust the levels so you have a pure-black-and-white image, as in the image below. This time, I made most of the art using a Pencil, but the principle is the same if you’re working with a pencil of the lowercase variety.
    • levels example
  • Mouth sounds. Again, lots of games use tools like sfxr to generate old-school beeps and boops, and that’s fine, but you very likely have a way more flexible sound-effect generator at your disposal. Every sound effect in Neko came from me standing in my closet with a towel over the door (to muffle outside sound and echoes) making noises into the Voice Memos app in my phone. Record a bunch of variants on the same sound in a row, then get the file onto your computer, chop it up in something like Audacity, and you’re good to go. It’s quick, efficient, and it makes your game stand out; the only downside is feeling kinda silly standing in your closet trying to do cat noises.

Things what didn’t go so good

  • Difficulty. This has been a perennial problem for me, and I’ve seen it in a number of other games too: when you’ve spent all weekend playing and replaying the same game, it becomes much easier for you than for someone approaching it for the first time. Neko is really hard; a number of people have told me they couldn’t even finish a single box. It’s critical to have other people play your game while you’re building it, or at least early enough that you can tweak it before you submit it—if the game’s too hard, people miss out on the fun of succeeding at it.
  • Tutorials. Think you’ve taught players your mechanics? You probably haven’t. People will misunderstand things you tell them, or forget about them, or not even notice your instructions at all. Games I’ve seen that do this well will show you prompts that don’t go away, or don’t get out of your way, until you’ve successfully done the thing they’re trying to teach you—there’s a reason basically every AAA game makes you go through a “press X to jump over this thing, press Y to crouch under that” section at the beginning. In Neko, I put instructions on the title screen, which is an incredibly easy place to not see them. Don’t do that, and really don’t put the instructions on the download page (at least not as the only place they’re available). Make sure your players always know what they’re doing.

This has run on longer than it was meant to, so I guess I’ll wrap it up here—I hope some of this proves useful for your next jam. If you haven’t played Neko Katadzukeru yet, please do; I think it turned out pretty well. Thanks for reading!

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! :)

Spelldown Post-Mortem

Posted by
Wednesday, May 4th, 2016 6:58 pm

First of all I have to say, Ludum Dare 35 has been a wonderful experience for Gabriel and me. After a good experience on the last Ludum Dare we decided to team up again for LD35 as team Pixelpotions. We had a lot of fun and (for the most part) made a fairly complete game.

We have been featured in two (to our knowledge) videos!
check them out:
Gaming Faster than Light

Pablo Perez

Please play and rate our game here, we rate and comment everyone who comments on ours.

ld00

Post-Mortem

When the theme was announced I was drawing a blank, it was past 3 and I felt tired. I was on Skype brainstorming with Gabriel and by talking with each other we slowly got the creative juices flowing till we were saying idea after idea. 2 hours after the theme announcement we had decided on an idea and art style. Because of time zone differences Gabriel would be making some mockup art while I slept.

RPG mockup

Mockup for SPELLDOWN

(more…)

Figment, a post-mortem

Posted by
Tuesday, May 3rd, 2016 5:15 pm

The following is a post-mortem for our entry, Figment. You can find the game here if you would like to play it for yourself. We plan to continue development after Ludum Dare, so if you’d like to learn more, you can also find updates on our website or twitter.

Figment is a dimension-switching puzzler about a little girl and her sentient cube.

Hop between the two realms of this dream world to solve puzzles and find out why you’ve been brought there in the first place.

Figment3

Whilst we had entered a few other jams before, this was our first Ludum Dare. We spent the run up voting on themes and trying to come up with some good ideas for the themes that we’d selected. As it turned out, ‘Shapeshift’ wasn’t one of them!

We kicked off midday on the Saturday, and started by wracking our brains for an idea that could fit the theme. Rich had been playing with the idea of a masking shader a few days before, so he was really keen to find an excuse to write one (the final effect is shown in the GIF above). This led us to the core concept of switching between dimensions in order to solve puzzles; we thought that this would tie in really neatly with the theme, as all of the objects in the game could change their form whenever you swapped realms.

In hindsight, trying to force a dimension-switching mechanic in to a 72 hour game jam game was probably biting off a little more than we should’ve. This was particularly poignant knowing that two of our three team members actually only had 48 hours to work on the game. Still, Rich was confident that he could get the core mechanics up and running within the first day, so we thought we’d take a crack at it!

Figment1

Before starting the jam, we’d decided that I would focus on music and sound effects (instead of coding), whilst Ed did artwork and Rich handled the code. So, while Ed started creating concepts for the characters and Rich began on the dimension switching, I took to writing the main musical theme.

Our previous game DiscStorm had all been chiptunes and dance music, so for a change of pace I decided to go for a hybrid orchestral piece. The unique hook was that I would score it twice and then have the game switch between versions as the player swapped dimensions. The idea was to write a melody that felt playful and upbeat in one realm, whilst being haunting or sombre in the other. It took the majority of the first day to get these two pieces finished, along with the code to handle the blending, but I feel it was well worth the effort – as the player is required to constantly switch back and forth between dimensions, it keeps the music feeling fresh, despite each only being three and half minutes long.

Working in the same room meant that every time someone produced something new, it had a direct influence on how the others approached what they were doing. Once Ed had completed the sprites for the little girl and cube, it became pretty clear to all of us that the game was heading towards having a rather “Nintendo” feel to it. That didn’t really come about intentionally, but in the spirit of a jam, as soon as we noticed it we all began to embrace that style.

After we wrapped up at the end of the first day, the game looked pretty similar to how it does in the screenshot above, minus the crate and the incidentals. Rich had the dimension switching code nailed down and you could move around the world, pick up the key and exit through the door, although there was only one level. We were left with a few sorting order issues, as the game is completely 2D, but it wasn’t anything we couldn’t look to iron out the next day. As I was settling down to go to sleep, my need to code got the better of me, so I grabbed a copy and added some screen-space effects to the dimension switch. In case you’re wondering, it’s a mixture of static noise, bloom and chromatic aberration, which all ramp up as the circle expands.

Figment2

Whilst the game pieces were coming together, we were still unsure at the start of the day whether it was actually any fun. We always aim to have a game that we can play by half way through a jam, so we’d fallen behind a bit with this one. Knowing this we decided to switch Ed off of art and get him designing some puzzles.

It became clear that there was a fair bit of depth in the mechanic relatively soon. I’d love to say that we’d planned this up front, but really it just came about from experimentation. Rich began getting a few of the levels in to the engine so that we could actually start testing if the game was enjoyable to play. Getting the first two levels built took a long time. Every wall, floor piece or object had to be painstakingly aligned in the Unity editor for both dimensions. There were also some very particular settings that needed to be used in order to get them to appear in the correct dimensions. The levels seemed pretty fun, but we couldn’t afford to have our developer creating them, so I finished a few sound effects and then swapped over to making levels during the afternoon.

As the day drifted on, Ed got a title screen together, incidentals for the world (like the shelves and rugs), and dialog designs for conveying the story. I finished off the title screen and got it in, as well as incorporating the rugs and shelves in to the newer levels. In the meantime, Rich endeavored to keep the mechanics one step ahead of the levels that were being made. This actually worked really well, as we like to design levels such that they introduce the mechanics gradually, allowing players to discover how things work for themselves. As a result, I could tell Rich which mechanic we needed next, he could code it up, and Ed could make sure the artwork was ready. For the most part, things worked out really well using that approach.

We closed the first day with three or four levels in the game, a fair few bugs, and the dialog boxes still needing to be implemented. I had planned on taking the Monday off, but if we wanted to get everything done there was no chance of that!

Figment1

I woke up and got going with the dialog system. We wanted a reasonable level of polish in the game so I took the time to have the dialog transitions fade in and out, rather than just snapping. After this it became a mad rush to get the ten levels that we’d planned implemented. I started getting through them as quickly as I could, but it became clear that we still had a few bugs to quash. As soon as Rich and Ed got in from work they jumped on Slack – Ed had finished all of the art that we needed (and a little more!) so he largely spent his time testing the game whilst Rich ticked off defects.

As the clock counted down, it became clear that we’d have to cut a few things. We’d taken a decision the previous day to cut a mechanic – a little monster that walks around in the ghost realm but turns into a statue in the human realm – but we decided to go a step further and cut level nine too. We had a plan for the game’s story by this point, so we all felt that having the final level would add more weight from a narrative perspective. I won’t spoil why if you’ve not played it, so I encourage you to have a go!

I realise that our post-mortem is a little late, but hopefully it’ll come in useful for those that read it! By far our biggest lesson learnt was that it’s important to create a game in which you can make levels quickly. About half of our development time in the jam was actually spent building the levels, rather than coding the mechanics. If we’d found a way to make that process swifter, we could’ve added more content in the time we had. If you’ve not played or rated the game yet, please take a look, we really appreciate it!

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!

Wood for the Trees – Post Mortem

Posted by (twitter: @RatKingsLair)
Thursday, April 28th, 2016 12:15 pm

Disclaimer: This article was written for the blog of Rat King.

Wood for the Trees is my entry for the 35th Ludum Dare game jam which took place in April 2016. For now I don’t know how the other participants will rate the game, as the voting is still going on. Yet it’s maybe time for a small post-mortem, especially as my last few entries were not really worthy for one of those.

ld35_20160418_204744_379

The theme of this Ludum Dare was “Shapeshifting”, which was a good theme, or at least I heard far less complaints about it than usual. For my part I didn’t have an idea from the beginning – or rather I prepared several in advance, but none of them actually motivated me when the weekend began. For some time I just ignored the theme anyway and did some physics-based experiments, but everything of that was scrapped in the end. Semi-inspired by the theme I then went on with an environmental experiment, which would be about looping and changing level tiles. A bit like our 7DRL Me against the Mutants, but this time in 3D. As usual I did all this in Unity.

My base idea was to have tiles as parts for the level map, and each tile would be 10x10m (conveniently the size of Unity’s standard plane), and instead of connecting the tiles in a linear fashion or even in a grid, I would define the connections manually so they can loop or have “impossible” connections. This way, a tile could be connected to itself (this actually happens in the game)! A lot of time went into developing the system of instantiating and destroying the needed game assets on the fly.

ld35_20160416_222626_207

With this representation of the game world it’s possible for the player to see things that won’t be there when they move. Thus I added smooth scaling to all objects when they get spawned or removed, just to make it more appealing and let people accept this strange environment. This system also imposed some limitations which actually turned out to make the game tighter and more focused:

WoodForTheTrees_MakingOfMovement

1) The player is allowed to move only from a tile’s center to the next, in cardinal directions. At first I had free movement, but this imposed problems with the tiles that lie diagonal to the current one. It would just feel alien. Restricting the movement was the only solution, and it also made the gameplay (adventure game) much more clear.

WoodForTheTrees_MakingOfFog

2) With my system it only made sense to display 3×3 tiles at once, thus I had to limit the view distance to 10 meters. This made me a bit depressed in the beginning, because it meant a pretty big, boring wall of fog in front of the player. But then I invented the “fog trees” – trees that would exist only in the fog, vanishing when the player comes near. In the end, they really helped making the distance fog less boring and even gave the game its name.

As usual I experimented only regarding gameplay mechanics, but as soon as I added the fog I naturally began to design the game’s appearance. The fog had to have a colour, so I chose one I actually liked. Everything else had to look (more or less) good from now on, which helped tons with not having to do that later. If I remember correctly the pixelation post-effect shader was added at the same time, and I just liked it – I don’t really have a justification for it. But it also helps to hide the fact that my 3D models are all very low-poly and have no textures.

WoodForTheTrees_MakingOfModels

By the way, this is the first time that I used Blender for a game jam; I like it more and more. It fits my style quite well I guess. For the trees I utilized a tool called HappyTree by Sol_HSA, which made it easy for me to generate four different trees and reuse them all the time. I only changed the materials.

The narrative structure of the game also developed more or less naturally: due to the fact I played some “walking simulators” beforehand I was okay with incorporating a personal story. So all content grew out of certain relationships that occupy my mind often enough. As a result it didn’t become a straight story really, but more like a set of emotions I wanted to share.

WoodForTheTrees_MakingOfAdventure

I didn’t plan to do a full puzzle game, but somehow I actually added enough elements like finding typical items and having to combine them, so I can now call it an adventure game without shame. Overall it’s a simple game in the sense that I didn’t even add a visible inventory (as it wasn’t needed), but thanks to the shifting environment and the somewhat allegorical hints the game should be longer than just a few minutes.

You could say the background story and the adventure game mechanics are somewhat contradicting or at least exist in parallel only. But whenever I think of my childhood (which the story is touching), I have certain games in my mind which I played back then, and Wood in the Trees actually recreates them in an abstract way. Furthermore, the seemingly mundane tasks represent the protagonists quest for absolution somehow. The mechanics and plot combined with the fog trees, the game’s name, the colors and some of the objects in the game, it all is symbolic and it’s okay that only a small percent of players understand them fully.

WoodForTheTrees_MakingOfAllSketches

WoodForTheTrees_MakingOfTiles2

Right next to creating the world system in Unity the hardest part of the game was actually planning it. I’m never big with story (something I really have to train), so I just wrote down a lot of things I’d like to say. Not everything made it into the game. And I laid out the puzzle progress on paper as soon as I decided that I would actually have puzzles. But only by actually implementing them I’d see if an item would make sense or not and from time to time a whole path was changed – thankfully always for the better.

Unfortunately I was not able to follow my initial plan to make the game within 48 hours (“Compo”) and had to extend to 72 hours (“Jam”). I never felt that I would actually be able to finish it, which send me to a rollercoaster of emotions during the game jam – either I was relaxed and had a “it’s okay, I don’t care” attitude, or I was angry at myself that I would fail at Ludum Dare yet again. I’m still surprised I actually finished – and it sure helped that for the Jam I didn’t have to create my own music. I suck at this still, and don’t stop hoping this will change some day. Instead I used a track by my brothers, which they composed many years ago for a game prototype Jana and I made in university. It fits the game well enough and actually adds to the symbolism of Wood for the Trees.

A monster?

After several days between me and the development I can now think about the game again. In hindsight I would change a few things, especially as players rightfully complained about those. Being able to re-read the notes and texts would be a great addition, and probably easy to do. Not removing the notes in the game would be a good start for that. Moreover, the hit boxes for the clickable objects are sometimes to small, and generally it’s not clear enough if you can interact with something or not. I would add a few more descriptions to some elements in the game, and also tweak the controls so they would be easier to understand. And I would take extra-care that players find the solution to the first puzzle easily. Last but not least I’m disappointed I couldn’t add any sound effects – not even some step sounds!

If I find time and motivation, I might do these changes and upload a post-jam version.

In any case I’m happy that Wood for the Trees already got some media attention – AlphaBetaGamer made the start (with a title optimized for SEO a bit too much), followed by WarpDoor, PC Gamer and Killscreen. Wow! It shows once more that pixel games – even fake ones – are the way to go I guess. And I visited the A MAZE (a festival for indie games in Berlin) a few days after Ludum Dare, so I even made an Android build of my game. It ran very laggy and the controls weren’t working correctly, but it was cool to actually being able to show something when talking about it. Even though I didn’t show it around that much I had a lot of fun – the fruits of productivity.

ld35_20160418_144327_513

If you’re a participant of Ludum Dare 35, you can rate Wood for the Trees here. In any case, the downloads can be found on itch.io – have fun!

And here’s a video – be aware, it’s the full walkthrough, so of course it contains spoilers:

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.

SHAPE.SHIFT() Post-Mortem

Posted by (twitter: @xanjos)
Monday, April 25th, 2016 10:05 am

I’ve just written up the post-mortem for my LD35 game SHAPE.SHIFT() which you can view by heading straight to my blog.

ld35gameplay

To see my previous post on how to get a good score in my game (because apparently it’s ridiculously hard), click here and if you haven’t tried the game yet, give it a play/rate by clicking here.

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.

[cache: storing page]