Hitnoodle Blog

Axe to the Shoulder – An Epic Mega Jam Chronology

We’re bored with Unity3D. A bit bored with 2D development. We’ve seen the awesome prototypes and games created using Unreal Engine 4. There was a gamejam around the corner.

Sum it up and we’ve got ourselves an Oh My Viking!


Before the storm

We’ve known for about two weeks before that there will be a big game jam for Unreal Engine. So, with such a limited time to learn, we decided that a bit of overall concepts would be nice as a preparation:

Theme…. STARTS

Friday 9 October, 3 AM. It’s “Standing on the Shoulder of Giants”. Literal meaning? Newton meaning? Attack on Titan meaning? We’ve decided to sleep and hopeful that a muse would give us ideas.

Morning comes and no eureka on anyone. CrazyMaul has just re-learned 3D modelling and I don’t even know if Trois at that time know how rigging on Blender works.

Well, first thing first, we decided that it will be a simple one-off gameplay. It relates with our nonexistent capabilities using unreal. We also decided to go with usual local multiplayer (see Dance of Thrones).

We also decided that we want some “cooperative” to the 4 person local game, so we want to make it two teams of two person going around competing against each other. Our basic game idea is to use the rope-spongebob-minigame but with viking, axe, and dynamic grappling hook.

So, two person attached to each other, holding with axe, moving with grappling hook, the arena is on the back of a giant, you win by killing the enemies and then standing on the giant’s shoulder.


Oh boy. This is where the madness begins.

  • Physics constraints are fine, we can actually use it to connect two objects.
  • But wait, one should always be a static actor. And it goes wacky.
  • We should actually test with some kind of a rope model with multiple physics constraint. I think that doesn’t work either.
  • Characters can attach to arena sure, but we actually need a flat surface. So we make a hidden one, an invisible box on the back of the titan.
  • Sometimes the titan need to “move” and all attached characters will fall. Camera Shake and Events is good here.
Local Multiplayer:
  • Need time to get used to PlayerStart and how unreal handle multiple character.
  • Deciding split screen or not, using two gamepads or one input (keyboard) for multiple characters.
  • Spawning objects seems easy, objects get collided objects and do stuffs to it also easy.
  • Level blueprint is our GameSceneController. Really.
3D Assets:
  • A character with a shield (different texture for each four character) and an axe. Well, we don’t have time for shields. Modelled.
  • Rigged, but then it’s wrooong. We actually need to rig it again and assign better weights. Someone cmiiw.

Sunday evening, almost two days. We decided to scrap the cooperation mechanic because of the rope-not-connecting-two-actor-dynamically problem and make it just 4 players with hook and axe against each other. Kill one, stand on the shoulder before the killed one respawn, then win.

Weekday and Jam

Monday starts and we have to back to reality to work. WORK NOT JAM. We only have evening to work on and I need one day to recharge. I don’t think we’ve made progress on Monday and Tuesday except rewriting the prototype codes into the real project and realizing that our 3D flow is wrong. Oh we created the landscape around the titan using the Ice assets, with snow and trees.

Wednesday is surprisingly a holiday and we can jam from dusk til dawn. The thing is not all of us can go and we need to finalized all the modules. Also.. this is funny.. we don’t have a working player, or even a game working at Wednesday.

Huge red flag. Assigned peeps new jobs to do and went with it. This is also around the time I realized git is useless. Animation is up and running.

Last 24 hour

Gave up on texturing the 3D models. Gave up UI that following the players. Gave up not-split-screen. Gave up four player to make room for two players.

That last thing.. it’s because we actually have to test it using authentic gamepads and we only have two of them.

  • Sound effects and BGM inserted. Feels epic already. /seewhatididthere
  • Battle done and tested around 6 hours remaining.
  • Created title and tutorial screen. HUD for winning. I think it was 4 hours remaining.
  • Combined gameplay logic, death respawn logic, bug fixing, seeing-random-bug-and-realizing-it’s-a-cursor issue fixing. 2 hours remaining.
  • First time packaging and build, testing. 1 hours remaining.
  • Uploading is slow as shit. Safe and submitted around 20 minutes remaining.


I think I learned a few important in this jam, like how spaghetti blueprint is, how it can easily related to C++, how unreal works, and how the tools correlate each other. Cascade is great, Blueprint is great, Montage is great.

Also, it’s crazy that it actually follow our usual jam schedule (2-3 days). Sure, the game it’s not up to our standard, but we can’t really “win” this jam anyway. So many great submission and I personally grateful of the experience. Exciting to see what we can do next! It can only get better!

Unity3D Single Scene Architecture

One of my eureka moment when I learned Unity3D was when Brett Bibby introduced the concept of Single Scene Architecture at one of his talks. As the name said, it means that you only worked with one scene at your release builds. By optimizing into only one scene, we can handle resource loading better and faster. Asynchronous loading, less overhead, and less memory needed.

