This has been a bit less busy week. I've been focusing mostly on applying static lighting to dynamic objects and effects, as well as some usual editor upgrades.

02/23 and 02/24: starting to implement static light sampling, not much luck yet...

...but in the evening I managed to get a part of it done...

...and later - the whole thing, with some improvements:

...including sample smoothing by weight normalization (removed the "dark rectangle" on the head, left side):

02/25: MSAA support was added...

...and some basic lens flares appeared as well

02/26: added adjacent surface dragging in editor, not really visible in the screenshot though...

...and later I updated the lens flares and implemented animation track blending (in the screenshot, the legs are standing but every other body part is running)...

...just to remove the flares later (for now, they really don't work so well without a strong light source) and add directional (sun/moon) light support for lightmapping

02/27: implemented level map generation and rendering

02/28: started to work on particle systems...

...and a particle editor

03/01: implemented high quality particle stretching (simulation of moving light source exposure to camera)...

...and finished the particle editor

03/02: made rendering upgrades to editor (debug drawing, entity icons):

 

So I didn't get to work as much on lighting or animations as I thought I would. I expect to do so this week but there are no promises to be made. To avoid burnout, it is important to not to force anything on myself and have a detailed step-by-step plan for implementing anything big, with options for testing between steps.

As for the static light sample point cloud, I made it as simple as I could:

• sample points are placed manually in the editor (so that they could be moved in case of math precision issues and I wouldn't have to make a generator)
• the mesh from those points is built in a very brute-force way, all added points are checked for all other points to create triangles (and if new triangles are more regular than old ones, the old ones get deleted and all their points are back in queue), then vertex adjacency (need just one common point for triangles to be adjacent) data is generated from those triangles
• interpolation is currently done in 2D only, by first looking up the closest triangle starting from the first and testing all adjacent ones if they're closer

If you think I can keep up the development, and if you're interested in what's going to be made here, please visit the Steam Greenlight page and vote for the game. It would mean a lot to me.

Add a comment

Since I've recently finished most of the editor work, I thought I could tell more about how it works as well as how it is designed. There's very few resources on this available, everyone just kind of tries to pick things up as they make it, so I thought it might be helpful to share my experience. Be aware though that some of the language used here will only be relevant to game developers that use C++, but I'll try to keep that to a minimum.

Everything begins with the most important thing - the data. The subject to edit. I knew I would like to keep it simple, but - how simple? From previous experience I thought I'd need some kind of blocks to make the basic layout and some other things (called "entities") to put everywhere. Let's start with the blocks.

Meet the block

Any block has 3 to 14 vertices and +2 surfaces (one for each edge, one for top, one for bottom). It also has top and bottom height. Even though it allows us to create walls in any direction, slopes can't be made just yet. For the slopes, each vertex has an extra Z coordinate for the top offset. It's mostly for graphics, though, since most of the physics is going to happen in 2D.

Surfaces describe how each side of the block will look (and perhaps feel as well) in the game. Each surface of the block has a texture and some parameters (offset, scale, angle) to specify how to map the texture to the surface.

The other things

As mentioned before, entities represent all non-block things in the game. Entities come in various shapes and sizes. A mesh entity would represent a pre-made 3D model, placed in the level in some specific way. A light entity would specify a light that illuminates surroundings at the specified position and color (and some other parameters). The data is different for each entity, the only uniting parameters are type and position - we do have to know where and what the entity is, after all.

To provide sufficient editing capabilities for entities, there are various user interface elements that can be added to the property list. On/off switches, numbers, vectors of two and three numbers, and even mesh/texture picking screens. To make all that work, we need a graphical user interface system that supports all required features.

User interface

The two main "schools" of user interface tell you: it's either immediate mode GUI (rendered and processed as you call a function) or regular GUI control (or window, or maybe DOM element, depending on who you listen to) tree with objects allocated and added to other objects. There is actually a way to squeeze through with the third way - one that combines a regular GUI structure with allocation-less (generally referred to as "allocated in-place") systems (UI controls can be inherited, added on the stack or included as class members) and some immediate mode trickery inside events to handle button clicks without having as many actual buttons.

However, that is not the only addition I could think of. To avoid the difficulties of working with a textbox or slider for numbers, I designed the number wheel - a control to increment/decrement the number as cursor is turned around the center of the wheel, at the speed specified by clicking on the right track.

Getting back to GUI control inheritance, just wanted to add that there are a few restrictions on the usage of such controls, biggest one being - copy construction / assignment does not work as expected, those features must by overridden properly (by manually copying property values and nothing else) or disabled.

To give some idea of the scale of the currently implemented GUI code, I can tell you it takes about 2000 lines of code and show this picture:

Given the size of the code as well as the number of defined classes, I can say that the user interface is sufficiently simple. Same thing could be said about the data. I have described it here in such detail that it could be implemented by many other developers easily. But the editor is not just data and user interface, surely it's not all we care about?

Simple... or is it?

There are many places for improvements in a typical game level editor. You have all the possible improvements of a modelling tool, a sculpting tool, image editing and so on. So it's important to know where to stop.

Actually, there's a lot more to cut without major losses way before that. Selection of multiple items, for example. Sure, it's somewhat convenient when you have to move many things at once, however the problems it creates usually does not outweigh the benefits. When I will encounter problems with my approach, I intend to create groups - objects that contain handles to other objects. These items could then be moved together, as well as targeted by many other features of the editor.

3D modelling is another such thing. As necessary as it might be to make the core layout more detailed, modelling cannot be used as it creates many issues. First of all, the walls have no volume that way. It might be useful for calculating if a bullet could penetrate some wall, for example. Second, you now have polygon triangulation issues, because polygons are easier to deal with in editing. For simplified volumes, it's the opposite - they can assume some things to avoid overcomplication of further calculations.

On the topic of blocks and further calculations, plane-based geometry description (a convex plane-based hull, or "plane-hull" as I'll call it here) is something I've opted to avoid as well. It would mean that every surface is a mathematical plane (vector+distance), not a polygonal face, based on vertices. Even though it aligns well with the needs of a CSG (constructive solid geometry) processing tool, it seems to be much easier to generate planes from a polygon mesh than it is to generate a mesh from planes. Here's why:

The short version of the "plane-hull -> mesh" algorithm is - create vertices at three-plane-intersection points (so essentially three nested loops with two kinds of intersection tests - plane/plane and plane/segment), for each plane - collect such vertices, sort them by angle, add this new polygon to the mesh. In practice, floating point math adds some issues to this approach as well. For "mesh -> plane-hull": for each polygon, calculate plane (cross product for normal, dot product for distance) and apply surface data from polygon. Less math, less loops, one tiny assumption (that all polygonal faces make perfect planes).

As for the entities... it's... interesting. Each entity type class is also the instance class and the user interface structure. That part's quite amazing. I can just insert either an instance or a type into another control and it's ready for editing. Cloning from either prototype or instance works exactly the same. There's also a system where it's necessary to register each entity only once and it takes care of creating UI buttons and provides an array where it's possible to find any entity prototype by name. The not-so-amazing bit is the scattered entity code (declaring a UI control at one spot, setting default value at another, serialization in two different places etc.), but that's something I'm willing to put up with, given that everything else that normally creates huge headaches is just extremely simple this time around.

War stories

This adventure of writing an editor has brought quite a few experiences of bug fixing to me. Forgetting to remove a deleted mesh pointer from cache, wild memory overwrites from double ownerships, created via copying. The last two are actually unique in that they show the same issues that forgetting the "rule of three" (C++ users should understand what I mean here) would show (double ownership), except that the rule was not in effect!

Not only bug fixing has taken some time. I estimate approximately 5 hours of walking around the room in an attempt to understand both my long-term and short-term goals, as well as how to design certain elements in the editor or its GUI. Planning is crucial to keeping momentum. Always Be Planning. This might sound extremely counter-intuitive to some, given that for planning, you have to step away from the code, stop writing it. But it pays off quite soon.

In ending...

I'd just like to say that the previous week has been extremely interesting, however this is just the beginning. It would help if you could vote for the game in Greenlight. As for me, I'm still working on the editor, but that's soon to be concluded, letting me get back to the game itself, as well as level design planning and putting it all together. I hope you're as excited as I am to see how it'll all look and play in the end.

Add a comment

This has been a busy week. I've been focusing mostly on character animations and editor upgrades. The editor, in its present state, is very usable, though I still see room for improvements. There are no plans yet to implement them, which basically means that I'll fix it when something gets in the way too often.

What there are plans for, though, is finishing animation work and adding some lighting effects. Those include light sample cloud for static objects, lens flares/light source sprites (they'll be soft, consistent and fairly predictable/static, so it should look very nice) and possibly some dynamic lighting as well.

Here's some pictures from the development that I made on the way:

02/16: Z offsets for vertices (for making sloped surfaces)

02/17: some editor design testing

02/18: implemented level saving, this is my first saved level

02/19: finished level compilation with lightmaps

02/20: linked editor lights to lightmap compilation

02/21: first imported animation

02/22: did more level design testing while working on animations...

...and it turned out that my mesh/animation export/import was broken...

...so I fixed it...

...and spent the rest of the day trying to put some lighting on the character.

02/23: finished the week by implementing animation player and doing some camera view testing

 

So only the animation mixer and ragdolls are left to implement for animations. Expected to be done this week.

Work not listed around the screenshots:

• Editor marker now adjusts to the height of the currently edited object.
• Implemented light sample entities in the editor.
• Added convenience shortcuts for block drawing (can set z0/z1 in drawing properties)
• Implemented null/black surfaces (null are removed, black don't use any space on the lightmaps).
• Implemented lightmap sample correction (moving them out of obstructions to avoid black spots).
• Implemented off-mesh lightmap sampling (for light sample entities).

Work listed but still important enough to mention until the end of time (well, maybe not that much):

• Character animation pipeline! It is a real pain to get it to work, so respect is well deserved for all those programmers who manage to do so, especially if it's done more than once and within all sorts of deadlines.

If you think I can keep up the development, and if you're interested in what's going to be made here, please visit the Steam Greenlight page and vote for the game. It would mean a lot to me.

Add a comment

This has been a busy week. I've been focusing mostly on the editor. I've implemented most editor features, only a handful of them was left for the next week.

Here's some pictures from the development that I made on the way:

02/11: basic UI controls

02/12 - 3D view, basic data

...and UI improvements

02/13 - vertex editing in UI

02/14 - block drawing...

...and block editing...

...and mesh drawing/editing...

...and item duplication/grabbing

02/15 - texture picking...

...and testing current state of level design abilities...

...and added vertex/surface editing...

...then tested level design some more...

...and finally added mesh picking

02/16 (just before I was writing this blog post) - finished generalizing mesh editing into entity editing, added one more entity type

 

So, like I said, not much work left for the editor. Serialization and lightmapping, both of which have the hard parts already done.

 

If you think I can keep up the development, and if you're interested in what's going to be made here, please visit the Steam Greenlight page and vote for the game. It would mean a lot to me.

Add a comment