Introduction

Welcome to Akigi Dev Journal!

This is a journal about my progress on building my game Akigi.

Akigi is a multiplayer online world where most believe that humans are inferior.

I'm building Akigi alone while working full time, which has me incredibly excited but also comes with its fair share of challenges.

I hope to share this excitement and these challenges with you along the way.

Goals

There are two high level goals with Akigi, a game goal and a business goal.

The game goal is to build something that players love and that I'm proud of. Not everyone will be a fan, and some might hate it passionately, but as long as there is a pocket of players that love the game I'll consider it a success.

The business goal is to earn enough revenue to be able to work on the game full time. This comes down to having at least a couple thousand active players. Akigi will be a paid game at $5/month. There will be no micro-transactions, ever.

Format

I want to share my progress and struggles on both the game and business side of Akigi.

I'll share every Sunday evening EST.

I'll publish game focused journal entries every week, and include a transparent business and financials update on the first post of every month.

On any given week I might share words, images, videos, charts, or anything else that best communicates the progress and struggles.


I hope that you'll join for the ride!

July 7, 2019

Hey!

I finally finished the physically based rendering tutorial - after 7 weeks!

I'll be posting it later this week on chinedufn.com.

I plan to integrate a lot of what I learned into the game engine - so I consider it all time well invested.

Financials

Our financials for June 2019 were:

item cost / earning
revenue + $4.55
photoshop - $10.65
clubhouse - $10.00
AWS - $89.02
ngrok - $10.00
--- ---
total - $122.95

Last months AWS bill was $113.79. We cut that down by $24.77 this month to $89.02 by getting rid of some unnecessary resources.

$90/month for AWS is right at the threshold where I'm considering consolidating some resources to get it down to around $30-$40 - but ultimately I think I'll focus on getting something worth paying for out rather than changing my server setup (going from ECS to EC2 for a few servers) only to have to change it all back later.

I'm adding one more ECS deployment for the payment serfer - so the bill should creep back over $100 in the next month or two.

Luckily after that there shouldn't be anything else to pay for until we have paying players and need to scale. But this sure is good incentive to hit that point more quickly.


We cancelled our Clubhouse subscription since it doesn't work well offline. In the last month we've started working offline heavily in order to focus without distraction. For now we're managing tasks using markdown files. If at some point that breaks down - we'll figure out where to go from there.


