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.