Isomyr is a free and open source 2D isometric game engine developed by Sam Payson at the Clarkson Open Source Institute.
A 2D isometric game engine is a variety of game engine which presents a seemingly 3D world by using 2D sprites the show 3D objects from a given angle. This works because the game camera never moves. Examples of existing popular games which use 2D isometric engines are Diablo 1 and Diablo 2, as well as my all time favorite game Lineage: The Blood Pledge.
Isomyr is designed to be an efficient well-architected engine which is general enough to be used as the basis for various different games. With minimal adaptation the code I currently have could be used to implement anything from a chess game to a strategy game to an RPG.
Isomyr is written entirely in C, and supports scripting (though not very well yet) in the Javascript programming language. The idea is that content creators (i.e. map designers, people designing boss fights, etc...) can write simple easy to understand scripts, while the real machinery of the engine is written in efficient modular C code.
The C code is also designed according to a new scheme that I have been perfecting over the past year or so. In essence, all of the C functions and data types are divided up into Go-style packages with well defined interdependencies.
For asset storage and configuration the engine uses JSON. To facilitate this, I developed a fast generic parser which makes it trivial to generate a JSON parser for any given C data structure.
In addition to the core engine code, I have developed a set of (quick and dirty) C programs which efficiently convert animations rendered with Blender 3D into sprite files that Isomyr can use. This allows for some pretty sweet synergy between open source programs, and will hopefully make the engine easy for people to design their own games with down the road.
Isomyr is designed according to the same Model-View-Controller mentality that is used by many web frameworks. Isomyr itself mostly fulfills the view aspect of the design, with model and controller being left to the designers building a game on top of Isomyr.
Typically the model would be composed of game state, things like the contents of a player's inventory, the world map, and the location of all the entities in the game. The controller is just the game mechanics, the rules by which everything in the game state changes.
It is then Isomyr's job to provide a conduit for communication between the model/controller and the person playing the game. This boils down to an issue of interfaces. We need to provide a good user interface for the player to interact with, and a good API (programmer's interface) for the game designer to interact with. This is the primary challenge that I have spent my time solving in designing Isomyr, mainly focussed on keeping the codebase consistent and providing good metaphors in the API.
When drawing a 2D isometric scene, you need to be very careful of the order in which you draw the sprites in the scene. If you draw sprites out of order you may end up with strange artifacts (like a table being drawn on top of something standing in front of it). The traditional method of doing this is a naive method that involves traversing a 2D array of all the drawable elements of the scene in a diagonal order.
In Isomyr, I've come up with a more elegant method that uses a heap to determine the drawing order. It is asymptotically slower than the naive algorithm, but it allows for some serious optimizations which, for the small values of n involved, cause it to actually run faster.
In addition to working on Isomyr this semester, I've also developed a tutorial on beginning OpenCL programming. It is designed for moderately advanced C programmers who haven't dealt with heterogeneous computing before. I am not finished with it yet, but when it's completed it will allow the reader to develop the same OpenCL pretty-but-useless n-body simulation that I showed in COSI a year ago.