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.

An interesting start

Now I did say a biweekly schedule for updates here, but I've been focusing pretty heavily on the project that I didn't really want to pass last week just to post a new update.

I think I am starting to feel the burn out of working on my project plus working full time. The last time I really felt this way was when I was working on Combatics Evolution. I really enjoyed that time even though it was extremely exhausting. I had a minor setback earlier this week when one of my drives that happens to house a large portion of the project decided to start dying on me. Luckily I've moved my data onto a new drive and created some online backups to keep my mind at ease. However, it still cost me about two days and a late night to get things set up again. I will be looking into getting a proper mirrored raid setup for my system in the near future but it isn't a pressing concern.

Unfortunately, a lot of my time over the last 3 weeks has been all about prototyping and proving architectural decisions. Something I was successfully able to finish last week and very happy to report that each component of the system I am building will work together nicely. Now, I am still going to intentionally not talk about exactly what I am working on, but I will talk about a few of the things I was prototyping and a bit of the logic behind it.

I'm going to be using Unreal 4 as my graphics engine. Notice I said graphics engine and not game engine. Part of my decision behind this was I really want to make use of the power of Unreal 4 when it comes to rendering and handling user input. I continued to spend a good amount of time digging into some of the internals of it as I started figuring out how I wanted to do the user interface. Unreal 4's GUI system is terrible, just terrible and poorly documented. I tend to find most of Unreal 4 is poorly documented and it is usually easier to look at the source code than to ask Google or read the documentation. This is one of the big downsides of Unreal 4, there is a lack of community and as a result a lack of good documentation and tutorials. Most of the tutorials I find tend to be all about blueprints... which is basically next to useless for me as I don't see the value in putting complex logic into a graphical based programming language. I think Unreal 4 was really targeted at non-developers and thus most of the guides and help talk about blueprints. Very few guides exist for 'how do I do X in C++' which has really made working with Unreal 4 a painfully slow grinding experience. I do see how once I become more fluent with the engine and gain knowledge about how I should be using it things will become noticeably better. The downside is that every hour I spend trying to figure out how to do something is an hour I am not actually doing something.

The result of this is a painful development experience, and don't get me even started at how rough the experience is using C++ in Visual Studio. It reminds me of when I was working at Autodesk and about half the time I was waiting on a compiler and loading of binaries to just run a quick check of the application. My development style is very closely tied to a rapid PDCA cycle, which means anything that slows down the cycle, also slows down how I develop code. From my experience, most people who code follow a similar pattern where you develop the code in pieces over time instead of trying to write a large chunk of code without testing it. This is why I'm intending to only use Unreal 4 as a graphics engine. I want to harness the power of the engine but I don't want to be slowed down by the lack of documentation and the architecture of the engine which is inappropriate for my project. If I really wanted to stick with using Unreal 4 for the entire project then I would end up having to fight the engine at every turn to make it do what I need it to do. I don't want to fight it, I just want to use it.

So how do I plan to escape the engine, and won't that be a lot more work? Well, yes, it will be a lot more work upfront as I need to come up with the complete system and I will need to clearly define communication interfaces between the Unreal engine and the rest of the system. This isn't a knee jerk reaction, I've been planning this and prototyping some aspects of the for the last 2 months. Recently (about 5 weeks ago) I decided to take a nose dive into Unreal and see what the engine had to offer. Basically evaluate how it works, what it can provide me, and build a basic prototype of the project I am planning to create in the end. My conclusion was I want to use the engine only as a graphics engine and interface for the user. Everything else I plan to make use of other frameworks and libraries in a modular architecture. Essentially, the way I am architecting the system will allow me to completely drop Unreal and replace it with something else, such as Unity. I won't do that unless the need arises, but it will always be an option.

