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.
To this one
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.
Earlier I’ve managed to make a fair action system and an inventory-based interaction mechanics, so currently developed interaction is a physical proximity-based interaction, as postulated earlier: a touch or a hit between objects (characters<->objects). So, basically, the player can touch anything in the level, but not everything in the level is able to react — the interaction is only performed in a mutual manner. At least, I’ve made such a conclusion. The concept is the following: there are some interactions, which are performed by the player’s character, the character can perform an interaction on an arbitrary object, influencing its state. The idea is quite simple: an actor makes the other actor’s mechanism to perform handling of a certain event, each event is described and handled in the event handling mechanism. The active counterpart of the interaction couple is LBSimpleInteractionMechanism (LBBasicInteractionMechanism), whilethe passive counterpart is LBEventHandleMechanism, however I’ve made some loopholes for the interaction mechanism to be able to handle events by the React() function. The following four procedures do form the interaction mechanism’s core, so when an additional functionality is needed, they are modified or overridden.
function bool CanInteract()
function bool CanReact()
But typically there’s no need to modify any code at all, so all needed data is set in the editor. To describe a new interaction, the designer should set its name and some values, which are used by this interaction.
Thus, the passive counterpart-actor’s mechanism, the LBEventHandleMechanism, performs the real event handling (what a surprise!). It is interacted by sending this mechanism SetParamInt() with param name ‘RaiseEvent‘ and a param value, containing this event’s id. After activation of a certain event, its params are set. For example, we can enable or disable movement, set movement speed of the current actor or do many other interesting things by this params.
For more convenience, interaction mechanism in a player’s character is wrapped in a character controller mechanism, which also wraps the inventory mechanism and many others. So, the player first activates a certain action, for example, a touch action of the player’s character. Also it’s quite a convenient way to perform some checks, but in the code, of course.
Now, all together. I’ve made a draft touch animation and a corresponding touch action, which is performed by our character. Well, the character doesn’t seem to have any hands, so it has to touch everything with its face, lol, so the current animation looks quite strange. Finally, we’re able to perform the touch action by pressing a key on a keyboard, as described earlier, so the pipeline can proceed. Next, this action plays a touch animation, which triggers the anim notify, which send the interaction mechanism a message via Interact(), and then, the interaction mechanism perform a coresponding interaction. It should be noted, that the action cannot be pefrormed (the animation won’t play), if we receive a negative answer from an interaction mechanism via CanInteract(). This is the fair way, I suppose, when you don’t touch things, that are not ment to be touched.
So, in this example, when animation time reaches a certain position in the touch animation, the animation notify is sent to the character’s interaction mechanism, which handles all the stuff by the HandleAnimNotify(). In this example, the actioncode is set to 401 and notifytype is set to ActionNotifyTypes_ActionPerform. Next, the check is performed, and, if this check is passed, the interaction is performed — the PerformInteraction() is called, which also says the interaction mechanism to perform a certain interaction immediately.
function HandleAnimNotify(int actioncode, int actiondata,
if (actioncode == 401)
When the cube (okay, the golem) is touched and all above stuff is performed, the event handling mechanism sets several values, which turn on movement, rotation and other logics. Also, I’ve made a camera effect, so when the golem is touched, the view toggles to a cinematic camera via the following kismet sequence.
Well, that’s the core of the interaction system, the concept looks quite acceptable, however it may contain some hidden problems, like simultaneous interaction with multiple objects. But for now, that’s how the interaction system is organized. Now we can see the in-game interaction example, where the object is being activated by character’s touch.
It seems to be one of the most complex parts of the game logic, but very perspective at the same time. Also I’m looking forward to making use of it in some even more complex cases. But for now, just a simple case: the player’s character activates some cubes. The video below shows, how it looks all together.
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.
So, I’ve made some improvements in the action-interaction system. It has been a long-needed update. In different games player is able to perform different actions, not only just run, jump and shoot. Well, honestly, a major part the gameplay nowadays is built around actions and interactions, so inadequate and ineffective solutions are unacceptable. This leads us to a completely new domain of problems: we need a separate mechanism for performing character’s actions. The concept is simple: there are some actions, each can be performed by the character. An action has certain properties, like it’s relationship with animation — an action may or may not have an animation, and it’s relationship with character state and other actions — an action may or may not have effects on the game pawn (except the animations effect). Thus, we come to a fairly easy solution — the LBBasicCharacaterController, which is capable of performing actions, which means the ability to play animations and change pawn’s states (virtually, of course). Basically, we’ll be working only with current character’s logic, leaving all underlying activity to the basic character controller. So, we’re interested in only in these methods:
function HandleActionStart(int startedaction)
function HandleActionStop(int stoppedaction)
function HandleAnimNotify(int actioncode, int actiondata,
Which do handle action start, action end and animation notifies, which may or may not trigger during the action animation. If we don’t need any character-specific logic or we just want a Garry’s Mod-styled animation player, we can just use the editor. For the designer it’s really simple — all what’s required is to fill out the Character Action List in the editor, which contains all the necessary data.
For example, here I’ve made four basic actions: touch, pick up, put down, carry, three last interactions I’ve been describing earlier, the touch action and the appropriate interaction I’ll describe later. Also I’ve made some auxiliary actions, which really don’t have any effect in the game, except they do play animation. All options of this actions are shown below, for example, them options of the touch action mean that this action is controlled by the certain animation: the action starts with the animation and ends with this animation, also it may have activation restrictions and switch links. What is activation restriction? It’s simple — the action cannot be performed from any actions (state-actions), except these. And the switch link is a type of a bridge between the actions — upon its finish, the action can be automatically switched to another one. Well, I’ve made some comments (been trying my best) in sources on GitHub.
Next thing, what is required — the proper animation, set up and linked to the LBBlendByAction animnode, which blends all animations. There’s also a default node, which is used to blend out, when the default action is active.
Thus, all, what’s required now is to call a needed action by the SetParamInt() function with param name ‘BeginAction‘ and param value containing the action code. Also, this can be performed from any sub-system, but I’ve chosen Kismet and its keyboard events.
Well, let’s test this functionality. I’ve made some random (though interdependent) animation sequences (though craggy) for the character, then plugged them into the new action system. There’s a state-action, which defines character’s state — the ‘Sit_Tie_Idle‘ action. There are also two gateway-actions — the ‘Sit_Tie_In‘ as an entrance into this state and the ‘Sit_Tie_Out‘ as an exit. And there are two actions, performed exclusively from the ‘Sit_Tie_Idle‘ state — the ‘Sit_Tie_Gym_1‘ and the ‘Sit_Tie_Gym_2‘.
Now we can make our character do different things. For example, we can watch our strange character doing its strange exercises (some kind of gym, maybe?). However, everything happens in the right order, for example, it can’t just start walking or jumping from a stretched pose, it has to stand up first.
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).
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.