Another $4.55 ($4.99 - Stripe's cut) made this month. Let's bump that up soon!


Next month we should be adding around $20/month to our expenses since we'll be purchasing Substance Painter and Substance Designer subscriptions.

Next Week

Before integrating some new rendering techniques into the engine I'm going to take a week to finish up our continuous deployment.

The easier it is to deploy - the more I will deploy. This is critical in these early days where I want to be rapidly putting out new mechanics and art for the early players.

The last (and hardest) thing left to set up continuous deployment for is the game's websocket server, so that should take up all of this week.


Cya next time!

- CFN

038 - June 14, 2019

A curious case of Rust to Rust FFI

  • Draw some diagrams with monodraw

  • Working on continuous deployment of the game server

  • Added some new commands to our CLI ak dist download-game-server ak test game-server-integration

July 7, 2019

Hey!

I finally finished the physically based rendering tutorial - after 7 weeks!

I'll be posting it later this week on chinedufn.com.

I plan to integrate a lot of what I learned into the game engine - so I consider it all time well invested.

Financials

Our financials for June 2019 were:

item cost / earning
revenue + $4.55
photoshop - $10.65
clubhouse - $10.00
AWS - $89.02
ngrok - $10.00
--- ---
total - $122.95

Last months AWS bill was $113.79. We cut that down by $24.77 this month to $89.02 by getting rid of some unnecessary resources.

$90/month for AWS is right at the threshold where I'm considering consolidating some resources to get it down to around $30-$40 - but ultimately I think I'll focus on getting something worth paying for out rather than changing my server setup (going from ECS to EC2 for a few servers) only to have to change it all back later.

I'm adding one more ECS deployment for the payment serfer - so the bill should creep back over $100 in the next month or two.

Luckily after that there shouldn't be anything else to pay for until we have paying players and need to scale. But this sure is good incentive to hit that point more quickly.


We cancelled our Clubhouse subscription since it doesn't work well offline. In the last month we've started working offline heavily in order to focus without distraction. For now we're managing tasks using markdown files. If at some point that breaks down - we'll figure out where to go from there.


Another $4.55 ($4.99 - Stripe's cut) made this month. Let's bump that up soon!


Next month we should be adding around $20/month to our expenses since we'll be purchasing Substance Painter and Substance Designer subscriptions.

Next Week

Before integrating some new rendering techniques into the engine I'm going to take a week to finish up our continuous deployment.

The easier it is to deploy - the more I will deploy. This is critical in these early days where I want to be rapidly putting out new mechanics and art for the early players.

The last (and hardest) thing left to set up continuous deployment for is the game's websocket server, so that should take up all of this week.


Cya next time!

- CFN

036 - June 9, 2019

Hey!

Still working on the physically based rendering tutorial and then incorporating what we learn there into the game.

Next Week


Cya next time!

- CFN

036 - June 9, 2019

Hey!

Still working on the physically based rendering tutorial and then incorporating what we learn there into the game.

Next Week


Cya next time!

- CFN

035 - June 2, 2019

Hey!

Still working on the physically based rendering tutorial and then incorporating what we learn there into the game.

Financials

Our financials for May 2019 were:

item cost / earning
revenue + $4.99
photoshop - $10.65
clubhouse - $10.00
aws - $113.79
ngrok - $10.00
--- ---
total - $122.95

Our AWS bill went up by $80 this month due to some new resources that we added for AWS ECS. There were some that we didn't need, so going forwards this should shrink down to $70/80 dollars per month or so.

We also got our first "paying player!" I put that in quotes because they signed up not as much to play but rather to support the game .. but hey .. it's a start!

Next Week

Get this physically based rendering blog post published and start incorporating PBR into our game engine.


Cya next time!

- CFN

033 - May 12, 2019

Hey!

As we mentioned last week, our goal for this passed week was to continue to polish the first quest in the game.

We made a lot of progress on some of the underlying code that powers quests, but we fell short on our goal of finishing up the art for the quest.

We'll have to pick back up on the art work during a future week.

Talk to Pookie Talking to Pookie will start the first quest in the game.

Working with the database

We were previously using a Postgres installation on our local host machine for our database - which led to inevitable issues and annoyances whenever we'd change version or switch computers.

This week we moved to running Postgres from a Docker container.

We also extended the Akigi CLI (ak) (powered by StructOpt) with a new subcommand, ak db.

Here's a quick look at the new ak db interface.

$ ak db -h
ak-db 0.0.1
Chinedu Francis Nwafili <frankie.nwafili@gmail.com>
Work with our database

USAGE:
    ak db <SUBCOMMAND>

FLAGS:
    -h, --help       Prints help information
    -V, --version    Prints version information

SUBCOMMANDS:
    create-migration    CreateMigration
    help                Prints this message or the help of the given subcommand(s)
    migrate             Run migrations against one of our environments
    seed                Seed one of our databases
    start               Start a postgres database docker container

And here's an example of the ak db migrate CLI. We used to use knex for migrations, but we've migrated our local and production database to use dbmigrate instead.

$ ak db migrate -h
ak-db-migrate 0.0.1
Chinedu Francis Nwafili <frankie.nwafili@gmail.com>
Run migrations against one of our environments

USAGE:
    ak db migrate --command <command> --env <env>

FLAGS:
    -h, --help       Prints help information
    -V, --version    Prints version information

OPTIONS:
    -c, --command <command>     [possible values: Up, Down, Redo, Revert, Status]
    -e, --env <env>             [possible values: Dev, Int, Prod]

Being able to quickly and easily start our local database, run migrations and seed data has made for a much smoother dev experience!

Persisting Items / Quests

When a player connects to the game we'll now load up their inventory and quests from the database.

When they disconnect we'll now persist their inventory and quests to the database.

Some elbow grease went into getting this set up and adding tests to our test suite since we didn't have much persistance prior to this - but now it's looking like everything is working correctly.

Next Week

Next week is our second Investment Week. We'll be automating the deploy process for the game server.

This is trickier than the previous deployment processes that we automated because they were all stateless. Our game server is stateful and at any point tens or hundreds or thousands of players can be connected via WebSocket.

We have a plan to execute on - so we just need to dive in.

I'll be traveling a bit later in the week so I'll try and get as much done as I can before then.


Cya next time!

- CFN

034 - May 26, 2019

Updates should be pretty slim for the next couple of weeks.

Working on enhancing our game engine's renderer.

- CFN

033 - May 12, 2019

Hey!

As we mentioned last week, our goal for this passed week was to continue to polish the first quest in the game.

We made a lot of progress on some of the underlying code that powers quests, but we fell short on our goal of finishing up the art for the quest.

We'll have to pick back up on the art work during a future week.

Talk to Pookie Talking to Pookie will start the first quest in the game.

Working with the database

We were previously using a Postgres installation on our local host machine for our database - which led to inevitable issues and annoyances whenever we'd change version or switch computers.

This week we moved to running Postgres from a Docker container.

We also extended the Akigi CLI (ak) (powered by StructOpt) with a new subcommand, ak db.

Here's a quick look at the new ak db interface.

$ ak db -h
ak-db 0.0.1
Chinedu Francis Nwafili <frankie.nwafili@gmail.com>
Work with our database

USAGE:
    ak db <SUBCOMMAND>

FLAGS:
    -h, --help       Prints help information
    -V, --version    Prints version information

SUBCOMMANDS:
    create-migration    CreateMigration
    help                Prints this message or the help of the given subcommand(s)
    migrate             Run migrations against one of our environments
    seed                Seed one of our databases
    start               Start a postgres database docker container

And here's an example of the ak db migrate CLI. We used to use knex for migrations, but we've migrated our local and production database to use dbmigrate instead.

$ ak db migrate -h
ak-db-migrate 0.0.1
Chinedu Francis Nwafili <frankie.nwafili@gmail.com>
Run migrations against one of our environments

USAGE:
    ak db migrate --command <command> --env <env>

FLAGS:
    -h, --help       Prints help information
    -V, --version    Prints version information

OPTIONS:
    -c, --command <command>     [possible values: Up, Down, Redo, Revert, Status]
    -e, --env <env>             [possible values: Dev, Int, Prod]

Being able to quickly and easily start our local database, run migrations and seed data has made for a much smoother dev experience!

Persisting Items / Quests

When a player connects to the game we'll now load up their inventory and quests from the database.

When they disconnect we'll now persist their inventory and quests to the database.

Some elbow grease went into getting this set up and adding tests to our test suite since we didn't have much persistance prior to this - but now it's looking like everything is working correctly.

Next Week

Next week is our second Investment Week. We'll be automating the deploy process for the game server.

This is trickier than the previous deployment processes that we automated because they were all stateless. Our game server is stateful and at any point tens or hundreds or thousands of players can be connected via WebSocket.

We have a plan to execute on - so we just need to dive in.

I'll be traveling a bit later in the week so I'll try and get as much done as I can before then.


Cya next time!

- CFN

032 - May 5, 2019

Hey!

Last week we were on a team trip at my job so I didn't get any work done on the game.

Financials

Our financials for April 2019 were:

item cost / earning
revenue + $0
photoshop - $10.65
clubhouse - $10.00
aws - $32.12
ngrok - $10.00
monitor - $1,424.03
--- ---
total - $1486.80

A few new items this month.

We've started using Clubhouse.io to organize / manage / visualize our upcoming work.

We also purchased a new 27 inch computer monitor since it was getting difficult to create 3D models on our 15 inch laptop screen.

The rest should look fairly usual.

Our AWS bill will be a bit higher ($100+) in May since we were using some additional resources that we didn't get charged for until early May. We should be able to bring that back down to $50-$60 per month.

Next Week

We'll continue working on adding new graphics and work on polishing up the first quest in the game.


Cya next time!

- CFN

031 - Apr 21, 2019

Hey!

Since last time we checked in I made a sweeping change to the codebase to allow for one entity to have multiple meshes.

Before the multiple mesh support refactor

Previously every mesh corresponded to one entity - but this broke down recently while we were working on an entity that needed to be rendered using multiple different meshes.

Model enum The old Model enum that we've now removed.

After the multiple mesh support refactor

Now we have MeshName to represent our different meshes and IconName to represent our different icons.

With this one entity can have zero or one icons and any number of meshes. This allows us to create entity's that were previously impossible to create.

IconName enum We now have an IconName enum for icons.

MeshName enum We now have a MeshName enum for icons.

Next Week

For next week we'll create a bunch of new 3d models in Blender, some of which we'll leverage using our new multiple meshes for a single entity support.

We'll also fix some UI issues that we've run into while play-testing the first quest in the game.


Cya next time!

- CFN

031 - Apr 21, 2019

Hey!

Since last time we checked in I made a sweeping change to the codebase to allow for one entity to have multiple meshes.

Before the multiple mesh support refactor

Previously every mesh corresponded to one entity - but this broke down recently while we were working on an entity that needed to be rendered using multiple different meshes.

Model enum The old Model enum that we've now removed.

After the multiple mesh support refactor

Now we have MeshName to represent our different meshes and IconName to represent our different icons.

With this one entity can have zero or one icons and any number of meshes. This allows us to create entity's that were previously impossible to create.

IconName enum We now have an IconName enum for icons.

MeshName enum We now have a MeshName enum for icons.

Next Week

For next week we'll create a bunch of new 3d models in Blender, some of which we'll leverage using our new multiple meshes for a single entity support.

We'll also fix some UI issues that we've run into while play-testing the first quest in the game.


Cya next time!

- CFN

030 - Apr 7, 2019

Hey!

We mentioned Last week that this week was our first Investment Week, and it went great!

Our goal for last week was to fix a problem where we'd make mistakes with our deployments here and things wouldn't work when people would try the game.

In order to do this we were to set up continuous deployment for 3 of our 4 core services.

We managed to set up CD for two of those services, our website / web application and our authentication server.

Continuous Deployment

We're using terraform to provision all of our AWS resources such as load balancers, AWS ECR (elastic container registry) repositories, IAM users, groups and policies, and many more.

The majority of the week was spent learning what these different AWS services were and understanding how to piece them together to set up continuous deployment to AWS ECS (elastic container service).

Our new setup is that on ever commit to our master branch our CircleCI workflow will run our tests, and if tests pass it will deploy our auth server and website server to ECR, as well as deploying our WebAssembly website application to S3.

Our payment server should work largely the same way when we set up continuous deployment for it in the future.

The one that needs more thought though is our game server. We can't just simply deploy on green master builds since there will be players connected to the server.

We need a deploy process that will warn players of an upcoming server stoppage, give them time to finish what they're doing and log off, then automatically restart the server. We'll think through this deploy process in a future Investment Week.

Financials

Our financials for March 2019 were:

item cost / earning
revenue + $0
aws - $32.12
ngrok - $10.01
--- ---
total $42.13

We didn't get charged for photoshop in March, the payments landed on Feb 28th and April 1st.

So there will likely be two photoshop charges for our April financials.

Next Week

Next week I'll be back to working on the highest priority items for my 5 Priority Weeks of my Super Cycle.

This mainly comes down to building our the first quest and making a lot of art for it.


Cya next time!

- CFN

029 - Mar 31, 2019

Hey!

Two weeks ago we introduced a new approach to our game development process that we call our Super Cycle, inspired by a process of the same name that we use for product development at my day job.

We wanted to kick off on April 1st, so we used the last two weeks to get a head start on the cycle and just generally start feeling out the new process.

We implemented a few things in the Rust + Wasm WebGL client such as rotating towards the direction that we're walking, hunting huntable entities and even whipped up a few basic models and icons. Among other things!

(As usual - these are all first passes and will need improvement and gloss over time.)

Tomorrow begins the first day of our first Super Cycle and I'm already very excited to make some focused progress!

Super Cycles

To quickly re-cap, our Super Cycle is a 6 week process that is split into two phases.

Phase 1 I'm calling the Investment Week. This is the first week of the cycle where we decide on what we'll be doing for the next 5 weeks after this first week, and is also time that we can spend working on things that aren't necessarily the exact thing that we need to do right this moment but will pay dividends over time.

Phase 2 I'm calling the Priority Weeks. This is the last 5 weeks of the cycle when we execute on the things that we need to be doing right now do give players a better experience.

Then we rinse and repeat.


I usually like to avoid inventing names for things and concepts when possible - but naming our phases and development process makes it a bit more fun which can be a difference maker when you're working on a multi-year project that requires consistent incremental progress regardless of the ebbs and flows of your life and focus.


Just to be clear - we'll still be releasing as frequently as possible all throughout those 6 weeks. We are in no way moving away from deploying frequently.


I'm loving the new Super Cycle process so far based on informally trying it out these last two weeks.

As I've worked on the game and its underlying tech for the last three years (way back when I was using Node.js on the backend and JS on the frontend!) I've come across lots of ideas of things to make to improve my work flow such as Percy, blender-iks-to-fks landon and lots and lots of other things.

When these ideas would come I'd usually instantly jump on them.

I found that in the last 2 weeks when ideas came I wrote them down and tucked them away - knowing that I could get to them during a future Investment Week.

Instead of instantly jumping on ideas that I'd have for investing in scaling longer term I was forced to stash them and prioritize them against other things that I could do during Investment Week.

I'm expecting this to be a massive improvement in my workflow since in the past I would let them pull me away from making progress on core gameplay.

Each time spending a 1-2 days or even sometimes 1-2 weeks of time away from delivering a great game sooner rather than later.

Granted those pull-aways would've all been shorter if I wasn't just working on the game in my spare time - but even still we want to be more deliberate about how we spend our time and never let things pull us in a new direction unless it's an intentional act of prioritization.

I will want to continue to work on these things and make these improvements to my workflow and tooling - just in a more structured and prioritized way.

The first Investment Week

Our first Investment Week has a heavy focus on further automating our deployment processes. Right now it's too easy for me to accidentally mess up a deploy since parts of the process are manual.

At this time there is no fully automated deployment for any of our services.

I've been improving our deployment scripts here and there - but nothing is quite so seamless yet.

An example of this is that I've known of an issue in the authentication server that can crash threads when people try to sign up for over a week now. The fix is simple, but I haven't gotten to it yet because I didn't want to go through the process of sshing into the server, pulling new code and creating a new release build.

Our CI has been red for months. I fixed it at one point but it's red again. This is mostly due to CI not really controlling anything right now. There is nothing that happens when CI is green.

Having my deployments be based on green CI will give me good reason to make sure that tests are always passing and make sure that I'm paying attention to the entire test suite, not just the tests for whatever I happen to be working on at the time.

Continuous Deployment via AWS ECS

There are four main services right now.

The authentication server, the billing/payment server, the website server and the websocket powered game server.

I'll be setting up continuous deployment of the authentication server, the billing/payment server and the website server this week after I get the test suite passing in CI. I'll be following this CircleCI tutorial on automating AWS ECS deployments.

The game server will need a much more complex deploy process since at any given time there can be thousands of active websocket connections to a game server.

I haven't begun to think through that deploy process yet. So for now it will still be a somewhat manual process until some future Investment Week when I decide to tackle it. Maybe even in the next one!

The first Priority Weeks

For the 5 Priority Weeks of this Super Cycle I'll be focusing on two overarching things.

One is being able to complete the first quest in the web client. Right now I have an integration test that completes the quest in code - but completing it in game requires UI elements, meshes and polish that do not yet exist.

Quest integration test An integration test that completes the first quest in the game by pretending to be a real player.

The second is creating and rendering the equipment UI. Right now we have a basic inventory interface taking shape - and by the end of this cycle we should have something similar for player equipment.

All throughout I'll be writing new tests and features, and creating new interfaces and meshes.

I'm hoping to end this cycle with things starting to look much more like a game.

Next Week

I'll update you next week on how the first Investment Week of the first Super Cycle went!


See ya next time!

- CFN

029 - Mar 31, 2019

Hey!

Two weeks ago we introduced a new approach to our game development process that we call our Super Cycle, inspired by a process of the same name that we use for product development at my day job.

We wanted to kick off on April 1st, so we used the last two weeks to get a head start on the cycle and just generally start feeling out the new process.

We implemented a few things in the Rust + Wasm WebGL client such as rotating towards the direction that we're walking, hunting huntable entities and even whipped up a few basic models and icons. Among other things!

(As usual - these are all first passes and will need improvement and gloss over time.)

Tomorrow begins the first day of our first Super Cycle and I'm already very excited to make some focused progress!

Super Cycles

To quickly re-cap, our Super Cycle is a 6 week process that is split into two phases.

Phase 1 I'm calling the Investment Week. This is the first week of the cycle where we decide on what we'll be doing for the next 5 weeks after this first week, and is also time that we can spend working on things that aren't necessarily the exact thing that we need to do right this moment but will pay dividends over time.

Phase 2 I'm calling the Priority Weeks. This is the last 5 weeks of the cycle when we execute on the things that we need to be doing right now do give players a better experience.

Then we rinse and repeat.


I usually like to avoid inventing names for things and concepts when possible - but naming our phases and development process makes it a bit more fun which can be a difference maker when you're working on a multi-year project that requires consistent incremental progress regardless of the ebbs and flows of your life and focus.


Just to be clear - we'll still be releasing as frequently as possible all throughout those 6 weeks. We are in no way moving away from deploying frequently.


I'm loving the new Super Cycle process so far based on informally trying it out these last two weeks.

As I've worked on the game and its underlying tech for the last three years (way back when I was using Node.js on the backend and JS on the frontend!) I've come across lots of ideas of things to make to improve my work flow such as Percy, blender-iks-to-fks landon and lots and lots of other things.

When these ideas would come I'd usually instantly jump on them.

I found that in the last 2 weeks when ideas came I wrote them down and tucked them away - knowing that I could get to them during a future Investment Week.

Instead of instantly jumping on ideas that I'd have for investing in scaling longer term I was forced to stash them and prioritize them against other things that I could do during Investment Week.

I'm expecting this to be a massive improvement in my workflow since in the past I would let them pull me away from making progress on core gameplay.

Each time spending a 1-2 days or even sometimes 1-2 weeks of time away from delivering a great game sooner rather than later.

Granted those pull-aways would've all been shorter if I wasn't just working on the game in my spare time - but even still we want to be more deliberate about how we spend our time and never let things pull us in a new direction unless it's an intentional act of prioritization.

I will want to continue to work on these things and make these improvements to my workflow and tooling - just in a more structured and prioritized way.

The first Investment Week

Our first Investment Week has a heavy focus on further automating our deployment processes. Right now it's too easy for me to accidentally mess up a deploy since parts of the process are manual.

At this time there is no fully automated deployment for any of our services.

I've been improving our deployment scripts here and there - but nothing is quite so seamless yet.

An example of this is that I've known of an issue in the authentication server that can crash threads when people try to sign up for over a week now. The fix is simple, but I haven't gotten to it yet because I didn't want to go through the process of sshing into the server, pulling new code and creating a new release build.

Our CI has been red for months. I fixed it at one point but it's red again. This is mostly due to CI not really controlling anything right now. There is nothing that happens when CI is green.

Having my deployments be based on green CI will give me good reason to make sure that tests are always passing and make sure that I'm paying attention to the entire test suite, not just the tests for whatever I happen to be working on at the time.

Continuous Deployment via AWS ECS

There are four main services right now.

The authentication server, the billing/payment server, the website server and the websocket powered game server.

I'll be setting up continuous deployment of the authentication server, the billing/payment server and the website server this week after I get the test suite passing in CI. I'll be following this CircleCI tutorial on automating AWS ECS deployments.

The game server will need a much more complex deploy process since at any given time there can be thousands of active websocket connections to a game server.

I haven't begun to think through that deploy process yet. So for now it will still be a somewhat manual process until some future Investment Week when I decide to tackle it. Maybe even in the next one!

The first Priority Weeks

For the 5 Priority Weeks of this Super Cycle I'll be focusing on two overarching things.

One is being able to complete the first quest in the web client. Right now I have an integration test that completes the quest in code - but completing it in game requires UI elements, meshes and polish that do not yet exist.

Quest integration test An integration test that completes the first quest in the game by pretending to be a real player.

The second is creating and rendering the equipment UI. Right now we have a basic inventory interface taking shape - and by the end of this cycle we should have something similar for player equipment.

All throughout I'll be writing new tests and features, and creating new interfaces and meshes.

I'm hoping to end this cycle with things starting to look much more like a game.

Next Week

I'll update you next week on how the first Investment Week of the first Super Cycle went!


See ya next time!

- CFN

028 - Mar 17, 2019

Welcome back!

Over the last two weeks I mostly worked on things that I need for www.akigi.com.

Because I'm building my own library for building client side web apps with Rust most of my work wasn't on the Akigi website, but rather on adding feature to Percy that I needed for Akigi.


The main thing that I worked on were a procedural macro for routing - along with a few other smaller features.

The reason for this was mentioned in the last journal entry - we were working on adding the ability to sign up for a monthly membership subscription to the game from the website.

I'm most of the way there - but still have a few checklist items left before you can start paying for the game from the website.

After that I'll be turning my attention back to the gameplay and really focusing in on making something compelling that we can start putting into the hands of some real players!

A New Development Process Going Forwards

I said that I'll be focusing on gameplay - but I've said that before.

Inevitably something always comes up with my underlying tech or infrastructure that causes me to jump away from the game in order to build or fix that tech/infrastructure problem.

While I want to continue investing in my underlying tech so that long term I can build at an incredible pace, I don't want to let that constantly pull me away from building gameplay functionality.

I need a more healthy balance. I have much more tech than actual gameplay and that needs to change.


The way I'm changing that is by adopting a new development process that will force me to prioritize, plan and then produce in a much more strategic cadence.

The idea came from a process that we use at my day job called Super Cycles - which was inspired by blog posts by buffer, basecamp and intercom about their own product development processes.

The Super Cycle

The way that my Super Cycle will look for Akigi is very similar to how we do it at my job.

I'll have a 6 week cycle - 1 week for prioritizing and planning, 5 weeks for producing, then I'll rinse and repeat.

Prioritizing/Planning Week

During the prioritizing/planning week (PP week) I'll be planning what needs to get done next. I'll also be allowed to work on pure engineering / technical infrastructure work that isn't user facing.

Things like as improving deployment scripts or our CI setup, or automating different parts of my development workflow.

Anything that invests in our ability to produce long term - but isn't necessarily an immediate problem that needs to be taken care of.

Having this dedicated week gives me the time and space to invest in tech that will increase our development speed and reduce friction - but all in a defined chunk of time so that I have to pick and choose what I invest in now vs. what can come in future planning weeks.

Produce Weeks

The next 5 weeks are produce weeks. This is when I execute on the prioritization/planning that happened during PP week and build things that will have a direct impact on players.

This will usually be things such as working on art assets, adding a new area to the game, building new things to do in the game or really anything that provides an immediate benefit to players.

This isn't to say that no engineering/technical investments will happen in this time - but if they do they'll only be ones that are absolutely necessary and are blocking other Produce work. An example of this would be deploying a server to accept payments. In order for players to be able to sign up and pay for the game I'd need to create a way for them to do so.

While doing so I might notice ways that I might refactor the deployment process for faster deploys. That would then be something that I'd note and save for a future PP week.


PP week is for prioritizing and planning as well as projects that aren't immediate wins, and the product weeks are for delivering gameplay and features that players will love.

I'm hoping that this new structure will help me focus on doing the right things at the right times, and I'm sure that as we go we'll notice little tweaks that we can make to the process to make it more and more efficient and tailored to how I work best.

Next Week

By next week I'll have the payments server working so that players can pay for the game (although there's certainly work left to make it even worth paying for).

I'll also build the first version of the equipment interface so that you can equip and dequip items in the game.

I'll be starting off the first Super Cycle on the first Sunday in April, so until then I'll continue to build features and think a bit more about how I want the cycle to look.


Cya next time!

- CFN

027 - Mar 3, 2019

Hey!

It's been two weeks and I've gotten a lot done - but sadly nothing that you can see and play with.

Fixing the texture atlas compilation process

I got a new laptop towards the end of January, and in February I noticed that by texture atlas compilation script wasn't working properly.

It was generating all black for all of my textures, whereas it used to generate the expected colors.

#Before psd crate Some sort of weird issue while using imagemagick for my Photoshop exporting script.

After some time I started working on my own .psd file parser and ended up publishing it on GitHub at the psd crate.

#After psd crate After porting my compilation process to using psd under the hood.

Website

I wrote a library called Percy mid 2018 so that I could use Rust to build Akigi's website.

Of course - this means that anytime I need new functionality that doesn't exist I need to go and add it.

This time around I needed to add a procedural macro for creating routes.

I've gained a bit of proc macro experience recently so this only ended up taking a weekend.

Financials

Our financials for February 2019 were:

item cost / earning
revenue +$0
aws -$33.03
photoshop -$10.65
--- ---
total -$43.68

Next Week

There are two things needed to be able to work on the game full time:

  1. The game is good enough that people are playing it

  2. The game is making money

In order for number 2 to even be possible, we need to implement billing/payments.

I'm going to focus on doing that this week, so that I can turn my entire focus back to making a game that's worth playing.


Cya next time!

- CFN

026 - Feb 17, 2019

Short update this week! I'll have more visuals next week!

I started the week by making it possible to mouse over the conversation text when talking to an npc and then clicking on it. That works like a charm.

Mid week I noticed that some tests were failing but I hadn't noticed because CI has been red for months ever since I did a big refactor. So I fixed some stuff and CI is now green again and I won't let that slip again.

Cleaned up the integration test for the first quest a bit and now it's much more readable. Previously the steps were inlined in one functionn but now they're split up to one function per step which in turn call their own sub functions when necessary. Much easier to maintain.

Along the path to green CI noticed that one of my tests for converting some PSDs into a texture atlas was failing. At which point I noticed that the script was no longer working properly and was just generating a black texture atlas.

Narrowed it down to imagemagick - think it's because I got a new laptop that's running a new version.

Tried to find an old version of imagemagick and couldn't. Didn't feel like building from source and permanently depending on an old version. Also tried googling for a couple hours to figure out how to export layers in later versions imagemagick as well as researching other tools but nothing that I wanted to use turned up.

So I opened up the PSD spec and started working on a crate to turn a PSD file into a data structure that I can make use of. I worked on it a bit and now have it working well right now. Going to use my free time today and tomorrow to create a little demo and then open source it.

Then I'm right back to working on the game client's gameplay and graphics.


See ya next time!

- CFN

026 - Feb 17, 2019

Short update this week! I'll have more visuals next week!

I started the week by making it possible to mouse over the conversation text when talking to an npc and then clicking on it. That works like a charm.

Mid week I noticed that some tests were failing but I hadn't noticed because CI has been red for months ever since I did a big refactor. So I fixed some stuff and CI is now green again and I won't let that slip again.

Cleaned up the integration test for the first quest a bit and now it's much more readable. Previously the steps were inlined in one functionn but now they're split up to one function per step which in turn call their own sub functions when necessary. Much easier to maintain.

Along the path to green CI noticed that one of my tests for converting some PSDs into a texture atlas was failing. At which point I noticed that the script was no longer working properly and was just generating a black texture atlas.

Narrowed it down to imagemagick - think it's because I got a new laptop that's running a new version.

Tried to find an old version of imagemagick and couldn't. Didn't feel like building from source and permanently depending on an old version. Also tried googling for a couple hours to figure out how to export layers in later versions imagemagick as well as researching other tools but nothing that I wanted to use turned up.

So I opened up the PSD spec and started working on a crate to turn a PSD file into a data structure that I can make use of. I worked on it a bit and now have it working well right now. Going to use my free time today and tomorrow to create a little demo and then open source it.

Then I'm right back to working on the game client's gameplay and graphics.


See ya next time!

- CFN

025 - Feb 10, 2019

For the past nearly three years the focus has been on setting the technical foundation for the game, but of late we've switched to working on gameplay and things that players see and interact with.

Along that vein, one of the first things that I added this week was some basic lighting.

Before after lighting Before and after adding our basic lighting.

The depth that was added to the scene from this basic lighting was a pleasant reminder about how small graphical enhancements can make a world of a difference.

I'm still not sure about the exact visual style that I want for the game, but I keep visualizing darker tones so I'll need to experiment with and explore that direction to see if I land on something that fits what I want to communicate with the game.

Fixing Terrain Bugs

Next up I fixed an issue that was causing entities to be rendered below the terrain.

Our terrain is comprised of a grid of tiles, each tile being two triangles.

When rendering an entity we'll figure out what tile it is on, and which of the triangles within that tile that our entity is currently above.

From there we'll create a ray at the entity's (x,z) coordinates that is above the terrain and pointing downwards.

We use this ray to run the watertight ray-triangle intersection algorithm against the triangle that the entity is above in order to find out the y coordinate of the terrain at the player's current location.

Then we render the player at that y coordinate. This way as an entity moves around it is always rendered on top of the terrain.

We've had this could in place for at least a couple of months but it wasn't working. The player would just jump above or below the terrain.

I figured out that it was due to a floating point precision issue. Instead of being rendered at a height of say, 1.91 or 1.45, the height was always 1.0 or 2.0.

Remember how I said that I was casting a ray downwards. Well I was setting the origin as some really large number. So large that there wasn't enough precision in our calculation.

Simply dropping that number to a more reasonable ray origin of 99 fixed the issue. We just need an origin that is always above the terrain, and right now our highest terrain height is 1.96 units.

The terrain code had tests but they weren't as extensive as other parts of the client since they were written when I first first getting used to testing the game client. Had there been better tests this bug likely would've never happened.

All in all took about an hour to track down.

Chatting with NPCs

I then got started on the conversation panel that you see when you talk to an npc.

Chat with NPC Starting a conversation with an entity. You're supposed to be able to click to select a response but I haven't added that interaction yet.

A conversation with an npc is a graph. Each node in the graph has the text that the player or npc has spoken and then a vector of responses.


# #![allow(unused_variables)]
#fn main() {
// Some of our types that power conversations with npc's
// These were written before I started more extensively commenting..
// So I'll have to circle back to explain these fields with comments..

#[derive(Deserialize, Debug, Default)]
#[serde(deny_unknown_fields)]
pub struct ConversationGraph {
    pub nodes: HashMap<u16, ConversationNode>,
    pub start_nodes: Vec<u16>,
}

// TODO: Make fields private
#[derive(Deserialize, Serialize, Debug, Default, Clone, PartialEq)]
#[serde(deny_unknown_fields)]
pub struct ConversationNode {
    pub text: String,
    pub speaker: Speaker,
    pub responses: Vec<Response>,
    #[serde(default)]
    pub weighting: u8,
    pub criteria: Option<EntCriteria>,
    /// Reaching this node advances the entity to another step in a quest
    pub quest_advance: Option<Quest>,
    /// Items that you receive when you reach this conversation node
    #[serde(default)]
    pub receive: Vec<InventItem>,
    #[serde(default)]
    pub consume: Vec<InventItem>,
}
#}

In the gif above there is only one response, but different nodes in that conversation will have multiple responses to choose from.

That conversation is already written out, I just couldn't show it because I haven't finished adding the client side functionality to be able to click the respond and advance in a conversation.

As mentioned last week, our user interface code is still young so I'm still feeling my way into the correct abstractions to be able to add new interactive interfaces quickly.

For now I just implement exactly what I need and then if I've seen the same pattern a few times I'll abstract it. That is just to say that after we build a few more interfaces we'll have a better sense of how to quickly build new interfaces going forwards.

Centering Text

One new bit of functionality that I needed was being able to center text.

My original plan was to write a method to iterate over the glyphs that I was going to render, find the midpoint and then shift the glyphs to be centered at that midpoint midpoint, but just as I got started I remembered that there is an existing library that does this.

So I migrated from rusttype to glyph_brush. glyph_brush uses rusttype under the hood so I felt confident that it would all work fine.

I ended up just reading the glyph_brush example and then figuring out how to make use of it in our code. This went mostly smoothly minus some caching issues that ended up just being due to glyph_brush's' default hashing algorithm having collisions on 32 bit systems. WebAssembly is 32 bit.

Tests

I'm really appreciating our tests. I've fallen into a routine where I can build out complex functionality without needing to run the game in the browser.

Then at the end I'll fire up the game and visually verify that everything works (since you can't trust fully a test until you've seen what it's testing).