Disclaimer: All of the development examples comes from Tinker Games’ INheritage BoE. I only speaks from my experience and I’m sure there are better ways, so take this (hell, all of the information in this blog) with a grain of salts again. Yes, I can’t create a reusable tutorial/framework yet.


When I’m developing a game on Unity3D, usually I will create and design scenes according to the flow and functionality I want to achieve. For example: SplashScene, StartScene, StageSelectScene, GameScene, and HighScoreScene to name a few. I will then create a script using Application.LoadLevel() to navigate through them.

On the opposite, on a single scene world, we will only work with one scene (I usually name my scene MainScene) and one object at that scene hierarchy, which is the MainCamera. There are no other objects at first, because it will be created from resource files (XML, json, prefab, what have you) later when needed. Of course, because we’re not using Unity3D scene management, we have to handle that ourselves.

By that, we have to mind (minimum) three things when implementing a single scene architecture. How we serialize and deserialize our object, how we manage our scenes, and how we manage our projects.

The concept of single scene architecture is to minimize all the object at the application starting point and to load all resources on the fly only when needed.


Serialization itself is quite a simple topics. It’s how we save an information or an object into a physical resource file and how to load that back to the original. For example, simple cases of serialization are saving progress data and loading level data.

We want to minimize the objects down to one, so we have to serialize all of other objects. In INheritage, we basically have two kinds of scenes, Menu and Game. Menu scene is where the buttons and images and scrolls take actions whereas Game scene is where the magic happens. The key thing to notice is, all of the Unity3D scene besides Game scene are Menu scenes. And so, we can treat them all the same in serialization-wise!


MenuScene design example in Unity3D.

I began by creating a model from all the elements in the menu. What kind of information needed to make the menu? Sprite, text, actions, glows, etc? I then create a class to hold all of the information and that class can serialize all of the scene data to/from a XML file. That class is also can create game objects according it’s data.

To sum up, I will have a MenuData class (singleton for easy access):

  • Holds all menu data information in arrays.
  • Initialize() and Clear() for basic data handling.
  • Save() and Load() for serialization.
  • CreateMenu() for creating game objects.

For serializing, I will have another game object that will save all current scene menu data to MenuData class and use that to save to the XML file. Deserializing just takes a method to load that XML file and another to generate the game objects.

The usual flow for my menu serialization is:

  • Design the menu as usual in Unity3D.
  • Serialize: Save all menu game objects to MenuData class (using script) and save that to XML.
  • Deserialize: Call MenuData.Load() to the XML file and MenuData.CreateMenu() from an empty scene.

The example is for menu, but the basic is all the same for Game scene and whatever specific scene/object you need to serialize.

Managing Scenes

So we can serialize all of the game objects in one scene, how can we make the transition and interact with each other? We handle this the usual non-Unity3D way: SceneManager / ScreenManager / StateManager. There are a lot of excellent tutorials about managing scene states, so please check others out and implement how you think it best.

For me, I start by creating how a scene is supposed to behave in it’s life. It will have the default behavior to be implemented when awaked, enabled, and destroyed. Load the XML and other resources in Awake(), start the menu transition in OnEnable(), and delete the resources in OnDestroy(). This SceneController script was created as a template and will be used to implement the scenes.

In my menu design, the interaction/transition was implemented on one script per scene. This script will handle how the object transitioning between scenes (which object fade in/out, when to glow, etc.), implement the buttons delegates (what to do when this button is pressed), and other things. All of this functionality will also be copied and used in the SceneController class.

SceneManager is the usual singleton manager that manages the scene transition. My implementation is simple and only changed a little from the initial Brett’s version. Here is the basic flow:

  • When we need to change scene, we call SwitchScene in code. For example: SceneManager.SwitchScene(Scene.AboutScene).
  • It will then search AboutSceneController script and attach it to the main camera, but NOT enabled yet. it will then load the scene resources.
  • When the loading is finished, it will enable the current scene script (AboutSceneController). The game then will transition to that loaded new scene. Also, it will destroy the previous SceneController script that is attached before.


SceneManager in action.

Multiple Projects

Because the minimal nature of single scene architecture, it will be difficult to debug or changing something. The straightforward solution is use two projects, one (or more) for designing the game and one other single scene project for building the release version.

Unity3D have a great editor capabilities, and it’s on the developer hands to extend the functionalities. Development projects is where you want to go crazy implementing editor that is easy to use and a scene that is polished and usable. Serialize that into XML and use that XML in the single scene project for best use of both worlds.


Using single scene architecture on Unity3D release project will optimize your game more. In your workflow, you will have a minimum of two projects, one design and one build.

  • Your design project is the usual development project. All of your scenes objects should be serialized into each own XML or whatever format you prefer.
  •  Your build project will consist of a single scene, with a MainCamera object and a SceneManager script attached. Maybe others too, but it should be minimal. This SceneManager will handle all of the scene management and attach the corresponding SceneController script according the current scene.
  • This SceneController will then load the XML and use that to create the scene objects. It will also manages it scene interaction and transition according to the implementation in the design project by copying it partially and manually.