Daniel Masterson

Programmer | Developer | Hypernerd

Three Thing Game - I finally won one!

Posted 15/05/2017 17:15:48 under Personal

So last Saturday (The 13th), I took part in Hull University's Three Thing Game competition, possible for the last time. This competition has each team be given three random 'things' from a pool, and our team was given the things 'Ambient Occlusion', 'ASCII' and 'Psionic'. Huh. Not the most inspiring words, but we worked with it and in the end we won! Well how about that?

The game we made was a sort of isometric twin-stick shooter thing in Unity with entirely procedural levels. First off, we had a visual idea with ambient occlusion that we've wanted to use for a while, so that was easier to pin down. Basically, only use ambient occlusion maps! Everything ends up grayscale, if not entirely white, with the only detail being provided by the shading caused by ambient occlusion. This shades in things like corners and inner edges between objects, as well as stuff like indentations to simulate the reduction of light in such areas. Here are two examples of the game with only ambient occlusion effects and nothing else.

One of the game's arenas with a faux Greek styleThe game's "generator" room, basically a sort of checkpoint

As you can see, even though we're not using actual lighting, colour or anything else that you would normally use to describe 'depth', you can still pretty easily navigate the scene while still having a striking game aesthetic. Even the player and enemies have this effect which works surprisingly well.

Alright, one of the 'things' is solved, and in a very nifty way too. How about we tackle ASCII next?

Now, I've made 3D games in ASCII before, and I might do a write-up of one of those later on, but ASCII won't really work with the current aesthetic. Looking at this, you can consider the aesthetic to represent a virtual or digital space, and what represents digital more than ASCII! We needed particle systems, but they don't work too well using AO, so how about having the particle systems be random ASCII characters? In addition, why not make the characters support colour, to make them seem very unnatural in this world. So that's what I did! First, I generated a texture atlas of a variety of Latin, Cyrili and common ASCII symbol glyphs. With this, I wrote two shaders, one for particles and one that I will use for normal meshes. The particle shader took the vertex id divided by four (Giving each particle quad its own ID), which is then used to randomly offset the UVs to select a random glyph. Add transparency and support for colour and we have a perfect particle texture! The mesh version, which will be used in the effect for meshes dissolving in and out, basically pastes the atlas in view space multiple times, offset by a random value each time. By offsetting both of these randomly using the scene's elapsed time, we can even have the glyphs randomly flicker over time. Perfect!

The player character with blue particle system hair shooting 5 'psionic' ASCII projectilesA part of the world fading in with the ASCII effect clearly visibleThe same part of the world, slightly in the future with the final surface starting to dissolve in.

Fantastic! It looks otherworldly and fills in our second thing! The final thing was actually super easy, we give the player psionic powers! The character's psionic potential is clearly visible thanks to his super stylish blue ASCII hair, and he can charge up and shoot psychic 'bolts' with the power of his mind. The player does this by holding down the left mouse button (or one of the triggers or bumpers on the controller, if we had managed to get controller support implemented). The longer it's held, the faster and more damage the bolt does. We also had plans for an ASCII/Psionic blade of sorts for melee attacks, but in the end that wasn't implemented, primary due to issues animating the player character. I won't get into those issues too much, but the psionic attack uses some awful hybrid of the jump and crouch animations just on the upper body and it sort of works. Also the character's upper torso is completely independent from his legs. It looks as goofy and painful as it sounds.

Now we just need a goal. We decided pretty early on that the 'plot' is that you're trapped in this virtual hellscape and must escape. You do this by acting three 'psionic generators' which are used to charge a portal. Annoyingly, a virus/worm/thing is obstructing the portal, so you better go kill it. Get to the end and kill the worm = Game complete. Easy.

And, surprisingly for a game jam, most of this was easy, The game ended out balanced and there was a full game loop, including completion and player death. I'm honestly very proud of the game, even a little bit surprised that we won. If you want, you can watch one of my teammates narrate a demonstration video and a play through of the entire game (Cheating a bit so he doesn't die). This is something I want to work on in the future too, so this might not be the last time you see AO.