Personal

I spent Saturday getting a physical and then hanging out with my sister and her husband so didn't spend as much time working on the game this weekend as usual.

Didn't finish all of the interactions so you can't actually click on the responses yet.

I'll get that working this week and continue to work on the game client. My focus right now is making it possible to finish the first quest in the game client.

We have an integration test for this quest so it definitely works on the backend, so we'll mainly need to add the user interface and graphics in order to complete it on the frontend.

This means that you'll be seeing lots more visual improvements over the coming weeks!


See ya next time!

- CFN

024 - Feb 3, 2019

Lately I've felt like I've been at peek focus and the progress has been compounding.

Sure, there's still plenty of room for me to get better at prioritizing what I work on and just generally working smarter not harder, but that aside I'm really enjoying feeling more and more on track to turning Akigi into an awesome game.

I feel as if I'm beginning to see the light at the end of the tunnel in terms of being able to release an early version of the game and have people play it while I improve it over time.

Which is strange because if you were to pull up the game right now you wouldn't see much. Just some placeholder graphics that are hard to even make sense of.

Game WIP The current state of the game client.

But behind this embarrassing simplicity is years of iterating on the code and tools that make it easier for me to add gameplay, and they're finally converging to a place where I can see the power.

That isn't to say that I'm not just going to magically have a great game. I still need to do a good job of executing on game design and the feeling of the world and gameplay.

