Week 1

Hoi,

This is my second attempt at creating my first status report for you, and if you're reading this, then we can safely assume two things:

• I haven't forgotten to use the "save to draft" feature, like I did a couple days ago just to watch in horror as my hours-of-work masterpiece desintegrated in a hindsight. 
• Thus it's evident I'm capable of learning from the stupid mistakes I make.

In this situation, we can speak about a good (re)start, and my ability to improve is probably comforting for both the team and the community alike. 

If you're not reading this, though, then... well, I am not only unable to learn from my mistakes, but is already speaking to myself and the project is in grave danger. Albeit it's safe to assume you will never see this warning. Well - life sometimes sucks.

Past & Furious

Just like, when you have to make the quite painful decision of actually re-implementing a game you've already spent a hell of a lot of development time (and budget) on. That being said, I won't talk anymore about this annoyance - what's buried is better staying buried - let me just assure you about this instead: while we're not going into lengthy details of the whats, hows and whys, it doesn't mean we haven't spent a long time analyzing the technical debts, the skill gaps, the planning and managerial mistakes, basically... the whole situation that led to this outcome, and how we can limit the chances such a disaster can ever happen again. From multiple perspectives, we've found the moral of the story, learned a couple of lessons, and... for the sake of the project, the community and ourselves, decided on moving forward to the future, instead of talking about the past.

So, let's talk about the future!

I'm not sure who is going to read these status reports, so while I'll try to be somewhat technical, I'll also do my best to translate everything to the common tongue (those will be in orange!). Please take a few seconds to provide us some feedback on how good or bad I was able to explain the situation, so we can tweak the next report accordingly. Thanks!

Things Devs did

Game Client

^{[Work in Progress] Our simplified / stylized tileset. Look, that's the western edge of the world! Oh, and a new terrain type! Oh, and...!}

1. The 7 months long hiatus has been about enough time for me to implement a new Client Framework, which I call the Kalamona Framework. It's still built on Unity, but instead of the older 5.2, it's been started in 5.3 and is currently built on 5.5, the latest stable release. The framework is by far not complete, nor perfect, and isn't overly tested, but a few things it can already do: it's past being a concept on paper - it can demo most of it's features, it already has a couple major features we missed in Phase 1, and, the features it has in common with the old engine significantly outperform the Phase 1 capabilities. The Kalamona Framework was originally built as a generic framework (in case I couldn't revive the project) so it's throughoutly documented and optimized. It already has the following features:

• Built for constant debugging & testing, with In-Editor visual feedbacks, trace logs, status indicators, etc. (since bug hunting is a lot easier, development may speed up and the game's stability and development quality increase)

^{[WIP] Every color and shape has a meaning... if you have the 200 pages long codebook for it!}

• Built on the fundaments of developing a professional, extensible business application, utilizing an MVP-ish approach and with the extensive use of design patterns, interfacing, abstracts and inheritance (it should meet certain coding quality criterias, including the topics of code documentation, code cleaniness and maintainability - generally decreasing the risk and severity of code-related issues).
• Built as a generic framework, so almost everything can be customized, extended and tweaked  (players may have richer settings - which also gives them tools to have it running on weaker devices -, and we have more tools for testing some game design options)
• Built with modding support in mind, so apart of the most necessary things, a lot of things can be tweaked without re-building the game. (development is directed towards later modding support, and it's a big thing, because modders create awesome stuffs for games and often reinvent or enhance games significantly! Also, it helps current developers to admit if a game concept just doesn't work and work out a different solution more efficiently.)
• Has a completely redesigned, fully customizable and extensible Map System. It supports layered hexagonal maps, rivers (something the old engine "forgot" after the Map Editor), traversable- and non-traversable maps, segmented updates for regions, Fog of War, Level of Details, full virtualization (with multiple strategies and fallback option on weaker devices), and something I always wanted: seamless zooming between overview and strategic camera distance with alternate stylized tiles for the big distance (I had it before Civ 6! ...though not before Endless Legend...). It can currently show thousands of tiles at once at solid framerate. While it may naturally drop with more and more visual features, compared to the old engine, it should remain significantly more performant.  (it's more advanced, easier to work with, lighter on both your GPU (video card) and CPU, full with player-tweakable settings and can support more game features.)
• A light-weight multithreading framework with Dispatchers. - while Unity isn't multi-threading, the underlying Mono is, just like most of the devices we're intended to run the game on. The Framework takes advantage of this if multiple cores are present (communication, updates - and everything bar rendering are smoother on multi-core devices).
• A generic object pooling solution with customizable pools, object types and full In-Editor support (game can run a lot better and can be finely tweaked for different device groups, offering a smoother user experience.)
• Automated workflow with In-Editor scripts and direct referencing capabilities for Sprite Atlases and optimizations for static and dynamic batching. Unity's devs are currently running a similar (albeit more complex) experiment with their Experimental 2D tools, but it doesn't have a release date, so I created my own workflow and tools.  (the project is a lot faster to work with when there are a lot of sprites and those change frequently - just like in Feudums. A lot more efficient for your GPU (video card) too!).
• The Kalamona Framework utilizes (and implemented) the Game Director concept. Game Directors are basically "AIs" (as a game term, not as in Science Fiction) with a single goal: to act like a Game Master / Storyteller, as you can see it in a tabletop game, a pen & paper RPG, or - by watching the AI Directors of games like Left 4 Dead or RimWorld. Game Directors are not to be confused with AI players, they are responsible for running (or, in case of an MMO game, supporting) a game session, they're not playing it. So they have full responsibility for querying and presenting the necessary game information for the players, and depending on the game mode, they may manipulate the game story based on the underlying game settings, configured presets, and the set of tools they have. For an MMO game, their tools are minimal to none, and are restricted to support, as the game is player-driven and is calculated on a distant server, but as we narrow the gameplay towards a single player experience, a director's importance (and list of tools) gradually increases. I intend to build Feudums' single-, multi- and MMO experience around this feature. The Framework currently has the base implementation of the Directors, and an actual single-player implementation that is used to create test situations for me. (it's a strong basement for game types beyond MMO, and also offers a standardized way to deal with I/O, communication and story-related features. It is also quite suitable for game-changer modding!)
• A lot of other small things that are probably just as important to me as much irrelevant to you.

1. I've recently started a prototype of Feudums' Coat of Arms generator, which is, though with a very limited, stone-age-ish user interface, already working. It currently supports shapes, base materials, background tint, Ordinaries, and some Charges. All parts are colorable. (well, it's self-explanatory. You'll get those CoAs at last! :))

