Zoomies Game Engine - Getting familiar with Picotron
So, recently I decided to write my own video game, again. But this time I want to try making it actually fun to play! But since I also like to challenge myself, I think it should be made in Picotron and should have rudimentary physics and some 3D rendering engine in Picotron.
Picotron is an amazing fantasy workstation made by Lexaloffle, who is also developping PICO-8. We will be using that!
Game engines. The core part of every video game. Each game has more or less a game engine, which can either be Unity, Unreal Engine or Godot for instance. It can also be made specifically for one game, like VVVVVV or Tildecube has their own game engine (which may get its own blogpost at some point). This is usually where I end up, for some reason I really can't get to work with those big complex game engines. Maybe one day I'll get the hang of Godot, but for now I'm sticking with the art of reinventing the wheel. A game engine does not need to be as general purpose and fancy as the big ones out there anyway, it can just provide just enough abstraction for me to comfortably implement my game while also having full flexibility on how it works under the hood.
I initially wanted to make a simple car game, but then figured I could also make really fun physics, then figured out I wanted to write a 3D renderer as well so I thought "Let's slap this into the project as well". For some reason I am always more interested in making something that is technically interesting. But again, the goal is to make a game that is somewhat fun to play, so let's hope I don't make it as boring as Tildecube or Rubymaze 3D (which has its own software renderer).
This series of blogposts will describe my journey throught writing my own game engine so I can make my funny 2.5D car game and what led me to take this maybe awful but funny decision, and how it went from small car game idea to more ambitious goals.
NOTE: This is NOT a tutorial on how to make a game engine, but may inspire one to roll their own.
The beginnings
I've been playing a lot of car games lately. From simcade like Gran Turismo to arcade games like Ridge Racer, without forgetting games with an interesting take to the genre like Driver 2. Needing gamedev practice to make someday my dream game, I decided I should make a car game. I wasn't sure what it would be (car chase? racing? something else?), but I knew it would have the following:
- Fun physics, not necessarily realistic, just fun.
- Could crash into other cars because it's fun.
- The cars can be tuned differently to provide different feels and provide gameplay variety and replayability.
- Driver-like damage meter.
- Isometric 2.5D (3D graphics, 2D top-down physics).
- Shove some procedural generation somewhere because I REALLY WANT TO. Maybe random car generator?
I first want to have all these goals checked, then I want to really dig into what kind of game I want and purely design the gameplay and goals. There are high chances I want something arcade and high-score based, but I will figure that out later. Once that series will be done, a series for the game itself will begin (I hope) and will focus on game design, rather than technical aspects like this blogpost series.
At this point I had to pick a tool. Godot? no... Unity? no. Picotron? Absolutely! Not much thoughts other than "there are fake tech spec limitations, therefore challenge" but here are some advantages that also encouraged me to pick this tool:
- First and foremost, it is a simple tool. The API is straight-forward and easy to use.
- Has fixed resolution, which gives me less stuff to worry about.
- Basic graphics, sound engine and input provided.
- Has actual linear algebra stuff. Which is perfect for a 3D software renderer and make physics calculation easier.
- It encourages me to reinvent the wheel, which again, hypes me a lot.
First attempt
My first attempt was to naively implement a car without any complex physics involved. The simpler it was, the best it would be and the easier it was to make the algorithms efficient (because remember, it's Picotron, our CPU cycles are limited!). I came up with the following design for the car:
It would have two circles connected together. It allows for rotation and makes collision impacts not too hard to detect and calculate. This will be the design that will remain in the future, at least for now.
The first implementation did not involve any complex physics, it would just apply velocity on the front circle and strafe to the direction one wanted to go and the rear would follow
It had pretty much just a speed $s$ variable, a direction $\vec{d}$ vector and $\Deltat$ time step. The velocity would be calculated as follow: $$ \vec{v} = \vec{d} s\Deltat $$ The direction would rotate depending on the joystick steering.
The speed would decrease when gas is not pressed, it is capped at a max speed and would drastically decrease when brake is pressed.
Very simple, very straight-forward. This is how it went:
First car movement iteration, it looked really boring, not interesting at all.
Let's say the outcome of this first iteration was very disappointing. No drift, very predictable, too easy to control, it was definitely not what I was looking for. It had to be more interesting, less predictable, actually challenging to control, it had to be tamed to be driven properly. But it was a good warmup! It allowed me to get familiar with Picotron Lua, how to use the tool the fantasy workstation provides, how to use its manual and get started with userdata data structures which will often be used for linear algebra, essential for physics and 3D programming.
The Zoomies Game Engine
It is at this point that I realised I should just implement a rudimentary physics engine to allow more complex behavior. Writing this physics engine would have the advantage to also have mass, frictions and force paramaters to toy with and tick the "Gameplay variety" checkbox. It will also become much more interesting in how collision impact will be calculated.
This makes the game much more technically ambitious as I thought it would initially be, and I'm hyped. This is when I thought I would first make a layer of abstraction before working on the game itself. This is the beginning of the Zoomies Game Engine. (Zoomies because cars go zoom and I love bunnies, and bunnies have zoomies).
Tags: programming, gamedev, zoomies-game-engine