Plus, even today I have more places to enhance, improve and simplify my codebase and tooling than I can reasonably prioritize any time soon.

No, I think that this great feeling is just coming from working on gameplay feeling easier and less painful than times past.

Since Rust makes it so easy to refactor I'm finding that over time my codebase is getting easier to work in and I'm getting faster.

Instead of being slowed down by the technical debt that can accrue as you build your own game engine, I'm empowered to address it when the burden grows to great without worrying about accidentally breaking things.

Terraform

Since my last journal entry I've gotten the terraform config working and am using it in production.

My EC2 instance, subnets, VPCs, Route53 DNS records and a few other resources are all specified in my .tf files and it's a breathe of fresh air.

I was able to delete quite a bit of documentation on setting up servers for the game in favor of configuration files and scripts.

As with everything there's more room to automate my dev-ops and deploy processes over time, but getting my infrastructure into terraform config files was one great step forwards.

Equipment

One of the next big things that I want to add into the game client is a frontend into the equipment system.

I've had the backend in place for a couple of weeks now but haven't spent as much time on the frontend as I need to.

I've started using Figma to design the front-end interface.

The code for rendering interactive interfaces in my engine is still a bit young so the next few interfaces are going to take a little longer than they should going forwards.

Even so, I'm still excited to make these enhancements and start making some progress on the interface front.

Game Figma Using Figma to design the game interface and figure out how to lay things out.

Financials

Our financials for January 2019 were:

Item Cost / Earning
Revenue +$0
AWS -$30.55
Photoshop -$10.65
New Laptop -$4990.83
--- ---
Total -$5032.83

The big expense from January was purchasing a new laptop. I bought one because:

  1. My old one didn't have enough disk space so I was frequently deleting things to make space. Mainly my target directories across a few of my Rust projects. (I didn't want to deal with an external hard drive.)

  2. I wanted compiling Rust / my IDE experience to be faster.

Both problems are now solved. The speed is great for maintaining focus and just generally feeling less bogged down while I work.

A big expense though.. I'll need to come back to this when filing my taxes....

Next Week

A few months ago I re-factored the networking protocol for the game and that led to needing pretty much the entire codebase to change since it was previously coupled to protocol buffers (which I no longer use).

At the time I fixed almost everything, but there's still a little bit of code that I haven't fixed from that refactor.

One being the code for conversations and the integration test for the first quest in the game.

So for next week I'm going to have that quest working and add as many graphics as I can to the game in support of that quest.

If all things go smoothly you should see some graphical enhancements to the game client throughout the week and especially by next week.

I'll also continue to work on the design for the equipment frontend so that I can focus in on building that next week.

In general I'm turning a lot of attention towards the game client. My goal is to release a playable version of the game on March 10th and then start iterating in public.


See ya next time!

- CFN

023 - Jan 20, 2019

Back at it again!

Last week I worked on the equipment system that allows players (and some entities) to wear and hold things such as clothing and weapons.

I got almost all of the backend finished, but there's still work left to be done on the front end.

I also did some work on the assets / graphics side of things.

I made a human rig in Blender and made a basic walk animation. It'll certainly need to get re-done, but it's enough to get an alpha of the game live.

I also made a quick mesh for a human - again just to have something in place for an alpha release - it'll need to get re-done and polished.

After that I spent a little time optimizing my script that exports assets from Photoshop into a texture atlas and from Blender into the binary format that my game uses. I used rayon to parallelize the collapsing and exporting of my PSD layers into PNG files, but the real savings came from running a release build of my asset compiler instead of a debug build. This brought me from 15-20 seconds to a few seconds.

In the future when I revisit these asset compiler optimizations I'll implement caching so that we don't re-process assets that have already changed, but I'm not sure when I'll take a look at that.