I am now at a point where all the technologies and components are tested and most of the non-trivial ones I have worked out how to integrate them together. I plan to make use of a large number of libraries and avoid writing code that isn't directly related to the project or connecting the libraries together. My current task is getting the full stack networking up and running, and perform some real-world testing of it to make sure the whole architecture is sound and practical. Once that task is complete and I then need to finish work on getting a reasonable way to get automated testing for it all working. I will also likely spend a small amount of time getting the basics of a build system together that will package everything nicely together. Once that is all complete, then I can start looking into actually building the project. I know I will need to brush up on my Blender knowledge in the next few weeks, but I'm going to defer that for as long as possible because I really would like to get the project going forward and out of the prototyping stage. Once I'm out of my initial prototyping stage and have the full stack functional I will start to talk about the details of the project, but until then I will continue to keep it light on the details.

Now where was I...

It would appear that things haven't changed around here in a while. I'm going to shake it up a bit.

When I last posted I was in graduate studies with very little spare time, and when I had spare time it really was to just try and relax and have some fun. It has been almost a year since I finished off my master's degree. In that time I've been doing what I feel like catching up on things I missed while in school.

One thing I have been doing a lot more since I graduated was work on my hobby projects. I sort of decided around December that I wanted to get back to working on things and spend less time playing games. Before that point I had poked a few things here and there kept myself a bit familiar with things going on such as the arrival of a free version of the Unreal 4 engine. Updates with Libgdx and news about what to expect with Java 9.

I've been working full time and with it a very heavy web development role which has brought my web skills back to the modern age and I've come to learn a lot more PHP, Javascript and SQL than I ever knew before. It was nice to get really sharp with my web skills as going forward it will be helpful if I ever need to crack out a website or dig into a database engine as a storage mechanism. It is sort of strange that before a year ago I never really valued the power of a database as most of the things I do with games has really been, keep it fast, keep it in memory and make it run well with multiple threads. When it comes to databases, you sort of get all that for free(ish) plus networking, data storage, persistence, redundancy if you scale it with multiple systems, etc.

I have also come to understand different types of database systems. SQL vs no-SQL, Graphing, and Geospatial. Which has lead me to start thinking about how I could turn them into powerful back-ends for games. Maybe not what you typically think of when it comes to games, but I really feel they would be of use.

There also has been two 'recent' languages that have caught my attention: Kotlin and Rust. Kotlin, I feel very much at home in because of my very extensive experience in the JVM ecosystem. Rust I haven't found the time to dig into but it is on my list of things to try out. I have a suspicion it will be a very pleasant low-level language. Another language I poked at a bit during my graduate studies what D. Which I have to say is a decent language if you come from a C++ background as it sort of melds together C++ and C#.

I have gotten myself very familiar with Kotlin and been using it for a couple of projects I got on the go right now. One of them was a survival-based tower defense (think of a more complicated version of Plants vs Zombies). Which I developed to an almost playable state but then decided to drop the project for something else that I've been itching to work on. Using Kotlin I realized I have finally found a language which I really like working with. While I have used Java for years, part of me really hated the verboseness of it and I started playing around with Scala, Groovy, and Xtend. Each of which are decent but none of them I was satisfied with their tool or library support. In my opinion the quality of tools and libraries for a language outweighs everything else about a language. Kotlin sort of fixes that issue. Not only is it a non-verbose version of Java but it is very tightly integrated with Java such that making use of Java libraries is natural and straight forward. Xtend was very much the same way, but the tool support was fairly buggy and the syntax seemed more hacked together than well thought out.

Anyways, I mentioned I have a new project I am working on... but for now I'm not going to say too much about it. It really has to do with the fact I am prototyping it out right now just to see if the tools I want to use will play nicely together. So far it has been good and I've been making progress but I feel its far too early to go into the details of what I am working on. Which goes back to my first point about shaking things up. Someone I know mentioned I hadn't updated my blog in a while... and it isn't because I haven't been up to much... more the opposite really. Now that things are sort of settled down in my life and things are a lot more stable I feel like updating this blog more often would be useful. I'm thinking to try and stick to a biweekly schedule... But I'm sure even with my best intentions I'll miss the odd week here or there.