Ludum Dare 31: MACHO KNIGHT!

Hey guys Nemo here! I haven’t updated you guys on this but over the weekend I was busy  soloing the Ludum Dare 31! The theme for this Ludum Dare 31 was “Entire game on one screen” For those who are unaware of what a Ludum Dare is, well Ludum Dares are a global online competition for game developers to create a game according to a set theme within a certain time frame, in this case 48hrs(compo) and 72hrs(jam) (I made a post about this previously if you want to learn more on Ludum Dare). So here’s the exciting part, my game. I present to you the mighty “MACHO KNIGHT”.  You play as the mighty Macho Knight. Fling off the hooligans from kidnapping your Lover using your mighty Macho Shield! Theme: I interpreted the word screen as protection, shield hence you have to protect your lover with one screen. And that is the entire game. ahaha

Controls Right Mouse Click To Move Right Left Mouse Click To Move Left Techniques 1. Enemies will fly further if they are hit whilst airborne 2. Boost off by facing in the opposite direction of your incoming enemies 3. Macho Knight’s shield can wear off enemies stamina, making them fall down to the ground (note: point not awarded)

Click here to Play

Click here to my Ludum Dare Page



What Went Right?

1. Soloing

Unfortunately my friend that I did the last Ludum Dare with was unable to attend the jam due to unfortunate exam times. So this time around I decided to solo the jam game which meant I had to work all three aspects of the game (programming, art, design). However with all that work to do, I managed to be able to complete the game with spare time on my hands. It was oddly satisfying on what I can achieve within such a short amount of time.

Hard work does pay off.

2. Fundamental Ideas

This time around I had two core ideas when designing the game. These were: 1. Easy to learn, Hard to Master I personally like games that have a simple learning curve but wields  a deeper mechanic behind it. During the design phase of the game, I referred to games that had similar core beliefs such as dive kick, lethal league, flappy bird. All these games had on thing in common which was having a simple control scheme. This is where I decided to have my game just rely on purely two axis left and right. 10844733_10205323332273045_2059939595_o

(prototype of the game)

2. Fun to watch, Fun to play Physics games are always to watch and play, and that is why i wanted to use the inbuilt physics engine provided by unity. The physics engine created interesting outcomes, seeing boxes fly left and right were some what entertaining. I had a few giggles playing around with the numbers. At one point in the development I just spawned tons of boxes just so that I could fling them away. 10853711_10205329465346368_466539692_o

3. Art

This time around I had to really go simple with my art. So I went with the core three colors (R,G,B) for my character design. The characters came out quite nicely that were both visually pleasing and readable to the user. Overall satisfied Characters Background2

What Went Wrong?

1. Math

Ahaha not gonna lie, I’m not the brightest with math. I had myself a bit caught up having to back to hitting the math books more than I had to look up programming errors ahaha. So I’ve decided to solve some math problems over the holidays! woo

2. File Back Up

At one point in the development my Unity crashed and I had totally forgotten to back up my game so I lost a bit work. What I should have done was to back up different versions of the game onto github so that when something did go horribly wrong I can always reload a previously working version.

3. Fatal Error.

Fatal Error, I don’t know exactly why its occurs to people ahaha. The biggest main problem is I’ve never experienced the fatal error so its really hard to pin point out the cause of it. I need to learn how to find a way to recapture these fatal errors so that I can prevent it from happening.

What I can do better next time?

1. More sleep

Ahaha More sleep. Always More sleep. I was soo dead from not having enough sleep.


Untitled-121 Untitled-12 10834318_10205335113007556_87875909_o menu Anyhow Nemo signing off! Till next time ciao.

Let’s Talk Basics

Hey guys Nemo is back from finishing UNI! So I’ve been planning out what content Game related topics to talk to with you guys, and decided to start from the ground up on game programming algorithms and techniques!

The topics that I’ll be covering over time:
1. The basics – Game Loops, Objects
2. 2D Graphics – Sprites, Tiles
3. Algebra – Vectors, Matrices
4. 3D Graphics
5. Input
6. Sound
7. Physics
8. Camera
9. AI
10. UI
11. Languages
12. Networking Games

