Update 2

Another refactor
Once more the game has been re-written from scratch, the Lua build was working great but certain limitations were becoming obvious. It wasn't a complete waste of time, the improvements to mod support were carried across to the new C# code base. This time I went with Test Driven Development and it has paid off well, within a month most of the features were implemented and working. Currently there's nothing to look at game play wise, just a series of unit tests that pass, I'm keeping the game's logic entirely separate from the user interaction aka actually playing the game.

It won't take too long to bring back the UX and allow the game to be played, but for now it seems unnecessary and would only slow development. There's enough unit tests to make sure bugs are found within seconds of hitting compile, instead of having to repeatedly play the game in a specific way to verify a bug has been squashed. I'm sure a whole batch of new bugs will be found when it is playable though. It also ensures the game logic is entirely separate from the UX, which means it'll be easier to debug and to make a headless server that doesn't need as many resources to run.

What's really new
So what's new since the last post besides all that? I introduced ECS architecture to improve the game's performance and support multi-threading, even with the mix of OOP and ECS the performance tests were very positive. In the early stages multi-threading shows a decent improvement and as more game logic comes in it'll provide a significant reduction in turn times. The mod support has improved over the Lua build too, a few more important hooks are in to allow for more flexible mods. Debug logs are more consistent and verbose too, which will help in the future.

Game play wise though I've been working on a completely new way to handle the quality of products worked on by your virtual employees. Prior to this change the employees would produce work with a quality and efficiency rating, just two numbers, while also randomly generating a number of bugs based on their skills. This method ended up being a memory hog, late game you'd end up having products take up megabytes of space because they'd have so many different versions with thousands of bugs each. Going back to the drawing board I came up with the MERC system, which stands for Modularity, Efficiency, Reliability and Consistency

The MERC system
Lets take a programmer who is working on a product that has had an average design phase, they'll write a bunch of code and produce say 10 units of work based on their skills and time. That chunk of work will have 4 values between 0 and 1 attached to it:

• Modularity might be 0.5 or 50% because the programmer is moderately skilled and the design phase was average. A poor modularity will impact fixing bugs, more code will be impacted by a fix, and adding new features will require more work and increase the chance of creating new bugs.
• Efficiency is 20% because the feature being worked on suffers from being written in a high level scripting language. If the feature was important you could change it to a lower level language, like machine code, or after being done you could assign a programmer to optimize the feature at the cost of modularity and consistency.
• Reliability is 60% due to the programmer being somewhat error prone, lacking knowledge in the feature and having little prior experience in the scripting language. This is the biggest factor in determining if a bug is encountered during a product's use.

• Consistency is 80% because the product is actually being worked on by a single programmer. You could also increase consistency by ensuring your company has clear programming standards, this might be done by producing a book on your preferred coding style and getting employees to read that.

There's many other factors that impact MERC ratings so the above isn't a complete example, just a basic overview. Another big impact for programmers would be the IDE used to write the code. Using a basic text editor vs an advanced IDE that has code prediction and consistency styling built in will be vital to producing software products that are industry leading.

The system works just as well for the designers, hardware engineers, writers, builders and even artists. Imagine a 2D sprite based character, Modularity is how easily you can swap clothing and hair styles, Efficiency is how impactful every pixel is to both the visual appearance and rendering cost. A low efficiency means you need to use more pixels to produce a similar quality of sprite as a higher efficiency artist, this means more power is required by the graphics card to render that art and produce a good looking game. Consistency is making sure every different outfit and hair style looks like they match visually. Reliability is about avoiding a single bright red pixel in an outfit that's meant to be entirely green or having a walk animation that has one frame of the character facing the wrong direction.

The new system ends up being a little bit of a cheat as bugs are no longer directly linked to the work performed. Instead when the product is simulated there's a chance of a bug being encountered by using the feature's MERC values, which will determine the bug severity, chance of encountering it and how difficult it will be to fix. Once encountered the bug is stored so it can be fixed or encountered again by other users, fixing the bug will naturally change the MERC values of the feature (hopefully for the better!). This seemed like the best compromise to keep the simulation code fast and memory usage low, while also offering a universal system that can be used by every profession. I'll look into opening this up to modding support so that mods can have their own values system.

Other news
I've recently landed a job working on web apps! While this is great news to myself it does mean there's been less time to spend on the game. The hope of releasing something playable by the end of the year is looking a little unlikely, but it does ensure I can keep this game free without having to worry about income. I haven't had any time to work on it since starting, due to being completely inexperienced in web dev, but I've been catching up quick and will start setting aside time to continue the game's development next week.

• Focus
  I still need to re-implement the handling of new product versions, so that developing new versions retains all the work done so far. It shouldn't take too long to complete this.
• The biggest task will be reintroducing QA support to products, being able to assign a team to test, report bugs and fix them.
• Client and server will be re-implemented next, which is really about getting support for serializing the state of the game. This work will also be a large part of being able to save and load games again.
• Once the above is done it'll be a great point to get the client running alongside Godot to make the game actually playable again. I should be able to reuse the majority of the work done in the last Godot build for this and have it up and running without much effort.