Week 6


We're past the sixth week since Feudums officially restarted and finally had our first infrastructure-related random event. Going by Clarke's third law (that a sufficiently advanced technology is indistinguishable from magic), it is my old observation that it's a perfect fit to poorly documented IT problems as well. At the end of this week, Unity, out of the blue crashed hard on some seemingly random thing and from that point, we were unable to open any of our scenes or do any work in it. Unity logs kept reporting that everything is perfectly fine... while the Editor itself kept hanging up in infinite loops whenever we tried to do anything. We couldn't even a create an empty, new scene. It was all a dead end.

Still, as a perfect example of how the same situation can be perceived differently by different parties, it has remained an "everything is superb" situation for Unity.

Long story short, it took nearly six hours to check the logs, uninstall & reinstall Unity, clone the code into a new project, have it hang there too, reinstall different beta or stable versions, remove third party libs, add them again, remove our old code blocks and add them again, remove various caches, etc - so, to basically proceed with trial and error (the most time consuming way to find or circumvent an issue). At the end, it still didn't work under either version. I was able to make it work again by cloning the latest code revision and manually adding everything that has happened since - until the codebase, on our side, became identical to what broke hours ago. That worked... but then we couldn't find anything in our code or third party libs that could trigger the issue again. It certainly had to be something Unity generated from our code and scene setups, but it never happened again on the same codebase.

Unfortunately, we still don't know for sure why the Unity Editor stopped working or how we can prevent it from doing it again. We know that it's about the building process, not the runtime (so it doesn't affect the executable game), but it's always annoying in a (mostly) scientific profession when you can't seem to find the root cause of a problem. Especially if, according to Unity's logs, it just didn't happen at all. Obviously, it had to be... magic.

Still, as Mark so perfectly pointed it out: life happens. There will always be random issues, chaos, unexpected turns - new challenges. These cannot ever be perfectly eliminated - sometimes it's just out of our control. How we treat them is something we can decide though.

We, for one, have developed some resistance to IT-related magical events over the years. We have code repositories and a backup policy we employ. We have action plans for various issues. In this case, the project code was safe in their repositories and I had my unsaved work locally (abiding Murphy's Law, the crash, of course, happened just before the daily code commit, so to put the most work possible at jeopardy). That means, in worst case - if the crash would have corrupted the local copy -, I'd lose a day of work (10-12 hours for me), and the time I spent investigating the problem. We ended up losing about half the worst-case time loss and I saved all the work, except a few tiny details, as the issue didn't corrupt the scene files.

Random issues, while frustrating, can't stop us - and just like the world would like to test this sentiment, while writing this post, I've got three power cuts, and lost a couple sentences a few times already. Still, it's almost ready. Frustrating? Yes. Still making progress? Why wouldn't we? This is the way it works.

But, since Feudums is going to be a magic-free world (for now), let's talk about our weekly facts a bit.

The Coat of Arms GUI in the works

 Game Client

  1. I've added some new debugging options / editor tools for more efficient testing, and made some further optimizations to the CoA structure while continued testing the new CoA assets.
  2. I've spent a day trying to improve the Coat of Arms Creator GUI.
  3. I've also designed the workflow / navigation of the Player Module related processes, from the splash screen to the game dashboard; and started to implement it.
  4. The client code has also been updated to the newest stable Unity version.

 Platform & Game Server

  1. Steve has primarily worked on code separation, refactoring and API testing of the Player Module - turning "internal beta" to "stable".

Yes, we're still populating the available options for the CoA


  1. The eff-ing miracle was over in like 30 minutes I posted the last weekly report. Fortunately, nothing serious has happened ever since, just the usual issues with pictures and rights management. Just don't be worse!

 In the next episode  

  • Client: I want to rig all the Player Module related scenes so we'll have full coverage for the Player Module and the CoA creator (which is part of the registration process) properly. It'll probably tie the release of these modules together on client-side.
  • Server: Steve is expected to finish the code refactors, setup initial values and then we can hook the client to the server, to test it "for real".
  • Site: We plan to raise a few questions for you in the very near future, which might require some work on the site code


  • +1 (Design): I've came up with borrowed a core idea from other, RPG-ish games (pen & papers and CRPGs alike) that would give an alternate way of creating unique Noble House backgrounds in minutes. We still need to talk it over and check if and how it can be seamlessly integrated to the workflow.

Ow, how adorable that little trickster is..!

See you in next week!