^{[WIP] The initial look & feel of our Coat of Arms creator view. We'll only make it look ugly in the last phase. ;)}

Platform

Being actively developed by our production partner - Instait - for months, our new platform's communication framework has just exited proof-of-concept status a few weeks back. This framework already offers (and can reliably demo) the main features:

1. A scalable communication server, built on SignalR (an enterprise level live communication library) and the IoC pattern. Just like our Phase 1 platform did, it supports secure communication through HTTPS, can use the websocket protocol and json, but it is also capable of using SignalR's Full Stack, full bidirectional communication, compression, player grouping, or utilizing automated fallback protocols (ie. HTTP) based on the network and protocol capabilities of client devices.  (it's quite reliable and can manage communication more efficiently and on smaller bandwidth. Dynamic player groups allows the efficient implementation of segmented tick updates, while bi-directional communication means clients doesn't have to "query" or "ping" the server unnecessarily and we can also send admin, or world-wide messages to the players.)
2. A Unity communication client, built on a custom SignalR client, with automated serialization and optimized deserialization of objects (objects are only fully deserialized on-demand).  (it works already on a couple platforms and is optimized for the handhelds' more limited resources)

This ugly website

With Instait's help, we've managed to migrate the site to a new location, and updated and hot-fixed many of it's broken parts, the login and registration processes included. We've also updated a couple other modules and gone on a massive bug hunt. Our new blog, the minimalist polls and all the new contents are part of this work. Unless critical issues may be uncovered, we'll lower the site's priority in favour of implementing the game now (it's expected to work. We'll continue posting new content, we'll be around, appear on the forum, and so on, but we won't actively coding for the site or making it fancier).

Things Devs will do next week

^{[WIP] Well, that river seems to be a bit... digital. And the big question? Will it be fixed in a week?}

Platform

1. Instait will work on the basics of the Player Module. This module has been just recently started, so it can't do much yet. We need to create the basics, then import the old user database into the new system, then integrate our site to the User Module, so you can use both the game and the site with the same account. By this time, we'll have a proper system to authenticate you in our (new) game client too.

Game Client

1. I will continue to work on the Coat of Arms generator. I want to implement a template system for typical CoA layouts (so players can use it much easier), and also create the GUI for the feature.

These will probably take longer than a week (albeit not so much longer), but we'll keep you updated on a weekly basis.

Additional Goals in this Chapter

^{[WIP] Ta-dam! This map looks better and better. A week of hard work! (He just turned hexagonal outlines off!)}

Once both things are stable, we'll

1. also re-create the Player Module related screens and code in the client
2. integrate Coat of Arms with the Player Module, so we can offer a full CoA experience to the players and finally give our Vanguard the extra CoA options they so much and for so long deserved.
3. We might then offer a custom build in a closed alpha for players interested to check it out.

That's all for the first week. Phew, that was short. 

Please don't forget to use the feedback poll to the right and provide me some invaluable feedback, or simply use the comments behind this blog post! As you can see now, feedback tools are mostly in your defense. :)

See you next week!