I dabbled in Unity a few years ago trying to recreate Alhambra, one of the board games I'd been playing at the time. I implemented the tile drawing and placement functionality which was in line with the rules of the board…]]>Mon, 21 Jan 2019 14:38:17 +0000Let's make a game... again!

I dabbled in Unity a few years ago trying to recreate Alhambra, one of the board games I'd been playing at the time. I implemented the tile drawing and placement functionality which was in line with the rules of the board game. However, I lost the motivation along the way and stopped shortly thereafter. In my head I had all the further steps planned out but I just didn't have the interest to put it all into code. A few months ago I decided to try again but this time go with something more dynamic and action-oriented. Bomberman felt like a good choice. It's a simple game mechanically but I also had some ideas how to change some of its features to avoid creating a straightforward clone.

Bomberman NES

I started with the logic, as coding is what I consider my strong suit. I put together some scripts that would place the tiles, walls and breakable obstacles. I added a few powerups and one enemy type that would randomly move around the board. I coded the movement of the player to be tile-based, i.e. you can only move from one tile to the next and you can't stop in between. I like this approach but it also felt easier to code as I didn't have to rely on more complicated calculations and/or physics components. I finished the first iteration of coding by adding a simple UI and the game was sort of playable, even though it still left much to be desired.

The first working prototype of the game

A fresh coat of paint

With the graphics as they were, the game wasn't very inviting. Before moving on to more functionality I decided to find an asset pack that would work well with the concept I had in mind. I came across the following set in the Unity Asset store (check it out!) and it contained all the elements I needed to refresh the game. Most of the sprites were animated but I also added some animations on my own, in particular for the walls and pillars, which were originally planned as tiles for setting up background environments. It is amazing how polishing the graphical assets of the game and adding sound can influence its feel. While the prototype was functional, the new coat of paint turned it into something resembling a real game.

The same mechanics but with updated graphics

Features!

In the meantime I added a second enemy type as well as a simple progression system, which opened a portal after destroying all the aliens and collecting a key hidden in one of the destructible pillars. This meant that it was now possible to play the game infinitely, as it scaled with every completed level. However, with one-hit-game-overs and no visible progression the few test players I showed the game to (my wife and colleagues at work) complained that it still wasn't that fun to play, even though it worked well mechanically. The difficulty of the first level was also too high and it took to much time to complete. This brings me to the latest update and the state the game is in now so let me summarize the feature list:

Level 0 - just a few enemies and destructible pillars to familiarize players with the mechanics of the game

HP - the player character can be hit twice before dying. HP is restored after each level and there are also pickups that restore HP during play

Score - each enemy is worth some points giving the players incentive to play more and beat their best result

Help screen with all the information needed for players to understand how to play

Level 0 and all the latest features

What's next?

I already have more ideas for improving the game. Some of them are really superficial, such as storing the high score between gameplay sessions to incentivise players to try to beat their best result. Others will require me to go deeper into the code. What I want to do next is add the possibility of setting up specific level layout. Currently, the levels are procedurally generated. This is cool because the game is different each time, but I also want to be able to design my own levels too. This is a requirement for a bigger feature which is... bosses! Playing bigger and bigger levels can only be interesting for a while. A more dedicated challenges, such as big enemies with more advanced movement and combat capabilities will breath some fresh air into the gameplay experience every few levels.

I'm always looking for more ideas and inspirations. I'm treating this game as a learning tool so nothing is out of the question. I want to understand how Unity works and how things should be done properly and not only as hacks that might work but there might be better ways to implement them (*cough* UI *cough*). If you would like to help me on my journey into gamedev, I would welcome all comments, ideas, concerns and wishes. You are free to check the game out on itch.io either in the browser or as a standalone Linux or Windows executable. Thank you for reading and I hope to get back to you soon with more updates!

(Click the image to play the game)

]]>
I hope 2019 has been good so far. I have been busy with the game and the progress is slow again. A lot of bugs and problems appear from nowhere and I started fixing one by one.

So far all the systems that i wanted before I started…]]>Mon, 21 Jan 2019 12:06:51 +0000Hello everyone,

I hope 2019 has been good so far. I have been busy with the game and the progress is slow again. A lot of bugs and problems appear from nowhere and I started fixing one by one.

So far all the systems that i wanted before I started putting more content like more different enemies, more challenging bosses , more levels and maybe different ships.

So far I have Quest System implemented. Where the players will get a 3 random quests to complete to earn XP and Coins. Players need to complete all to get new right now.( Maybe in the future I can have the option to skip or get new one when they finish one.)

Next I have implemented the Upgrade shop where the player spends coins to improve his/her ship. Right now I have few upgrades maybe in the future I can add more.

Next on the list I made the Level selection , I might change it in the future but for now It fine. Each level will have a range of level. Enemies in Level 1 will be level 2-3 for example. So if Player needs to continue he should level up first otherwise he will have a tough time. It is a progression that I thought it will be nice to have.

Next each Level will have challenges for the player. He doesn't have to complete all of them to continue he only needs to finish it once to unlock the next. Each of this challenges are there for people to give some replayability.

Also I finished the first draft for the option menu.

Here you can lower or increase the volume. Mute the audio, enable or disable the auto fire. And finally customize the distance of the ship from the finger.

Last but not least the game includes a boss Battle system although right now the boss is very easy and not challenging. I am trying to focus on polishing the existing systems before adding more enemies and more challenging bosses.

Also the first playable build is out and few people played it. Thank you for all the feedback i will start give the build around more to get some more feedback and improve the game better.

That is all for this week.

]]>
I have just released the latest build of my tech-demo for Legends of Mythology and the second development vlog.

To get the latest version of the game, join the swalk studios discord and take a look in the #dev-updates channel! Simply follow this discord link to join: https://discord.gg/XnXzDgK

]]>
1. I am starting to think the mini map is redundant for this level, this level is too…]]>Sun, 20 Jan 2019 16:03:34 +0000Have been busy with a lot of personal stuff, it took a bit longer to complete all my goals I set out in devlog #5. So let's see where we stand in Patient Zero.5:

1. I am starting to think the mini map is redundant for this level, this level is too small to have a mini map be any use for it. But I did implement a map, which appear when you pick up the map in the corridor. Use "m" to activate the map. There is still a lot of things I can do with this map ... let me think on it.

2. I implemented a new "flashlight texture" and to make the flashlight a bit more realistic, I gave it a small "offset", the flashlight trying to catch up where you look.

