Updated: Jun 7, 2019
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.
Part of the game consists of interacting with merchants. There are a couple of purposes you might find to be obvious for this
Selling items for a profit
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) omnirift.com]
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:
Drag an item from one ItemStorage to the other
Double click an Item
Right click an item
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.
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) omnirift.com].