Q: How would I start to implement Duality extensions and plugins for others to use?

My suggestion would be to implement each major new system (ParticleFx, Animation, etc.) in its own plugin project, as seen in my old DynamicLighting experiment: A Core Plugin extending engine functionality and an Editor plugin providing more suitable and comfortable editing capabilities.

Approaching new feature sets like this keeps Duality modular and makes it a lot easier to keep track of class interconnection and dependencies. It also keeps down the overhead for users who do not need all of the features: A game without dynamic lighting doesn’t need to boot up the lighting subsystem or clutter the codebase with lighting-specialized classes.

However, implementing a whole new engine feature in your games local plugin first for prototyping isn’t such a bad idea, since it takes away a lot of the “quality code design” pressure. Extracting a finished product later will leave a designated time window for API cleanup and small polishing tasks that doesn’t interfere with the development of your game.

Q: Can I use external libraries in my Duality plugins?

Yes. Simply reference them in your project and place their .dll files in the Plugins directory as well. When you need to set up and shut down external resources globally, override CorePlugin.InitPlugin and CorePlugin.OnDisposePlugin methods.

Q: How would you implement communication between Components? What about a messaging system?

The first approach that likely comes into your mind when thinking about communication between Components is manually retrieving them, store their reference and directly invoking methods on them. That’s pretty strong coupling between the involved classes. Isn’t that bad?

Direct coupling between specific Components looks like an ugly thing from a code design point of view, but is the easiest solution and even fully sufficient in a lot of cases. However, there should be a clear line: Use direct coupling when both objects are, by logic, directly coupled – like a Car and its Wheels. Don’t use direct coupling when you have some generalized behavior in mind – like messages that anyone could listen for.

The second case is where all those ICmp interfaces emerge. Their purpose is to generalize certain kinds of Components by their behavior and / or communication traits. ICmpUpdatable models updating behavior, while on the other hand, ICmpCollisionListener is a mere communication device.

Getting to a generalized messaging system, I’ll just skip ahead and show some code:

Here’s the same thing from a Components point of view:

I’m sure there are other ways, but that’s probably how I would’ve approached it. You should also keep in mind that any kind of messaging implemented like this will walk the entire scene graph to retrieve its listeners each time you send a message. Though, it should be fine as long as you don’t send a huge amount of messages each frame.

Q: How would you use the Component-based GameObject design when approaching a game like Civilization, taking into account landscape, units, cities, etc.?

The solution to your problem might not be obvious, but it really isn’t as complicated as you might think. Not everything in a component-based approach has to be done utilizing a lot of objects. Sometimes it can be more suitable to focus on fewer, more complex objects. How would you implement such system *without* a component-based game object system? Since the actual implementation of a “Component” is completely free, it is entirely possible to apply most other code designs to component-based systems as well, although not being equally useful for all of them.

The landscape is a typical case for a single, specialized object. You can implement it as a Component or set of Components which you add to a single “Landscape” GameObject consisting of your Tilemap data, a specialized Renderer for visual display and probably some game logic bound to it. I’m picturing something like this:

Landscape GameObject
+-- Transform
+-- Tilemap (Generic implementation of a tilemap, data only)
+-- TilemapRenderer (Accesses Tilemaps and renders them using a Tileset)
+-- Landscape (Rules, Game-related logic)

Units could be implemented as individual objects that are bound to your global landscape object by their Unit logic.

Unit GameObject
+-- Transform
+-- SpriteRenderer (Or similar)
+-- Unit (Keeping it bound to the Landscape, Rules, Game-related logic)

You could also split up the “Unit” Component into its own micro-hierarchy to serve different kinds of map objects:

Component
+-- MapObject (Anchoring something to a tile position, general logic)
    +-- Unit (Controlled, can walk, fight, etc.)
    +-- City (Builds stuff)
    +-- Collectible (When walked over, provides a bonus)

This should cover some basic setup. Of course, there has to be some kind of global database to store the Tileset used by the Tilemaps, Unit Types, etc. This is what Resources are for. In Duality, you can not only derive from the basic “Component” class, but also from the “Resource” class to store that kind of information globally available.

Q: But what’s the big advantage of Components for that kind of game?

There is no need for Components in this case! But they’re not standing in your way either.

Component-based approaches are specialized in modeling the interaction of objects which are not necessarily known when laying out the object management system or engine structures. Their greatest strengths are extensibility and modularity. Unlike in classic inheritance hierarchies they allow you to dynamically combine different pieces of functionality for each object individually. They obviously reach their full potential in games with a more versatile environment or game world and allow non-programmers to creatively combine existing functionality in whatever way they need.

