January 03, 2021
Hello, and welcome to the start of another year.
At the beginning of last year I had high hopes. I thought that I would have a fun alpha version of Akigi ready in April 2020.
These dreams ended up being far from reality.
It was not until the end of October that I even started to work on player facing functionality consistently.
And even still today most of my time is spent setting the underlying engine foundation for whatever gameplay I am working on at the time.
This is what I signed up for by choosing to make my own engine for Akigi.
Fortunately, I don't at all regret taking this long route to the destination. I'm very happy with the trajectory of my engine and I know that there will be an inflection point where I begin to move with top pace.
When will that be? I'm not entirely sure.
I made a list in 099 of the things that I thought were left before I could move at the pace that I want to.
But because I have never released a game before, there are bound to be additional major speed blockers that I notice between now and when that list of tooling is completed.
So, all I am doing for now is sticking to my script. Focus on putting out more game play, and let everything else fall into place around that.
I'd like for 2021 to go differently. I think that it will, but I am admittedly hesitant to say that since I have said it before and I was wrong.
I feel like I am close to the inflection point. I feel like I am nearing the moment where I can start to add in fun game play every week. With larger new updates every month. I feel close, but I am scared to say it because I have said it before and been wrong.
I think that Akigi will be a special game. Not to all, but to some. I have so many gameplay ideas that I want to implement. Some will strike a chord, others might flop.
I'm still motivated. I'm still hungry. I still have the utmost faith in my codebase to help me push Akigi to where it needs to be. I still know that with continued practice my art will be unique to me and enjoyed by some.
I will just keep pushing, and when the light at the end of the tunnel becomes unmistakable I will announce the first official version of Akigi.
It will all work out in the end. That I am sure of.
As mentioned in the last journal entry, I've begun work on being able to create bows and arrows.
I spent a solid amount of time planning out how crafting in Akigi will work.
I'm very happy with how I approached this.
I did not just sit down and try to come up with functionality out of thin air. Instead, I started from the feelings and emotions and thoughts that I wanted the crafting system to create, and then from there I landed on how it should work.
Now, whether I will successfully deliver on my goals here is another story, but I'm happy with the plan that I have in place.
Because this is the first real introduction of crafting into the game, there will be some time that I need to spend adding in various foundational implementations for crafting.
As such, I'm expecting to spend January on the crafting of bows and arrows.
After that, however, it should be much easier to add in new crafting experiences.
This journal entry is getting a bit long, so I'll write about what my plans are for crafting in Akigi in the next journal entry.
Crafting bows and arrows in Akigi involves a collecting and creating a number of intermediary items before you assemble your final product.
Before this week anytime I needed to add a new item to the game I needed to adjust a number of data structures and methods.
For example, there's a c-like
ItemId enum with different methods such as
.equipment_id() -> Option<EquipmentId> which returns the corresponding equipment id
for an item, or
None if it is not equippable.
Needing to update a dozen or so different parts of the codebase every time I added an item made me not want to add in new items.
This week I added an
items.yml file where I can define items, and then wrote a build script that automatically generates all of the data structures and methods
that I need.
# Example item definitions BeastCage: id: 26 display_name: "Beast Cage" ground_renderable_id: BeastCageNotBent ButchersKnife: id: 28 display_name: "Butcher's Knife" ground_renderable_id: ButchersKnife equippable: renderable_id: ButchersKnife slot: MainHand
Last week I mentioned that one of the key missing tools that I need is the ability to auto generate icons for items.
The idea would be to iterate over all of the item's in the game and use the engine's
Renderer trait to render the item and
save the rendering to a PNG file.
Both my linux and mac CI servers run the full asset compilation process.
As it stands now I have two implementations of the
Renderer trait, the
MetalRenderer and the
Neither can be used to power linux CI.
WebGlRenderer runs in the browser so getting PNGs out of there would be a hassle. The
MetalRenderer only works on
macOS, so that is also ruled out.
For this reason I started working on a third
Renderer implementation, the
I do plan to have a
VulkanRenderer in the future that I will use on Linux and Windows, but for now the
WebGpuRenderer is higher priority since I can use it in the browser to
WebGlRenderer whenever the major browsers support
My linux CI server is an EC2 instance. I will need a linux server that has a GPU whenever I make the asset compilation process auto generating icon.
So, I'll be buying a refurbished cheap machine and loading linux on it as a replacement for the EC2 instance.
This should cut $40/month or so off of my AWS bill.
Fixed logic issue where attacks did not cool down while you were out of combat.
Fixed the lower body walk animation stuttering if you were walking while attacking.
The finances for December 2020 were:
|item||cost / earning|
|Stripe fees||- $0.44|
|adobe substance||- $19.90|
|adobe photoshop||- $10.65|
|adobe illustrator||- $22.38|
I'm going to continue working on being able to craft bows and arrows.
The amount of art that I do per week has started to slow down, so I'm going to think about why that is and make some adjustments to my process.
Cya next time!