C++ Reflection for Fragment Engine

Posted 20/04/2017 22:29:43 under Fragment Engine

Reflection systems - allowing a program to inspect it's own code at runtime - is extremely handy for game engines. For example, rather than hard coding a list of objects that can be spawned by the console or be selectable from the editor, the engine can just look for all classes that either subclass a particular type or have a particular flag. Another example would be for networking - and is something that I'll be writing for some upcoming coursework - whereby instead of writing bespoke methods per class for networking, a programmer can just add a 'replicated' flag to a particular field and a generic method handles updating automatically. The same would work for Remote Procedure Calls (RPC) - just mark a method as an RPC method and the reflection engine (And some form of preprocessor) can handle it as appropriate. C# has a built in reflection system, as well as a very handy attribute system (You tag types, methods and fields as you define them in a pretty intuitive way). Sadly, Fragment Engine is built in C++ (Which may be ported to D, providing slightly more features here, but it's C++ for now).

So, C++ is kind of barebones and doesn't provide much fanciness, especially with introspection and reflection (Bundling type information into an exe would both bloat it massively and just annihilate security techniques). C++ has the typeid operator, which is handy and even works at runtime, but its main purpose is to test if two types are the same or not based on whatever internal name the compile gives types. We can't find out anything about the types themselves from this, and as such, we have to make it ourselves. This system is partially inspired by the system in Unreal Engine 4, albeit with the aim to avoid the creation of a separate preprocessing tool for as long as possible.

Basic Reflection Engine Requirements

The engine I will be creating must do the following:

  • Gathering of all type information at runtime - A future goal would to also support this through libraries (Mods and plugins, etc)
  • Allow the spawning of any type stored within the engine's database from a string identifier
  • Support getting and setting values from fields within supported types using a string identifier for that field (and potentially string version of the value, that must then be converted to the correct type)
  • Support [recursive] serialization and deserialization of supported types to any format (JSON, XML, Raw binary)
  • Allow fields to be tagged and have metadata applied to them. ie: Replicated, valid ranges, prevent serialization etc
  • All this must be done via preprocessor macros and C++ - no preprocessing tool or code generator until I really have to

So, lets begin!

Handling Types

The first thing I need the reflection engine to do would be to gather and store a collection of types. While I would like to do something simple and restricted to the header alone, this didn't turn out to be practical when I started (Although a recent juggling of the code might make this possible again soon). In any case, I add reflectable types via the following:

//Example.h

class Example : public FEClass
{
	FE_DECLARE_CLASS(Example, FEClass)
};

//Example.cpp

FE_DEFINE_CLASS(Entity)

Here, the class must inherit from FEClass or a class that eventually inherits from FEClass. FEClass acts as a base for all reflectable classes such that there is a common base type to spawn from, as well as (potentially) providing core methods for reflection purposes - A ToString() method comes to mind. FE_DECLARE_CLASS sets up a number of static methods and fields so that a programmer can get type information of a class by simply calling Example::GetReflectionInfo().

FE_DEFINE_CLASS is where the true magic and horror happens. This macro creates a new class that inherits from FEClassReflectionInfo - holding all type specific reflection info, as well as those of its fields - and sets an instance of this class to the static private variable created by FE_DECLARE_CLASS. This uses the fact that static constructors run before main() to ensure that all type information exists as the engine starts - the constructor runs a method defined in a protected portion of the base class to add itself to the main engine class. To add to the horror factor, I previously borrowed JavaScript's concept of self-executing functions to run this code before main. Thank god that's gone, eh?

Handling Fields

