Ikenfell - Development Details

I get asked often, "What are you making Ikenfell in?", "Are you using Game Maker/Unity/RPG Maker/etc.", by other developers and aspiring creators. Sometimes this is because they are interested in creating this type of game, but often it is simply out of curiosity by fellow game developers.

It made sense to create a little page where I can easily link people when asked these questions.

Programming Language

I am developing Ikenfell in C#, using Xamarin Studio, on a Macbook Pro. I am not using Unity or anything like that, just coding standard C#.

Why C#? This language is monumental to me, for many reasons. I find it extremely clean to read, and the syntax is close enough to C that I can avoid a lot of the tedious punctuation that tends to clutter languages such as C++ and Ecmascript (JS/Haxe/AS3/etc).

I love C#'s feature set. Knowing how to use it means you have the power to optimize your code in fantastic ways, but are able to code in an organized fashion, putting clarity before performance until optimizations are required. I can use enums to restrict options, I have access to various numerical types that convert with ease, and a ridiculously complete standard library with lists, dictionaries, hashsets, algorithms, file io, very nice and complete documentation, and naming mechanisms that actually make any lick of sense (I'm looking at you C/C++, honestly, "strxfrm()"? unacceptable).

Best of all is "structs", which in C# allow you to create value-type objects, which exist on the stack and are not garbage collected. Since Ikenfell is a turn-based game, garbage collection basically has no effect on the gameplay, and any slight interruptions it might cause are negligent. Structs help a lot with this, since they allow you to control the memory lifetime of your objects in an idiomatic and idiot-proof way, leaving me to worry more about code organization and big-picture thinking.

Engine & Tools

Ikenfell is built using a custom engine, written on top of SDL2 and OpenGL. SDL2 is a fairly low-level library which allows me to open windows, create and manage rendering contexts, and listen for native events such as keyboard input, joystick input, screen/resolution changes, and detect any important system specs I need. SDL2 and OpenGL are both very cross-platform, allowing the game to easily port to many different devices, and my system/rendering layer can easily be replaced with a different toolset if these two tools ever fail to meet a particular platform's requirements.

The "engine" is a simple but extremely robust Entity-Component engine. I can create managers, entities, and components, and all the game objects and code is built out of these. Ikenfell is an RPG, which means a very large portion of the game is built on systems, and I break these systems into pieces that I an assemble and re-assemble using components. When I need components to deviate from their base behaviour for gameplay and design purposes, I tend to use C#'s various polymorphism mechanisms to assist with this (specifically: inheritance and interfaces).

Finally, how is the game actually built? I have an editor layer that I've built on top of the game engine, that I launch when I am actually working on the game. This includes: a map editor, a room editor, an entity editor, a tile editor, and a script editor. In the map editor, I can create rooms, delete them, move them around, and can view Ikenfell's world from afar to see how it is piecing together. The room editor gives me access to the entity/tile/script editors; here I can place entities I have pre-fabricated, build rooms out of various tilesets, and write custom scripts into various object instances. Which leads me into my next section...

LUA Scripting

The final piece of the puzzle, event programming and cutscenes, and built using the Lua language. Lua is a very robust scripting language that has been around for a quarter century. What it lacks in object-oriented features, it makes up for in simplicity, clean syntax, and excellent performance (for a scripting language).

Every C# component I write can optionally have a Lua interface, which is exposed to instance scripts that I can write in the game's editor. For example, the Transform component will have functions such as set_pos() and move_to(). If an Entity does not have the Transform component, it will not have these functions. Using Lua also means that I can easily write and test scripts, and if there are any errors, the game crashes back to the editor. If I wrote this in C#, it would mean I would have to re-build the game every time, and re-navigate to the room/object I was editing every time. Lua means I can gracefullyc crash and resume editing where I left off. It is possible to also use C# to this purpose, but the setup for this is much more complicated, and C# code, even when used as a scripting language, is much more verbose than Lua, meaning I'd have to type a lot more for even very basic things.

Cutscenes and game events are written using Lua. Since Lua has coroutines, I created a layer to wrap Lua's cutscenes in C#. I use C#'s "enumerators" feature to create a coroutine system, similar to Unity's (but cleaner & requiring less syntax), and many of the Lua functions available actually run C# coroutines internally. Effectively, this allows me to write a series of Lua "functions" as a series of events, where the code will pause and yield until the function has completed its lifetime before moving onto the next. For example, I can say: dialogue(), dialogue(), walk_to(), dialogue(), and those events will happen in order, but I can write the code as a series of functions. This makes writing cutscenes extremely fast, elegant, and clear to read and edit later. It also gives me a ton of control over the various aspects of cutscene design, such as positioning, effects, text, pacing, expressions, animations, and user input.