This past week I was supposed to get the inventory system working and rendering with some placeholder images.
I was a bit sick during the week but had a great Saturday morning and by Saturday at around 11:15am I had the inventory back-end and front-end in place.
Rendering an inventory with a couple of items. Clicking on an item pulls up a menu to interact with the item.
Working on this feature marked a couple of milestones in terms of coding practices for both the game back-end and front-end.
On the back-end I've started using the failure crate to better create and handle errors within our different methods.
For example, when an entity attempts to pickup an item, we'll first check to see if it has an inventory.
If not, we'll log an error and return an
Making use of the
On the front-end I've started to use test-driven development for all of the functionality implementation.
I've been using TDD on the back-end for some time, but not as much on the front-end since I was just getting used to writing and structuring my Rust + WebAssembly code and didn't have the mental bandwidth to worry about tests.
Now that I'm pretty comfortable with Rust on the front-end I've begun to write tests for everything that I'm working on.
It's great because I don't need to refresh the browser. I built just about the entire inventory front-end using TDD and went days without needing to check on it in a browser.
I actually have a lot of great things to say about unit testing in Rust, but that's another subject.
On the back-end we have an
Inventory component that power all of our inventory logic and data.
For example, we have methods for picking up items, dropping items, and combining items in order to create new items.
Clicking on an item that can be picked up. Clicking "Pickup" will send a message to the backend.
When this message gets processed the
InventorySystem will make the player pick up the entity.
While working on the inventory I started thinking about how I'll be making and storing the icons for the different items in the game.
As a one person team, automation is critical. The more that I can delegate work to my tools instead of me needing to do it manually, the more possible it will be for me to release and grow the game by myself.
The method that came to mind for my icons is having an automated process that iterates over my meshes in Blender, positions a camera to look at the mesh, renders an image of the mesh and then includes that rendered image in our texture atlas.
In theory it sounds like it should give me free access to icons for any game entity without needing to do extra work whenever I make a new entity.
In practice I'm imagining that it'll take a few iterations and edge cases before it works smoothly.
For example, for an animated model I might want the screenshot to come at a certain keyframe and not just at the bind pose.
Or even for a static model I might want the camera to be at a specific angle.
For a system like this I'd start by ignoring those concerns, and then if they actually came up I'd address them when I needed to.
It'd probably just boil down to being able to override my default icon rendering process using some easy to configure settings in a settings file.
Then on a case by case basis I could override the rendering settings for any model that I wanted to.
This is just brainstorming of course, I'd wait until I actually needed something like this before ever implementing it.
Yeah, none of this is a concern at the moment - we can revisit this after we've started adding real (non-placeholder) meshes to the game and have a much better sense of how and where we're making use of our models.
Our net loss for the month of October was $40.38. Just our usual Photoshop and AWS expenses this month.
Still earning $0 in revenue per month, but hopefully that'll change once we get the game launched!
By next week I'll implement the first piece of the combat system, melee. Specifically you'll be able to use the boxing style against other entities.
See ya next time!