3. The freezer door code panel is working and the freezer door has its own animation with sound effect ... still thinking about creating a small cutscene where the door opens.

Also noticed I moved slower in the room, need to take a look at the "mist" particle system.

4. Decorated "cold room" and the end corridor - the "ragdolls" will later be replaced with proper dead characters.

5. Some nitty gritty stuff - the seam of a corner wall wasn't meeting properly, corrected that. Locked the cursor in the beginning of the game.

Please be advised "01234" will NOT be the code for the freezer door panel and you will have to put in more effort to find the code

My goal/s for next time:

1. Several people suggested that the pickup objects needs something like a glow to make them more noticeable, will be working on a solution for that.

2. Will be working on "My Horrible Collection", our first item, a bloody eyeball.

3. Pause Menu needs attention to get it in a more of a working state.

Thank you for reading, have a good week ahead. Romi

]]>Crumbling World. After playing through the game myself, it dawned on me that the movement mechanics for the player’s character were a bit too basic for my taste. Soon…]]>Tue, 15 Jan 2019 18:32:33 +0000Since the last update, I have been working on the Jump and Grab Edge System for Crumbling World. After playing through the game myself, it dawned on me that the movement mechanics for the player’s character were a bit too basic for my taste. Soon after I figured this out, I decided to rework these movement mechanics, as I thought it would be great to add a bit more complexity to each of the levels to break up the flatness of the game and add a bit more diversity to its gameplay along the way.

Jump and Grab Edge System

To add some additional geographical variety and depth to the levels, I added the jump system, as I wanted players to notice the randomness of the procedural level generation process even more. For example, within The Dark Forest level, I opted to add waterfalls and other natural elements, which both add more graphical variety to the game’s design and allows for the introduction of the Jump System to new players.

In the coming weeks, I am planning to add more exciting jump elements that will be specific to each level. Players will be allowed to jump only when they find themselves at an edge, so they won’t be able to jump across flat surfaces. I hope that this difference will not be too confusing for players and that it will be something they understand intuitively after playing through the game. As is the case with many classic platform games, if players fail to reach the other edge their character will die – but there is no need to fear, as I have added a chance for players to grab the edge even if they fail to jump across the gap successfully.

The Grab Edge System

As I have alluded to in the past, Crumbling World has many different sources of inspiration, with one of them being the classic Prince of Persia game first released in 1989. I have always been a huge fan of these classic platform games and wanted to include some ingredients from the original Prince of Persia in my game – one of which is the Grab Edge System. The Grab Edge System allows players the opportunity to save themselves after failing to reach the opposite edge during a jump. At first, I thought that this would be a purely aesthetic feature, but I soon realized that it was much more involved.

From animations to coding, it was clear that adding the Grab Edge System would demand some serious attention. I spent just over a week to develop and refine this feature. In its current form, the system works with different colliders and calculates the position of the player. This means that when a player fails their jump and collides with the edge, the system will automatically trigger the animation, allowing a player’s character to climb the edge. While this sounds simple enough, in theory, it was pretty tricky to implement in practice.

For Crumbling World, this system continued to become more and more complicated as the player’s controller currently uses both root animation and coded movements, depending on the animation. So, while the jump animation is managed by code I’ve written, the root animation manages the climbing animation. This led to a pretty demanding technical challenge, as seamlessly switching between these modes to achieve the successful effect of climbing the edge was difficult. When I was finally satisfied with the way that the effect was working, I realized that it looked bizarre, as the player was climbing with weapons in his/her hands, which is nearly impossible to do in real life. To fix this issue, I decided to create a system that would store a player’s weapons during the jumping and climbing process, which in turn allowed for the climbing animation to look far more natural.

The Breakable System

After developing the Jump and Grab System, with my inspiration from the classic Prince of Persia game remaining, I decided that it would be fun to add ground elements that will break when a player steps on them. Due to the fragile nature of these ground elements, I decided to call this feature the Breakable System.

In practice, it works in a way that is very similar to the Jump System. Players can jump over these elements, but if they step on them, the ground will quickly break, and the player may fall off the map. If this happens close to an edge, then players can grab the edge to save themselves, but if players are too far away, then their character will fall to their doom. I believe that this introduces more variety to the game and makes it more fun at the same time – as quick-thinking players can also use the Breakable System to eliminate enemies they encounter throughout the game.

Using the Breakable System to get rid of enemies.

That’s all for this Crumbling World update. I’m looking forward to starting 2019 strong and look forward to sharing my progress with you soon. As always, thanks for reading! More importantly, don’t forget to sign up here to join the exclusive Beta Test before it closes!

]]>Mon, 14 Jan 2019 16:54:47 +0000So I finally got a few friends together for a weekend Game Jam on itch.io this past weekend. Ultimately I'm happy that we were able to create a playable game. I could have finished the game myself, but I always want to get others involved to see if we could make a team for larger projects. I used to get my friends together for what we called Code Days to keep them motivated to work on their own projects and to also do exercises to better our skills. This is the first game my friends and I completed as a group. I headed the brainstorming phase and tried to keep anyone on track. I had to say no to a lot of things they wanted to add. I'm a professional developer. I know many times things don't go as plan and will rarely be what you imagined. I have a good grip on my friends capabilities as programmers and their Unity familiarity so I knew the things they wanted to do weren't going to happen.

One teammate likes to find existing projects and rip out only what they need. I am a fan of not reinventing the wheel myself, but he has very little experience in Unity. Starting from a basic tutorial and working from the ground up would have been faster than trying to figure out how a project full of things we don't need works. He was responsible for obstacles and the boss fight. He didn't get to the boss fight.

Another teammate doesn't know how to keep things simple and ends up doing way more than is required for the project. It makes him slow at producing a finished product and it wasted my time as the project compiler because I'm ripping out unnecessary functionality, but at least he was better at using Unity and effectively completely all his tasks for player movement.

The last teammate wants to be a game developer so bad, so I try to get him involved. However, he has little basic knowledge of programming not just syntactical, but also like mentally. He cannot perform the process of thinking how about how he wants something to work and then putting it into code. He has made a few games, but he makes heavy use of things like blueprints and prefabs and his programming knowledge is like 'make 5 variables for a list of 5 things instead of making 1 array to hold said things'. He wants to be programmer, but won't take the time to learn the basics. He did not finish the user input Simon says like mechanic. I had to implement something simple like clicking real fast to fill in that portion of the game.

