Starting an open source project

The free and open source software ecosystem is a rough, harsh place. Lots of initial work has to be put in to ensure your project is successful, the conditions need to be just right to get third-party contributions, and often you still need a thick skin to handle the conflicts that inevitably arise.

But as both those who contribute and those who maintain projects themselves know, it’s a labor of love. As a long-time supporter of many projects, I myself am willing to accept the risks and launch a new project of my own. I have been working on building a data-oriented game engine in C++11 for a few months now, and it has just recently seen a fully-fledged port to Rust. I thought I would share it with the world and have it be developed in the open.

Enter Amethyst. This is a work-in-progress game engine written in Rust that aims to be both data-oriented and data-driven, taking heavy inspiration from the industrial-strength Bitsquid engine (now called Autodesk Stingray). There are plans for an entity-component-system (ECS) architecture and a strong emphasis on modularity (e.g. multiple graphics API backends for the renderer, easy to bind to Lua/mruby/Python for scripting). Amethyst is in its early days yet, so don’t expect to be wowed. The most it can do now is transition between game states in a pushdown automaton design, and there is preliminary work being done on the renderer.

I have a few design documents up on the wiki, an unfinished online book, generated API documentation, a CONTRIBUTING file for people interested in helping out, and also a simple command-line client that can generate full-fledged game projects like this:

$ cargo install amethyst_tools
$ amethyst new mygame
$ cd mygame
$ amethyst run

I am also starting another blog called This Week in Amethyst on January 18th, 2016 that will detail the weekly changes and updates from the project as it evolves.

So what do you all think? Are you interested in helping out? Have you started an open source project and have some wisdom to share? Leave me a reply in the comments below.

Game engines: What they are and how they work

Featured image: Crysis Expanded Mod

Most people are familiar with the following video game titles: Battlefield, Halo, Doom, Civilization, Call of Duty, Half-Life, the Sims, and Unreal Tournament. Chances are, you may have seen the term “game engine” associated with them, but don’t really know what the term means. Perhaps you know what game engines are and think you have what it takes to write your own? In either case, I will introduce you in this article to the wonders of game engines and attempt to explain their internals as simply as I can. I assume that you, the reader, is familiar with basic programming parlance. If not, you might not understand everything I’ve written here.

Basics

A game engine is essentially a software development kit (SDK) that contains the source code and tooling necessary to get a basic video game up and running fast, letting the developer script in the gameplay, levels, and characters, without needing to touch a single line (or at least, much fewer lines) of C/C++ code or know advanced programming.

This allows the game developer to focus more on the gameplay and the “fun factor”, spending less time on complex math and other mundane boilerplate trying to get everything set up. This is analogous to an automobile designer selecting a ready-made engine from a trusted third-party vendor, eliminating the need to build a custom engine from scratch and therefore saving time, money, and effort.

Read more