A “boardgame” like civilization behaves in many ways perpendicular to that concept. In most cases, all Units, Cities, Tiles and other game elements are similar in their ruleset and logic. They don’t need Components and you, as a developer, don’t usually need the ability to dynamically construct new kinds of objects or introduce new kinds of behavior later.

Q: The ContentRef<T> struct is used wherever referencing Resources. What is that good for?

I use this construct and a centralized ContentProvider in Duality because of several reasons:

1. Due to the editors design concept, it should be possible to dynamically reload any Resource whenever necessary, even while the game is running. That means, there needs to be a central register of currently loaded Resources to keep track of what to update when a reload occurs: The ContentProvider. It also assures nothing is loaded twice, just because it is requested twice.
2. Why doesn’t it return Texture, but ContentRef<Texture>? Well, imagine the user deletes a Resource in the editor. Updating existing instances won’t suffice anymore – we need some kind of hook to actually set all references to that Texture to null, and the ContentRef indirection layer is exactly that. When accessing a ContentRef that refers to a deleted Resource, it will let go of old data and immediately show that something is missing.
3. ContentRef also enables us to talk about Resources that aren’t even there, which isn’t uncommon during development time. Without ContentRef, requesting non-existent Textures would result in a couple of null references. We can’t compare them, tell what they where trying to retrieve or even if they are intentional or not. ContentRef always holds both path an reference, solving all of these problems. That also allows deleted-and-then-restored Textures to magically re-appear throughout the level. As a bonus, it will be the ideal location to implement streaming behavior in the future, because it allows referencing “not-yet-fully-loaded” Resources and using them as soon as they’re available.
4. It is possible to pass around ContentRefs without loading the references Resource. If not done explicitly, they will be loaded on their first access. Referencing them doesn’t mean implicitly loading them, although you can always request doing so explicitly.
5. Duality uses semi-automated Serialization based on Reflection mechanisms. When serializing a ContentRef, only the path is serialized, preventing Resources to be dragged into the serialization hierarchy without the need for manually handling such cases. It also takes care of retrieving the actual Resources after deserialization – as soon as they are needed.

Q: Will there be more Mailbag posts?

Probably.

1. A game that decides by itself whether and when it wants to be played. It’s not in the mood? Well, too bad. Can’t play it now.
2. This could be expanded to have a game with an actual character. Randomized using a hardware-specific seed.
3. Make game descisions have an effect in other games as well. Let’s say you decide to threaten and rob a trader you meet on the street in an Rpg game. This descision is stored somewhere persistently and available to other games to use. Imagine playing a different game, months later, when you suddendly find yourself in the exact same scene – but this time you happen to be the trader. You’ll be your own victim.
4. Speaking in general terms, building a game on the concept of descisions could be interesting. Confront the player with his own descisions, with indifference and pointlessness (can’t alter a predefined fate), with circular storylines (the same stuff happens over and over again, regardless of player action), with self-fulfilling prophecy and descisions that are essentially directed by others.
5. A game that can only be played once, even after re-installing it. You’ll only have one chance and everything will be irreversible. If you quit, the main character will commit suicide and that’s it. It’ll be final. Your choice.
6. React dynamically to outgame events. Start subtlety with the system date or time and proceed to use stuff that’s currently in the news. Is it possible to do that using automated data mining? Maybe when abstracting certain events to a metaphoric or diffuse level.
7. “Use XY with game”: DragDrop files, images or texts from the windows explorer into the game to do ingame-stuff. Imagine a 2d adventure game where your inventory isn’t in the game but on your desktop. Whatever you have on your desktop will be your tool in the game environment.
8. Kind of a different concept, but related to “integration into your OS”: A game that gives you quests to solve outside the game itself.
9. Trust. “Do you trust me?”, asks the game. “Er.. why.. yes”, answers the player. “Then”, responds the game, “show me the folder in which you store your personal data”. Doesn’t really matter if you actually do something harmful with that data or not. Trust is more about the potential what one could do anyway.
10. That one’s actually from a colleague: A game that actively tries to bore the player out of his mind. The player gets points for playing it anyway. It’s like a staring contest. Who will give up first?
11. Search the users computer for data that can be used to dynamically generate parts of the game world. Documents that have been opened recently might affect what books a charakcter has in his bookshelf. Songs that have been played often could play randomly in the ingame radio. Use the spectrum of installed programs to determine character traits of the user and incorporate these somehow into certain game characters.
12. Run a backround process that posts cryptic messages in documents and folders the user visits. It will become active as soon as the game hasn’t been played for a while (weeks?) and hint at events from the ingame story or world. Shouldn’t do anything harmful and deactivate itself after a while of course. Game viruses are still viruses after all.
13. Inception-like multilevel story that is actually a loop: The layer following after the last one is the first one again. You’ll never know, which one was “real” – but if everything exists in a logical loop, does it make a difference anyway?
14. Faith. Not religion. Not society believing something, but an individuals belief. Not necessarily faith in god or higher power. Has any game really brought up the aspect of faith in general? Here’s a straightforward example: Most players of a certain genre believe their character will respawn if they die, that there will be a checkpoint or savegame that rescues them. Shatter that belief, prove them wrong, multiple times. Leave only scorched earth in their silly respawn-faith. Then, plant the seeds of it again, subtlety, and later trigger a situation in which it matters whether there are respawns or not. Some kind of test. A leap of faith, in metaphorical sense. The player can take it – or not. It all comes down to whether he believes despite being proven wrong in the past. Here’s the twist: The actual outcome whether there are or aren’t respawns in this final test is actually random.