I left myself to pick up anything they couldn't do and compile their parts into one game. I was also responsible for UI and game visuals like infinitely scrolling background. My work load was mostly helping my friends out when they were stuck and pointing them in the right direction, and also just keeping them focused. I drew most of the art in paint.net and found and modified other art. The music for the game we also found. I was the last one awake last night recompiling and testing and recompiling and testing. Getting the UI Canvas to look right outside the game editor is always a hassle for me.

I have the most experience with Unity, but I'm by far no expert. I learned some more tips and tricks to implement in my future projects from working on this one. But enough of my typing, here's what you've been waiting for, right?

Why should I do it?

Ensure your setup!

Have you ever had the problem that your prefabs lost their references? May due to some…]]>Sun, 13 Jan 2019 17:27:48 +0000This article is about prefab testing. I started using it for my game Industry City and really can recommend it to everyone.

Why should I do it?

Ensure your setup!

Have you ever had the problem that your prefabs lost their references? May due to some renaming? Well: I did and still do. It is something that happens rarely but periodicaly - specially after I've done some refactoring. But of course not all prefabs are affected. Sometimes there are just one or two. If they're frequently used then no problem. You will notice it immediatly. But the bigger your project the higher the chance that you'll release a bug. And even worse: you won't always remember the how the correct settings of them were!

No Scene required

Another reason is: you can make sure that your prefab is working correctly way before you use it in any scene. I first write all my tests before placing it in my scene. Of course I've to test them manually again later on (to ensure that I've forgotten nothing) - but the main basic core functionality is working perfectly fine ;-). This also have the benefit that the code for your prefab can be finished faster. Let's take a context menu as an example. In your Scene you first need several things being ready to provide a context menu. E.g. a raycaster to find the component you'd like to show the context menu for. If you trigger chances only on Property-Updates (I will show you later in code) then the context menu will become really hard to become implemented.

Solving a bug forever!

Think of the following scenario: You find a bug. You solve the bug. What will prevent the bug from appearing again? Imagine the bug was a missing check. Now you refactor the class after a couple of months again and forgot to implement that check again. May because that check isn't obvious. The only thing which can help here is having a proper test!

So let's have a look how a test will help you here. Right before you solve the given bug you try to reproduce it by a test. Because the bug is still there the test will fail during the first run (great - that's how it should be). Now you are takling the bug. You know your bug is fixed when your test is green. So you can fix it without even starting your game a single time. But of course you also should varify afterwards that the bug is gone by trying to reproduce it within your game. Like in scenario before we now travel in time a couple of months in the future. You refactor your code, you forgot that one important check and .... BOOOM. At least one of your tests will fail. Now you are aware again of that bug and you will fix it.

But there is also another benefit. Some bugs are really hard to reproduce. May due to time intensive steps to reproduce or because they need special setups or both. So having a test for the bug will really speed up your development.

What do I need for writing those tests?

Your code in an own assembly

Therefor just create a folder in Unity3D and give it a name (which will also be the name of your assembly). Next you will Do a rightclick on that folder and select Create > Assembly Definition.

If you want to know more about assembly, you can have a look here: Using assemblies .

Test assembly

You also need a test assembly (I'd recommend Play Mode test). Unity will be happy to create that folder for you. Just do the following steps:

1. Opening the Test Runner Window (Window -> General -> Test Runner)

2. Select a parent folder in your Project View

3. in the Test Runner Window select Play Mode and click on the Create PlayMode Test Assembly Folder Button

Unity has created an empty Test-Folder with an asmdef-File inside. Now click on this file and add your game-assembly as a reference to the section: Assembly Definition References. I've named my game assembly Logic and so for me it looks like this:

Inside that folder create a script called PrefabLoader and store the following code inside:

public static class: Because we don't want to allow creating instances of that class it is defined as a static class.

Load<T>-Method: This method is looking up your Asset on a given path you'd provide as a parameter. Because you don't want to have the original asset you create a copy of it (Object.Instantiate(...)). And finally you'll get back an instance of your prefab.

ScriptableObject<T>-Method: Actually this method differs only in a few details from the Load-Methods. First of all it is only meant to be used for ScriptableObjects and the second change is that it is not creating a copy. It will return the original asset. But here you've to be aware of the following: Changing anything in the returned value will affect your original ScriptableObject! My intention to write this method was for using ScriptableObjects which are more or less used as an alternative to enums. Therefor I need the original reference.

I've moved those two methods into its own class because I've multiple classes for loading my prefabs. And with this helper-class I don't have to rewrite the same code again (even if it's short).

Creating our prefab

When I say: creating our prefab I only mean the non-code-part. To have it a little bit "cool" I want to create some traffic lights:

I simplified it down to use only one material for everything. Of that material we later can easily change the colors. So the basic traffic light looks like this:

Creating some Scripts and Folders

Starting with the base component

First of all we need our script for the traffic lights. I call it TrafficLight and attach it to the root object of my prefab. In the end this component will be the one we're requiring for integration test. Of course you already can start providing some fields, getters and setters. But only things that are required for your test. So my first setup of the class would look like this:

Code

public class TrafficLight : MonoBehaviour {

[SerializeField] private TrafficLightStates state;

[SerializeField] private Color defaultColor;

[Header("Red light")]

[SerializeField] private Color redColor;

[SerializeField] private MeshRenderer redLight;

[Header("Yellow light")]

[SerializeField] private Color yellowColor;

[SerializeField] private MeshRenderer yellowLight;

[Header("Green light")]

[SerializeField] private Color greenColor;

[SerializeField] private MeshRenderer greenLight;

public TrafficLightStates State {

get => state;

set => state = value;

}

public Color DefaultColor => defaultColor;

public Color RedColor => redColor;

public Material RedLight => redLight.material;

public Color YellowColor => yellowColor;

public Material YellowLight => yellowLight.material;

public Color GreenColor => greenColor;

public Material GreenLight => greenLight.material;

}

Display More

So I'm able to request everything from within the test. Because I don't want other classes to be able to set other Materials/Meshrenderer those fields aren't providing a setter method. I also don't have any Unity-Life-Cycle methods so far her, because I won't need them. Those traffic lights should only change in case when the state is changed. And this I can notice during a setter-call.

As you may already noticed: my state is also something custom. It is a enum:

Code

public enum TrafficLightStates {

Stop,

TurnToGreen,

Drive,

SlowDown

}

So far so good. Now we can start writting our tests.

Some words about structuring

It is good practise to have in your test folde a similar folder-structur like in your acutal code. In my case I have everything placed within the folder Traffic Light. So I'll also place my tests related to the traffic light in a folder named the same:

Creating our test

