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.
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:
I don't have to use poor design with if checks for components
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:
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:
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.
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,