Doopel Ponger is Out!
As of writing this, about a month ago I released my first game to Itch.
WooHoo! Great! Awesome! Right? Well, I've made a hand full of games over the last few years but released them right into the trash once I was finished with
them. So I don't really see putting a game up on the internet as something to celebrate. But as much as I'd like to go on a rant about how I think Doopel Ponger
is a crap game and should have never been put out publicly, I thought I'd reflect on what I learned and write about it here.
What I Wanted To Learn
With all the games I've made in the past, I created them from scratch in either C++ or Java. I typically used some kind of graphics framework like SFML/SDL/libgdx but there
was no "hand holding" like Unity does. Because I was working on a much lower level I never had much polish and all the games I made had a very prototype feel to them.
Since I did not have to build everything from the ground up, I wanted to really focus on polish and making the game look as good as a programmer can.
Things I Ended Up Learning
Not to say I didn't learn about adding polish to a game, but I learned several other things on top of making a game look better. The first being shaders.
And oh man shaders are magical! I have just scratched the surface of shaders and its just insane the amount of power shaders give you. But there's a cost, in that
shaders are much, much harder to write and understand than traditional programs. In my opinion this is because the math involved is not something I am not
comfortable. And to make things worse, when I mess up the math, it is hard to debug. While I did not get too heavy into the math of making things look cool,
I did create a few mesh deformation shaders as well a color changing shader used to obsorb colors of bullets.
Here are a few high level bits of information about shaders, these have been dumbed down for my own understanding and probably aren't 100% correct. But it is helpful
for me to understand what is going on.
Vertext shader. The vertext shader, as you can probably guess, is the shader that runs for every vertex on the mesh. In this shader you can control
where the vertex should be drawn in the world. It is important to note that if the vertex is moved here, any collision detection will not match as hitboxes
are handled by a different system than the renderer.
Fragment shader. This shader is run on every pixel of the mesh that is drawn on the screen. Anything from modifying the colors or fine grained movement
can be done here. This is the step that does the mesh deformation in the lasers and when Schmitty Doop gets hit.
Shader lab. Shader lab is a Unity specific technology and it helps create the connection between Unity's C# land scripts and the GPU land shaders. For example,
shader lab is used to send data from the custom C# scripts to the shaders or access special variables like the game's timestep.
Compute buffers. Even though I stripped out all compute buffers in the final release of the game, compute buffers can be used to send chunks of data to the shaders.
I originally used these buffers to send the color information when the bullets hit walls, but replaced it when I found out compute buffers did not work in the
browser build of the game.
Screen shake is in every game and it is one of those things where if it is done right, you won't notice it's there. And oh boy, I had no idea how dfficult it is to get right. It is also one of
those things where there are about a million tutorials online but 99.9% of those tutorials look like trash. I eventually went with a screen shake that uses perlin
noise to calculate rotation and translation offsets. It's not perfect but I've tweeked the magic numbers to get it to a place where it seems good enough. I'll probably end up going back
to the parameters again the next time I need screen shake.
Lastly, is creating the difficulty for the game. Looking back this is probably one of the most brought up points of game development that I was not really paying attention to. Just before launch,
I tweeked Doopel Ponger to have a difficulty so that I would win about 50% of the time. In reality, I have put in 1000s of hours working on this game and it is literally impossible for me to
be a judge of how difficult the game is. So using me as a benchmark of difficulty is a very, very bad idea. In the future I have no idea what I'll do, but it will not be based on me.