Dev Blog: New BiomeClustersBrowser

The last few days I’ve been thinking about how to improve the BiomeClustersBrowser into something a little more helpful in regards to all the data one biomecluster can hold. So I decided to collect the most important information of the cluster and present it right away in the browser, so you can see at once, which biomecluster you want to be editing further.

I also integrated a search command to search and filter the BiomeClusterList by:

  • Names
  • Selection Criterias
  • Stamps
  • Grass
  • Decorations

So now you could search for ‘RealRock’ or ‘Gold’ and find all the clusters conating that certain rock or deco type.


Dev Blog: New Cleaner & Bugfixes

For the last few days I have been working on completely rewriting the ‘Cleaner’. This piece of code deletes all the empty properties before writing a yaml file. It already existed in EPD before, but it wasn’t very reliable and did not clean every single property. Now it should work very reliably and really remove all empty properties from the Yaml. Before I also had to ‘restore’ (reinitialize) the playfield object again in order to beeing able to enter values again after saving a file. With the new cleaner this isn’t necessary anymore, because the object you are actually editing does not get changed anymore, just the data that gets written to YAML.

Additionally, I added a filter to the POI Browser to be able to search for POIs via GroupName, Scenario, etc. I also wanted to add a special scenario mode, but it doesn’t work as it should yet. For that I guess, I have to rewrite a lot more on the PropertyParser.


Dev Blog: Under the Hood

At the moment I am working on the substructure of EPD. Nothing to show off in a big way. When I started to code EPD, I was just beginning to learn WPF (Windows Presentation Foundation). Over the years I’ve gotten to know new development patterns and have partly implemented them already.

The major part of EPD, however, still doesn’t use modern design patterns yet. If you have something to do with C# (or .NET in general), you will surely have heard about MVVM. EPD already uses this pattern in its core – The PropertyParser – already. Although not in a puristic implementation, as I use a lot of reflection that saves me 1000s of lines of code because of all the properties a yaml file has.

This part is staying the way it is, with some changes I already implemented due to the new combined editors. I always was afraid that these changes might break EPD in a way that I could not fix anymore. So I always was very hesitant to try it. But as it turned out, it wasn’t as complicated as I thought it was. Fortunately it worked out, otherwise the combination of Editors would not have been possible at all.

MVVM stands for Model-View-Viewmodel and is a design pattern, where the underlying code (mechanics, data and functionality) gets completey decoupled from the UI. That makes changing and Unit Testing a lot easier and efficient.

So at the moment I’m transferring all the code, that currently is part of the UI class into its separate ViewModel and then link all the data and commands back to the UI via MVVM. That’s an ongoing process, as EPD already grew into a really big project, but I have to start somewhere, and the main UI and its Editors are a good starting point.

This will take a few days, I guess and then I’m back into the more interesting feature development business. 🙂

Here’s some info about MVVM, for those who care. I’m guessing not too many. 😀

MVVM (Wikipedia)
MVVM (Microsoft Blog)


Dev Blog: Added ‘Create New Playfield…’ Mechanics & Closing of Editors

Today I added the mechanics for creating fresh playfields. Therefore I needed a new ComboBox in order to beeing able to select fixed respectively random playfield types.

It seems that the new ‘Create Playfield’ mechanics work fine so far.
I also added a (mock) title bar to the editors with a closing button. Now you can create, open & close the two new editors as you want.

Next up: A total rework of the saving & exporting code.
I’m not sure yet, if exporting of dynamic parts separately of static parts should be possible. But would be addable at any time, I guess.


Dev Blog: RandomEditor and new Unified UI

Development is progressing rapidly. It looks more and more like this is going to be a major rework.

I have now integrated both the Random Editor and the old Fixed Editor interfaces into the main window. They are all separate modules now, that can be loaded and unloaded from the UI. When you now open a fixed playfield yaml, the FixedPlayfieldEditor module is loaded into the user interface. And also the RandomEditor doesn’t open a separate window anymore, but is also loaded into the same mask.

This means that all functions will be optimized and unified to work (almost) equally on random and fixed playfields.

There’s still a lot of work now, as all EPD functions that work with playfields need to be reworked and/or fixed to work with this new modular approach. That means all buttons, all menus and so on need to be reworked to handle the new UI properly.

But on the long run this will also open up the possibility to add other modules at a later time.

Let’s see where this goes. 😉


Dev Blog: New Random Playfield Editor coming up

I finally decided to overhaul the current Dynamic Editor and go for a new Random Playfield Editor. After the first ~100 builds the result looks quite ok. Of course, I still have to test all internal Playfield connections and then adjust the read/write code, then sooner or later the preflight, and so on. But I’m cautiously confident that everything will work as I imagine it will.

This new editor will allow you to edit the _dynamic and _static yaml file in one single editor and it will feel like editing only one file. Just like the Fixed Playfield Editor. It will also be possible to mix dynamic and static properties on one tab, as you can see in the screenshot.

Here’s a first screenshot of the new Random Playfield Editor