YYZ

In Part 1, I talked about coming up with a concept and creating a demo prototype in 3 days to test the idea.

After creating the demo prototype, I wanted to program the game systems properly moving forward.

Buildings

The first system is a BuildingManager script, as buildings are core to the game.

A manager in programming is similar to a manager in real life – it manages a group of people objects in the game, and I can retrieve information like how many buildings are on the map in total, how many of them are houses, etc.

This is important as it will be where I write the code to determine the construction logic. For example, to construct a building, I need to do 3 checks:

1. Do I have enough resources to build this thing?
2. Is there a wooden deck underneath to build this on? (Cannot build on water)
3. Is this grid occupied by something else? (Check for overlaps)

Aside from that, I need to create for myself a way to store building properties. I created ScriptableObjects which store data for each building, and these values are all easily adjustable in one place.

Things like what is its name, its description, its cost, what resource it consumes and produces, are all stored in one convenient place, and can be adjusted on the fly.

I had modelled different buildings and to save time, created a scene with all buildings in it.

To capture the icons, I use a 1:1 aspect ratio and scale them to fit the screen.

One of the cool scripts I wrote in a previous project is an automated way to capture 2D icons of 3D objects, and output them with a pre-determined file name, so that if the 3d model is updated, I just need to run the script to update the 2D icons. Cool isn’t it?

I am working alone, and don’t have a UI artist or a concept artist to work with to handle the 2D elements, so I have to think of ways I can reduce my workload in those areas and work smart.

Game Flow

To make a plan of what kind of buildings I want to design, I sketched out a pretty looking game flow.

One of the issues I struggle with is how to blend RTS and RPG together.

In an RTS, the camera is of a third person view and usually very far away, to give players an overview of their base, and the ability to freely move the camera and click on any object on screen.

But in an RPG, the camera is usually up close to give you a more intimate feeling.

While the game now has a player character to control and follow, this was not the initial plan. Initially, I wanted this to be more of an RTS. You don’t take control of a character – you’re more like god building up a town.

But one of the conscious choices I made early on in the development, after consulting with a friend, is to give the player a a playable character that they control. Rather than using the arrow keys to move the camera, the arrows keys will move an avatar, and this player character is how they interact with the world.

It is a dramatic change.

But I think it is better this way as it adds a level of immersion into the world. You’re not just a god manipulating the world, you’re an actual person living in it, and you now make choices through this character, that will influence the world and people around you. I think that with a character, the game will flow much better, and you as a player can immerse yourself into the world of Stranded.

Not to mention, if the game has a story, it would be better experienced by a character.

Lastly, I am going for a game with very relaxing vibes. Here is a slide I wrote in my deck about my vision for this game. I think if the game were to have activities to engage in, or even quests to talk to people, which is a very RPG thing, then having a player character is beneficial.

Speaking of which, I wrote a story draft.

Story

Currently, you are able to build a pier in the game.

When you build it, the game will show a short 3 second cutscene, and the camera’s aspect ratio changes to a cinematic one. The cutscene is only triggered by the player’s action. It is made seamless and flows naturally in the world to not take away too much control from the player or disrupt them.

I believe this is an improvement to storytelling from my previous games. All cutscenes should ideally be a result of player’s actions, and will trigger an event to happen. It should also be clear what is going on. In the above case, a boat with a survivor appears.

It should also not have distracting elements. Thus I hide the UI in cinematic mode and the black bars coming in is an indication to the player that ‘hey! this is a cutscene, you don’t have to click anything, just watch what happens’.

You can then go closer to Alf and click on him to talk to him. You are then presented with a Dialog.

I scripted a dialog system similar to the one I wrote for Enchanted Heroes. It allows me to create multiple player choices, which will be very interesting down the line, and allow different choices made to have different consequences in the world. My dialog script is also dynamic enough to do some really cool story events.

I personally love having mystery in the game, and I love science-fiction, so thinking of those elements made me really excited to develop the world and story.

One improvement I made over Enchanted Heroes is using TextMeshPro for my project, which unlocks better ways to display my text and include sprites within dialogs as well to better make fancier text and provide clarity. This being a resource management game, saying 20 Wood is rather long, but saying 20 <icon of wood> is a much faster way to read the information.

The sentence at the top is not only shorter but you can clearly read the resources you require by opening your inventory as the inventory displays all your item icons.

That’s it for now!