June 21, 2020
One of the more visible changes of this week was fixing the terrain seams that started appearing last month when I started mip-mapping the texture atlases.
After enabling mip mapping for the terrain in May I started seeing these gnarly black lines (left). This week I fixed that issue and now the terrain is looking much nicer (right).
Fortunately I found a blog post on how to properly sample mip-mapped tiling textures, so it just came down to spending a few days adjusting my tooling and renderer around some of those concepts.
I started learning Adobe Illustrator this week after getting some advice that it was good for creating icons.
My takeaways so far is that it's good for flat icons, but because I want the interface in the game to have depth I'll want to combine Illustrator and Photoshop.
I'm going to go through a couple more Illustrator and Photoshop tutorials this week and then start applying what I've learned to design Akigi's UI.
In 069 I mentioned that I've been lightly investing in passing our renderer test suite using Apple's Metal graphics API in order to power future tooling.
I made more progress on that this week. The Metal renderer can render meshes using the game's physically-based lighting model.
The output from running the test suite against the Metel renderer. Haven't added skinning to the Metal mesh shader yet. I still need to tweak the image comparison to allow for a little leeway, the top test should not be failing.
I got excited by this and took a little time to get the game running in a desktop window using winit.
It worked like a charm. So, when I some day port the game to desktop it looks like I'll be in good shape.
I'll keep making little bits of progress on the Metal renderer over the coming weeks here and there when I feel like a break from working on gameplay.
After that I'll add a WebGPU renderer so that our tooling is platform agnostic and can be run easily in CI.
Akigi is approaching 100,000 lines of Rust code, and as such I'm starting to need to care about things that weren't as relevant before.
For example, I used to be able to get away with CI not working for a bit since if any integration test started failing it was pretty easy to figure out why even if it was a week later.
As the amount of source code increases it's means that there are more places that can be the reason that an integration test is failing.
Because of this increased surface area, it's now very noticibly easier to address an issue when I have full context than to address it a few days later when I've already switched to working on something else.
So I made moves to force CI to always be working and tests to always be passing.
I upgraded to GitHub Pro and enabled protected branches in a way that pull request branches must always be passing before they can be merged into master.
I also tried upgrading to CircleCI pro, but then I started needing to worry about staying under my build minutes limit so that I would not have to upgrade even further.
So I spent all of Sunday biting the bullet and moving to GitHub actions using a self-hosted runner.
Setting up the runner took minutes, but getting all tests passing and continuous deployment working with all of the correct permissions ended up taking me the entire day.
The good news is that now I have full continuous deployment.
This is foundational for my new goal, deploying something visible to the game daily.
I'm making progress on the gameplay, but I need to move more quickly.
I need to be introducing interesting new gameplay every week.
And massive new bits of gameplay every month.
I don't fully know what that looks like yet, but I have an idea on how to start to encourage that sort of pace.
Learn to release often and reliably.
So, starting this week I'll be deploying at least one visible change to the game every day, in an effort to learn how to build the habit of always improving player facing aspects of the game.
I'm not yet sure what will go into best facilitating this practice.
I'm just going to start and then learn as I go.
If the GitHub actions setup works well for a couple of months I'll want to switch to a reserved AWS instance instead of on-demand since reserved instances are cheaper.
- I'm currently using a t3-medium instance.
Right now tests take just shy of four minutes and building for distribution and deploying takes around 9 minutes. I have some ideas on how to shave the deploy steps down to under a minute and to shave time off the test job as well but that isn't too important right now. is fine for now.
- Basically ideas revolve around leveraging
CARGO_TARGET_DIRenv variable to maintain multiple build caches so that building is instant for unmodified crates and seconds for modified crates.
- Basically ideas revolve around leveraging
Deploy something visible to game everyday.
Cya next time!