Next Week

  • Finish my terraform setup so that my infrastructure is fully in source control

  • Build out the equipment frontend so that players can equip and dequip items.

  • Introducing lighting to improve the look and feel


See ya next time!

- CFN

023 - Jan 20, 2019

Back at it again!

Last week I worked on the equipment system that allows players (and some entities) to wear and hold things such as clothing and weapons.

I got almost all of the backend finished, but there's still work left to be done on the front end.

I also did some work on the assets / graphics side of things.

I made a human rig in Blender and made a basic walk animation. It'll certainly need to get re-done, but it's enough to get an alpha of the game live.

I also made a quick mesh for a human - again just to have something in place for an alpha release - it'll need to get re-done and polished.

After that I spent a little time optimizing my script that exports assets from Photoshop into a texture atlas and from Blender into the binary format that my game uses. I used rayon to parallelize the collapsing and exporting of my PSD layers into PNG files, but the real savings came from running a release build of my asset compiler instead of a debug build. This brought me from 15-20 seconds to a few seconds.

In the future when I revisit these asset compiler optimizations I'll implement caching so that we don't re-process assets that have already changed, but I'm not sure when I'll take a look at that.

Next Week

  • Finish my terraform setup so that my infrastructure is fully in source control

  • Build out the equipment frontend so that players can equip and dequip items.

  • Introducing lighting to improve the look and feel


See ya next time!

- CFN

022 - Jan 13, 2019

Hey!

I missed last weeks dev journal post, but I was finally able to get my WebGL Water Tutorial published and get back into working on Akigi.

The first order of business this week was migrating from my own hand written web bindings in my Rust code to instead using web_sys.

When I first started writing the Rust web client for the game web_sys didn't event exist, but nowadays it's very robust. I more or less ended up using my water tutorial as a guide since it has working web_sys code and then fumbled around for a few hours fixing compile time errors until everything worked again.


After porting to web_sys I spent some time improving my dev ops. As the sole developer on Akigi it's important for all of my processes to be as automated as possible so incremental improvements now will pay off in spades long term.

I started using terraform to create configuration files for managing my infrastructure.

The immediate benefit here is that since I've ported almost all of my old manual process for setting up new AWS resources into configuration files that terraform uses to automatically provision and updated my infrastructure I can now add and modify resources very easily.

This was previously a point of friction that would make me put off things like spinning up the server application for processing payments.

Learning Terraform Me going through the Terraform tutorial

Terraform was very easy to learn and get started with and, while my infrastructure is currently on AWS, it makes it possible to be multi-cloud in the future since it isn't coupled to a single provider.

I also wrote a quit script to deploy the game assets to s3. I was previously drag and dropping them and would often forget to do this when I pushed up a new version of the game.

There's still much more room for improvement on the dev ops side... But we'll continue to approach these enhancements incrementally over time.

Next Week

With those code and process improvements out of the way I've started diving into working on things that you can actually see!

Next week I'll be working on the equipment system and making it possible to render multiple pieces of equipment for a single player.

By the end of the week I'll have a human rig animating a few placeholder models as well as the equipment systems in place on the front-end and the back-end.

This means that the game world will finally have something that resembles a character. It'll be ugly and have poor texturing, but that I can clean up over the rest of this month.


See ya next time!

- CFN

021 - December 23, 2018

Still working on the water rendering tutorial. Just polishing up the art for it. It'll be live by next week.


See ya next time!

- CFN

021 - December 23, 2018

Still working on the water rendering tutorial. Just polishing up the art for it. It'll be live by next week.


See ya next time!

- CFN

020 - December 16, 2018

Hey!

This past week I was supposed to work on rendering water in the game.

I've made quite a bit of progress, but there's still some work left to do.

Progress on water renderer Water renderer is mostly working, just need to soften up the water's edges using a depth texture.

We still need to make sure that we're setting the water's transparency based on the depth of the water. This will help make water near the shore more transparent than areas of the water that are deeper.

I'm planning to write a tutorial on everything that I learned about rendering water, so realistically it should take a little over another week before we see any water in the game.

Regardless, a lot of the techniques that we're learning will help us in all of our graphics implementations going forwards, so cheers to progress!

Next Week

I'm going to continue working on the water renderer, write up the tutorial and start getting it integrated into the game.


See ya next time!

- CFN

019 - Dec 09, 2018

Hey!

This past week I was supposed to begin working on rendering water in the game.

I've never written a water renderer before so I've had to do a bit of Googling to figure out how it should work.

After I felt like I had a firm grasp of the concepts I began working on creaing my own water rendering tutorial.

When learning new graphics programming concepts I find it helpful to write a tutorial on the topic.

This gives me a greenfield fresh application to write without worrying about any other surrounding code, as well as the opportunity to really solidify my understanding by having to explain it to others.

So far I have a blue quad that will eventually become water, and a camera controlled by the mouse.

Inventory This blue quad will eventually become water.

I also started working on a scene in Blender that will be included in the tutorial. Since water is reflective we want to render other things in order to demonstrate that.

Inventory Started working on a scene in Blender to render the water onto. This will allow us to demonstrate reflection and refraction.

Next Week

I'm going to continue working on the tutorial and should have something in place by the end of the week. After that I'll begin integrating the water renderer into the game!


See ya next time!

- CFN

018 - Dec 2, 2018

This past week I was supposed to plan out everything for the game's release.

Made some progress but there's still a bit left. I'm going to pause here though since I have a good roadmap in front of me and am getting a little tired of planning.


This week I'll be working on rendering water in the game.

I haven't written a water renderer before so this might take more than just this upcoming week since I'll need to do some research.

Regardless, next week I'll show you the progress on the water renderer!

Financials

Our net loss for the month of November was $41.12.

Item Cost
Revenue +$0
Photoshop -10.65
AWS -30.47

See ya next time!

- CFN

017 - November 25, 2018

This past week I was supposed to work on a billing server so that players can pay for the game.

I used Rocket, stripe and stripe-rs to get it working and every wrote a couple of integration tests!


I'm now turning my entire focus towards planning out the remaining work left to finish and polish the first release of the game. The goal is to have a concrete, detailed action plan and then stay heads down on bringing it into fruition.

I wanted to get that finished today but started to feel a bit sluggish over the weekend, so I'll spend all of this week finishing up my plan and by next week I'll have a very clear sense and timeline for what's left for launch.


See ya next time!

- CFN

017 - November 25, 2018

This past week I was supposed to work on a billing server so that players can pay for the game.

I used Rocket, stripe and stripe-rs to get it working and every wrote a couple of integration tests!


I'm now turning my entire focus towards planning out the remaining work left to finish and polish the first release of the game. The goal is to have a concrete, detailed action plan and then stay heads down on bringing it into fruition.

I wanted to get that finished today but started to feel a bit sluggish over the weekend, so I'll spend all of this week finishing up my plan and by next week I'll have a very clear sense and timeline for what's left for launch.


See ya next time!

- CFN

016 - November 18, 2018

This past week I was supposed to continue working on the combat system and have something working that you could see.

Fortunately we were able to get the basic systems in place!

Inventory Engaging in combat with another entity.

Combat Backend

Combat between two entities ends up being powered by a few different systems.

The CombatSystem is responsible for determining whether or not an entity is allowed to attack another entity, and if it is setting the necessary state to indicate that they are in combat.

The DamageSystem is, unsurprisingly, called upon when we want to deal damage to an entity.

The SpawnSystem, which originally powered spawning different entities, is now also used to begin the respawning process when an entity runs out of health.

And then finally the MovementSystem is called upon when you're out of range of the entity that you are targeting.

We implemented a new method in the MovementSystem that allows you to find a path that is between a certain distance away and near some position, which will be useful when we want certain attacks to only work within certain distance ranges. Such as a ranged attack that requires you to be at least 2 tiles away but no greater than 10 tiles away.

Combat Frontend

We didn't have to do very much to get the frontend working, which felt great because it showed that we're starting to have the foundational pieces in place that make it easier and easier to add new functionality.

We made it so that when you click on an entity with the Attackable there will be an option in the interaction menu to attack that entity.

Inventory Clicking on an attackable entity shows an Attack option.

We also made it so that when an entity takes damage we'll temporarily show a health bar above their head, so that you can more clearly see how much health they have remaining before you've won the battle.

Inventory After taking damage we'll temporarily show a health bar.


As with most of the other frontend work thus far, I'm using placeholder graphics as I get things into place. When we're closer to release we'll need to do several passes over these graphics to get them more production ready.. But for now having just enough visually to see things work is fine.


I also started working on a server to allow players to sign up for a monthly subscription for the game. Since the game needs to make money in order for me to be able to work on it more, it makes sense to start getting a billing backend in place.

Next Week

By next week I'll have the billing server live and deployed and it will be possible to pay for the game. Granted, we don't even have production quality graphics or gameplay in place yet so we're a bit of a way from the game actually being worth paying for.

However, I'm hoping that making it possible to sell the game will help me stay focused on the things that are necessary for release (and thus revenue.. and thus more time to continue working on the game) vs. things that are important but not mandatory and can be improved after release.

We want to release quickly and iterate on and improve the game.

We'll also plan out the first city in the game so that we can start getting it into place.

Now that many of our backend and frontend modules are in place it should hopefully be easy to continue to extend them to support more interesting gameplay.

Building the first city and all of the things to do in it will put these systems to the test and we'll extend and improve them as we go.


See ya next time!

- CFN

015 - November 11, 2018

This past week I was supposed to get the combat system in place.

I made a good bit of progress on the backend implementation, but nothing that would be visible to you.

Things such as building out a CombatSystem DamageSystem and SpawnSystem to power the different elements of combat.

I'll need a bit more time to finish up the backend and get the frontend in place.

Next Week

I have a vacation coming up next week so I'll have some larger chunks of time to make progress on Akigi.

By next week I'll have new things for you to see. Until then take care!


See ya next time!

- CFN

014 - November 4, 2018

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.

Inventory 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 InventoryError::NoInventory failure.

Inventory Making use of the failure crate


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.

The Inventory System

On the back-end we have an InventorySystem and 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.

Inventory 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.

Future Tooling Thoughts

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.

Financials

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!

Item Cost
Revenue +$0
Photoshop -10.65
AWS -29.73

Next Week

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!

- CFN

013 - October 28, 2018

This past week I was supposed to work on the inventory system and plan out the payment system that will allow people to pay for the game.

I'm made almost no progress this week. Just about every day I had some work or friend event to attend.

