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.


EPD v1.90.1 Build 2282 Experimental is out!

This is EPD 1.90.1 experimental (EPD 2 alpha). Please understand, this is a work-progress-version version with some rough edges, but I think it can’t hurt to have some feedback and bugreports to be able to react as fast as possible when some breaking changes show up that I might not have been aware of.

Please let me know what you think of the UI and the new mechanics and what needs to be added/changed. Now is the time, as I’m knee-deep in the guts of EPD and reworking everything from the ground up. πŸ˜€


  • New RandomEditor to handle both Static and Dynamic Files in one Editor
  • New Unified UI, RandomEditor & FixedEditor in same MainWindow.
  • New ScenarioSelector to handle working directories
  • Massive internal codebase change: Switched MainUI mostly to MVVM pattern and Databinding
  • UI Update: More refined UI, conssitent color scheme

Known Issues:

  • Especially in RandomEditor, but also the FixedEditor, some properties might not initialize correctly and thus might not get written to yaml at first save.
  • Status indicator in the bottom of MainUI not always updating reliably (‘Playfield saved…’ message)
  • playfield_debug.yaml or yamls with other file names cannot be opened at the moment.
  • When saving a fresh fixed playfield.yaml, you still need to create the playfield folder by hand. No automatic selection of scenario path and no creation of folder based on template name defined in ‘Create New Playfield’ block yet.
  • Preflight not yet working for random playfields.



Dev Blog: New Scenario Selector

During the revision of the Save routines I thought about which paths I should offer in the SaveAs dialog. After some time back and forth and testing around, I decided to add a scenario (or also ‘Main Game’) selector to the ‘Create New Playfield’ block. This would have been intended for a later release, but it seemed to be a good idea to integrate it right away. πŸ™‚

It’s still far away that all functions and modules in the PlayfieldEditor are taking this into account, – that is still a lot of work – but the first step is at least done. The ‘Create Playfield’ button sets the current scenario path and it also will be suggested when saving.

Also, when opening a playfield I now determine the scenario path from the file path and set the ‘Create new…’. block to this scenario, since it is very likely that if you open a playfield in a certain scenario, you also want to create a new playfield in this scenario.

The entire configuration is already exported to config.xml when closing EPD as ‘CurrentScenario’, so you can continue where you left off.

Last but not least I refined the UI a bit with new grid splitters (controls that allow you to enlarge and shrink individual areas by dragging) and a more uniform color scheme. I think this makes the whole thing look a little tidier now.


Dev Blog: New Custom RandomPlayfield SaveAsDialog & Refactoring

I’m still in the process of converting the entire framework around the editors and the main interface to MVVM. There are still some routines that need to be adapted. But altogether, I’m making good progress.

Recently I was busy adjusting the Save/SaveAs routines. This required a new SaveAs dialog for RandomPlayfields. Here you can choose which file parts you want to save, i.e. Static, Dynamic or Both (=Default). Since these are always two files, I cannot use the Windows standard dialog windows for saving. I only need a Folder Picker to select the folder where both files should be saved. I’m still thinking about adding custom inputboxes for allowing to change the default file names (playfield_dynamic, playfield_static & space_dynamic), although they would not work in the game. Not sure about that yet.

SSG RoundTrip:

For RandomPlayfields the so-called roundtrip via the SSG already works again. That means you can load or create RandomPlayfields in EPD, then edit, save, load into SSG. Then export a playfield.yaml there and import it back into EPD. This was an important step. Of course I still have to fix some bugs and test some usecases, but it does look quite good.


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

EPD v1.64.0 Build 2054 is out!

New Preflight is coming along well. I tought, I release a WIP version for you to see and give feedback. There’s some chance, that there are some regressions as Preflight is pretty much woven into Playfield mechanics.


  • New Preflight:
    • Total rework of Preflight engine to make creating new preflights more modular and easy to understand.
    • New batch of preflight checks (Dronebasesetup, PlanetVesselSetup, BiomeCluster texture setup).
    • Now also supporting status type ‘Warning’ besides ‘Error’ and ‘Success’
    • Now you can save, even if Preflight reported errors (New button in Preflight window ‘Ignore & Save’)
    • Showing of PreflightLog on saving can now be disabled if no errors were found in Preflight.
  • Playfield tree will now remember collapsed/expanded state of each tree node when cleaning up backups/bins or just when refreshing.
  • CreatureSetup: Changed description text in tooltip for ‘Delay’, as this was confusing.
  • Removed ‘IsOrbit’ property from Space playfields. Don’t think that’s needed anymore. If anyone knows for sure, that this one’s still needed, plz let me know. Then I’ll enable it again. 


  • Some Preflights were marked as Success, although they failed.
  • Options Editor ‘forgot’ current playfield name, thus ‘SaveAs’ routine was called instead of ‘Save’ after closing of OptionsEditor.
  • A bunch of little bugs.

>> Download <<