Hey developers!

We've just put together a new video on how to create a game in 2019. I'll take you through the basics and get you up and running to make the core features of a 2D endless runner!

This tutorial will get you going if you're sick of trying too many different things or don't know where to start.

Make sure to check it out, and let me know what you think!

All the best,


93 views0 comments

Updated: Jun 7, 2019

Welcome back.

I lied last time about what I said I’d mention in this log.

In reality, I’ll talk about trading in the game. Specifically, I’ll talk about how I planned out adding the trading feature, its underlying architecture, and how the player is intended to use it in-game.

Why Trading?

Part of the game consists of interacting with merchants. There are a couple of purposes you might find to be obvious for this

  1. Selling items for a profit

  2. Purchasing items for use

So far, the only planned purpose of currency is to purchase usable items and ship components.

Thus, the player may choose to take the following approach early in their playthrough: mine profitable resources by searching through astaeroid fields, making a profit, and improving their stats and abilities until they feel ready for the next arbitrary task.

Trading with Merchants

To trade with merchants, the player may approach one and “interact” with one; which is essentially opening a communication link with a character.

Side note, the interaction system is driven by links with Rewired, an amazing input overhaul asset for Unity, as well as PC & Consoles Controller Buttons Icons Pack which is a collection of input icons as a Unity asset.

Finally, TypeSafe, which I talked about in the previous log, is used for a static reference to the Icons so that a static dictionary can associate the icons with Rewired actions.

Let me know if you want to hear more about that. [Email bilal (at)]

Moving on: the player then is presented with a trade window in which they can stage items to purchase and sell.

In this view, you're seeing a MarketWindowContentContainer, which holds two ItemStorageViews connected to two IMerchants which each have access to a respective ItemStorage interface.

There are 4 ways the player can stage or un-stage an item, and one way to accept the trade.

I'll let you guess the latter.

As for staging, the player may:

  1. Drag an item from one ItemStorage to the other

  2. Double click an Item

  3. Right click an item

  4. Select an item and press sell or buy respectively

Here's what it looks like when an item is staged:

It becomes green, and moves to its opposite ItemStorage.

I know.


Oh, and notice that the cost or profit of the transaction is updated when an item is staged or un-staged.

For the record, here's what it looks like when an item is selected:

After the player accepts a staged transaction by pressing the center button, they will see the items stay in the staged area but lose staged color, indicating it now belongs to that ItemStorage. That looks like this:

Planning my Work

It's hard to say how long I should work on something since I work a full-time job and do more than just code for the company, but I try to create "sprints" before I work on anything for the game.

When I say "sprint," I'm talking about the Agile Software Development concept of planning a goal to complete over a period of time, commonly 2 weeks.

For example, I created a sprint that included the trading window that included full functionality with items in inventories.

I'm currently using Zoho Sprints to plan out this game, and create said sprints.

Designing the Architecture

I'll keep this part short since I don't want to overly explain something that can be simplified.

There is a concept in Software Development that encourages separating UI code and "Architectural" code.

In this case, we could say IMerchants transferring items between ItemStorages is our Architectural code, and the calls to make this happen attached to the buttons is UI code, as well as refreshing the window when items are staged and un-staged.

To achieve this, I used events. Fundamentally, this system works by staging and un-staging events, as well as some others that are slipping my mind at the moment.

Basically, an item is dragged, it becomes staged, that fires an onstage event, this communicates to all Architectural and UI systems, telling them they're allowed to run their listeners.

That's all for this one.

Check back in October for the third devlog!

P.S. you can ask me anything by email [bilal (at)].

Talk soon,


#skrpg #developerlog #assetstore #devlog #gamedev #unity3d #visualstudio #c #net #unityassetstore #coding #unity #programming

88 views0 comments

Updated: Jun 7, 2019


This is the beginning of a Developer Log series I'll be doing seriously for this next game I'm working on. I want to share a lot with you, but I'll keep this brief so I actually get it done. My plan is to release one of these logs every month despite how little or how much progress I've made since the last.

Some Background

This game, as any other, has many similarities or universal concepts that it can be categorized under. For example: SKRPG is a 2D top-down space RPG with a focus on stealth and "getting by." In SKRPG, the player only has access to miner tools, so one has to improvise in fights, usually avoid combat, and pick fights wisely. There is a persistent world, so the player may collect items, tools, ship modules and so on through mining, training, and combat. The player may complete a main quest-line as well as a few minor quests on the side.

