At my work at Aptible, we recently came across an interesting performance issue with one of our more frequented controller actions. It became slow enough that our customers and internal users noticed that something was amiss. I want to document how we got into that situation and how we diagnosed and developed a solution for it as I think it’s informative for how to fix things like this in the future. I’ll show what the high-level process looked like, show some tools that allow us to profile Rails applications, and do a little deep dive at the end into what exactly was causing the problem.
Gotten a real basic UI in place now, still needs some touch up as you can end up in situtations where there is a negative health
displayed on the scree.
The AI in place actually works, sort of… It’s real basic and “cheats” in that it knows where the player is in world space (where as the human
player does not). Essentailly its a realy simple alogrithm where it take a first shot at random and then know whether it’s shot
landed too far or too close and then adjusts the next shot to fit in whithin those new constraints. While she’ll whittle down close to
the player tank, he will still get into weird states where it will keep missing you. I seem to recall friends of mine running
into these issues building their own AI’s. I’ve got to do more research here to determine what a good algorithm here might be.
Contemplating different camera angles, but after trying them out it took it too far away from the “Scorched Earth” game concept (if
nothing else just to give me some guardrails to get to completion), as well as added additional complexity with the third dimension.
I finally worked in a basic start UI just so it looks like a more “complete” game. I’ve got get the tail end of it done as well so
you actually go through and progress through the game. My thinking is that I’ll work in how to “quit” and then how to “win” and from
there I’ll go fill in the levels in between.
Speaking of the levels in between, I implemented some simple procedural generation of the terrain, which turned out to be dead simple.
With Unity you can simply access the Terrain objects height map and just set it dynamically. I simply utilized the built in Perlin
noise generation that Unity comes with and that gave me a decent starting place. Ideally I could rely on procedural map generation and
amp the difficulty up using some other mechanic (more accurate enemies, etc) , however I might end up having to draw up some maps anyways.
That’s it for now, I’ve been diving into writing custom shaders as well. Not sure if
they’ll fit into this project but they’re cool to learn about (I had no idea you could do
some of the things you can do with them).
Gonna try and get the following done this week:
Windows build
Different types of shells (Sabot vs. HEAT)
Experiment with eliminating the power controls (only have elevation)
I finally gotten around to posting my work in progress game:
Still a lot of work to be done but I’m excited by the progress I’ve been able to make. It’s been a
rash of challenging work with various starts and stops, as well as trying to make time away from my day job.
One of the big changes for me has been moving from the relative safety and familiarity of web development paradigms
back to freeform OOP. The code you see running in the video was a morass of state and interdepent C#
classes that all talked to each other in really bad ways. It’s been refactored already, and I’m
beginning to learn that game development requires you to really think about the bounded contexts of
each system the game uses and what those API’s should look like.
As far as using Unity goes, I’m actually quite happy with it. Being able to manipulate game objects so easily
and the drop in way you can either use the editor environment or simply stick with code is excellent. I recently
was able to tackle some more Unity tutorials at catlikecoding.com and got a feel for profiling the game and writing
my own shaders (my experience with the tinyrender series using Rust helped my a great deal here). While I don’t
fully understand the math behind 3D engines, I’ve got a rudimentary understanding of how modern 3D engines work, and if I needed to write my
own shaders I probably could eventually mash one together.
While it’s technically playable, it’s got a long way to go from being fun. Since this is my first
game and to make things easy on myself, I decided to really pick one game mechanic and
stick with it rather than try to invent something novel. I’m sticking with the “programmer art”
right now and the next steps are to try and get a simplistic AI together (right now the enemy
tank just fires randomly at you), and putting an end to end experience together (splash screen, start new game, save games, etc).
After that, I’m going to try and distribute to some friends and see what kind of feedback I get.
Hello again internet. I decided not to wait the customary year to update this
blog and decided to write this now. We’re more than halfway through the year and
I’ve taken some time to take stock of where I am at professinally and where
I’d like to go. I’ve even gone so far as to layout a roadmap of what I’m
learning in my spare time.
Bested by the beast! After a few days of fighting my Windows demon, I alas leave
a bitter and broken warrior. I was able to move the ball a little further forward.
I determined that the issues wasn’t actually in the Ruby build scripts but seemed
to be related to the way our build scripts were expecting Ruby to be built. Now,
it remains to be seen whether that the system works as a whole (Rake was still not
installed properly), but I’ve had to switch gears back to working with Elixir.
Source