Daniel Masterson - About Me

A New Look - Going Full Vectorheart

Sun, 01 Nov 2026 23:15:00 GMT

A New Look - Going Full Vectorheart

If you’ve visited before, you might have noticed things look a little… different. Gone is the polite grey-and-blue look, and in its place is a whole lot of cobalt, chunky pipes and angled lines. Welcome to the new MasterOf.Dev, now in glorious vectorheart!

Wait, what’s vectorheart?

Somewhere in an old, steel, CD briefcase in my house is a stack of Official PlayStation Magazine demo discs, from disk #1 until the last one my dad would buy me. On a couple of those discs were demos for Ace Combat 3: Electrosphere and Wipeout 3. I played those demos…a lot, and while I couldn’t have told you why at the time, I always loved how they looked. Not just the games themselves, but everything around them. The menus, the logos, the little bits of UI that felt like they’d been designed by someone from a slightly cooler future than the one I was living in. I always had a thing for the sci-fi and cyberpunk.

Fast forward to now. After playing the recently released Ace Combat 8, I fell down a bit of a rabbit hole into the history of the series and rediscovered Electrosphere. In the process, I found out something I never knew - that style actually has a name. Vectorheartz. Flat colours, simple shapes, thick lines, curves and hard 45 degree angles, lots of whitespace and the occasional hazard stripe for good measure. Basically, the late-90s idea of what a slick, corporate future would look like.

As someone who’s always liked that style (even before I knew what to call it), I ended up studying it a lot more, looking at everything from game UI to album covers and posters from the people still making this stuff today. And somewhere along the way I realised my own website was… fine. It was fine. It was perfectly functional, a bit of grey, a splash of bright blue, some diagonal stripes. While it was ‘me’, it was a generalized, basic form of me. The corporate me. Functional, but not very fun. So, with a lot of research, trial and error, it resulted in this!

The New Look

The whole site is now built around a small palette - a deep navy, a saturated cobalt blue and an icy white - with almost nothing else. No gradients, no glows, no drop shadows. Everything decorative is SVG, drawn as thick rounded pipes that run along and bend at 45 degrees, plus the odd circle or disc. The bottom left of the main content panel itself has a chamfered corner, the headings are in Audiowide, a font that I feel is quite similar to the fonts used in those PS1 games. There are tiny monospaced labels scattered around giving you entry numbers, file numbers and read times. Are they strictly necessary? Not at all, in fact they were quite annoying to add. Do they add a little bit of extra fun? Sure. Plus, they make me happy!

One thing I was strict about was motion. Nothing on the site animates on its own while you’re just sitting there reading. After all, I do care about accessibility and website performance. If I’m going whole hog on this style, the lease I can do is not burn your GPU rendering spinning orbs or 3D gimmicks. Even so, page transitions certainly are animated. The line art draws itself in when you arrive on a page, and things react when you interact with them, but once a page has settled it stays settled. I want it to feel like the classic overengineered but otherwise usable UI of a cyberpunk future, not something I would have made 10 years ago when I discovered all the CSS animation technologies…

View Transitions

This is the bit I’m most pleased with. The site always used view transitions - it was one of the reasons I moved from Gatsby to Astro (Although not the main reason. Moving away from Gatsby to anything was the main reason, but that’s another story). With view transitions now being stable in all browsers, though, I’ve decided to put more into it. The page content slides away along that same 45 degree diagonal and the new page slides in to replace it. Go back and it runs in reverse. If you click through to a post from the blog list, the title and date actually morph from their spot in the list into place on the post itself, and back again when you return. It’s the sort of thing that’s completely unnecessary for a personal blog, which is exactly why I had to have it. I know I mentioned literally one paragraph ago that I wanted to be somewhat tasteful and not abuse new(ish) technologies, but view transitions are way too cool. Plus I learned a lot!

The About Page

The about page got a pretty big overhaul too. My portrait is now sat inside a big circle hooked up to the rest of the page by a set of pipes, and the text flows around it rather than just stopping dead in a column next to it. This is done using CSS Shapes, specifically shape-outside - something I’ve not really had to fiddle with before, as I almost always work with plain boxes. It’s one of those CSS features that’s been around for ages but I’ve never had a good excuse to use. Now I do!

The contact links also got a promotion, from a plain bulleted list to a proper grid with each service’s logo and name as a header, and I’ve added my Bluesky while I was at it.

The Lab

You might have also noticed a new item in the navigation - the Lab. This is a new home for small experiments and toys that run right here in your browser. The first one is a Base16 Theme Picker, born from my eternal curse to never be able to choose a colour scheme. Given I use NixOS with Stylix, the colour theme does propagate into both my KDE/GTK apps, as well as the SystemD terminal, so I figure it’s something I want to get right. Anyway, it shows you two themes side by side on real terminal output and code, eye test style (“One or two? One… or two?”), and narrows hundreds of schemes down to your favourite. You might find it useful too if you use Base16 themes anyway, or utilize Stylix yourself.