Now I will create a TrafficLightFixtures class. This also will be a static class making use of our PrefabLoader:

Btw: It is really easy to get the path to your prefab. Just do a right click on it and select Copy Path. Or remember the shortcut CTRL+ALT+C.

Now we want to create our test. Therefor we need a new class and we call it TrafficLightIt. The It stands for "Integration Test". For this article I will only set up a few tests so that you get what you would be able to ensure with integration testing:

Tests to ensure that the prefab was set up correctly (like if the MeshRenderer are present. Think of the intro of this article - that could be broken!)

Tests for the default state: If we place a traffic light then we always want it to be in a defined state (like having stop lights).

Tests for the logical part: what happens if we change the state to something new.

The results of the tests are the following:

Our default-state is how we want it to be. Now let's tackle the logic. I will update the setter and add some more methods to our component:

Code

public TrafficLightStates State {

get => state;

set {

state = value;

UpdateMaterials();

}

}

private void Start() {

UpdateMaterials();

}

private void UpdateMaterials() {

switch (State) {

case TrafficLightStates.Stop:

SetLights(true, false, false);

return;

case TrafficLightStates.Drive:

SetLights(false, false, true);

return;

case TrafficLightStates.SlowDown:

SetLights(false, true, false);

return;

case TrafficLightStates.TurnToGreen:

SetLights(true, true, false);

return;

default:

Debug.LogError("Something went wrong here...");

return;

}

}

private void SetLights(bool red, bool yellow, bool green) {

redLight.material.color = red ? redColor : defaultColor;

yellowLight.material.color = yellow ? yellowColor : defaultColor;

greenLight.material.color = green ? greenColor : defaultColor;

}

Display More

With this code everything except for one test is green. This is about that our red light is turned on and everything is off. But if we hit play-button we can see that it actually is correct:

The problem is that the code in our Start-Method is never invoked in our test. But we can fix this very easily. Therefore we've to change our SetUp-Method to the following:

Code

[UnitySetUp]

public IEnumerator SetUp() {

TrafficLight = TrafficLightFixtures.CreateTrafficLights();

yield return null;

}

The important changes here are:

[SetUp] -> [UnitySetUp]

Returntype void -> IEnumerator

That will enable the Unity-Lifecycle-Methods being called within the SetUp-Method. With IEnumerator as return-type you've to provide at least one yield return. At this point our Start-Method is being called.

Now all our tests are green. Concratulations

]]>My girlfriend is a physicist and today she told me she loved me to the moon and backShe then proceeded to inform me that love is a vector.

This will be a short post but comes after I faced what was the hardest problem I have ran into in Unity to…]]>Thu, 10 Jan 2019 22:32:48 +0000My girlfriend is a physicist and today she told me she loved me to the moon and back

She then proceeded to inform me that love is a vector.

This will be a short post but comes after I faced what was the hardest problem I have ran into in Unity to date.

But this post is not about that problem (that will be in a future post). This post is about what helped me solve the problem: Vectors.

When you start coding in Unity and need to position and object you quickly learn to use a Vector3 (or Vector2 without the z) and it is quickly apparent that a Vector is 3 points x, y and z representing the point in space you want your object. But if you are like me you begin to wonder why is it called Vector3 and not Point3 after all you are using it to position an object at a point in space.

The answer goes back to what a Vector is. Don't worry I will provide some helpful links after I am done rambling! Basically a vector has two components direction and magnitude. In other words which angle is the vector pointing to and how long the vector is. But then how can you represent it using only three components x, y and z?

For most situation we encounter it turns out setting one end of the Vector to 0,0,0 works just as well as setting it to a position away from the origin. The vector (0,0,0 to 1,1,1) is the same as (1,1,1 to 2,2,2) but in the first case we only have to store 3 bits of information not 6. There are apps online or drawing vectors on graph paper can let you see this visually.

Because vectors can convoy direction as well as magnitude they are useful for a wide array of things such as finding out where an enemy is in relation to the player, determining the forward velocity of a car while in a skid, adding force to objects and more.

Two pages were useful for me when I was trying to learn more about Vectors in game design:

The first is Unity's own page explaining Vector math in games and the second describing what a dot product is and why you should use it (Spoiler: It's faster then most other vector operations!)

At the end this post is only a brief of brief mention of Vectors and hopefully encourages you to learn more about them. They will arise in many situations in game development and understanding vectors will explain to you why we use Vector3 instead of Point3 to position objects.

In the end 20+ hours of frustration and trial was solved with ONE line of code doing a dot product between two vectors. More on that in the future.

]]>Wed, 09 Jan 2019 20:53:12 +0000Wow a week has gone by fast! From my last blog to now a lot has happened and throughout this week, this week's lesson was how to roll with the punches. Updating Unity to 3.0 was an interesting adventure but love the new features. Unity HUB decided it was going to throw a tantrum throwing every error possible. After many attempts to rollback, reinstall unity 3.0, deleting library, and deleting the cache. I came to conclude unity hub was the enemy so it had to be DELETED. Now I got unity back to working, I have come to appreciate one of the assets I learned; backing up your project and version control. Even when unity was throwing its tantrums I knew my beloved Warforce Empire was safe :). So now that tid bit is out of my system, we can talk about my project and the latest update. Creating the enemy base was the simple part, I enjoyed putting it together and building it up. The talented artist team I am using made modular parts so you can really put your own originality in it. The AI logic on the other hand was the challenge for me. I learned a couple algorithms to use A* and Breadth First from the courses I took but decided for this game I would explore unity's built in Nav. It was quite easy to use. Everything was built in, just bake, add the agents and call the functions basically. I still have some finesse to do and fine tune the behavior of the enemies I want but its at a good prototype level. Another lesson I learned this week is prototype first to get the basics down then you can fine tune otherwise frustration and no early debugging leads to more frustration. I finished the player buildings with particle effects for when they "explode". I wish I could have got more done this week but I guess in retrospect I did do a lot. Learning how to fix unity editor, balancing life and development, taking time to be creative, and slowly working out the coding logic without anyone to hold my hand. <----- That last bit is a huge accomplishment for me. Thank you to GameDev courses for instilling me with writing out what I want to do in pseudo than working through it visually helps a lot oh and my new best friend (the scripting api).

Next weeks goals are finish the behavior on the enemies, create the UIs for each building, get the build drag and drop logic to work, finish landscape and trees, fix the sky box so it can look more like its actually nighttime and some kind of boundary that looks appealing(right now it looks like a flat plane you roll off the earth) , get the supply ui to work and update, get the camera to work (screen scrolling on edge and pinch to zoom in/out).