You know, I’m certainly not a game designer. But there must be some use to those random brainwaves.

If this is the case, you might have noticed the complete lack of updates since August. There are several reasons for it and I plan to revive this blog as soon as they’re gone. I’m in the last semester of my studies now an they required me to do an internship spanning 360 hours. So I asked Deck13 about whether they’d like me to hang around five days a week instead of one, and they accepted, so I began in the end of August. My job was to create an all-new Asset Management system, because the old one was a little buggy, hard to use and already grinding on the nerves of a lot of people. (Asset Management means making the import and processing of game content into the engine manageable, reproducable and configurable.) It was an exciting task, involving large portions of software design and GUI design – needless to say, it completely absorbed me for the time being. After nine to ten hours at work plus two hours getting there and back home, there simply wasn’t anything left for Duality. At least not beyond bugfixes and small tweaks.

But that’s over now. What currently keeps me away from active development is my bachelor thesis that’ll be due in the end of January. I’m approximately 70% done by now, and since I’m writing about the Duality project, it’ll most likely find its way into this blog when the time comes. Only in german, though.

There is a new CamViewLayer called the Grid. It has less to do with Tron than it has with geometry and its goal is to ease Camera navigation and give you a visual scale context. It automatically adjusts to the current zoom factor and displays the cursor positions world coordinates.

Also, texts displayed in a CamView now have those neat, black background boxes.

The new design-time data feature allows the editor to tag GameObjects with any kind of data. This data has nothing to do with the Core library and only exists in the editor. It is even stored in a separate, project-global file.

As for a first use, it is now possible to lock or hide objects. Locking prevents the object from being selected / picked in the CamView, which had been really annoying for full-scale static backgrounds.

Showing Components in the Scene View is now optional. If you don’t like it, just disable it. There shouldn’t be any global disadvantages and everything else still works the same.

When entering the Sandbox and no CamView is currently available, one is automatically created and set to Game Mode. If there is one available, it is focused to user input can be delivered without delay.

The PropertyGrid now has a Debug Mode that also shows non-public class members for custom Components.

You can download the Platformer Example here. It contains a project template that will set up the example project from the video. Just use it to create a new project.

Today I’m going to show you some new or improved features and how to develop a simple platformer.
One of the things I’ve recently improved is the smooth animation system. Instead of regular frame-by-frame sprite animation Duality is also able to blend smoothly between animated frames by using a special shader. This will make your animations look more fluent, especially when few frames are available. In that case, the difference becomes obvious, while on high frame rates it might just make it look a little nicer.
In my first approach, I was simply using a linear blend between the current and the next animation frame. However, this would introduce visible artifacts in all pixels that are fully transparent in one frame and fully opaque in the other. In a simple linear blend, the transparent pixels color would bleed into visibility because they’re mixed with visible pixels.
This unwanted behavior was fixed by introducing some more lines to the shader code that will weight each pixel colors total involvement by their transparency values relative to each other. If there is a pixel visible in one frame and invisible in the second, it will simply fade in or out without changing its color at all.

So let’s begin with our example platformer. Click on File / New Project to bring up the new project dialog. By default, Duality can create and empty project or one based on the currently opened one. It is also possible to use a custom configuration by clicking the “Browse” button next to “Project Template”. The download package comes with an example template in case you want to try it out. However, we’ll go with “Empty Project”. Duality now creates a new project folder, applies the selected template and updates the required binaries.

First we’ll need a player character. I’m going to import a simple sprite sheet by dragging its file into the Project View. A new Pixmap Resource will appear. Right-click on it and select “Create Texture”, then select the new Texture Resource and adjust its number of animation columns and rows to fit the image. You can check the per-frame preview to if the values you entered made any sense.

