Updates in current project. Transferring to Unity3D. Framework renewal.

Well, it has been some time since the last post here (looks like it has been about a year). So maybe it’s time to make another one, huh? Especially due to some changes in current project. Especially due to amount of such changes.

First of all – the whole project has been transferred to new game engine, «Unity3D». Well, it was a tedious task, which took few months, of course not counted in 9-to-5 days, but it took some time. You may think it’s easy to transfer resources – just copy 3D models, textures, etc into a different folder. Maybe then you’ll even have to place them in some scene and somehow link them together in the editor, but it’s not that hard. Yes, sure, but my project used to have quite a huge amount of resources. However, I managed to perform this task in a couple of days. The most challenging task was to transfer the code. I mean the code. Porting the code in such cases intends a huge amount of work: from updating all calls and all usages of all internal and built-in functions and components to a complete rework of everything. Which path did I choose? I think a middle one. I had some ideas which I wanted to implement, but old version of project’s framework just wasn’t capable of carrying this changes out. Anyway, I had to transfer all the code to C#. So it was a kind of an opportunity to make a clean start, but keeping in mind some well-proven methods. The center idea was to specify the purpose of those blocks called «Mechanism». For example, I decided to make them less universal – to remove all things related to arbitrary data input-output. Also I decided to clarify their cooperation model – to make them explicitly independent or linked together. Describing all innovations here is pointless, but to mention, new project’s framework is now more narrowly-focused, making more use of state machine logic.

Next, it took some time to link it all together. I’ve just imported all the stuff into folders, made a project, a scene, then just placed some stuff in that scene. Well, it wasn’t that hard, I would say it was some kind of fun, but…


But the sad part is that Unity3D is as simple as a pie, but it still doesn’t have some essential built-in things, like material editor (I know there is one at this time, but, damn it’s a piece of crap) or in-game logic editor (like Kismet in UE3). However, there are some solutions available at it’s own store, but some of them are complicated as hell and some of them are piece of crap too. So, setting things together caused a some amount of hemorrhoids. However, making use of my old resources (hi-res meshes and textures) made the scene look quite nice. And with addition of couple of shaders from the store it turned into a somewhat nice scene (virtually as nice as it looked back in UE).

The next task was setting up all game logic. Well, there’s not much from original game logic in the project at the moment, but at least we can test the new character system from my ‘new’ framework. Setting up complex things like characters in Unity3D is somewhat an interesting task: Unity has built-in component system, which allows you to build everything from scratch just by adding right components to your blank object (as far as I know, it’s called component object model). Currently, there are dozens of them in Unity: rendering components (they make stuff appear on the screen), physics and movement components (they make stuff move all around), some utilities and, finally, custom components. So, adding mesh to your object (or character) is easy – you just have to add a MeshRenderer and MeshFilter components. But making any other stuff like movement or interaction causes some haemorrhoid: you have to write your own scripts, which are attached as components to your object. Lucky me, ’cause I know how to handle scripts and all the ‘code’ stuff, poor you if you don’t.

So, the character is processed by a custom component which holds all available actions, such as moving, jumping and all other characters’ stuff. Those actions are not components, neither they are added directly to the playable object, they are independent pre-set resources which are processed by the master component (which is added to the object).  Just for test purposes I’ve added only movement mechanics to the character (previously imported xenowalker character). Well, it worked – we can move around with our character: we can run, jump and fall with appropriate animations being played.

Oh, sure that wasn’t that simple as drag-and-drop stuff. As I said earlier, I spent several months debugging this system to make it work. Crap, crap, crap, it wasn’t easy’n’simple at all! Only then I could use this custom component. But for now I think the framework has reached some ‘point of stability’ which means I’ve done with all the basic stuff (basic action performance, transition between action, etc) and I can now focus on producing more complex real game logic.

Also, unity editor is quite permissive in things you can do in it’s edit mode or in it’s play-in-editor mode. For example, you are free to playa around with any values in your object’s components’ fields. Or, if you already have some working game logic, you can test it any way you want it. Yea, I found it quite fun to play with.

Play around with all things in real time? Easy as a pie. Literally – P-I-E (play in editor)

And, finally, a couple of word about graphics. As we can see, everything is looking not that bad – there are baked shadows, indirect lighting, reflections, even subsurface-scattered materials in the scene. However, not all of this stuff is essentially provided by Unity.

For example, I used legacy 3d models and textures (contents of the project), also I took skin shader from the store (it’s free, however), and, of course, I used my own game logics (the framework). For example, if I would start everything from scratch (with only basic knowledge in game development), it would be a total hemorrhoids: I would have to plan and build my framework in terms of component object model (it’s not very close to object-oriented model we normally use), I would have to make my own scripts for all basic stuff (movement, interaction, player controls, etc), I would even have to write my own shader programms (oh, it’s a lot of pain). It’s not that simple, I guess. Or I just could use some ready-to-go solutions (tonns of them in the store). Honestly, I tried to use some frameworks like ‘racing game kit’ or ‘3rd person basic framework’. What can I say? They’re not working! At least those so-called frameworks or kits. Okay, maybe they are not working as I want them to work: they are not flexible at all, they are not universal, they have strange structure (often illogical), they are hard to study after all (so few documentation). For example, one of those ‘fast character kits’ asks your characters to have specific bone hierarchy, and another asks your characters to have a special foot placement. What? Well, that’s ridiculous, at least, in my case. However, there are some ready-to-use 3d models, textures and animations (even complete characters)  in the store which often comply with these demands. But really, why it’s so hard to put all this things together and make them work?! Maybe just because all this things were made by different people in different time with different ideas in their heads.