A bit disappointing.. but I'll try to make up for it by having a very focused week this week.

This has been a few weeks straight of accomplishing less than I had expected due to external distractions, which suggests that I need to figure out how to re-focus and stay on track.

I have the designs and plans for the inventory system - so by next week I'll make sure to have it all working.

Sketch file The sketch file where I work on the game designs before I implement them.

See ya next time... hopefully with much more progress!

- CFN

013 - October 28, 2018

This past week I was supposed to work on the inventory system and plan out the payment system that will allow people to pay for the game.

I'm made almost no progress this week. Just about every day I had some work or friend event to attend.

A bit disappointing.. but I'll try to make up for it by having a very focused week this week.

This has been a few weeks straight of accomplishing less than I had expected due to external distractions, which suggests that I need to figure out how to re-focus and stay on track.

I have the designs and plans for the inventory system - so by next week I'll make sure to have it all working.

Sketch file The sketch file where I work on the game designs before I implement them.

See ya next time... hopefully with much more progress!

- CFN

012 - October 21, 2018

This past week I was supposed to work on client side interpolation as well as plan out the monthly subscription system so that people can pay for the game when it's released.

I spent Thursday - Sunday at the Rust Belt Rust conference and spent the few days before that working on Percy since I was speaking about it at the conference, so I actually didn't spend much time working on Akigi this week.

However - I was able to get the client side interpolation working on the plane ride back to the city.

Interpolate position Interpolate the client's position as it moves in between tiles. The vertical jerking is a bug in our terrain height calculation. I'll fix that..

I'm pretty tired from this weekend so I'll be short here.

Basically - our server tells us where an entity is in tile coordinates such as (0, 0) or (0, 1) for the bottom left corner tile and the tile right above it respectively.

On the client side we keep track of the 3d world coordinates that we're rendering the model at - such as (0.0, 0.0, 0.0).

If we see that the tile position of the entity is at a different location than our world coordinates, we'll interpolate towards it.


# #![allow(unused_variables)]
#fn main() {
// Real code snippet
impl State {
    fn update_local_entities(&mut self, dt: f32) {
        for (entity_id, server_entity) in self.server_state.iter_entities() {
            let local_entity = self.local_state.entities_mut().get_mut(entity_id).unwrap();

            let tile_pos = server_entity.get_pos().unwrap();
            let tile_pos = (tile_pos.x as f32, -1.0 * tile_pos.y as f32);

            let mut world_pos = local_entity.pos_mut();

            // This entity is already in the proper position. Don't update its position.
            if tile_pos.0 == world_pos[0] && tile_pos.1 == world_pos[2] {
                continue;
            }

            let speed = (1.0 / GAME_TICK_DURATION as f32) * dt;

            // TODO: This code is very similar to the block below - normalize them
            if (world_pos[0].abs() - tile_pos.0.abs()).abs() < speed {
                world_pos[0] = tile_pos.0;
            } else if world_pos[0] < tile_pos.0 {
                // Increase local position
                world_pos[0] += speed;
            } else {
                // Decrease local position
                world_pos[0] -= speed;
            }

            if (world_pos[2].abs() - tile_pos.1.abs()).abs() < speed {
                world_pos[2] = tile_pos.1;
            } else if world_pos[2] < tile_pos.1 {
                // Increase local position
                world_pos[2] += speed;
            } else {
                // Decrease local position
                world_pos[2] -= speed;
            }
        }
    }
}
#}

So if the tile position is (0, 1) we'll slowly interpolate the client position towards (0.0, Y, -1.0).

Note that Y is a variable that depends on the height of the terrain at a given point.

Also note that the z coordinate is negative. In OpenGL negative z is going into the page, but our tile coordinates only use positive numbers so we just flip the sign here.

Next Week

By next week I'll plan out the payment system (likely using Stripe) and build out the backend and frontend for the inventory system that will hold your items.


See ya next time!

- CFN

011 - October 14, 2018

This past week I was supposed to work on the akigi.com website for the game.

A day or two into the week I completely ditched that goal. I quickly realized that "working on the website" wasn't a definitive clear task.

I had no real end goal or target to aim towards and that's always a recipe for disaster.

It was a poor goal for the week and I'm glad that I was lucky enough to sense this before burning much time.


Instead, I switched to a goal of implementing movement. And we got that working!

Movement Click to move to another tile.

I first started by working on the backend. In the client request handler I added a new handler for movement.

When a player says that they want to move to a certain location we'll process that and if it's a valid location we'll set the player on a path in that direction.

Move to code Handling clients requesting to move to a location.

This is generally how much of our future functionality will be handled. A player says that they want to do something and then we handle that request and change server state accordingly.


After getting the backend in place I started to work on the client side of things. A player needs to be able to click on a tile and then click "Move Here" in order to tell the server that they want to move.

Move here interaction Move here interaction.

This led to me refactoring and enhancing my terrain implementation to more easily retrieve information about our terrain tiles so that we could do collision detection.

I added a few new utility functions including an implementation of watertight ray triangle intersection, a function to determine the ray that the player's mouse is casting into the scene and various other bits to help us know which tile is being moused over.

Tiles between implementation Utility function to give us all of the tiles between two points to reducer the number of tiles that we need to do mouse ray collision detection against.

Throughout the client side implementation I ran into several bugs where my tests were passing but the moused over tile detection wasn't working properly when I tried it in game.

I eventually started rendering some runtime debug information and was then able to quickly see that my unit tests were flawed and I was expecting off by one information in some places.

Runtime diagnostics Rendering information about the hovered over tile helped me to eventually figure out why things weren't working and fix it.

My big takeaway from the weekend was that I need to do a much better job of having runtime diagnostic information in place so that I can pick up on things that my unit and integration tests might not be showing me.

Next Week

I'll be speaking at a Rust conference this weekend to speak about Percy so I'm not expecting to get much work done on the game.

By next week I'll implement client side interpolation of our entities' positions and plan out our monthly membership subscription implementation so that people can pay for the game after we release it.


See ya next time!

- CFN

010 - October 7, 2018

Hey!

This past week I was supposed to implement the first version of the public chat system and continue planning out the remaining tasks for releasing the game.

This was my second week in a row of spending much less time on the game than I'd like. I moved on Monday and spent the next couple of days getting my things in order.

I got back to working on the game on Thursday and tried my best to make up for lost time.

Public Chat Chat that you enter appears over your characters head for all to see.

When a player types in a chat message and presses enter we'll send that up to the server. Other players will see your message above your head for a couple of seconds before it disappears. Conceptually simple, so the main work was to just get some basic systems in place to cleanly power features like this.

Getting screen coordinates A function to get screen coordinates from world coordinates so that I can render the 2D text right above the 3D character's head.

Financials

Our net loss for the month of September was $240.84! Probably one of my largest losses yet due to two annual subscriptions that I started.

Item Cost
Revenue +$0
AWS -30.89
Ngrok -$60.00
SSLMate -$149.95

Two big yearly payments for this month. One for $60 for ngrok which we're using to make it easier to test the game on mobile devices. The other is $149.95 for a wildcard SSL certificate. I de-activated the 5 or 6 SSL certificates that I had in favor of this yearly one. Just less to worry about whenever I add new subdomains that need SSL (which seems to be happening every couple of months..)

We have a monthly photoshop cost of $10.65 but that didn't land until October 1st so that'll be reflected in next month's report.

Next Week

I'll be traveling to go speak at a Rust conference in a couple of weeks about my young but progressing Rust front-end web library Percy.

So this means that this week is a good opportunity to work on the akigi.com website which is powered by Percy. I'll be mapping out on paper how I want it to look and then working on the site.

For some places where I'll want to highlight images of the game I'll leave a placeholder image in lieu of adding a more polished screenshot when I make some progress on the graphics.

I'll also continue working on planning out the remaining work for releasing the game.


See ya next time!

- CFN

009 - September 30, 2018

Hey!

This past week I was supposed to implement terrain rendering and make more progress on planning out everything that's left to do before the initial release of Akigi.

I was off my routine a bit since I was at my job's team trip for most of the week, but luckily I still managed to make some progress.

Rendered Terrain We render our terrain using a heightmap and multi-texturing it with a blendmap.

Our terrain is a grid of triangles with the y dimension for each vertex determined by sampling from a height map image.

When we render the terrain we sample from a blend map and use the sampled blend map color to determine the weightings of four different ground textures for that fragment (currently grass, stone, water and dirt but those are placeholders).

When we render entities such as players we ask the Terrain struct for the height at the location of the entity and use that to determine the entity's y coordinate in the world.

This ensures sure that an entity is always rendered just on top of the terrain even though our terrain has varying heights.


I didn't get much planning done during the week due to travels, but I ended up making up for this on Saturday and Sunday. Our release planning is progressing nicely and I have a much clearer sense of the remaining work.

More release planning When I'm finished planning a task I give it a pink "Fully Planned" label.

At our current pace I'm expecting to be done planning in mid October and then ready for release around mid December.

Right now these are estimates based on the planning that I've done so far.

When I'm done planning out my release tasks I'll have a much more concrete sense of the exact release date.


On Saturday I took a little time to smooth out some of the deployment process. I now have a script to automatically deploy the game's web client. Needing to manually run commands and drag and drop files into AWS S3 was becoming a bit of a hassle since I deploy once a week right now.

I also purchased a wildcard SSL certificate for *.akigi.com, replacing my old individual certificates.

Next Week

Next week I'll continue planning out the remaining items in my release checklist. It feels like we're roughly 1/3rd of the way through planning out our release tasks so if we can get it to 50% by next week that will be wonderful.

I'll also implement the pieces of the chat system that I want in place for release - namely being able to enter chat text on desktop and have it appear above the players head.

I'm going to hold off on implementing chat on mobile devices and displaying recent messages in a chat box until after release.


See ya next time!

- CFN

009 - September 30, 2018

Hey!

This past week I was supposed to implement terrain rendering and make more progress on planning out everything that's left to do before the initial release of Akigi.

I was off my routine a bit since I was at my job's team trip for most of the week, but luckily I still managed to make some progress.

Rendered Terrain We render our terrain using a heightmap and multi-texturing it with a blendmap.

Our terrain is a grid of triangles with the y dimension for each vertex determined by sampling from a height map image.

When we render the terrain we sample from a blend map and use the sampled blend map color to determine the weightings of four different ground textures for that fragment (currently grass, stone, water and dirt but those are placeholders).