Yes, I have a lot of content to cover with you guys!

Note: I am not a qualified tutor nor am I trying to be one. I am still a learning and pursuing in the field of game development. Content that I put up are purely on my understanding and experience from game development. I am just a fellow blogger that wishes to spread the joy of game development. So then with that said. Shall we

Let’s Talk Basics!


Basically, a game program is one big loop, a loop repeats a series of actions until the player has terminated the game. We call this term as the Game Loop, which can also be referred to as a frame. Yup that’s the same frame when hear gamers talk about their fps “Oh man I have 300 FPS (frames per second) my computer is so badass”. 300 FPS would mean that the Game Loop is completing 300 loops per second. The Game Loop contains everything that occurs in the game, such as processing the input, updating the game world and also generating outputs (2D or 3D graphics, audio, music and dialogue). Whatever is in the game is in the Game Loop.

The Game Loop put into Pseudo-code:

while game active
process input
update game world
generate output

Note: This is the very basics of a game loop architecture for simple games. Not all games use this game loop, instead they would use Multithreaded Game Loops.

Multithreaded Game Loops are programmed to harness the full potential of the computers CPU and it’s available cores. So that it can execute multiple lines of code at the same time thus reducing the heavy load, and giving the players a steady 60 FPS on their game. However there are some drawbacks to using multithreaded game loops in some occasions, due to its split processing there can be delays, which could cause input lag. Input lag refers to when a player inputs and the game displays the character moving a fraction slower. This tiny lag can be detrimental for games that relies on precision, timing and relexes such as Fighting Games. Other than that, multithreaded is the way to go for any game that requires heavy load of processing.

Time and Space

“Time waits for no one”

Games rely on time, without time there wouldn’t be any motion or action in the game. Before we get into talking about time, we need to understand the clear difference between Game time & Real Time. This might sound obvious but Game time is the time elapsed in the game’s world, whereas real time is the time elapsed in the real world. What I mean by this is, Game time can be programmed to fit the need of the game, time can run slower or faster. Whereas Real time is constant, runs at the same pace all day everyday of our lives.

Now then, lets rewind the time a bit, when games first game out, they were programmed to be played specific processor speeds. However as time and technology grew, more variations and faster processors came in the market. Which meant that games designed to be played on specific processors weren’t playable on newer processors as the game would run 10 times faster than usual because the game is being processed at a faster rate. We’ve probably have seen this once in our lives, when we put in an old dos games into our new computers with intel i7 processor and when we ran it, it would run super fast making it impossible to play, causing us to download a program to lower our processing speed to match the game.

This problem has been solved by the use of Delta Time!
Delta Time
– The time in seconds it took to complete the last frame.
So what does delta time actually mean?, well instead of thinking movement in terms of pixels per frame, we put it in terms of pixels per second. Regardless of the frame rate, any object using delta time will move exactly the same over the same period of time.

The Delta Time put into Pseudo-code:

object.position.x += 120 * deltaTime

The object will move 4 pixels per frame when the game is running at 30 FPS, whereas it will move 2 pixels per frame at 60 FPS. They would both be moving the same amount however the higher FPS would have a smoother transition.

Note: Any transformation, rotation and scaling should be done using the function of Delta Time.

So how is delta Time calculated exactly?
Delta Time is dependent on the elapsed time of real time since the previous frame.

while game active
realDeltaTime = time since last frame
gameDeltaTime = realDeltaTime * gameTimeFactor
process input (done using gameDeltaTime)
update game world
generate output

Game Objects

Games consist of Game Objects. Game Objects by definition are everything that are required in the game. They can categorized into three types of Game Objects:

Non-Static Objects
These objects can be your main protagonist/antagonist or any moving objects in the game that are required to be updated each frame. These occur in the “generate output” in the main Game Loop.

Static Objects
These objects are your background, UI frames that don’t move and do not require to be updated. They only have to be drawn once.

Trigger Objects
Triggers are updated every frame however do not require to be drawn. A clear example of this is the camera within the game. Triggers also control the flow of the game, it determines when it spawns other objects into the game.

Well that concludes the first content chuck. I hope you guys got the basics of a game program. Ciao for now!