June 6, 2016

Multi-threaded, Networked, and Expanding

Since my last post a significant amount of my time as been working through some of the fun and exciting challenges of working with Unreal 4 and fleshing out some of the larger architectural parts of the project. At some point I'm going to have to put a name on the project and while I have a working internal name that I currently use, I still haven't decided if I want to stick with it. Naming is hard. I sometimes find giving something a good name is harder than actually building the thing you are trying to name. So for now, I'm going to call it 'the project'.

I can never stress it enough about how important architecture is when it comes to building an application. Throwing software together and expecting a good result is like taking a box full of puzzle pieces expecting the puzzle to assemble after you've shaken the box. Sure, over the lifetime of the universe it might happen, but lets be honest, nobody has time for that. I've seen many games go from being single-player to multi-player, go from being single-threaded to multi-threaded, or go from running well on a single-platform to running well on multiple platforms. It is possible, but doing it after the fact is a very huge investment compared to setting things up correctly the first time. I believe the term is technical debt, and when it comes knocking on the door for payment it has the tendency to stick around. One of the many design decisions I make when starting most projects is to figure out what my options are, and then more importantly how to make it happen with the least amount of effort from myself over the long term. If I look only at the short term is is very easy to slap together a prototype and get something practically unmaintainable out the door. Sadly, I see it happen far too often where a project goes out before it is ready. If you want some good examples take a look at some of the early access games on steam.

I have been under the strong belief over the last 10 years or so that any demanding project which isn't making use of multiple threads is just not being designed well. I do see the value of simplicity in writing a single-threaded application, but I also know it isn't hard to multi-thread an application if you go with an event or task-based approach. (It isn't coincidence we are seeing task-based features being added to our current modern languages like C#, C++, JavaScript, etc).  One advantage of being event-based is the ability to easily scale the application. Like everything, it does come with a cost, in particular it makes tracing the flow of logic a bit more complicated and reasoning about the system is slightly more challenging. However, it forces you to make clean separations of concerns and have an extremely low-coupling. I'm not a huge fan of actor-based systems, but the general idea behind actors I really like and make use of them. Below is an example of why I like this approach.

In the above image you can see CPU activity of my computer when running the project I am working on under a moderate artificial work-load. Now I say artificial because I am still in the process of connecting everything together. Okay, that is a little bit of a lie, it is all connected I have just been cleaning up my communication layers between different areas of the project. Nevertheless, the above image is an example of an application which will scale with processing power. Moreover, half of the above load would vanish if I added a second computer. With my given architecture it is possible for me to have the application run on a server cluster without a huge investment of my time. I am not planning for it, but the option is there if I ever see the need to spend my time expanding the system. The reason I can do this is because I have designed the architecture of the system to operate this way.

Again, if I just wanted to get a working prototype done and out the door that could have easily happened over a month ago. In fact I did have a basic working prototype in Unreal 4 a while ago. However, my concerns with Unreal's architecture made me decide on going with a hybrid approach where I am using Unreal 4 without building most of the project inside of it. In the next few weeks I will be able to start focusing on fleshing out the project instead of getting all the parts working together. Essentially, I'm on the edge of getting into the fun part of the project, but until then the shroud of mystery about the project will remain.

No comments :

Post a Comment