Until I write again, get coding, get creative, get your game on, and roll with those punches

]]>Tue, 08 Jan 2019 17:37:06 +0000I want to take a few moments to share my thoughts on the importance of a strong background story in video game design. After joining and attending a couple of different game development groups, I have noticed how many of us struggle to put our ideas into context during the prototyping phase of a game’s creation.

Prototyping Our Games

Regardless of your background, we all follow different processes throughout the creation of a game. Some of us like to start with the creation of innovative new game mechanics or graphics styles, while others like to take original ideas and mix them with the best features of different genres.

The main struggle that I have noticed is that even if a great prototype is created that uses both stunning visuals and mechanics, it can be difficult to develop it into a full game without an underlying story. Regardless of the size or type of video game that you’re creating, even if it’s an entry for a Game Jam, a strong and well-developed background story can help it stand out from the pack.

Furthermore, when prototyping a game, it can help to ask yourself questions such as:

What are the goals of my game? Who is our main character, and what is their background story? What enemies will players face and why are they considered enemies?

Most of all, it is important to make your main character relatable, as the most enjoyable games ensure that players can relate to the main characters in some way.

Overall, our games need a context that makes sense and allows for all of the needed pieces to come together to form a cohesive experience. The more cohesive the experience, the stronger and more appealing the game will seem to potential players. While your storyline can be straightforward – you don’t need to be writing a novel after all – the underlying connections between the game elements and storyline need to make sense.

For example, let’s say that we are prototyping a level for a classic platform game, where the player starts at point A and needs to get to point B. During this journey, players will encounter many different enemies that seek to kill the player when they enter their range of vision. To combat these attacks, players have access to different skills such as climbing walls, double jumping, and fighting back with power-ups.

As our level is built entirely using cubes, and all of our mechanics work perfectly and feel great, we as designers may think that we have made a perfect gameplay experience. However, without proper insight, it is easy for developers to wonder:

Where are we going from here? How do we allow the main character to more powerful in this game? What is this game about, and why do we need the player to reach point B? Why are these enemies trying to kill the player, and what made them enemies in the first place?

The background story is quite possibly more important for the developer’s guidance than for player’s enjoyment, as it allows us to keep developing the game even when we run into questions or doubts like these.

If we can create a storyline that provides reliable answers to all of these questions, then our players will feel more rooted in the game’s world. This will not only make the game feel like a more in-depth experience but will allow them to focus on achieving their goals and objectives while enjoying the game.

The Basic Story

As a guide, let’s work on developing an insightful short story for our game prototype. For this example, our game will be an action platformer where players need to avoid enemies – specifically, players will be controlling a soldier who is sneaking into an enemy base with the goal of recovering a powerful weapon that was recently stolen. The enemies within this game will consist mostly of drones, which can detect players if their movements are not correctly hidden.

To give the game more depth, we can take this basic story and make it even more interesting if we push our imaginations to the limit. Let’s take our initial story about the soldier and modify it a bit with some historical or fantasy elements. Instead of infiltrating a modern military base, players will be working their way through a set of old temple ruins set in the medieval Japanese countryside. This setting works out well, as it fits our level mechanics and will bring exciting concepts to our level designs. Players will need to be able to sneak and have skills like climbing or double jumping, so a ninja concept seems like the best fit for our setting.

We’ve successfully defined our setting and player skills, so it is now time to define the player’s character in greater detail. As a ninja in medieval Japan, he belongs to a secret faction, who has tasked him with the recovery of an ancient and powerful weapon that has the potential to instantaneously destroy the world if it falls into the wrong hands. This puts a novel twist on a classic story and allows us to build out the goal of the game with a clear context.

The enemy drones that we discussed previously can now become Undead Dark Creatures, risen from Hell with only the mission of protecting this powerful ancient weapon in mind. Instead of having motion detection abilities, these enemies will be able to attack when a player’s ninja character enters their field of view. As you can see, once we have defined the basic storyline it becomes far easier to assign behaviors and attack mechanics to both friendly and enemy characters.

In a sense, a game’s storyline is a bit like a glue that helps game designers put all of the pieces of their prototype concept together. Having a basic story in place not only helps to keep designers focused during the prototyping phase, but more importantly establishes a strong foundation for future development of enemy and level mechanics. Defining a basic story allows us to start building a new world that can continually grow in complexity, features, and goals as the development process continues to move forward.

On the other hand, it is vital that we as game designers do not underestimate the power of a good background story. Creating innovative game design techniques continues to become more and more difficult as hundreds of new games are released every year. Soon, a quality story may be the only thing that allows your creations to differentiate themselves from the dozens of other games that use similar game mechanics.

When Should We Develop The Basic Story?

Speaking from personal experience, the basic story should start being developed at the very start of your game design process. This doesn’t mean that you can’t opt to create a story based around an innovative new game mechanic, but it does mean that you should be able to outline the basic storyline before creating your initial prototype. Whenever I get a new idea, I can’t wait to get started, yet trial and error has taught me that sometimes writing a brief game design document (GDD) can pay dividends in the long run when it comes to working through roadblocks and difficulties. Without a GDD to refer back to, it can be very easy to give up and abandon a prototype before it has even really started, as we don’t have access to a greater vision for what we would like to see in our finished product.

These prototypes can be very basic – even using just cubes to see how a game feels can provide great insight into a concept. However, if you are working on a prototype to get funding or get a better understanding of just what a game can be, it is probably a good idea to put some real effort into your creation. To get started, I highly recommend watching this video about fast game design from Gameloft, as they have tons of great insight into the process.

I hope that this guide was helpful and serves as encouragement for you as you work towards writing and planning out your stories before diving into the more exciting yet challenging phases of game development.

]]>

What is an Exception?

An exception shoudl be thrown in case…]]>Sun, 06 Jan 2019 16:57:44 +0000In this article I'd like to tell you something about exception handling and a way how you can solve the problem of a missing global exception handler. But let me first give you an introduction.

What is an Exception?

An exception shoudl be thrown in case when your code runs into a problem and can not handle it by itself. As an example think of a method which is parsing a json-file and returns it as an object. Your workflow looks like that:

1. Find the file

2. Read the content of the file

3. Parse the file

4. Create the new object

5. Write the data to the newly created object

6. Return the object

But now something is wrong with the file. Let's say: it isn't there. So your workflow is broken and the parser isn't able to handle it on its own. That means that the parser should throw an exception and somewhere up in your hierachy one should catch it. But only in case when you really can handle the exception there.