In the end, fields turned out to be easier than anticipated. As I wanted to hide all the reflection info construction stuff from the programmer (So they can't add their own arbitrary fields to the type info instance and ruin everything, etc), I needed a way to call code that's only visible in one place. This place turned out to be the constructor of the reflection info. Great, but how do I put code there that details field types? There's no way to inject code, and you can't add code elsewhere that adds field info to the type info - that means exposing an 'Add' method and trusting the programmer not to call it!

Actually, there is a sort of way to inject code. Preprocessor macros support varadic arguments (Basically, you can supply as many arguments as you want). Normal programming languages then bundle all these arguments into an array that the function can then iterate through. The C++ preprocessor...isn't as powerful. There are some fancy tricks to loop through these arguments, but we don't need them here. In fact, putting __VAR_ARGS__ somewhere in your macro's definition just dumps out all the supplied arguments as is. Luckily, we only need to write code, so all we do is supply code!

FE_DEFINE_CLASS creates the type info class for a specific type. Therefore, instead of creating the macro as 'FE_DEFINE_CLASS(CLASS_NAME)', we put 'FE_DEFINE_CLASS(CLASS_NAME, ...)', with the ellipses indicating that it's varadic. Then we just dump __VAR_ARGS__ at the bottom of the constructor, and we can supply code as parameters that we want to inject into this constructor. It feels hacky as hell, but it works, and ends up quite elegant. Now, I know by 'code', you may think I mean doing something like:
 

FE_DEFINE_CLASS(Example, AddField("fieldOne", "int");, AddField("fieldTwo", "float"))

And while that could work, it could get verbose. Instead, we introduce another macro! (Hooray?). This macro is called '_FE_PROPERTY', with the underscore indicating that you shouldn't call that macro directly. Instead, you should use either 'FE_PUBLIC_PROPERTY', 'FE_PRIVATE_PROPERTY' and 'FE_READONLY_PROPERTY'. These are all very similar, but set a few core flags. In Fragment Engine, I define a 'public' property as one that's modifyable in an editor, as well as one that's saved to and read from disk. A 'private' property is the same, but should be readonly or hidden in the editor, while a 'readonly' property is one that's visible at runtime to debugging tools, but is not serialized at all in any form. This way of flagging properties will probably change soon, but it's how it's implemented. These macros expand into a bunch of code that defines stuff like the field's type, its offset and size in bytes and so forth. The actual _FE_PROPERTY macro looks like this: 

#define _FE_PROPERTY(CLASS, NAME, PRIVATE, READONLY)	AddProperty(L#NAME, MakeShared<FEReflectableProperty>(		L#CLASS,												L#NAME,													typeid(CLASS::NAME).name(),								offsetof_s(CLASS, NAME),								sizeof(CLASS::NAME),									PRIVATE,												READONLY											));														\

And is called like this:

FE_DEFINE_CLASS(Example,
	FE_PUBLIC_PROPERTY(Example, fieldOne)
	FE_PRIVATE_PROPERTY(Example, fieldTwo)
)

Note how the programmer doesn't need to know or care about the type of the field, or any of the other deep down stuff like byte offsets and whatnot. This is stuff they would have to write if we didn't have access to the magic wizardry of the preprocessor! With this ,the code that FE_XYZ_PROPERTY expands into is dumped at the end of the constructor for the type info, and it just 'works'. We have the byte offsets and field sizes, meaning that we can now iterate over these fields (in their raw form) and with some super dodgy casting, can get and set arbitrary data at runtime! Sounds like a security nightmare, and it probably is! Even so, if we write a deserializer, this can read in data from a file, spawn classes and populate their fields entirely automatically. If the deserializer handles textual data, it can just nab the type name (as a string) of a field from the type info, and pass the string to a converter to get the actual data out of it.

What's Next?

Well, you've probably guess that I'm not a fan of the FE_PUBLIC/PRIVATE/READONLY_PROPERTY system, and you're right. I aim to change it to support any number of supported flags and settings, as well as potentially arbitrary ones defined by the programmer. This would be something in the form of:

FE_PROPERTY(Example, field1, PUBLIC, READONLY, PROP_META("description", "An example field"), REPLICATED)
FE_PROPERTY(Example, field2, PRIVATE, PROP_RANGE(5, 15))

Everything after the field name would then be a set of defines containing more code. This would then likely add and change properties on the result of AddProperty (once I make it return the new FEReflectableProperty that's passed into the second parameter).

In addition, there's no specific per-instance reflection (as in, the network system can't find out what values have been changed on a particular instance yet, unless it were to store a copy of that entity's state at the previous time of sending data). This may either be implemented as another secondary structure, or a copy of the type info might assigned to each new instance of a reflectable class (They must be created via the Reflection Engine rather than through 'new' at the moment, so assignment can either be handled there, or the base constructor of FEClass).

Summary

Overall, this reflection system at the moment is very simple but very powerful, and it's feature set will only improve in the future. I've only provided a very simple summary of what I've done at the moment, but as this system matures, expect follow up posts providing more in depth details on the intricacies. Even so, I feel that I've provided a basic explanation that you may use to create your own reflection engine if you so desire.

An Introduction to C# Attributes and Runtime Reflection

Posted 03/04/2017 22:29:43 under C# Tutorials

Hey there! As I've had some questions from my friends about this, I've decided to write a basic guide to C# attributes, C# reflection and potential use cases for both. For the sake of definition, 'reflection' means the ability for code to look at or 'reflect' on itself, also often known as introspection. These techniques tend to be used for metaprogramming, where the program can examine itself and dynamically modify its own properties without any special hard code to do it (Other than some basic reflection). This means that you can then add another class and your reflection system should [hopefully] be able to automagically handle the new class without any new code. Attributes allow you to then be able to tag things in your classes, including the class itself, fields and properties, methods and even method parameters! A reflection system can then get these attributes and handle things in different ways. Unity is a great example of this. One Unity attribute allows you to mark a static method in such a way that a button is added to a toolbar using properties you specify within the attribute. Clicking that button then runs that method. Another when applied to a class that inherits from ScriptableObject adds a context menu item that allows you to create an instance of that class as an asset.

And Unity is an example of one of the major use cases for reflection and attributes is: Editors. Editors, whether for games, word processing or otherwise, tend to be expandable by users other than yourself, whether through co-workers, plugins or otherwise. In C#, someone could write a new class for a game object or other primitive, and the editor automatically populates its list of spawnables, as well as its properties window when an instance is selected. You can tag static methods as being callable from the toolbar or a context menu, and you can tag which fields should be saved without having to write fiddly save/load logic on a per class basis.

So, what do this magical fantastical attributes look like. If you've ever worked in Unity, you'll may have experienced this before in something like:
 

public class SomeBehaviour : MonoBehaviour
{
	[Serializable]
	private float someValue = 13.37f;
}

Here, the attribute is the word 'Serializable' in the square brackets before 'someValue'. For Unity, this makes someValue viewable in the editor, even though it's private, as well as allowing someValue to be saved and loaded too and from the scene - something that doesn't normally happen to private variables. Some attributes can also accept parameters as they are technically constructors, and they can run their own logic if need be (although most of them just store their values in public fields). For example, in Unity (Again), you can do:

public class SomeEditorTools : MonoBehaviour
{
	[MenuItem("Editor Menu/Do A Thing")]
	private static void DoAThing()
	{
		Debug.Log("I did a thing!");
	}
}

Here, the attribute MenuItem takes a string being the path for a menu item. When Unity recompiles this script and looks for these attributes. The path will be interpreted, and a new menu category called 'Editor Menu' will be created, with one button within called 'Do A Thing'. Clicking that button then runs the DoAThing() method. Notice how DoAThing() is private, yet appears to be accessed from outside the class. The previous example also had this. How is this possible? You wouldn't normally be able to access private members in anything but the same class! Luckily(?) for us, reflection systems can bypass the protection systems that are in place for normal code. This gives reflection a lot of power (Which is why it's sort of hidden away), but for good reason. Like the serializable example, you might want to be able to save things to disk that you don't want normal code accessing in any situation. Someone desperate enough can find their way around it - hence why unobfuscated C# is not secure - but it prevents people from doing things inadvertently and bypassing checks you have elsewhere.

So. Where to start? I guess creating your own attribute would be a good way to go, so lets do that. It's pretty easy, you just have to inherit from the Attribute class! Let's create an attribute to mark which fields to save. We can do that like this:

public class SaveableAttribute : Attribute
{
}

Bam. You've just made a new attribute! It's highly recommended that you always end the class name with 'Attribute', but don't worry, you don't need to type that in the actually attribute when you tag something. This is mainly done to prevent name-conflicts with non-attribute classes. If we wanted to accept parameters, like an enum to say how it saves or a bool to indicate that it also saves on autosaves, we'd do something like:

public class SaveableAttribute : Attribute
{
    public bool DontSaveWithAutosaves { get; private set; }

    public SaveableAttribute(bool dontSaveWithAutosaves = false)
    {
        DontSaveWithAutosaves = dontSaveWithAutosaves;
    }
}

Here, we just accept a parameter (and can give it a default to make it optional) and set a public property of field so it can be read later. The rules for this are the same as any standard class, and you can even put methods in there (Although anything other than getter methods don't tend to be useful). This is the attribute we'll be using from now on.

Now, to use the attribute, we'll just tags something with it. Here's an example class:

public class SomeObject
{
    [Saveable]
    public float a = 13.37f;

    public int b = 9001;

    [Saveable(true)]
    public string c = "Test";
}

Here, field 'a' is saveable at all times, c is saveable but only when not autosaving, and b is not saveable at all. Notice how we didn't type the full SaveableAttribute name, the C# class will automatically expand that for us. These attributes mean nothing though if we don't have code to handle them, so lets do that!

using System.Reflection;

public class SaveManager
{
    public string GetSaveStringFor(SomeObject obj, bool isAutoSave)
    {
        StringBuilder saveString = new StringBuilder();
        SaveableAttribute saveableAttr;

        saveString.AppendLine("[SomeObject");
        foreach (FieldInfo fieldInfo in obj.GetType().GetFields())
        {
            saveableAttr = fieldInfo.GetCustomAttribute();

            if (saveableAttr != null && (!isAutoSave || !saveableAttr.DontSaveWithAutosaves))
            {
                saveString.AppendLine(fieldInfo.Name + "=" + fieldInfo.GetValue(obj));
            }
        }

        return saveString.ToString();
    }
}

Now this meaty bit of code does a few things. First off, to use reflection in your code, you need 'using System.Reflection' at the top of your file, allowing you to use FieldInfo and related reflection classes. If you're using Visual Studio, it will shout at you pretty sharpish and provide the intellisense to automatically add it. Now, this SaveManager class is just an example, preferably you'd have some list of objects you want to save, and be able to accept all types rather than just the 'SomeObject' type, but this is good enough to demonstrate. We create a string builder as we're going to be doing a lot of concatenating for this, as well as create a variable to store a SaveableAttribute (This is just so we don't keep on allocating more memory for each iteration of the loop). Then we append some form of string into the loop to identify the object type (Reflection allows you to create an object from a string as well, so this is handy), then we start a foreach loop. FieldInfo is a metadata class, holding all the low level information about a field in a class (Fields being basic variables. Those variables with those funky get/set parts are called properties and use PropertyInfo instead) and from a FieldInfo we can grab all attributes attached to a class. Now, the list of FieldInfo's are stored within a classes Type info (This is just an instance of the 'Type' class), which contains all potential information about a type and anything within it. Therefore, we get the type from the object instance via GetType(), then get all the fields from that type with GetFields(). Pretty simple.

Now, in the loop, we call GetCustomAttribute<>() on the FieldInfo we're currently on, which allows us to grab an attribute by type. If the FieldInfo doesn't have that attribute, then it returns null instead, allowing us to ignore this FieldInfo. In this instance, we also check to see if we're either not autosaving, or if we are, the attribute lacks the DontSaveWithAutosaves flag. If it passes this if statement, then we can append a line to the save string, being the FieldInfo's name (Literally the name you gave the variable) and the value that was stored in that field in obj. This is why obj is passed as a parameter to GetValue, the FieldInfo is part of the type of the class, and is not specific to any one instance. Now, if we run this test code (Assuming you're in a console application):

class Program
{
    static void Main(string[] args)
    {
        SaveManager saveManager = new SaveManager();

        SomeObject objA = new SomeObject(); //Will stay default
        SomeObject objB = new SomeObject(); //Will be changed
        SomeObject objC = new SomeObject(); //Will also be changed

        //Change all of objB's properties
        objB.a = 42.0f;
        objB.b = -1;
        objB.c = "This was changed!";

        //Change all of objC's properties too, but this will be saved as with 
        //autosave marked true so c shouldn't be saved at all
        objB.a = 3.14159f;
        objB.b = 5000000;
        objC.c = "This was changed for objC!";

        //Save A normally
        Console.WriteLine(saveManager.GetSaveStringFor(objA, false));
        //Save B normally
        Console.WriteLine(saveManager.GetSaveStringFor(objB, false));
        //Save C as if it were an autosave
        Console.WriteLine(saveManager.GetSaveStringFor(objC, true));

        Console.ReadLine();
    }
}

Then you should get the following output:

[SomeObject]
a=13.37
c=Test

[SomeObject]
a=3.14159
c=This was changed!

[SomeObject]
a=13.37

Notice how we're missing b entirely from all three objects (It was never marked Saveable). Also note how the second object's values are different from the first's, while the third object - saved with isAutosave set to true - is also lacking any value for c. This is only scratching the surface for what's possible with reflection and attributes. For example, MethodInfo - storing all info regarding a method surprisingly - has an Invoke method that can call that method on an object (or none at all if it's static), allowing you to automatically create UI elements. As mentioned before, you can create an instance of an object by having it's typename as a string, then loop through all it's properties loading in data saved to disk. The possibilities are vast, if somewhat complex. As a bit of an annecdote, one project had me integrating Clojure into a data analysis tool written in C#. As many types and methods already existed in C#, it ended up being easier to tag methods with attributes saying that they're callable in Clojure (as well as giving them a Clojure friendly name), and having a reflection function generate Clojure code that invokes the C# code. This also made making plugins much easier, as the plugin maker could just write in C#, and Clojure could automatically work with it.

Anyway, I hope that I helped give you a very basic understanding of how C# attributes and reflection work (These should also work in VB.NET and other .NET languages, so give it a try!). Until next time!

Book Review: Revelation Space

Posted 03/04/2017 12:02:45 under Book Reviews

Alongside starting this site, I've also decided I might as well start reviewing things I like. Lets begin with sci-fi book (there will be a LOT of these) from 2000, the first in the Revelation Space universe - conveniently named Revelation Space - by Alastair Reynolds. Personally, I hadn't seen very much of this series and found the entire collection on offer on the Google Play book store after finishing a previous book. I read some reviews and a synopsis, and bought it there and then. This was a very good decision.

Revelation Space takes place in the 26th century, following three different characters who's stories slowly converge near the finalé. The story regularly jumps between these characters and their associated timelines, something that's seen in the future stories as well. Alastiar doesn't hold back with his terminology, starting as is if you already assume major components of his story and only later explaining what certain things mean either through context or various scene hints. He very rarely goes into an explicit explanation of something, and this I like. I personally feel it makes the story feel more real, as if you've been catapulted into this time and just have to learn things through experience, although I can understand how people would dislike this way of writing, and the start of the book is heavy with this, getting easier as the story goes on.

To make the rest of the review make a bit more sense, I will add some backstory here. After expanding out into the universe, the human race split into a number of factions. The primary factions are:

  • The Conjoiners - Focused on mental augmentation and communication, as well as the advancement of the human mind. This faction created the lighthuggers, giant interstellar starships that could reach speeds in the the speed of light. Something caused them to suddenly stop producing the lighthuggers, and the remaining ships became extremely valuable to the scattered settlements of humanity for trade. Most lighthuggers were bought up by the next faction...
  • The Ultranaughts (Or Ultras) - Transhuman spacefarers and traders who tend to favour obvious mechanical modifications to their body. They pride themselves on running lighthuggers, growing a new dreadlock for each session of reefersleep (Basically cryogenic stasis) which is of huge value for them.
  • The Demarchists - A faction that uses democratic anarchy - or Demarchy - to run themselves. While not pure human, for the sake of this book they could be considered the most 'normal', with primary character Sylveste being one of them. This faction isn't referred to much in this story, but becomes a part of the story later on.

The first story strand follows an archaeologist by the name of Dan Sylveste, living on a newly colonised desert planet called Resurgam where he's investigating the mysterious disappearance of the previous alien inhabitants of the planet called the Amarantin. He discovers that they appear to have been destroyed by their sun around a million years ago - going against the logic of normal stellar physics - as well as the fact that they may have become technologically sophisticated. These discoveries slowly happen as Resurgam goes through multiple political upheavals and rebellions, something that pretty much becomes a staple of Resurgam.

The second strand follows Ana Khouri, an ex soldier from the planet of Sky's Edge who was injured and accidentally transported to Yellowstone, a planet in another star system, due to a clerical error. Since her husband has apparently remained on Sky's Edge, as well as the fact that interstellar travel is still slower than light, she decides to use her soldiering skills to become an assassin on the planet of Yellowstone. To add to this, Chasm City - the largest settlement on Yellowstone - was one of the greatest cities in all of human space before an attack by 'The Melding Plague', a nanotechnological virus that corrupted all sophisticated technology - including the self modifying buildings - into twisted and deformed shapes. The city is now semi-lawless, with the majority of people living in The Mulch on the ground, while the rich live in The Canopy at the tops of the corrupt buildings. The rich, being the only people in the city who can remain immortal, run a sort of death game where they are hunted and can feel the fear of death. Khouri is one of these 'legal' assassins, and the story follows one of her hunts and her later reassignment by the mysterious Mademoiselle who tasks her with assassinating Sylveste.

The third strand follows Ilia Volyova aboard the Nostalgia for Infinity, a lighthugger (a semi-rare ship used for interstellar travel) run by a skeleton crew of Ultras - a faction of humanity who pride themselves on cybernetic augmentation and being the primary faction for interstellar trade. This crew also want to find Sylveste and to get him to help cure their captain - a man infected by the Melding Plague and who is slowly - for the lack of a better word - consuming the ship through the corruption of the plague, slowed only by being placed in cryogenic stasis. The crew have just entered the Yellowstone system looking for someone to run the armory after the previous user died under mysterious circumstances. Once they've found a new crew-mate, their plan is to travel to Resurgam to capture Sylveste.

The story then follows the plot of Khouri infiltrating the Ultras, infighting between the Ultras, and group's realisation that the Amaratin were destroyed by an intelligent alien race called the Inhibitors. I don't want to spoil, but there's a lot here and it sets up the stories and the universe that continues into the next four books (as of writing), as well a wide number of short stories. Aside from the blunt start, I just love this story: the world[s] Alastiar has created, the plot lines he creates (even without you realising) and the very varied and unique characters that are both protagonists and side characters. The universe he has made feels very real, and while the overarching theme is pretty much a sci-fi trope - cosmic entity that destroys life, resolving the Fermi paradox - it's done in an interesting and unique way that I love. Overall, great book (and series) that I definitely suggest you read, even if you're not fully interested in sci-fi.

Overall rating: 5/5

What is Fragment Engine?

Posted 01/04/2017 18:10:26 under Fragment Engine

Ah, Fragment Engine. A project that will probably take my entire life to complete because I am but one man and there's only so much time I have on this planet (Unless my plans for cybernetic immortality come to fruition, but we're not there yet). Since literally nobody but some friends and a few of my lecturers at university have ever heard of this thing, I've decided to write about what exactly it is.

The Name

Why did I call it 'Fragment' Engine? To be honest, I was doing a lot of GL shader work when I started work on this, so the phrase 'fragment shader' was drilled into my head. I thought it sounded cool and - as I thought more about how I want the engine to work - it also became more appropiate. I'm planning to create the engine so it could be developed in a 'fragmented' way (Basically just a modular engine) and from that point on the name just stuck.

Core Info

Fragment Engine will hopefully be a full 3D game engine along the lines of Unity and Unreal. I'm using it to learn about all fields of game engine development, as well as the development for tools necessary for game development. It's written in C++ (I am thinking of porting it to D, but more on that later) and currently only supports Direct X 11. As of this post, it also lacks anything but a graphical engine - no sounds, no networking and very basic physics. Even so, I'm happy with the progress I've made on it, and it helped me net a very high mark on one of my university modules.

Current Features

Currently, FE has support for some pretty advanced features. These include:

  • Full DirectX 11 support - Packaged as a subsystem so that I can hopefully implement other rendering systems as well.
  • Support for the full shader pipeline, including Hull/Domain and Geometry shaders
  • Deferred rendering with HDR texture support
  • A full reflection engine, allowing automatic serialization of game objects (More on this in a future post).
  • C++ coroutines built in a similar fashion to Unity's coroutines. (More on this in a future post too. I suspect this might be Windows specific, but hopefully I will be able to make it portable)
  • Chromium browser as a UI. I find that HTML+CSS+Javascript to be an obvious choice for UI development, although at the moment there is signficant overhead with using Chromium. Even so, this also allows essentially webpages to be used as textures in the environment, making things like control panels extremely easy to make.

Future Features

These are features I plan to implement in the immediate future. Some of them will even be implemented within a month (At least at a basic level) due to another pending coursework. These features may include:

  • A bespoke physics engine with support for rigidbody and soft body physics. This will be run in at least one seperate thread.
  • Implicit networking using my reflection system. The aim is that a programmer can just tag a variable as 'replicated' and the networking subsystem handles it all for you.
  • A proper editor, either built into the engine or as a seperate runtime alongside it.
  • Some form of portable shader support. This will probably be done by writing the shaders in Cg and/or having a node based shader creation system, similar to Unreal Engine 4's. I'll probably implement both.
  • Support for OpenGL and Vulkan. While it's unlikely, I would even like to support the ability to switch rendering engines at runtime.
  • An audio system of some sort. I plan to implement one where the programmer can extract audio data at runtime such that they can use it for DSP effects and visualizers.

Far in the Future Features

These are things I definitely won't get done soon, but which would be nice.

  • Platform portability - Mac and Linux support!
  • Extreme platform portability - Game console support!
  • Super extreme platform portability - Android, iOS and all the others!
  • D conversion. I really like the concept of D, especially with it virtually being C# but in C++ land. I feel it could make development a lot easier at the expense of C++ purity, but it's not something I'm able to do until at least my course is over.
  • Some form of scripting engine. Whether it's Lua, C# or something completely custom (Probably not), I'd like the ability for arbitrary code to be written outside of the C++ code but can then interact with it. This would make the engine a lot more accessible to those new to programming, and would allow rapid iteration of things in game. I might even attempt a system for non-programmers like Scratch or Unreal Engine's Kismet/Blueprint systems.
  • A bespoke HTML+CSS+JavaScript UI engine that's a lot more lightweight than Chromium. It should still support most of the expected modern features (Including things like <video> and <audio> tags), but lack many of the things that give other browsers their overhead. By being integrated with the engine directly, it also means that Engine specific features could also be introduced such as positional 3D sounds and sending image data to the UI for things like render targets.
  • VR support. Naturally.

Can I Use It/See the Source Code?

No. At least, not yet. I'm still using this in my university coursework, and I don't want to be accused of plagiarism or helping other people plagiarize my work, so for know it's a completely private personal project. Around July/August time though I'll probably reveal it properly to the world to judge my awful programming practices like how I use Allman indenting or how I use the C# naming conventions.

It Begins

Posted 31/03/2017 23:57:33 under Personal

Welcome to my portfolio site or whatever this turns out to be!

I'll be using this site to act as a public diary of sorts, as well as to post info and updates about my various projects and generally act, as I said above, as a portfolio. I even plan to do some programming tutorials, both beginner and advanced for things I find neat!

Also, this site is written entirely from scratch with a suspicious lack of code (Even I'm shock at how little PHP I used for this blog system), so hopefully this protects my site from all those wordpress viruses and whatnot. Hopefully.

I'll continue to update my site over the next few weeks - for real this time - and hopefully have something professional that I wouldn't be entirely embarressed to show to people.