Xona System 8 is the name of a new game engine / game development framework that I am building in C# on top of the XNA / MonoGame framework.
Its purpose is primarily for building new games quickly — it is both a game engine in its own right, and also a game development framework, where games can be developed quickly. Part of my goal is also to allow releasing older XNA games for release onto PC and other consoles — with the updated requirements of today’s games (resolutions, framerates, online services, etc.)
The below video shows its very beginnings. Currently it showcases the distinction between the game and the engine, with clearly defined ownership: engine running the graphics, rendering, font manager, and update layer vs. the game simply requested such resources with minimal API access.
- Low resolution / pixel-zoom screen (I am Retro! “Retro Re-invisioned“)
- Graphics rendering sub-system
- Extensive font library (the fonts you see are my own)
- Font render & animation framework
- Texture / Sprite creation
- Sprite requests
- Integration into the engine
- No level details handled
- simple engine API calls
I have made several engines over the past couple of years (well I have all my life, since I was 7 — but in the past 2.5 years, I’ve made several in MonoGame), as you can see in my other videos. Some created in less than 48-hours in game jams, and some are side passion projects. Many are recreations of technology I invented long ago — which I built in hand-optimized assembly & machine language, Turbo Pascal, GW-BASIC, and TI BASIC (yes that’s a 50,000x speed difference — from 1 frame per 30 minutes for a half-screen F-Zero style texture mapper in Tandy graphics to 30 frames per second in assembly in VGA, pre-GPU).
Side-Scrolling Shmup Engine
Arena Shmup Engine
Pseudo 3D Scanline Road Engine
3D Ray Casting Engine
Equation Rendering Engine
3D Polygon Engine
Barrier to Entry
It is time to break down the barriers to entry that prevent these engine demos from becoming full, feature-rich, implemented, playable, and releasable games.
It is time to collaborate all of the work into a single engine system – a game dev system – that allows the extra “fluff” of a game to be handled elegantly by a core engine, a system of sub-systems, that are all protected from the user (the game maker), and remove it from distracting efforts of focusing on the game.
Its purpose is to provide a framework from within which to make prototypes — such as simple weekend game jams, or quick ideas that can be tested and tried, without rewriting an engine from scratch (or borrowing code from a prior engine).
Quick Development – Prototyping
While it is great to witness the core code from my 2D Side-Scroll Shmup Engine be reused almost verbatim in my 3D Voxel Engine (animation system just works, along with sprite scaling, with simple Vector2D changed into Vector3D) — along with the code from my 2D Arena Engine used verbatim in my 3D Ray Cast Engine (this still amazes me just how similar the 3D game is to the 2D game; I totally get it, Carmack). What would be better is if the engine provided this code, the framework, to the games that want it.
I am going back to my roots as a TI BASIC, GW-BASIC, and Turbo Pascal developer where either the language was simple enough (BASIC dialects) or the language was powerful enough (Turbo Pascal units) to allow an extremely quick foundation upon which you could build. I feel anyone who has not written code in the original BASIC interpreters that accompanied home computers — where you could write an entire game in a screenful of code (like I did with Tetris, including saving high scores) — is missing how simple & quick programming can (and should) be. In structured languages you can build utility units to help out, as I did with Turbo Pascal, but for some reason this seems harder today.
The goal is a working graphics test from Visual Studio “File -> New -> Project” in 5 minutes flat, a full game in 1 hour, and a polished demo in a weekend. No more barriers.
I am keeping the following concepts in mind:
- “Fight code entropy” – John Carmack
- “You never, ever, open the (encapsulated) box.” – Chris “Kiwidog” Hargrove
- MVP – minimal viable product. What do I need today?
- The First Pixel – Motion is more important than perfection.