How to NOT handle an Exception?

I often saw it that devs are using exception as a part of their workflow (so like you would use an if, switch, whatever...). If everything is fine go this way if an exception is thrown go that way. HELL NO! Don't do this! When an exception occurs that means: Your workflow ends HERE!

Also don't just catch any exception. Only catch the exceptions you want/can handle. You prefer that your game crashes instead of having an unexpected internal state which can completly mess up everything.

How to handle an Exception

The important thing is that you only catch an exception in case when you are able to handle it. Handling does not always mean something complex. In some cases it is only about logging. Sometimes handling means to start a new workflow. Think of the following scenario:

Workflow A

1. You want to send a request to a server.

2. You get a ServerConnectionException.

3.1 Log the Exception

3.2 Start Workflow B.

(Without the exception this workflow would have send the request and would do something with the respond of the server)

Workflow B

1. You try to do a reconnect to the server.

2. Reconnection was successfull.

This would be a self healing system. After Workflow B has finished the app could retry Workflow A again.

Global Exception Handler

I actually was looking for something like that. A global exception handler should be the latest place where I'd be able to catch exceptions and react on them before they make my game crash. In my case I wanted my GameManager to register to it. So that it can watch out for a given Exception which is only thrown during loading in case when one of the data-files where messed up or missing. If an exception is thrown I want to force a recreation of all those files.

To keep a long story short: There is none or I wasn't able to find it.

How I handled it

Actually it wasn't that complicated to get it working also without a global exception handler. The first thing I'd to archieve that I've a centralized place from which I trigger the loading of the game (which is my GameManager). Because I try to avoid hardcoded stuff I was using UnityEvents to keep things flexible. Let me show you with a code example.

Creating my own base exception

I like to have one base exception from which every of my other exceptions are inheriting from. That would look like that:

And next I want to have my specific exception which is thrown in case when there went something wrong during the loading:

Code

public class LoadException : MyGameException {

}

For this article it is enought to only have an own exception. Of course you could provide more constructors or information to the given exception if you want. But for now we will stay with the implicit default constructor.

Preparing our GameManager

I've created a new one for that article and here it is:

Code

public class GameManager : MonoBehaviour {

[Header("Events")]

[SerializeField] private UnityEvent onSetup;

[SerializeField] private UnityEvent onInstall;

private void Start() {

try {

onSetup.Invoke();

} catch (LoadException) {

Debug.Log("Could not load files. Trigger re-creation");

onInstall.Invoke();

}

}

}

Display More

Very simple as you can see. We just provide two events: One for loading and one for installing our files. The inspector will look like this:

That's all for our gameManager. For those who haven't used UnityEvents: they are really awesome! And I will now show you why :-).

Creating a class which is loading / installing files

I will call this "CityManager". In my game the CityManager is taking care about the map and also about loading/creating it. Here is someting "similar" :-P:

Code

public class CityManager : MonoBehaviour {

private readonly string _mapFile = "my-map-file.bin";

public void LoadMap() {

if (!File.Exists(_mapFile)) {

throw new LoadException();

}

// Code to load the map

}

public void CreateNewMap() {

Debug.Log("Creating new map");

// Code to create the map

}

}

Display More

So here is some small code snippet which is runnable and probabbly will always fail (which is totally fine for that article). The only thing which is now left to do is to register those methods to our events. Because we are using UnityEvents we're able to do this without writing any single line of code :-).

Register our Events

My current scene looks like this:

And as you can see: there are my two gameobjects and both have their manager-components attached to them. Let's select the GameManager and click on the (+) of both events. It now should look like this:

Now drag and drop the CityManager to slot on the bottom left. Do this for both events. If you've done it right your it now should be the same like this:

On the bottom left you now can see the CityManager-GameObject and on the top right the dropdown says that now function has been selected. We will change this now. Click on the dropdown and select CityManager -> LoadMap for the first one and CityManager-> CreateNewMap for the second one:

When I now run the whole thing the console has the following output:

In my opinion this is a really nice way of solving that problem. We load the game and in case of an exception (file not there, file corrupted, ...) we are able to react on it. Also we're highly flexible because the loading code is not hardcoded within the GameManager - but is triggered by it.

Also we've a proper ExceptionHandling. As soon as one component is running into trouble by loading the game the whole workflow will become interrupted and we start the "selfhealing".

Last words: For those of you who are new to UnityEvents: I really can recommend you to use them. They give you all the benefits of the C#-event-system + the ability to use the inspector.

]]>
1. The infection-thirst-hunger system is up and running, food-, water bottle- and syringe pick ups can be used to…]]>Sun, 06 Jan 2019 10:44:58 +0000I took a 2 week break from Patient Zero.5, but are in full designing and creating mode again. I got a lot done in the past few days.

1. The infection-thirst-hunger system is up and running, food-, water bottle- and syringe pick ups can be used to lessen the effects of hunger, thirst and infection.

2. Meet our first living NPC, Jack Peterson. Created some dialogue between Jack and Jane, this in turn created an objective to be completed.

3. The beginning of a mini-map system is being put in place.

4. Added sound effects for our "zombie" creature (growls and death sound) and rat monster (hiss and death sound).

5. Decorated the place with more dead bodies, fallen beams, wires, bricks and blood decals,

6. Tweaked the lightning and dimmed it. Now your flash light can do its proper job - light your way in the darkness.

7. Finally, I have experimented with Post Processing, hope your guys see it, Not a huge fan of a lot of bloom. It hurts my eyes.

What I will be working on for the next week:

1. The mini-map system.

2. The code system on the "Freezer" door and door animation.

3. Decorating the "Freezer" ( not what you think, I promise.)

4. More dialogue.

5. Playing around more with the lightning and Post Processing.

Thank you for reading and may 2019 be a wonderful year for all of us.

]]>Thu, 03 Jan 2019 16:09:05 +0000Hello everyone ! I hope you had a nice new year eve and happy holidays. I did not do much work over those weeks but I wanted to share the little I have done. I did worked on the UI systems and Mechanics and I step into some weird performance issues with the UI specific and I had to rebuild the UI again few times.

The past few weeks I mostly Worked on Optimize the game for Mobile. I am not so familiar with 3D and Mobile so I had to do a lot of research and play around with the settings to achieve optimal visual and performance. Some of the optimizations I did are:

-I added implemented Object pooling for all the GameObjects in the game like Projectiles , Explosions etc. To increase the performance on Mobile.

-Made many lighting static and baked the Lightning instead of Real Time.