When we render entities such as players we ask the Terrain struct for the height at the location of the entity and use that to determine the entity's y coordinate in the world.

This ensures sure that an entity is always rendered just on top of the terrain even though our terrain has varying heights.


I didn't get much planning done during the week due to travels, but I ended up making up for this on Saturday and Sunday. Our release planning is progressing nicely and I have a much clearer sense of the remaining work.

More release planning When I'm finished planning a task I give it a pink "Fully Planned" label.

At our current pace I'm expecting to be done planning in mid October and then ready for release around mid December.

Right now these are estimates based on the planning that I've done so far.

When I'm done planning out my release tasks I'll have a much more concrete sense of the exact release date.


On Saturday I took a little time to smooth out some of the deployment process. I now have a script to automatically deploy the game's web client. Needing to manually run commands and drag and drop files into AWS S3 was becoming a bit of a hassle since I deploy once a week right now.

I also purchased a wildcard SSL certificate for *.akigi.com, replacing my old individual certificates.

Next Week

Next week I'll continue planning out the remaining items in my release checklist. It feels like we're roughly 1/3rd of the way through planning out our release tasks so if we can get it to 50% by next week that will be wonderful.

I'll also implement the pieces of the chat system that I want in place for release - namely being able to enter chat text on desktop and have it appear above the players head.

I'm going to hold off on implementing chat on mobile devices and displaying recent messages in a chat box until after release.


See ya next time!

- CFN

008 - September 23, 2018

Hey!

This past week I was supposed to start making progress on planning out everything that I need to do in order to put out the first release of Akigi.

I was also supposed to implement terrain rendering.


I fell very short on my goals this week.

When deciding on what I wanted to get done I completely forgot that we were taking a team trip to Oklahoma at my job.

I arrived here on Friday and won't be back home until this coming Friday.

Travels put a bit of a damper on my progress and I ended up doing less release planning than I had hoped to. I didn't start on the terrain renderer until Sunday and I haven't finished.

Going forwards I'll need to be a better job of paying attention to how much time I'll have available in throughout the week while I'm deciding on what I want to get done.


My process for release planning has been to keep a list of things that I need to get done in a Trello board, plan them out on paper, then type out an implementation checklist onto the relevant Trello card.

Release checklist in Trello Working on planning out everything for launch.

When a card if fully planned it gets a pink Fully Planned label so that I can better see how much planning I have left.

Release checklist items Each card has a planned out checklist for how to complete it.

Depending on the scope of the task I'm finding that it can take anywhere from ten minutes to two+ hours to fully plan a card.

I'm noticing that I start to slow down a bit mentally when planning through one of the larger tasks, so I'll need to do a better job of breaking tasks down into smaller bite sized tasks that I can more easily hold in my head as I plan.

Next Week

I'll be in Oklahoma until Friday and am not expecting to get much done. This week I'll continue planning out my release checklist and finish the terrain rendering.

Next week we'll be backed to regularly scheduled programming and I should be able to make much more progress.


See ya next time!

- CFN

007 - September 16, 2018

Hey!

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!

Touch Controls Some text rendering and a simple skeletal animation.

Rendering Text

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.


Next Week

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!

- CFN

006 - September 9, 2018

Hey!

This past week I was supposed to update my blender-exporter and renderer to support textured meshes as well as add a placeholder 2D UI element that I'd render using WebGL.

For most of the week the wasm32-unknown-unknown target that lets you compile Rust code to WebAssembly was broken on MacOS which slowed me down a bit because I couldn't check to make sure that my textures were rendering properly.

On Monday I realized that I could use a docker image target wasm32-unknown-unknown on linux so after fiddling around a bit I was able to compile to WebAssembly.

By Thursday morning I was rendering to textures in my mesh visualizer program, and around 1:30am on Saturday I had my game serving a texture atlas that I was using when rendering meshes.

I have the process fairly automated. I save my meshes in Blender and my textures as PSDs and my build script automatically generates a binary with all of my meshes and a texture atlas with all of my textures. The meshes get de-serialized into a data structure that points to the associated texture's coordinates within the larger texture atlas so as I add or change textures and meshes it all just works.


On Saturday morning around 11:40am I got off the phone catching up with my mom and got started on some work. I needed to help my friend uptown around 4:15pm so between lifting, showering and getting ready I had about an hour and a half of the afternoon to make progress. I found a tutorial on rendering 2D sprites which was exactly what I needed to render 2D UI elements.

That first moment that I was able to log into the game on mobile and interact with it and all I needed was a URL was powerful for me. While there isn't much going on just yet, I had a strong feeling that being able to access the game on the web without installing anything and being able to just dive right in would be something special. I'm excited!


On Sunday at 2:38am I had a placeholder "menu" (empty white 2D untextured rectangle) showing up on click and disappearing when I moused out of it. All that was left was to update my touch controls to be able to interact with both the camera and this menu.