More experiments will follow. Probably. Eventually. Maybe I’ll create the next cookie clicker? We’ll see.

Under the Hood

It wasn’t just a restyle, either. Previously, all of the content on this site was pulled from a Strapi CMS hosted in Railway. The problem is that the Strapi install was getting increasingly outdated, and keeping it alive and happy was becoming more effort than it was worth for a blog I update about once every couple of years (Sorry). So it’s gone! Every post and page is now plain Markdown living right alongside the site’s code. No CMS, no database, no server to babysit. If I want to write a post, I write a file. It’s what Astro told me to do all those years ago, and I’m finally listening.

Speaking of Astro, I also upgraded the site from Astro 4 all the way up to Astro 7, and from Tailwind 3 to Tailwind 4. That went…better than anticipated. God I love Astro.

What’s Next?

Honestly? Hopefully more posts. I said that back in 2017 and again in 2020, so I’m not making any promises, but now that writing a post is just opening a text file, I’ve run out of excuses. And if you spot anything broken or looking odd on the new design, let me know on Bluesky. I’d love to hear what you think.

Anyway, that’s enough from me. Go click between some pages and watch the pipes draw themselves in. I’ll be here, admiring my 45 degree angles. Or sleeping. It’s been a rough few…years.

Magnetar - Global Game Jam 2022 - Day 3

Sun, 30 Jan 2022 16:29:10 GMT

Magnetar - Global Game Jam 2022 - Day 3

[Read the previous post here]

Magnetar by danm36

And with that, the jam is over, and my game is complete! It’s got a full gameplay loop and everything! You can download it from itch.io from the widget below or from the Global Game Jam site or the GitHub repository using the links at the bottom of this post.

As you’d expect, the final day was spent on game polish, such as being able to win and lose, or having a final boss. Wait, no, that’s important stuff!

Okay, so day 2 didn’t go too great, and it was a mad dash to get everything finished. Definitely don’t think too hard about how the final boss is just a cube that’s been extruded a bit and told to shoot a lot of bullets. Or how the game is way too easy, except when the stars align and you’re completely swamped with bullets. Even so, I’m pretty proud of the end result. There’s a full gameplay loop, with win and lose states, and even a two player mode! I also actually did put a ton of polish in places when I should have been fixing the core mechanics. For example, the main menu. I’ve very proud of that. The animation, the sound design, the unnecessary nature of it. Wonderful.

The very beautiful ‘Command Ship’, or final boss. Each of the large square ports regularly spawns common enemies, while the two blue prongs shoot a rapid stream of alternating polarity bullets. Ignore the design outside of that, I had an hour and a half to model, program and configure this and I just went ham with the extrude tool.

In addition. while there’s no soundtrack, every important action does have a sound effect. Sure, they may not be mastered very well, but it’s there and it helps a lot with the game feel. And there’s the background asteroids, something I nabbed quickly from another shelved project of mine, Elysian Fields. I mean, I could have very easily potato-ified a sphere in Blender, but I already had some lying around and any minute saved was worth it. With them there, there definitely helped a lot with adding depth to the scene, and showed that you were actually moving through space (Something that wasn’t best conveyed with just the skybox, where you could have just as easily said you were spinning around in place).

Honestly though, even though my game isn’t the most unique or special, it’s nice to do a game jam after so long, and finish a game that isn’t just a horrible buggy mess! This definitely isn’t my last jam, by a long shot.

The Global Game Jam page for Magnetar can be found here.

The GitHub repository for Magnetar can be found here.

An example of gameplay. Each of the glowing dots is a bullet - the white ones are the player's, while the red ones are positively charged and the blue ones negatively charged. The player's ship is currently negatively charged, as shown by the blue trails and the UI, meaning the blue bullets will be repelled, but the red ones attracted. Moments after this screenshot, the player was hit with a large number of bullets.

Magnetar - Global Game Jam 2022 - Day 2

Sun, 30 Jan 2022 03:58:42 GMT

Magnetar - Global Game Jam 2022 - Day 2

[Read the previous post here]

A lot has happened today, and at the ripe ol’ time of 4am, that concludes day 2. Tomorrow (But really later today) is the final sprint towards the finish time of 3pm, so after writing this I’m going to have a short rest before I continue. I need it after redesigning the entire game concept a good three times…

