Hey there. You know what? We want to make content for Drag. Yes, we are really, really hyped for the new update!

But see, after some time, it gets quite tedious with creating level packages by hand.

Until now

So far we have used three tools:

1. DragEdit, a level editor for drag
2. Notepad (yes, the windows one)
3. Packagebuilder, a compiler that uses the textfiles created by DragEdit and notepad to build packagefiles

DragEdit – The leveleditor for Drag

A wind of change

When we started our work on the update, I realized that in order to manage the different levelpackages we have to do more than just create textfiles and link other textfiles to them just by hand.

The old flow we had. Three tools before unity and one included handwriting!

So I thought about writing a tool, which integrates the packagebuilder into its workflow seemlessly. It should create the textfiles with the same content as always and compile them just with the click of a button.

One thing to note is: The packagebuilder is a pure CLI tool. It works great for dragging (no pun intended) files onto it and compiling, but there isn’t much more to it.

The design

So I started designing the tool.

I set some goals I wanted to achieve, so I always had something to guide myself through the code writing process:

1. The tool had to be written in WPF and C# (take that UWP!)
2. It had to make use of MVVM
3. It had to include a loader for both compiled and uncompiled packages
4. It had to include shortcuts for levelediting

So, yeah, I basically reached every aspect in this list.

It was my first 100% MVVM driven tool I wrote and I am very proud of it. But besides that I had a big problem:

The PackageBuilder only compiled levels, not decompiled them.

So I had to write a decompiler first, which didn’t work correctly until the very last day of development, because I was to stupid to read my own code.

The Interface

The Package Manager for Drag

This is the Package Manager in its final form. It also has all of the pre-update packages loaded.

Everything in the level pack can be edited directly except for the orderID, which is set by reordering the packages in the list on the left.

Upon selecting a package, the data is displayed on the right side of the interface. One of the best features (which required a minor rewrite of the level editor) was the Edit Level button, which allows the user to open the given package in the level editor and make changes. This integrates the editor into the workflow.

The editor also spits out a 100×100 pixel image that represents the pattern of the level, when the level is saved. In a new iteration of the PackageManager, the editor application may be triggered to generate these for a whole package (this functionality already existed!) and load them as a preview below the reorder buttons. But currently its not needed so it has to wait until the next update.

Conclusion

Things we need to keep in mind when we write the next tool:

1. A level-compiler always needs a decompiler. Of course, there is a decompiler built into the game, otherwise the file couldn’t be loaded, but the compiler itself should be able to decompile those levels aswell.
2. A level editor should always accept drag and drop of levelfiles as a launchoption!
3. Tools that make the workflow faster, more streamlined, and easy to access for new teammembers (or other teammembers in general), should be thought of when developing a game. In most of the games I was part of, the tools had a critical role and could easily speed up production!
4. MVVM is great, I should do this more often.

We optimized our workflow to this:

Our new development flow. We practically do not need to change the tool after we start the package manager.

That’s it. The update is currently incoming and will be released next week.

I hope you all have fun dragging! If you don’t have the game, get it here.