-Removed Skybox and made color instead.

There are few issues with the Upgrades and Missions Screen lags the game for 5 sec when you first enter but then it working good.

When all the systems and mechanics work as intended I will continue added new enemy types and missions.

That is all for now.

]]>"Just code it"

I forget who exactly said this during a game jam last year after I made about a certain shoe company slogan. But the message is very clear; stop talking about your ideas and try to actually create them. And just talking about ideas was a…]]>Wed, 02 Jan 2019 03:59:31 +0000"Just code it"

I forget who exactly said this during a game jam last year after I made about a certain shoe company slogan. But the message is very clear; stop talking about your ideas and try to actually create them. And just talking about ideas was a great description of myself before last year. I have to give full credit to Ryann who for weeks discussed game design with me at work while she entered and actively worked on game jams. I can only assume finally having heard me talk too much she gifts me Jon's first course under the condition that I entered my own game in the next game jam.

The day finally came and the theme came out "End of time". I love escape rooms and I had wanted to build an escape room game so this theme fit perfectly. And finally I "Just coded it".

Two and a half weeks, many hours and keyboard pounding later I had my first real game since I coded Connect 4 in university : Reboot Time. And beyond what I thought was possible I won that game jam. To say I was shocked was an understatement. And even better when friends and family tried my game they enjoyed it. Yes it was short (except for Jon's time but he had Ryan to help him out) but it was a complete game.

Since that time I have started on a larger, more involved project relating to this initial project. I do plan to write more about the project and about particular challenges I have encountered and solved. Scaling up has been a challenge, learning new concepts has been a challenge.

But when I do get stuck or end thrashing on an idea and not moving forward I try to think back to the success I had. And then do what I was told:

Just code it.

]]>
Lately I've been struggling to find any motivation to do anything. I have a few projects that need to get finished but no drive to hop on. I suggested writing it…]]>Tue, 01 Jan 2019 23:03:44 +0000Going out with life gets tougher each week, but going through is the important part Huh?

Lately I've been struggling to find any motivation to do anything. I have a few projects that need to get finished but no drive to hop on. I suggested writing it out would help, so now I have to make it roll from here. What have you guys been dealing with lately going into 2019. Let's build each other up!

]]>Tue, 01 Jan 2019 17:24:22 +0000Back around June of this (last) year I dropped out of the (then) monthly game jam with the theme "Connection". I had decided I wanted to go a match-3 style game but after a few days realized that I'd bitten off more than I could chew (at least for a 2 week game jam). I still liked my concept though and decided I wanted to follow it through all the way to publishing as a sort of test case for the process.

I'm a big fan of science fiction and am particularly inspired by the series The Expanse. I came up with the theme of the player working for an Asteroid Mining company based on Ceres. Basically you travel from Asteroid to Asteroid (levels) mining ores and other materials. I wish I could take all the credit and say I developed this all on my own but truthfully I picked up Wilmer's Match-3 game course on Udemy and have spent the last 6 months working though it here and there when I had a free few minutes. I've now reached the point where the basic match-3 game play is done and I can start customizing and creating levels and building it out.

Here is the basic game play function:

I'm working now on customizing the icons - what you see here is the 3rd or 4th iteration. I had started naming my spites by their resource names, so aluminium, bronze, gold, platinum etc. The problem is that most metals are pretty much the same color. Or at least similar enough that I was having trouble telling the difference between pieces. So for now its ended up with a rainbow (albeit muted) color palate. The alternative would be to have similar colors but also alter shapes - fully expect to overhaul this a few times before its done.

I'm also thinking about adding a 3D component creating an asteroid field then using a Cinemachine cut scene to dispatch the player to the next level.

I'll keep you all posted as I continue to build it out!

Happy New Year all!

]]>Mon, 31 Dec 2018 23:08:24 +0000Going public is my first fear to get over. Always been shy and critical of myself. But I guess thats why I love games so much and why I want to develop games. Games brings people out of their shell. Explore new worlds, bring on an adventure, re live 8-bit days, meet other players, and just release themselves from a tireless real world day. I have made casual games but I wanted to challenge myself with something big. My supportive husband bought an art asset for me to use in whatever game I wanted to create. As I was strumming through all this beautiful medieval assets, it dawned on me I cant find a good RTS on mobile. Even my kids and friends cant find one. Thus the challenge and the idea was born. Now I needed a name, after inquiring with family and going through alot and I mean ALOT of names; I settled on Warforce Empire. Ok now that I knew what I was going to create and the name, I knew I had to write out the game design. This is no hyper casual game you can create on the flow. Alright, Now its time to set out my goal for the upcoming weeks. OK fellow readers now that I caught you up . Here is the goals and challenges I face this week:

*Get LumberJack functional- this was my biggest challenge I faced in coding. Wanted him to find the nearest tree and start chopping then rinse and repeat automatically. Be able to select and move him

* Tree functional- Health added and be destroyed after it reaches 0

*House functional- Health added and be destroyed at 0 also implement explode animation script(The talented artists Im using for my art gave me a explode building script to use)

*LumberJack UI finished- 5 food and 1 person to train

*Finish GUI - I learned this is important to finish early so you can see how the layout is going to be

Next week Goals and Challenges are: Build the enemy city, Enemies AI functional(All logic complete), Create the unique boss for this level, Get the spawn and nav to the player base working, Some enemies will guard their city and some will make their way in waves to the player city.

]]>

What went wrong?

Being "scared" of new things

The first problem I've noticed was that I tried…]]>Thu, 27 Dec 2018 11:41:38 +0000I've made the decision to start my project again from scratch. The whole project failed cause of a bad project planning. Let me explain you how it came.

What went wrong?

Being "scared" of new things

The first problem I've noticed was that I tried staying within my comfort zone. I'm used to write common applications - no games. So I'm used to have simple user interfaces, menues and such kind of stuff. Also my experiences with backend-stuff is not that helpful for 3d-games. Instead of tackling this new stuff I decided to write a game based on menus you could click through. The further I came the lower was my motivation to continue. Finally I noticed that I was about to write a game which I would never ever play. That killed my motivation completly!

My game is called Industry City and in my initial planning you only would see numbers to that city. But never ever see a real city! This is just disapointing...

Planning without a prototype

The next big mistake I did was trying to plan the whole thing withouth having a prototype. Now I've one and already realised the benefits of it:

You get a feeling for your game

You can make decisions based on something existing (e.g. I really struggled with the camera. It took my some time to find an angle which made me happy. For a couple of minutes I thought it is just not possible to display the city as I want to have it).

