ORE Devlog January 2020

It’s all been a bit quiet on the blog and stream front, this was due largely to business getting in the way, but my mental well being has also played a part.

Let’s get the one that’s difficult to talk about out the way first. I was going to write an in-depth article about this but a brief synopsis will suffice and the brief synopsis goes something like this…

Seven years working for people who in my opinion had zero clue how to effectively manage people and motivate people, instead adopting a ‘I’m better than you’ stance all the time and delivering the criticism to match. An inability of senior management to recognise the positives within my team and to thank us for all the effort we put in (our customers loved us and we consistently achieved some of the best feedback in the company but this counted for nothing). Net result for me was a complete lack of confidence in my ability to produce software and a constant need to re-evaluate my decisions just in case there was ‘a better way’.

A note to the people concerned – If by chance either of you are reading this, you may disagree with my assessment and that would be typical, but this is how I ended up feeling and it is my opinion of you as managers (an opinion that’s been shaped by having a lot of different managers in the course of my career, some good and some bad, but none of who made me dread going to work which is what you two achieved along the path to my destruction).

I started to get my mojo back around spring 2019 and so I started streaming and working on our new game project with the view that having an audience (even if it’s actually 0 people) would help force me to make decisions. Unfortunately it didn’t work out as well as I wanted and I’ve already thrown most of what I did since then away.

The reasons I’ve thrown much of it away were primarily because I ended up feeling I was approaching it in the wrong way. Instead of focusing on the core of the engine and starting at the very beginning, I was focusing on fancy GUI based editors and the complexity within the application was spiralling out of control. So just before Christmas I ditched everything and started again at the very beginning with the exception of one or two utility classes such as the texture atlas.

For this project, the very beginning is the Lua interface because that’s what’s going to be used to get the content into the engine and control everything from simple object interactions to the complex quest lines we envisage within the game. I’ll go into detail about that below, but before I do, I’d just like to cover a few other bits of why progress has been slow.

Indecision (Again!!!)

I’ve been trying to settle on some dev tools to keep track of issues, source code and documentation. I’ve been looking at all sorts, at the time of writing, I’m using YouTrack, Gitlab (I don’t see this changing anytime soon) and Wiki.js, and I’ve had to do some server wrangling to get these running on my CentOS 6 box but they are all there apart from YouTrack not pulling issue status out of commit messages (and JetBrains… if you happen to read this, I really don’t think much to your on-line resources, they’re great if everything is working but I’ve tried to find even the most basic information about how YouTrack looks at source repos and the information is lacking, some ideas about how frequently it scans if it’s periodic, which processes do the scanning, where can I find their configuration… you know basic shit you need when things aren’t doing what they should be, anyhow I digress).

To Test or Not To Test? That is the question

Should I be writing unit tests for everything? The obvious answer is yes, I should and whilst I can see the benefits they provide, I’m still not convinced they are always the best way forward.

One argument for them is when it comes to refactoring. Make a change, re-test and that’s great. But since you’re supposed to write tests up front and then write code to make the tests pass, that requires you to know in advance exactly what you want the interfaces to be, what methods you’ll have etc. etc. etc. I don’t know any of that right now. This is a journey of discovery.

Another argument for them is that if you do them right, you end up with nice loosely coupled code. But here’s the thing… I’m not sure I want loosely coupled code. I’m aiming to make my code blindingly fast because that’s what I need. This isn’t your average desktop application, it’s not a server application where you can theoretically test each ‘transaction’ if you will in isolation. Sure I have classes that are for a large part self contained, but even they are hard to test without doing a huge amount of setup, much of what I’m writing now requires complex structures to be setup in Lua and to then look at say every property of the objects they spit out. Sorry, but errors in these routines will be self evident within the editor… tiles won’t have the right frames, the right properties etc.

And then there are things like the texture atlas… how can I fully test that with unit tests? I can visually inspect the images it produces to check they are correct a lot easier than I could write code to check them.

So, I’ve been toying with unit tests but not on the game project. I did create a test project but I’m just not convinced unit testing the stuff I’m working on now is worth my while. This is based on my experience with The Ray Tracer Challenge which defines a ray tracer and all the things you need to make one by way of unit tests. Putting the tests together is the bit that takes the most time… sure I know I can run them over and over, but for simple things I’m just not convinced they are worth the effort.

That’s not to say any of you reading this should adopt my attitude to them, I think part of my problem with them is that I don’t want to bog myself down with them because they would add a layer of decision making I’m not sure I’m ready for right now. I need to make progress on the main codebase of the game and focus on that so I can regain my mojo and self belief. Periodically I take a look at them and each time I make more progress towards using them, so I’ll get there in the end.

If by chance Nick Hodges reads this… sorry Nick 🙂

My Business Went Nuts

And the other reason progress has been slow is because my business went crazy in the last quarter of 2019 resulting in me either having very little spare time or being so tired I was just falling asleep at my keyboard. Thankfully, Christmas intervened and I’ve spent most of my holiday moving things on.

So where are we?

The Lua interface is now taking shape and some of the biggest hurdles I felt I faced have been hopped, the biggest one being how to get the definition information out of Lua and into the objects that will contain it within the ORE engine.

That doesn’t sound like much, but to this point it’s involved some deep diving in into the Lua API and learning it and the Lua used to define things and also some deep diving into the runtime type information facilities Delphi provides, something I’ve really never done before so it’s been a great learning experience.

I’ve just published an article about pulling Lua tables out using the Lua API (this covers a gotcha that caused me no end of issues and ate a lot of time) and the facilities I’ve written are now at the stage where I have just a few more specialist types to support during the processing and I’ll have the ability to pull in all the tile definition data I need to start building the renderer and the top down map editor.

And so concludes this instalment of my devlog. If you fancy following along on this game development journey, feel free to drop by my stream and have a chat 🙂 Until next time, happy game deving, happy gaming, take care.