Eventually I settled on having only the enemies shoot magnetic bullets, and the player’s ship is of a certain polarity. By holding a button, you can flip the polarity, allowing you to selectively attract and repel the enemy bullets to - hopefully - clear your way. This also immediately gave way to a surprisingly easy to implement two player mode, whereby each ship has the opposite polarity and they can’t be flipped. Combining this with giving the players different weapons - shooting directly ahead for player one and at angles for player 2, and you’ve got the recipe for a good co-operative dependence system (so long as you don’t accidentally fling a bullet at your buddy.

Player 1's ship is on the left and Player 2's ship is on the right. Player 1's ship is also the single player ship.

The enemies are extremely simple, and there are currently three implemented types (with ideas for six). The most basic enemy just sits in one place and fires in one direction, making it very easy to defeat so long as your magnetic field doesn’t put you in a negative state. The next type is the first enemy, except it now looks at you. Finally, there’s one that tracks you and fires two shots at once, although since both bullets are of the same polarity they quickly separate, adding an aspect of chaos. The fourth enemy I was in the process of implementing is essentially a ‘mine’ or ‘blast’ enemy that just spews a bunch of bullets in all directions.

The three current enemies that are definitely not palette swaps.

In addition to this, I’ve also finally managed to set up a main menu scene, allowing you to choose between either mode as well as giving a small tutorial. The logo has a short animation I spent way too long on, but that’s something you’ll have to see next post (or when you can play the game). Now while the game does feature a fancy spline you can loop around on and a number of battles to take part in, there’s not exactly a ‘win’ state. Or, actually, a ‘lose’ state. If you die, the ship just keeps exploding. That’s a tomorrow problem I think. Honestly, I’m sure I’ve done more stuff, but looking back, it was mainly just gameplay experimentation and fighting with the magnetism system. Hopefully more content gets done tomorrow.

The Global Game Jam page for Magnetar can be found here.

The GitHub repository for Magnetar can be found here.

Magnetar - Global Game Jam 2022 - Day 1

Sat, 29 Jan 2022 10:45:51 GMT

Magnetar - Global Game Jam 2022 - Day 1

It’s been a long time since I’ve done a game jam, so I’ve decided to take part in Global Game Jam 2022. I’ve finished day 1 (Friday the 28th of January) and made both more and less progress than I would have liked.

First off, the theme. “Duality”. It’s a good theme, and I had plenty of game ideas to work with…that would have taken well over the allotted time span. Still, I’ve finally settled one one. I don’t think it’s necessarily a ‘good’ idea, mind, but it’s still a good way to experiment with the idea.

My project is called ‘Magnetar’, and if that wasn’t a big enough hint, the duality I’m aiming for is with magnets…IN SPACE!

The general game will be a shmup/bullet hell based in a typical space-based environment (Reduces the needed assets 😉), and alongside the standard yellowish-white bullets that act like normal bullet hell bullets, there will also be red and blue ‘magnetic’ bullets, representing north and south or negative and positive poles respectively. The player, using standard shmup controls, will fire their normal bullets by holding the spacebar, but when the enemy throws magnetic bullets their way, they can left or right click on the screen to send a specific positive or negative in that particular direction (The standard bullets are un-aimable like in a typical bullet hell), with this bullet either attracting or repelling the enemies bullets and - likewise - the enemy bullets affecting the player’s own. There will also be suitably charged enemies, meaning that these magnetic bullets can home in on the enemy - unless they swap polarity.

Now, I don’t have 100% confidence in this project like I did with several previous ones (My Microsoft Excel-based dungeon crawler naturally being the best possible idea anyone can have…), but fingers crossed it turns out better than I hoped.

After day one, starting with a meeting at 5pm with the event organizer and ending when I got hungry and tired at 10:30pm, I made considerable progress. In a shocking display of creativity, I decided to do the player model before even prototyping the project for…some reason. While the model isn’t exactly stellar, I did just make it in an hour and it more than conveys the idea.

The Player Ship, as seen in Blender. It looks a bit like a bird, but then I think forward-swept wings are cool.

With that out of my system, I finally opened Unity. For those who know me, this is a rare sight - when Game Jamming I usually do something stupid and off the wall, like my previously mentioned Dungeon-Crawler-In-Excel or building a ray-traced 255 colour RPG in the windows console. Still, other than using two Excel sheets as some form of Duality, I figured I should probably actually use something more designed for game development…this year. After sorting out a number of the usual FBX import issues, I finally had a ship in game. I wrote in a basic character controller, including keeping the ship within the visible bounds, as well as a controller for the ‘playable zone’. This allows the player’s ship, the camera above and anything else directly tied to the playspace to move along a given spline (And, if I’ve got time, hop between splines). Rather than rewrite splines for the 4th time in my live, I decided to grab the excellent ‘Unity Spline Editor’ from OpenUPM (An excellent store of free Unity libraries) and, within a surprisingly short amount of time, managed to get the playable area moving along an arbitrary track, rotations included.

Annoyingly, the bit that got me stuck was shooting. I’ve built up a bullet pooling mechanism that can pool arbitrary bullet prefabs no problem. The problem is actually shooting the damn things. At the moment, I’ve been trying to shoot them into the global area (ie, not tied to the roving game space) as that’s “more realistic”, and for whatever reason I can’t get the velocities to either be the right speed or direction. Now, I am tempted to instead bind bullets to the play area, meaning that the environment around the moving space will become nothing more than a backdrop. I guess I’ll just have to have a play around and see.

Anyway, to summarise, after around 5 hours of total development work, I had a player model, a player controller, a roaming play space and the concept of bullets. Not too bad I guess? Anyway, now it’s time for day 2!

The Global Game Jam page for Magnetar can be found here.

The GitHub repository for Magnetar can be found here.

The Return of the Development King

Fri, 14 Aug 2020 16:52:58 GMT

The Return of the Development King

Ok, so my domain ‘masterof.dev’ might be considered a tiny bit extremely narcissistic, but a friend suggested it when .dev domains were first announced and I just had to buy it. And then, after wrangling SSL certs into place…nothing. But that changes today. Today, I am back.

To be entirely honestly, my previous website – entirely written by yours truly – was built on pretty shaky ground. Hey, if you knew the URL, you could write any posts you wanted pretending to be me since I hadn’t implemented auth yet. That’s how shaky it was… I’ve decided to give in and am now using the significantly more user friendly WordPress as a basis, hosted by my NovaDawn Studios network, naturally (That actually just saves me a ton of effort rigging up a new WordPress install, so shush). Maybe, with an interface I don’t hate massively, I’ll actually post more. Fingers crossed, eh?

Speaking of NovaDawn, I don’t want to spoil too much, but we’ve got a big project in the works, so follow that blog alongside this one to keep updated, you hear!

Anyway, for now, I’ll sign off. But I’ll be back… You bet I’ll be back…

Three Thing Game – I finally won one!

Mon, 15 May 2017 16:15:00 GMT

Three Thing Game – I finally won one!

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 AO’s arenas with a faux Greek style.

The 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, that’s one of the ‘things’ solved, and in a very nifty way too. How about we tackle ASCII next?

Now, I’ve made 3D games in raw 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 we did! First, I generated a texture atlas of a variety of Latin, Cyrillic 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 and floored (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 projectiles.

A part of the world fading in with the ASCII effect clearly visible.

The 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 actually quite easy, The game ended out balanced and there was a full gameplay loop, including completion and player death. I’m honestly very proud of the game, although I’m still 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

Wed, 19 Apr 2017 23:03:00 GMT

C++ Reflection for 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 with regards to 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 for use 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 (I can probably use templating much more successfully for this, but for now it’s preprocessor only).

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 variadic 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 now. 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 might have guessed 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

Mon, 03 Apr 2017 21:29:00 GMT

An Introduction to C# Attributes and Runtime Reflection

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: 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 C# or 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 to 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 tag 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# compiler will automatically handle the ‘Attribute’ suffix 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(object obj, bool isAutoSave) 
    { 
        StringBuilder saveString = new StringBuilder(); 
        SaveableAttribute saveableAttr; 
 
        saveString.AppendLine($"[{obj.GetType().Name}]"); 
        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. This gives us access to a number of key reflection classes such as FieldInfo. If you’re using Visual Studio, it will shout at you pretty sharpish and provide the intellisense prompt to automatically add it. Now, this SaveManager class is just an example, requiring all fields to have an appropiate ToString() method, 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 you can probably surmise that methods use MethodInfo) 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 check, 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 – a type that stores all info regarding a method, shockingly – has an Invoke method that can call that method on an object (or none at all if it’s static), allowing you to automatically do things like create UI elements. As mentioned before, you can create an instance of an object by having it’s type name as a string, then loop through all it’s fields and properties loading in data saved to disk. The possibilities are vast, if somewhat complex.

As a bit of an anecdote, 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 developer could just write in C#, and the Clojure frontend 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 with some different syntax, so give it a try!). Until next time!

Book Review: Revelation Space

Mon, 03 Apr 2017 11:02:00 GMT

Book Review: Revelation Space

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 finale. The story regularly jumps between these characters and their associated timelines, something that’s seen in the future stories as well. Alastair 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 Ultranauts (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 armoury 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] Alastair 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?

Sat, 01 Apr 2017 17:10:00 GMT

What is 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 appropriate. 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 PBR 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 significant 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’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 and 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 now 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

Fri, 31 Mar 2017 22:57:00 GMT

It Begins

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!

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 embarrassed to show to people.