Hello !

Ace-ced and Haneton here !

First of all, we were really excited about joining the jam. It was a thrilling experience for us. It was our first game jam and we are more than happy about the results :

We’ve both reach a point in our student’s life where we’re getting into game making and wondering about going further on this path. Seeing how Go Gobelins was received makes us glad and hopeful for the next step we have to do in our game dev’s journey. We are very thankful to all the people who took some time to rate, comment and give us feedbacks on our work. It helped us improve Go Gobelins and we have already made and planned some changes for Go Gobelins. Go Gobelins may become a mobile game later. However this will take us some time.

Anyway, it was a very good experience for us and we’ll definitely be there for other jams ^^

If you’d like to try out the game : https://haneton.itch.io/go-gobelins

Hello! During the voting period I posted part one, part two and part three of a series about technical aspects of my LD43 entry. I said in the third entry that it would be the last one, but I'd forgotten to write about something quite substantial, so here goes..! 😨

This is a screenshot of the game, F.O.U.R., and if you still want to play it post ratings, here it is~

Dialogue system

Whew!! I'd written so much about graphical solutions that I'd completely forgotten that I spent a bunch of time on my dialogue system, including a custom Unity editor to create the conversations. Surely that ought to be interesting too. Perhaps even more so!

Here's what the dialogue system looks like in action:

As you can see it offers multiple choices sometimes. I did end up discovering a bug near the end that I didn't have time to fix that limited me to quite shallow dialogue trees, but luckily I didn't need more for this game. Would certainly have fixed it if I'd had more time, tho!

Basic design

Might seem weird, but the first thing I did was to find a font I liked, since I knew for a game of this scope and time limit I'd have to make sure manually that the text would fit in each box rather than program a system that would spread dialogues over multiple boxes automatically, so I wanted the font face and text size in place right from the get-go in order not to have to fix anything later in case a different font than the one I started with would take up more space in the boxes.

