← Back to blog

The Vendor: An Introduction

• 3 min read

The Vendor—An Introduction

Engine Choice

In the last few years, I’ve worked with a couple of game engines: GameMaker and Godot. They both were great engines to work with. Being able to publish Zim’s Word Game on both Apple, Android, and PC platforms with a single codebase was handy. GameMaker’s object system, with easy event handling, was powerful.
Godot felt closer to C++ development, but their scene system left a bit to be desired. Last winter I jammed with some friends on a multi-player title. It was a great learning experience but ultimately found myself fiddling with settings and guessing at engine internals to get the desired behavior.
25 years ago, I learned C++. Object-oriented programming was an instant fit to my mental model of how to structure programs. I’ve always been nostalgic for it. Why not make my own game engine? There’s a litany of reasons not to.
But there’s one reason I’m going to—it’s fun.
There are some features in The Vendor that I’m excited to implement that simply aren’t possible with engines I’ve worked with in the past.
The engine is for me. The game is for everyone else.

Zixel

My 2D engine is called Zixel. It’s a 2D engine that will use: - Raylib for rendering - Box2D for physics - Steam for distribution

There will be some other technologies but those are the core libraries that have been used thus far.
Zixel will be developed as a statically linked library and linked to the game at build time. I’ll elaborate on the design philosophy in future posts but here’s a simple overview.
Borrow from the simplicity of GameMaker’s object and event system and maintain the clean interfaces of a properly architected C++ application. The concept of Rooms will be used as well.

Project Management

I am notoriously bad at staying focused on an end-goal. New project syndrome is real. Hell…I still have Pin Sheet Pro going on at the moment! Don’t worry PSP, I’m not letting you rot on the vine. In order to set myself up for success, I’m going to use a simple agile process. With help.
Claude will be my project manager. We’ve already jammed together on a high level design document. With that document, Claude will be breaking down the project into sprints. I’ve completed the first sprint. ..well, just as soon as this blog post is posted.

My Process

Code. Every. Day.
It’s that simple.
Coding brings me joy. Coding games even more so. Watching pixels splash across the screen is a great feeling. Watching others get joy out of your creation: S-tier.
Get up well before the sun and put in the work. It’s an energizing way to start the day. The toughest part is trying to not lay in bed at night thinking about the next morning’s work!

Accountability

In order to keep myself accountable, I’ll be posting updates after each sprint to this blog.
Note to self Probably worth cross-posting to Itch.io and the [Zimventures Steam page] (https://store.steampowered.com/curator/42816402).

Sprint 1: Engine Foundations

And here we are - the end of Sprint 1! Sprints are two weeks long, for your information. This first sprint was focused on getting the basics of the engine up and running. There was a LOT of boilerplate put down. Lists are awesome, let’s use them.

  • Graphics
  • Basic camera system
  • Sprite rendering
  • Input system
  • Keyboard, Mouse, and Gamepad input
  • Action mapping (input) system
  • Generic Event Bus
  • Base Object class with all the relevant hooks
  • Room system
  • Steam integration
  • Box2D
  • mouse-over detection
  • Asset management (blog post coming on this one!!!)
  • Package on build
  • Load from asset bundle
  • UI
  • 9-slice sprite rendering
  • Dialog box (can’t move them yet)
  • Buttons
  • Text rendering
  • Settings
  • Persist to Steam
  • Local storage
    It was a productive first sprint, to say the least.
    Given that it’s boilerplate, the game itself isn’t much to look at. There’s a sprite, who I’m naming “Frank” for now. So far, Frank can move around the screen and can receive mouse-over notifications.

Next Sprint

For the next work cycle, the focus will be on building out a tilemap system. At a high level, the task list looks like: - Spritesheet building - Efficient rendering (don’t render tiles outside the view frustum) - In-game editor (the bulk of the work) - Serialization

....and away we go.