So, finally, the only thing I’ve imported from the store is that cool subsurface-scattered shader – I used it on the character. I really enjoy it, just look at that shadows and that glowiness, it really looks like world-space subsurface scattering.

To conclude, here is my personal opinion about Unity3D.

Warning, butthurt alert!

Good sides are:

  • Unity itself is small and compact, runs even on a calculator;
  • It allows to make logically-structured projects, makes good use of folders;
  • It has a liberal debugging scheme: debug every aspect, debug scene, debug code, debug in real time, debug in IDE, debug in an old-school-style with all that logs;
  • It is based on .Net Framework with all its powers and dark magic;

Bad sides are:

  • No matter what you say, it’s hard as hell to start from scratch;
  • Unity is full of bicycles, literally – f-u-l-l o-f b-i-c-y-c-l-e-s;
  • There are some ready-to-use bicycles, but you can’t always use them (at least all together);
  • Good graphics level is hard to achieve, it goes too flexible here;
  • Horrible situation with some WYSIWYG-must-haves like material editor
  • Updating every damn second (some of my code parts have already outdated);
  • I’m still searching for a good code explorer (like UnCodeX), I don’t like VS’s tools.

However, transferring is now complete and there is no way back.


Recently I’ve been working on some updates for one of the new levels from the project «A Dream In The Fall». What happened? Well, I Just made basic geometry smoother and the whole level changed beyond recognition. Not much progress though — the sand still looks crappy and the lighting is out of order at all. But I’m on my way to fix it!

Actually it’s not true, because I seem to be one of that dudes, who do things and only then think (best case scenario), so everything resulted in a complete rework of everything from scratch including element locations, paths, triggers and other important stuff. And yes, I’m still not satisfied with the result! Well, I’m doing such updates with almost every asset, and this iterative refienment proceess seems to stop at never. What is the problem here? Just only total time spent? Well, while I’ve been working in this industry, I’ve seen some dudes being planning, projecting, constructing in the paper each damn level before making it in the editor. It took hours, days, months and the result was still a piece of guano (wild animals’ shit). Also there are some examples from big guys in modern industry making #blocktober flashmob, demonstraiting their pedantic approach to level design. Oh, come on, that just thier work for bread ‘n’ butter. What I do — is a total random-driven process! Once I’ve worked with random level generators, you know what — I’m one of them random generators.

Just made several assets (stone slabs or whatever), took them each in the hand and started dropping them in this hot low-polygonal sand. And, of course, the most important hemorrhoids here is collision models on these meshes. Well, I’ve managed to solve it — just puth everything in blocking volumes, lol. Well, that’s all about this short story of making shit even shittier, but removing some shit from this shit on each iteration.


The second part of the recently developed level for the project «A Dream In The Fall». This part of the level consists of platforms and tracks too, however there are not that many indoor parts. Just quite a linear path, surrounded by areas of quicksand.

This area of the level is designed as a final part — the player is able to find here another character — the head, which is stuck in the sand. Possible ways of interaction with this character depend on how many golems the player has activated.

The graphic components hasn’t been improved since the last update, however the setting and the atmosphere is quite satisfactory. There will be some improvements with new, detailed meshes and better textures (the sand really looks like plasticine), but later.

Some test run on a new level

Just made a test run on a level I’ve made recently. Playing with ground-walking bipedal character (xw_char), which is capable of walk, run and jump. Also, there’s a good, smooth camera plugged in, which can be attached to almost everything.

Yes, now we’re able to jump. I’ve decided to make ground characters able to jump. Why not, it’s qute fair in comparison with other characters, which can fly or event teleport (but can’t walk, lol). However jump system needs some fix.

There’s also another interactive actor – the way-pointer (mg_char). Most of the time the player just follows this actor. When the player is too far away it stops moving, and when the player is close – it speeds up (such a hackneyed idea).

Well, let’s look, how it all works all together. However, it turned out to be quite hard to use keyboard instead ot the joystick (okay, gamepad).

A strange construct in the desert

One of the first levels for the project «A Dream In The Fall». The idea is to find and capture all golems to be able to shove a stuck head. The level mostly consists of platforms and tracks, that connect the platforms. Any other area in the level is a quicksand, which pulls the player down.

The playable character for this level is a walking character (xw_char), which is capable of fast movement and overcoming most of the obstacles. It is also capable of interacting with some interactable objects, placed all over the level, which are used to capture golems.

All golems are initally deactivated, so any golem, except the first, is ought to be interacted in a certain way (well, I think it should be just a touch interaction) to become active.

The graphic component still needs serious improvements: the detail level of world geometry is very poor, especially – the textures, also the sand looks like an old heavily urinated carpet.