I ended up going for the (100% free—that's important!) font Caviar Dreams by Lauren Thompson, since it had this overall elegance to it, while still mixing it up a bit with the funky lowercase e, as you can see in the screenshots above~

Programmatic design

In the end the dialogue system ended up a bit hacky and messy since I didn't have too much time to do it properly and only did what was necessary to fit the game. By coding up a custom inspector/editor in Unity for the conversations (which were implemented as serialisable objects) I was able to hide any unnecessary implementation details and prevent myself from making any mistakes.

To give you an overall idea, here is the default Unity inspector of the type on the left versus the custom one on the right:

I spent almost an entire day of the jam on this altogether, but in the end I think it was worth it, since apart from the aforementioned bug, I was then able to add new conversations very easily where necessary.

As you perhaps can see, the structure is recursive and allows for nested multiple choice branches, altho I never did end up doing much with that since the narrative didn't end up demanding it, in part because I just didn't have time for anything so advanced—I was running out of time as it was! ⏰

Simplification

Originally I tried to design the system so that it was possible for dialogues to branch back out to where they came from at the end of a subtree and continue from there, implementing this complex system of conversations as a stack that had to be pushed and popped to. In the end I got rid of this and made all conversations just recurse deeper and deeper and end at the final node instead, which saved me a lot of headaches and did the job just fine!

That's it?

I don't know. I didn't exactly go deep here. You probably didn't learn anything, haha. But just to give you a basic idea (perhaps of what not to do, at least!) in case you're thinking about doing something similar for your next jam. 😗

Thanks for peeking!

Thank you for your interest in my first jam game. Next time, I will make a more interesting game. Thank you for liking my graphics and humor.

Finally, it's online.
https://bbaf.itch.io/cake-hunters
I had to optimize it a bit, reduce sprites size, remove some debug code, add UI for the main menu, etc.

Enjoy!

Thanks for the great score! I'm still over the moon, and I still can't believe how I placed highest in Humor, a category that was challenging for me to get right in the past.

When the theme landed, I was absolutely stumped. I didn't want to retread some familiar and obvious ground, so I eventually landed on the trolley problem. Thought to myself that it's probably a unique enough idea - until I saw the numerous LD entries about the trolley problem that eventually spawned from the theme. Oh well. I still hate the theme!

At least there's a twist to the game that's not apparent: The game was inspired by the Good Place: Trolley Problem episode. Not spoiling too much of the episode, but I wanted to introduce a new wrinkle into the good old trolley problem.

By making death as graphical, juicy and visceral as possible. And making it actually possible to kill everyone.

Moral choice in most story based games are usually pretty cut and dried. Choose the good or evil route.

With the premise of the trolley problem, where the "evil option" isn't usually entertained, I wanted to entice players to consider alternatives though: do you do the usual expected utilitarian outcome, if the consequences are vague - or do you explore and play around in a game's space, and what happens when you somehow chance upon "evil"? If you do a max kill, all you get is a scolding from the game, which notices you doing something different. There's also a "hidden ending" if you get max kills for all levels.

The fixed camera was intentional as well, as in later levels you didn't have the luxury of seeing where you were headed and you'd have to make snap decisions which might cause regret later on. Sort of mirroring how moral decisions are made in real life where you don't have complete foresight of the situation. This made for some unintentionally hilarious moments - loved it when a twitch player accidentally steered the trolley into a maximum kill.

The chickens were kind of an afterthought. I've always had the idea that if you wanted to score easy points in a Ludum Dare entry, add a good dose of chickens. They're kooky, lightened the mood, yet introducing another conundrum: which would you place more weight on - a person or a chicken? And in the morally ambiguous space of the game, where there's a clear counter on the number of deaths that goes up regardless of pax or fowl, discovering whats really at stake is part of the "fun".

Putting aside the pretentious philosophical waxing, in terms of the jam, it didn't go as smooth as I hoped though. I spent the first day re-learning Blender, and playing around with the ragdoll physics. On the second day, I spent too much time implementing the rails and the movement of the trolley - not the most optimal solution, but I'm able to put together a level pretty easily.

Finally, the audio was put together in a mad rush at the end. Managed to squeeze in some bad voice acting for sound effects, which worked well and is encouraging for future LD entries. I'm particularly proud with how the BGM ended up fitting the tone that I desired, given the comedic yet sinister nature of the gameplay (was listening to Bonetrousle from Undertale for inspiration)

If there's one thing I didn't like about this - it was too short with just 3 levels, and I would have liked more time to fully develop the puzzles and explore more ethical conundrums. As it is though, I'm pretty satisfied, got to polish my pretty rusty 3D modelling skills and didn't lose much sleep over a entry that was scoped pretty tightly.

Onward to the next LD!

Check out the game if you like

Making some progress with my LD follow-up game The Omicron Directive.

As a big surprise, @knightsunder contacted me about possible collaboration. He made an awesome mockup for potential graphics of the game. Looking great:

https://www.youtube.com/watch?v=MwyyVi2n6Pk

Thank you everyone for the feedback and ratings on my game, What We Hold In Our Hearts! Here's how my numbers tallied up this time:

And using the nifty software over at ldstats.info, here's how I've fared over my past four Ludum Dare entries.

I was happy to see my mood rating increase from previous contests, since that is where I spent most of my brainpower this time. Overall, I wish my ratings would have been higher. But, I learned a lot from the process and feedback by trying something new and different to me, which was my whole goal for submitting. Time for my development story and lessons learned.

Brainstorming

When the theme was announced, I brainstormed like everyone, trying to decide my particular angle on "sacrifice." My go-to game style is a puzzle game, I'm very familiar with how to code them up, but I'm pushing myself out of this box this year. Whereas in previous contests, the theme was wrapped up in mechanical twists, this time I wanted to make a game dripping with theme and mood and worry less about innovation and mechanics.

I finally settled on making a game where the player was trying to save themselves and their possessions following some unnamed disaster. I wanted to make the player feel like they were making a sacrifice themselves, in the vein of the Companion Cube from Portal, and not just playing a game about sacrifice. It felt too easy to set up a situation where the easy and expected thing to do to win the game was for the character to sacrifice something (people, money, items, etc.) with no consequence to the player.

Luckily, I found a list of items people most regret leaving behind in emergencies, and built my game around these ideas. I sketched out the following images to be my valuable possessions:

• War Medals
• Personal Diaries
• Children's Stuffed Animal
• Passport
• Jewelry
• Family Photographs

My thought was that somehow in the game, you would form a connection to these items, and then be forced to leave something behind, causing player devastation and inconsolable tears. Well, that was the plan, anyway.

Parallax

My game would involve running, lots of running. That in itself can be boring with just pressing a button to run, so I tried to add player interest in a few ways. First, the running would need to be rhythmic and need constant attention. I initially thought of having the player hit keys for the left and right foot of the character. I eventually simplified this to be repeated hitting of the "<" and ">" keys on the keyboard to go left and right.

Second, the scenery needed to be evocative of the theme. I'd taught my students about parallax backgrounds, using ideas from this excellent tutorial, but had never wrapped a game around the concept. This was the time!

tutorial

I started out by copying an old demo project, which as we'll see later, was not the best idea. It got me started with some initial code for the parallax, which I was able to swap out with some cold forest/swamp background images I made.

I was heavily inspired by the Forbidden Forest images in the first Harry Potter movie, as you can see here.

Anima2D

Now, to make some characters that run. I'd just learned about the Anima2D package in Unity in October, as I developed a puzzle game called Bunny Kiss.

Wanting to see if I could transfer what I learned, I set about making a simple flat character in Illustrator and give it a skeleton for movement in Anima2D.

To make it move, I decided to implement a walk cycle based on an image from Lynda.com.

And we have a running character! Hooray! Time to implement the actual game mechanics, or so I thought.

Crash and Recovery

On Sunday afternoon, my bad decision earlier caught up with me. Because I'd copied a Unity 5 project to start, and was now using Unity 2018, weird things kept happening. In particular, the Invalid AABB errors (which no one really seems to know why they occur) were overwhelming my development process. My computer was losing battery power, and even when plugged in, there were huge lags in trying to get the game to run. And every so often, Unity would just close on me. Also, my hard drive was mysteriously filling up, I suspected with all of these errors being logged in cache somewhere. So, I followed the recommendations to wipe the Unity cache for the project.

TERRIBLE IDEA!

I got back some of my hard drive space, but somehow lost all of my prefabs, and animations, and skeletons, and AUGH! Nothing worked!

It was time to start over with a fresh Unity project. Sigh.

I still had all my graphic assets and code for the game, so by the evening, I was able to get back up to where I was before, with much cleaner setup, and no more mysterious AABB errors. My character animation was more like limping than running, but whatever, it needed to be finished.

Also, I haven't learned how to substitute out the images in Anima2D once the skeleton has been constructed, so for the other characters in the game, I changed their brightness to make them distinguishable. I was running out of time, and needed to focus on making an actual game instead of just a running character.

Timing and Tuning

I settled on having three characters in the game, you, your friend, and the unnamed enemies who are after you. Your friend runs up and says you have to go, then starts running, and the enemies are not too far behind. You needed to run after your friend, not too fast or you would start to drop your precious items, but not too slow, or you would get caught by the enemies. I found using very small exponential growth in the speeds of the characters was the right way to go, starting out the friend and enemies slower than you can go, but by the time the minute is up, the friend is about your speed but the enemies are much faster, as the following graph shows.

As for timing, I was able place the enemies just far enough behind the friend that it would take them about 45 seconds to reach the friend. Also, if you did nothing when the game started, the enemies would catch you in about 4 seconds.

In my dialog manager script, the friend will signal that the next safehouse was found at 50 seconds, and the safehouse is entered about 5 seconds later. So if you just go slow and track your friends speed, you will both get caught too early! However, you get to slowly bump up your speed as you run, if you try to run again before the animation has finished. And in doing so, you can push a little on your friend in front of you and make their speed faster.

But if you bump up your speed too much, then you get clumsy and start dropping items. You stay clumsy until you pick up items you dropped. And your speed is reset each time you stop moving back to your default speed, so you need to be going faster at the end of the game or you are caught. I wanted to make it a very narrow balance for the player to walk, and with some good tweaking of the numbers, I think it works well. Ultimately, I wanted to make it even tighter, in that you would have to make at least one sacrifice of an item to make it to the end, but I let that go just to get the game working.

One other thing I thought was essential, was that I would never outright tell the player the right rhythm for tapping or the speeds of the characters, they would need to figure it all out through playing and losing the game. I did add one indicator, a repeated clip of labored breathing to let you know you were starting to go too fast and become clumsy. I did test it after the deadline of adding in a clumsy meter for you to know your exact level, but it made the game too easy to play, it was much better to have it all work by intuition.

Finally, I added in the GUI elements and dialog, set up the selection of the initial items, and it was time to submit!

Feedback

This was my first time making a platformer game with dialog and narrative, and I learned a lot. Most players felt the game was too short, and would be a great setup for a longer game with more variety in the missions to get from safehouse to safehouse. I agree. While I could usually churn out enough levels of a puzzle game to make a good demo prototype, this proved very hard to do in the limited jam window, especially with my reboot on Sunday, and the messy get-it-done code that resulted. I've since cleaned up the structure to allow for future extensions, making a class that specifically manages the dialog state and timing, hopefully I'll have time to revisit this game soon. I now feel like I have enough experience to guide better platformer projects by my students and a nice working tutorial game to demonstrate the concepts in class next time I teach my game design course.

Watching ElysiaGriffin and YourBr0ther and a few others play my game on their Twitch streams was amazing! Their play followed the narrative arc I was hoping players would experience, (get trampled, go too fast, learn to pick things up, then try to work out the right speed) and I got to see first-hand how someone would navigate the system with my minimal explanations. You should definitely try to get your game playtested in this way, Twitch streamers for Ludum Dare games are awesome!

Here's a link to the post jam version, and check out the Github repo to see more details of how it was made.

Thanks for reading and all the feedback, see you next LDJAM!