A 2d menu that we can mouse out of Clicking shows the menu (haven't added options to it yet) and mousing out of it dismisses it.

On Sunday morning I realized that I'd need to be able to access the game on a mobile device locally while I worked on it so that I could get a good sense of how it felt in mobile browsers. I signed up for Pro ngrok plan ($10/mo) and set up ngrok subdomains for my authentication, asset, game website and WebSocket servers and was able to access localhost from another device very easily.

Touch Controls Your first finger shows the menu, your second finger controls the camera.

Side note - I never knew you could plug your iOS device into your laptop and view the console. I had a rendering issue when I first accessed the game from my iPad but by viewing the web inspector I was able to find the issue and fix it within minutes.

Next Week

This week was a first for me since I'd never written re-usable 2D rendering functionality within a WebGL pipeline. In the past I had just used HTML and CSS on top of my WebGL canvas.

Next week will have another first - rendering text with WebGL. I'm going to try using rusttype since it has a few examples that I think I can adapt.

I'll also get vertex skinning / skeletal animation working in the game. I'll make a placeholder skeleton, mesh and animation and render this animation in the game.

Since I haven't rendered text before I'm not sure what stumbling blocks I'll run into.. so I'll just commit to these two things this week. Let's see where this goes.


See ya next time!

- CFN

005 - September 2, 2018

Hey!

This past week I was supposed to automate more or my mesh and texture build pipelines and add texture support to our client renderer. I knew that my sister's wedding would be during the weekend so I tried to make sure to underload my work for the week.

By Tuesday I had my placeholder meshes being automatically packed into a serialized hashmap of models and served to the client. I was successfully rendering the correct meshes for the correct entities by reading from this hashmap. Good early momentum!


But after early wins came some early losses. My version of photoshop that I.. uh.. found a few years ago stopped working right as I was about to create some placeholder textures. I spent a couple of hours trying to create some textures in Procreate (an iPad app) and eventually figured out a good system.

Even so, It was clear that photoshop + a mouse was mostly superior to Procreate + apple pencil, so I ended up buying the cheapest Photoshop plan for about $10.65/mo after taxes.

Going forwards my texturing workflow will be mostly based on Photoshop but I might use my iPad if I'm on the go or trying to hand draw bits of the texture using the Apple Pencil.


I spent Wednesday and some of Thursday working on automating the texture bits of my asset pipeline. Our textures are Photoshop PSD's with a different layer for different parts of a texture such as the hat, legs, arms or gloves of a model.

Texture Layers Photoshop Each piece of the (placeholder) texture has its own layer in Photoshop

Our build script takes all of these layers and merges them into a .png file. We then take all of these .pngs and combine them into a texture atlas. In the future we'll need more than one texture atlas, but one works for now.

In the future we'll also want to dynamically determine our texture png size based on the dimensions of the model that is using it. So tiny models would have proportionally tiny pngs.

PSDs to PNGs Convert PSD files into PNG files

This all worked great and by Thursday afternoon I had an automatically generated texture atlas that I was serving to the client.


Thursday evening and all of Friday I had wedding things for my big sis, but then Saturday afternoon I was able to get back to work. I made progress adding uv support to my blender-exporter library and quickly had an integration test and implementation for exporting my uvs from Blender.

I then wanted to update my mesh-visualizer that I use to visualize my test meshes to verify that my exported uv's looked correct (a last bit of certainty even though it is heavily tested.)

Unfortunately I upgraded to the latest nightly Rust and started having issues with the ``wasm32-unknown-unknown` target that powers by WebAssembly builds. I spent Saturday night and a good bit of Sunday morning trying to fix my issues but with no dice.

Eventually I decided to just wait a few days until (hopefully) the latest nightly works again. This is certainly a trade-off of working with bleeding edge tech. For now I'm only targeting WebGL so short of wipping up a quick desktop OpenGL visualizer I'm stuck waiting for a fix. No worries though, I'll just design next week's goals around this. In the meantime I can just continue TDDing my work so that by the time I need to manually look at the visuals they'll be easy to change / refactor if they didn't work as expected.

--

So I didn't finished getting my textures rendering in the web client this week and I'll have to just have this carry over into next week.

Next Week

I'm anticipating my wasm32-unknown-unknown target being broken until mid week so I'll factor that into my goals for the week.

Next week I will finishing updating blender-exporter to add support for uvs, start rendering textured models in the game client and add a WebGL UI menu that appears when you click or tap and disappears when you mouse away or tap again.

I haven't made UI elements with WebGL before since I previously always used HTML + CSS for the game's UI so this will definitely take more time than it would if I were more experienced. Monday is labor day giving me some extra time this week.

Financials

Our financials for the month of August were:

  • Revenue +$0
  • AWS -$30.89
  • SSLMate -$15.95
  • Photoshop -$10.65

For a grand total of -$57.49

August 2015 AWS AWS spend for August 2018


See ya next time!

- CFN

001 - Aug 5, 2018

Hey!

Last week I worked on the www.akigi.com website, as well as creating the devjournal.akigi.com website.

For the Akigi main website I’m using Percy, my work-in-progress toolkit for building web front-ends with Rust.

The Akigi main website is using placeholder images and doesn’t have all of the copy and information and pages that it will need, but getting something live is a good first step and I can iterate from there.


This week I’m going to work on getting an early version of the game live and “playable” on the Akigi website. I put “playable” in quotation marks because I’m going to port the game’s WebGL web client to Rust so I can’t imagine that in one week I’ll have too much more than a blank canvas.

I want the game live so that people can check it out and give feedback all throughout the development process up until release.

I’m porting game’s web client to Rust because after porting the back end to Rust in January 2018 (from JavaScript) I felt much more productive in the codebase and I hope to see the same gains on the client side.

Business & Financials

The first post of every month will include a business & financials update.

I July 2018 Akigi earned $0 in revenue.

As for expenses, I’m not sure.

I’m charging things to a couple different cards that I also use for my personal life so expenses are littered around by card statement. If I had to estimate I would say that I spend less than $50/mo on the game - mostly on Amazon Web Services.

I’ll get all of the expenses onto one dedicated card for easier tracking and reporting and come back with a more detailed breakdown next month.


See ya next time!

- CFN

004 - Aug 26, 2018

Hey!

This past week I was supposed to

  1. Have the backend serialize client state, send it down to the client and have the client deserialize those state updates.

  2. Render placeholder meshes at the locations of all of the entities in state.

  3. Add arrow key and touch controls for making the camera orbit your character.

Getting the state updates serializing/deserializing was pretty straightforwards. I used serde and bincode to send down the binary data over WebSocket.

Client World State The server and client crates both depend on a client-server-common crate with, among other things, this ClientWorldState struct.


Last week I was using the cgmath crate for my linear algebra but I wanted to move to nalgebra, mostly because it has really good documentation. (Side note I discovered nalgebra through GitHub's new recommendations on their homepage so thanks GitHub!)

Porting my math over to nalgebra took under an hour, the examples and documentation were top notch.

After that rendering my placeholder meshes was easy since, again, a lot of this is stuff that I already had working in my JavaScript client and I'm pretty much just re-doing in Rust now that I've fully committed to using the language / ecosystem for Akigi.


Luckily, getting the camera to orbit was also straightforwards since I've done it a bunch of times in other demos / apps, so that came together quickly as well.

Testing Mobile Touch Controls Making sure that the camera controls work on mobile when you touch and drag the screen.

Side Tasks

I knew that I'd be spending Saturday with a family friend and that I would be tired on Sunday from going out with some friends on Saturday night so I short loaded my work for the week. I ended up finishing what I set out to finish on Friday at 5:30am, giving me a couple extra hours to knock off some side tasks.

With that time I migrated from CircleCI 1 to CircleCI 2 and set up a weekly job to deploy the latest dev journal chapter so that I can stop dragging and dropping the files into s3.

It was fun setting up the IAM credentials. Gave my CircleCI just enough access to deploy to my s3 bucket and invalidate my cloudfront distribution. In the past I never really dove into fine grained permissions.

The AWS policy generator was really useful! A friend of mine named Will has engrained in me long ago that I should be careful to not give third party services access to stuff that they shouldn't have access to.

I also got a head start on planning out some of the things that I'll need to implement soon, namely some of the UI and knowing where the player's mouse / finger is clicking on in the 3D world.

Next Week

My sister's wedding is on Friday so I won't be getting much too done from Thursday - Saturday I don't think.

By next week I'll create three more placeholder models and make sure that we render the correct model for the correct entity based on the entity's model component.

I'll also add texture support to my renderer. I'll give each of the placeholder models a placeholder texture and make sure that the correct model is rendering the correct texture.

Doing all of this will "require" some enhancements to my automated asset build process, namely:

  1. Exporting all of my PSD texture files into PNGs using imagemagick

  2. Combining those PNGs into one texture atlas (in the future multiple, but one is fine for now)

  3. Serializing a HashMap of all of my meshes into a binary array (in the distant post-launch future multiple binary arrays at multiple levels of detail, but one is fine for now)

  4. Downloading these assets on the client side and using the right one at the right time

"Require" is a bit of an overstatement here. I can get definitely things working with less automation. But one important thing for me is that since I'm a complete noob to art I need it to be as easy as possible to make tiny improvements.

I can't spend many focused hours working on art like I can on code / technical problems, at least not yet. So low friction to rapid iteration is mission critical for me.

I've already built these exporting / preparing tools in isolation, so this week will come down to stitching them together and making sure that the front-end is rendering everything properly.

I'll spend the rest of today planning it all out and try to blaze through most of it before the wedding weekend and finish up the remainder late Saturday and on Sunday.

I'll also need to prepare the financial update for next week (every first dev journal of the month includes a financial update), so I'll need to figure out what I'm spending money on.

I originally thought that I'd just move everything to a seperate business card but that would be a hassle and I'll wait until I've done a few financial updates before worrying about making it easier.


See ya next time!

- CFN

003 - Aug 19, 2018

Hey!

This past week I was supposed to make some changes to our networking code and get a 3d model rendering.

I also started to notice how much of a positive impact keeping this journal has had on my development process. More on that at the bottom.

Networking

Since we've moved away from JavaScript and we're instead using Rust + WebAssembly for our web client we no longer needed to use protocol buffers and we can instead just serialize a client's known world state on the server side and then deserialize it on the client side.

This meant moving away from .proto definitions and instead using serde with bincode for serialization/deserialization of plain old Rust structs / enums.

Most of the Components in our Entity Component System were unfortunately quite a bit coupled to structs that were generated by rust-protobuf, so I needed to do quite a bit of refactoring in order to remove the rust-protobuf dependency.

Refactor ECS

I must have spent around 10 hours fixing compile-time error after compile-time error and there is still some work left.

By Friday 8:30 AM I had made a ton of progress but realized I wouldn't finish in time for this week's dev journal entry if I was going to also get a 3D model rendering.

But also realized I didn't need to finish.. A lot of this backend code gameplay functionality that doesn't matter right now because there is no frontend client to make use of it.

Fortunately we have a solid number of unit / integration tests in place so I'll comment the code back in and get it working little by little over the coming weeks.


For what it's worth I'm very glad that I got pretty far here because while trying to change basically every data structure that the game server uses I went over a few failed iterations before I landed on something that felt like it fit.

If I had switched away from protocol buffers without trying to make changes across the codebase and instead commented everything out immediately I would've landed on one of my earlier terrible data organization / access approaches not realizing that it would become my nightmare in a couple of weeks.

Rendering a Model

Earlier today I got a 3D model rendering in the Rust WebGL game client! You can see for yourself on www.akigi.com!

Rendering something Successful rendering!


WIP Capuchin The blender File

A month or two ago I wrote a Rust + WebAssembly + WebGL demo for rendering blender models, along with an exporter for exporting Blender meshes and armatures - so my work here mainly boiled down to copy pasting from that demo and leveraging my open source exporter.

Lessons learned from keeping a journal so far

Knowing that I need to have this journal entry up for you every Sunday evening has turned my prioritization up to a level I've never known possible.

I'm loving keeping a dev journal and more generally having a weekly deadline for something that people can see / play with. It's forcing me to not be able to spend time digging into technical things that don't matter right now and instead re-focus on gameplay and stuff that players care about.

This is useful for me because I have a tendency to get absorbed in the technical aspects of building a game and by the time I look up I've done more than was needed and still haven't shipped anything.

For example, I didn't optimize the WebAssembly builds or compress them so I'm basically serving a 2Mb non --release wasm module in production right now (that should be much, much, much smaller when I run it through wasm-opt and use a --release build).

I was just racing to get something live. Sure it would've been an extra hour or so tops to make sure that release builds are much tinier, but the amount of opportunities that I've had this week to spend an extra hour on something that wasn't a blocker must be at least a dozen or two.

I think it comes down to when you're working alone easily to justify things in your mind or just brush them over, but when you have to explain it to others (you!) it becomes very clear when you're wasting time. A lot of things that I might've dove into and tried to solve are becoming TODOs and I'm sure that I'm going to get an alpha out more quickly because of it.


Here's me writing a TODO instead of spending 30 minutes doing something that I just don't need to do right now:

TODO Example Leaving a TODO to save that extra 30 minutes of unnecessary exploration.

Actually as I type this I'm realizing I might not even need this.. maybe I can set a header for cloudfront & the browser to take care of this for me. Anyways - a future problem.

Next Week

By next week I'll start sending down real state updates to the client and rendering placeholder meshes at the locations of all of the entities that are in game state. I won't worry about delta encoding state updates for now - that can come when there is an actual game to play...

I'll also add arrow key controls (desktop) and touch controls (mobile / tablet) for making the camera orbit your character.


See ya next time!

- CFN

002 - Aug 12, 2018

Hey!

Last week I was supposed to get the game deployed so that you could "play" it.

"Play" in quotes because you could technically log into the game, but there would just be a blank canvas.

We got this task done! I hooked up Google and Facebook login via OAuth and you can now login to the game and see a blank black game screen.


This week I'll be working on being able to actually render 3D models in the game. This functionality used to exist, but since I've moved from JavaScript to Rust I need to re-implement a lot of the client functionality. The hope is that this minor setback pays off in long term productivity and codebase maintainability.

I already have an open source blender exporter to export the model data from Blender, so I'll just leverage that in my game's codebase. Shouldn't be too wild.

I'll also be tweaking the game's networking code a bit. Now that I'm using Rust instead of JavaScript on the client side, I don't need to use protocol buffers anymore. I can just serialize player state updates on the server side using serde, send them down the wire and then deserialize them on the client side.

This will remove my protobuf and rust-protobuf dependencies meaning that we no longer need some separate specification and toolkit to power our networking protocol.


So far these journal entries haven't been very visual, but hopefully as we start getting things into the new client I'll have pictures and/or videos to share.

But, as always, you can always check out the latest progress on the Akigi website!


See ya next time!

- CFN

001 - Aug 5, 2018

Hey!

Last week I worked on the www.akigi.com website, as well as creating the devjournal.akigi.com website.

For the Akigi main website I’m using Percy, my work-in-progress toolkit for building web front-ends with Rust.

The Akigi main website is using placeholder images and doesn’t have all of the copy and information and pages that it will need, but getting something live is a good first step and I can iterate from there.


This week I’m going to work on getting an early version of the game live and “playable” on the Akigi website. I put “playable” in quotation marks because I’m going to port the game’s WebGL web client to Rust so I can’t imagine that in one week I’ll have too much more than a blank canvas.

I want the game live so that people can check it out and give feedback all throughout the development process up until release.

I’m porting game’s web client to Rust because after porting the back end to Rust in January 2018 (from JavaScript) I felt much more productive in the codebase and I hope to see the same gains on the client side.

Business & Financials

The first post of every month will include a business & financials update.

I July 2018 Akigi earned $0 in revenue.

As for expenses, I’m not sure.

I’m charging things to a couple different cards that I also use for my personal life so expenses are littered around by card statement. If I had to estimate I would say that I spend less than $50/mo on the game - mostly on Amazon Web Services.

I’ll get all of the expenses onto one dedicated card for easier tracking and reporting and come back with a more detailed breakdown next month.


See ya next time!

- CFN