To see it in action, just grab Pixmap or Texture and drag it into the Cam View. Duality will create a new GameObject for you. Now enter the sandbox mode by clicking the “Play” button above. You will see animation playing in its default configuration. If you want to take a closer look, use the mouse wheel to move the camera closer. Press it and move the cursor for regular 2D camera navigation. Because we’re now viewing an upscaled version of our character, it looks a little blurry. To achieve a pixelated look, selected the Texture Resource and set its interpolation mode to “Nearest” instead of “Linear”.

The player animation is currently running through all available frames. Let’s change that to use a walk cycle in one direction. Select the player GameObject and open the sprite Components tab. Set the AnimFrameCount property to three, which is the length of a single walk cycle in our sprite sheet. You may also set the first frames index to change directions or adjust the animation speed.
However, something doesn’t look right yet. Our character walks a little.. strange. A quick look at the sprite sheet reveals that we’re using the wrong animation type for it. To fix that, select the GameObject again and change the animation mode to “PingPong”. It should look much better now.
To improve it a little further, you can activate the smooth animation feature. To do that, select the characters Material Resource and change its rendering technique to one from the SmoothAnim folder. As always, just use dragdrop.

The following step is entirely optional, but illustrates a concept that will prove to be useful in the future. First, stop the sandbox mode. Then, click the player character GameObject and drag it into the Project View. This will create a new Prefab Resource of our player object. You can think of a Prefab as a global template for objects that will exist multiple times throughout the level or game – like enemy characters, powerups, etc. An immediate advantage is that it’s very easy to create new instances of a prefab object programmatically. The next big advantage is that prefab instances maintain a link to their Prefab and will be updated when you modify it globally. That way, you can change an enemies hit points globally instead of individually for each enemy.

I’m now fast forwarding a little because what you can see here is nothing new: Just importing sprites for back- and foreground and creating some GameObjects out of them via dragdrop. After finishing a first level setup, click the “Save” button in the Scene View to save it. A new Scene Resource will appear in the Project View, which I’ll rename to FirstLevel.

Of course we’ll also need some kind of collision detection. To allow physical interaction between our objects, they will need a RigidBody Component. Right-click on the world object and select New / Physics / RigidBody. Then open the RigidBody tab and set the BodyType property to “Static”. This will assure our level affects other physical objects without being affected itself. Next, open the RigidBody editor and define the objects shape. After doing the same for the player character, you can hit the “Play” button and see how they interact. If you want to drag the object around, don’t forget to switch back to the Scene Editor.

I don’t want this video to get too long and I’m really running out of time, so I’ll just fast-forward the following while talking a little about the theory: There is more than one way to create a platformer and Duality doesn’t really favour any specific way. In this example, which will be included in the download as a project template, I’m taking the 100% physics-driven approach. A character is constructed out of two objects like you can see in this scheme. The upper part is a fixed-angle RigidBody which is joined to its lower part using a RevoluteJoint. This kind of joint allows the lower part to rotate freely while maintaining a constant relative position, like a wheel. A RevoluteJoint also allows us to apply a rotational motor force to that wheel – and that’s basically how our character will move. It’s one of the more physically correct approaches, so it will be more suitable for a Limbo type of game than a Super Mario clone.

In matters of programming, there isn’t really much work. All the character controller needs to is check the keyboard input and adjust some Component properties according to it and that’s basically all it takes to walk around. Jumping isn’t more complex either. Although it’s not a big deal of setting up the basics for a physical platformer, I found out one disadvantage of it to be very hard to maintain. It takes a lot of balancing, property adjustments and little hacks to make the platformer controls actually “feel” good. But still – although not quite easy to handle, physical simulation also remains the main advantage of this approach, because it allows you to incorporate physical puzzles, enemies or other gameplay elements seamlessly.
But I guess the best advice is to acquire your own experience.

You can get it here.

So what is it exactly that you can see here? A Skybox, some fog and a very early version of chunked heightmap terrain. It’s a study-related project I’m currently developing together with nine others and our goal is to create a simple flight simulator –  from scratch. This includes both hard- and software, the latter one of which is my main responsibility.

Although being 3D and having different requirements, the engine running behind all this is basically a modified version of Duality. We’re working under tight schedule and I think we wouldn’t have been able to pull it off that fast without the accumulated source code and know-how of those two years Duality development. I guess that was really lucky. Also, this is an opportunity for me to learn a lot and spot design weaknesses I have overlooked so far. Which is a good thing since I’m probably writing my bachelor thesis about Duality.

Well, I guess I’ll have to get back to work. Wish me luck.