There's a Story, Right?

Yep. This game is supposed to communicate a scenario where certain questions arise. Some of those might be:

"Do the negative things I do matter in the end?"

"What makes me... me?"

"Am I a good or a bad person?"

"Does sacrifice for the greater good really make sense?"

"Is freedom or safety more important?"

And so on. Please know this: I don't expect to answer these questions, but I think it's interesting when a story can get one thinking about deep important motifs in life that as a species we often question. One could argue that these questions are not really important and you are what you do... and that's why I like to bring these questions to the surface. I think having introspective arguments like this with your brain is important, and having someone think about these through my favorite medium (GAMES!) while having fun would mean a lot to me.

tl;dr: I'm not going to try to teach you how to be a person, but cognition is cool.

Just Tell me What the Game Is Already

Okay. Sorry. So I want this game to have a couple of "gameplay feelings." The player should be very cautious to pick fights. The player should feel as though they are in a no-man's land where encounters are high-risk, and they should lay low. That said, the player should also feel able to progress and be smart doing the right thing.

You might pick the right fights, mine the most efficient ores, explore to find the best goods, or perform side quests to get tools earlier on. I want a lot of the game to feel like a 2D Stealth Space version of Morrowind (EXCLUDING the combat system), but with its unique features of course, and not as RPG focused beyond tool/item progression. You'll see eventually anyway.

The Juicy Technicals

In this blog post I'd like to get into some of the underlying systems that run (and will run) the game. Right now, there isn't really content in the game; I've spent most of my development time creating OOP Architecture, patterns in code and Unity, and so on.


To begin, my first and most basic rule in SKRPG is that every GameObject in the scene has an Actor component. Everything is expected to have this component so that everything can determine for itself what happens when it interacts with another Actor. This way, I solve two irritating and common problems in Unity:

  1. I don't have to use poor design with if checks for components

  2. I can allow GameObjects to use polymorphism through inheritance to determine what

For example, when two actors collide, a function will fire on both allowing them to act however they want. (If it's a piñata ship, I guess candy gets flung through the void?)


The game has items. You might think that's the most exciting sentence of this section, but lets continue: items are the form of progression in SKRPG.

Rather than levels and experience, the game will be designed in a way that the player can progress through finding, receiving, buying, or being rewarded items.

For example, higher tier mining tools, and different types of mining tools. Drills -> Lasers -> Asteroid splitters? Anyway, so that's a thing.

Here's how they're implemented: ScriptableObjects. I have items within folders in Unity, and their metadata is stored through attributes serialized in Unity. What I mean is that I edit their values through the inspector, visually as separate objects.

Here's what scriptable objects look like in the Editor:

Then, they can easily be accessed and used in the game through dragging into something's inventory, or through script. I'm currently assigning random ores to asteroid ore nodes using constants generated by this awesome Unity Asset called TypeSafe, which you can check out here:

Here's how that looks in code:

Read more about TypeSafe here...

Ore Node Generation

This game will have the same world in every new game. That said, parts of the world will be procedurally generated once. By your overlord, Bilal. Joking, I mean that it will be the same generated world for every player though, pre-generated before the game build.

One important generated part of the game includes Ore Nodes. These will be generated for every asteroid in the game.

I've used Editor Scripting, which you should not be intimidated to do at all, to run a script that will appropriately create and position Ore Nodes on every asteroid that has an Ore Node Generator script.

Here's a picture of that button in the editor:

Here's what the custom editor script looks like:

If you want to add a custom button like I did in the editor, all you need is to write a MonoBehaviour script, then write an editor script that references it as I do in the picture above.

In my example, OreNodeGeneratorEditor is my Editor Script, and OreNodeGenerator is my MonoBehaviour that I'm using as a component.

After generating ore nodes:

After Generation

Now, the OreNodeGenerator.Generate function is called on every OreNodeGenerator. If I only wanted this to happen with the referenced OreNodeGenerator, then I would just call myScript.Generate rather than use my OreNodeGenerator.all static attribute.

What my generate function does is find random points along an asteroid (or any polygon collider), pick a random Ore, create an OreNode prefab and store the ore as a reference in it, then move it to that random position and set it as a child of the asteroid.

That's It?

This is all I'm going to talk about in this blog post. In the next one, I'll most likely talk about the control design and implementation, how to play, and some more in-depth code.

Until next time,


#devlog #developerlog #skrpg #unity #gamedev

139 views0 comments

game development