007 - September 16, 2018
This past week I was supposed to implement WebGL text rendering and get skeletal animation working. I've implemented skeletal animation systems enough times that I felt like I had a good sense of how long it would take me, but since I've never implemented text rendering before the timing on that was a bit of an unknown.
Thankfully, we were able to get both text rendering and skeletal animation in place!
Some text rendering and a simple skeletal animation.
Before I started this week I knew pretty much nothing about rendering text, so the first thing that I needed to do was look up some references.
I found an example in Rust and also read a few articles about the general concepts and then got started on getting it working in my WebGL application.
I ran into some early stumbling blocks, mainly due to me misunderstanding how things worked. Naturally when you're doing something for the first time you get stuck a bunch, so it took me a couple of sit downs before and after my day job before I got things working.
On Friday at 7:50am the text renderer was in place and I could render whatever text I wanted, wherever I wanted in any font that I wanted. Neat!
Along the way I broke my texture atlas support, but on Friday at 11:05pm I got it working again.
I was previously using my own adapted version of a texture atlas bash script that I found online. You can probably imagine that a bash texture atlas script was difficult to tweak. On friday I migrated to texture_packer and things are looking good!
On Saturday afternoon I started working on the skeletal animation and got it working around 7:40PM. I'm updated my asset build script to export all armatures from Blender and now when rendering a mesh I'll look up the associated armature and make sure that the correct armature data buffer is being used.
I was talking about the game with a friend on Saturday and realized that the number one blocker to me having more time to work on it (I really enjoy working on it so I want to work on it more!) is releasing it and just enough players to support full time development.
Without having real players I won't know if it's something that only I find compelling or if others do too.
Since I'm a one person team Akigi doesn't need millions of players to be financially viable, just a couple thousand players paying monthly would be enough to work on it full time.
I like that because it means that I don't need to chase a fad or make something watered down. I can work on what I think is cool and just need a handful of other people to think that it's cool too.
So the number one thing that I need to do by next week if have a list of exactly what I need to get done in order to release.
It can be easy for things that aren't actually necessary to sneak onto a list like that, so my mentality will be to cut it down and cut it down until I can't possible cut anything out.
I'll also set a hard deadline while I'm working on this list to make it easier prioritize and cut things out that aren't 100% necessary.
After this I'll plan out what I need to do for every item on the list.
All of this planning will take me some time, but I'm certain that the time will quickly make up for itself since I'll having a more clear focus on exactly what to be working on.
Cool things that don't make it into the initial release can get worked on post release.
The goal isn't to decrease the scope of the game long term, just to decrease the scope of what's necessary to launch it and then work on the rest post launch.
Aside from this, I'll also be adding a height-mapped terrain support into the game in preparation for working on the first town.
See ya next time!