You concentrate on the core of your game! (My first version of Industry City startet with the main menu! This is something which really doesn't have to be implemented in first stage!)

You start with a MVP. This is something you can ship very early to your testers. So you can get feedback as fast as possible.

You can find a proper project structure based on it (my last project structure only worked in theory...)

You have a shorter planning phase and start early with development (my last planning phase took nearly a week!)

Too much details

I also think I've spend to much time on figuring out details. I actually tried to go for a mvp but I didn't. I noticed this within one of the last weeks when I did some refactoring. I decided to throw code out which wasn't necessary for the first version. And in the end it felt like I've removed the half of the code I've written so far. Sadly there still were things inside not belonging to a first version (like Menu, Settings, Create Company-Screen). I've spend over 90% of my time for realising things I didn't need so far.

The next big time consumer were the 3d-modells! But to be honest: I don't regret it that I've spend time there ^^. Why? Because I've learned a lot of usefull stuff about Blender and Substance Painter. And this will become really usefull when Industry City once will leave the MVP-State!

By the way: I also think that my project setup wasn't really clever. It was designed based on a theoratical assumption. And in the end I wasn't really happy with it plus it sometimes made no sense. But I'd to keep it.

How i tackle it now

Using a prototype (kind of)

I've started watching some other videos about unity3d-game-dev on a more advanced level including some parts about project planning. My actual start wasn't that bad. Think about key concepts of your game - how you would sell it to someone doesn't know anything about it. But don't try to work out details or (graphical) designs yet - it is too early. They started with a prototype-project and used it to try things out + verify ideas. Because they've mentioned how to packaged components I guess they'll later in the course will realise the final game in a new and clean project.

I will go a slightly different approach than they. My current prototype should grow to my MVP. So it is only kind of something you'd call a prototype.

Working with mindmaps

A mindmap is a good thing to have ideas visualized (they're using mindmaster.com where you can have up to 3 mindmaps for free). I was using this together with a word-document in order to have some documentation. There I've the information about things I want to realize within my MVP - but also ideas which might come after I've finished the MVP.

Because my word-document isn't a living document I now went over to hacknplan. Hacknplan is a nice and free kanban-board so that you can organise your task in very good way. When I create a task based on a node of the mindmap then I add the id of the task as a comment to the node. So I always have a great overview of what is planned and what not.

Onion-conecpt

A onion is based on layers. And in the middle (the core) you've your most important conecpt/feature. In my case that would be the city life. Every layer which I put in top of that should be benefit for the core concept. Also it defines how important a feature is for your game. The closer to the core - the more important it is.

I think this can be a good thing to find your core elements. But I only used it at the very beginning. Now it is a dead document.

Question all your tasks!

Before you start working on a task - really think about if they're necessary for the mvp! As an example: I've created one task that wants me realize a movable camera. But at this point I don't need it (because the city is just not big enough). That means: as long as the city can become completly displayed on the screen I don't need it for the mvp.

Was it worth it?

Well - I'm far away from finishing the game. But up to this point I would say: YES it was! Before the "restart" I only had menus. It think it would've taken me at least half a year until I'd be able to put something in the store. Because I started with the menus it made no sense to invite testers.

But with the new approach I already have released the 2nd version of my --- lets call it --- pre-pre-alpha ( https://play.google.com/store/…id=de.jfruit.industrycity ). And as you can see: I really didn't started with menus. No: I've concentrated on the core. And my core is the city!

]]>Sat, 22 Dec 2018 18:45:45 +0000I've been more or less MIA from GameDevHQ for about a month. Back in mid October I had applied for a Social Media Strategist position at another company, and towards the end of November they brought me in for an interview. It was honestly the best interview that I can remember having. About a week later they called my references and offered me the job. I accepted. My last day at my former employer was Friday and I have the next 2 full weeks at home before starting the new job January 7th.

I'm excited because this gives me a lot of time to work on my own projects. I spoiled myself on Black Friday this year and bought a Marvelous Designer 8 perpetual licence, a 1-year Substance Annual Indie license, and a Red Giant Universe annual license (video/motion graphics for Adobe After Effects). I've had a Marvelous Designer subscription before but I'm new to Substance painter & Universe so I'm excited to try them out. I'm also hoping to work on my half finished game Ceres Connection, which I have been inching along since the GameDevJon Game Jam #4 back in June. Hopefully I'll be able to show it off a bit in the next week or two.

]]>
It's been a long time since the last update, I apologize for this. Anyone who knows me knows how little "social" I am, due to the little habit of using forums and blogs.I would like to update the status on the development of Hazardous…]]>Sat, 22 Dec 2018 11:44:10 +0000Greetings to all.

It's been a long time since the last update, I apologize for this. Anyone who knows me knows how little "social" I am, due to the little habit of using forums and blogs.I would like to update the status on the development of Hazardous Materials 2. (hazmat2 from now to shorten ...)First of all there was a choice that changed the artistic style of the game: we decided to move to an entirely hand-drawn, "comic / grotesque" graphics, abandoning the retro-pixel art style.

The reasons for the change were many: as the sketches of the game were created we realized how immediate it was to produce and visualize in a simple way the story, the characters and all other images: everything simply took place immediately, on the contrary, to obtain the same result with a pixel art graphic, a greater effort was needed that was lengthening the times, giving results that did not satisfy us.

The "spirit" and the feeling of the game remained unchanged, it will always be a frenetic arcade that we hope will thrill the players at least as much as it is exciting us in the design and implementation.

We are creating a complete story, the game will have a whole "story mode" in which you will face an adventure between different levels, there will always be an "endless" mode in which to achieve your own record score.

There will also be some interludes of game, with mini-games together with the characters of the game, but I'll tell you about this one more time.

We are almost there!! A first part of assets created for a playable test level has been over, we are assembling the parts, rewriting a new piece of code and building a test level for all the tests.

During these Christmas holidays, I certainly know that I have more time to work and I can dedicate myself to completing the test level.

This level will be the start to try some game mechanics and different modes. Everything has been designed to be modular, expandable and customizable as desired.

Soon I will be able to show you more, I planned to realize in the next posts a first glimpse of the gameplay, the presentation of the playable characters, the evil "nemesis", the history and the background of the adventure we have designed and much more.

If you want to stay updated on developments and follow the fantastic designs that are made you can follow the Instagram profile at THIS LINK!!

I take this opportunity to greet all the community that is following us, all of you happy Christmas holidays and happy new year !!