Epsylon - The Guardians of Xendron takes the player on a journey to a futuristic world investigating a very special Science-Fiction setup. With a team of rather different characters the player investigates, and if required fights, his way through a large case. How you solve the case is though up to you. Combine the strength of your team members is important as no team member alone can crack the case alone.

Report RSS Tutorial Map and other Goodies

This had been planed earlier but a lot of work came in between about the conversation system, tutorials, soundscape and what not else to name a few.

Posted by on

Conversation System Overhaul

The main work went into reworking the conversation system from being game specific into a generic system provided by the game engine itself. This allows now anybody to use this sophisticated system. New conversation actions and conversation conditions have been added. loading classes are now ready-made to use for your projects. Some basic playback classes are present now in the game engine to build upon. Furthermore the conversation editor received tons of improvements and additions I might show in an extra technical video later on. The system is flexible so you can do anything from highly complex to simple and basic conversation, cutscenes and game mechanics. This had been quite an important rework since I'm using the conversation system in my game project not only for conversations but also cutscenes and entire game mechanics. This extra development time has thus been well spent in this system. See the video below for in-game use of the system or the ZPOC video here as an example for using the system in an entire different project.

Tutorial Map

The rest of the time went into assembling the different pieces together into a first tutorial map. This one combines now new stuff like:

  • improved soundscape based on OpenAL
  • dynamic footsteps adjusted to speed, actor type and floor material
  • tutorial system with dynamic content
  • various cutscenes realized with the conversation system
  • All the latest graphic changes enabled and included like the environment rooms
  • Modeling new flashlight which fits better than the old large brick
  • Remodeling the thunderpad into a smartphone type device including full real-time finger control input as well as adding some applications to it (upgraded from the old thunderpad).
  • Improving dual-use of flashlight and smartphone in your secondary hand.
  • Conversation over phone call support.
  • Lots of ideas, game sequences and story bits added to the design document
  • and a bunch of other changes that I forgot to mention since they are so many
  • little warm-up puzzle of the easy kind to get the player used to the game mechanics

So all in all a lot of new things and everything plugged together in a playable tutorial map. Nevertheless it is work in progress and contains placeholder stuff like the voice acting (i suck at voice-acting... and more so on female kid voices like Sean's voice :P ) and stuff I experiment with (like Sean's mental voice experiment)

So instead of text better moving pictures. Most probably I'll not make many more of those since the audio-desync on capturing is so costly to fix it's getting too problematic to work with. Before I get engine level video capturing working I'll keep videos to a minimum.

So here it goes, the tutorial map from entering up to a stopping point.


And here some minor videos tapped in between like level changing by boarding the train or sean skulking around the city (including missing animations :P ).

All videos are also on YouTube so if you can't see/read something due to quality issues you can try there. Links are with the individual videos.

Feedback is always welcome and I'll see what I can include.

Outlook

Next up tackling more engine tickets to work off and finishing up the first investigation sequence unrolling inside the building. The conversation system also needs some bug-fixes and stripping deprecated features so you get only what really counts. Until next time.

Comments
SinKing
SinKing

I like the conversation system though I'd look up some conventional framing methods (like full shot and close-up). It seems like you could get better angles on those characters for presentation.

I'd prefer a more visual explanation, because reading in games is always tedious, even if it just involves learning the control scheme. Just an image of the item and explanation of which functions are key mapped would suffice; more importantly those functions have to be available through either the main menu or a command key, so you can toggle them through or look them up again easily.

There is also some information that could be abbreviated. Unless there is reason to state that something isn't going to happen, e.g. the player will naturally assume that he gets off ladders automatically. In other words: if he had to press a key in order to that I'd state it, if not he'll figure out. Generally, give your players enough freedom and not too much dialog or your game character will come across as some kind of a crazy who talks to himself on every occasion. I know that is a kind of classic adventure mechanic, but it only works with certain kinds of characters and settings. Sometimes a little less talk means more atmosphere and more visual storytelling.

Reply Good karma Bad karma+3 votes
Dragonlord Author
Dragonlord

Actually I've done research about camera shooting techniques beforehand and implemented the system as well *** as the used shots according to the information located therein. Used here is framing placement according to typical rules, establishing shots, close-up shots (front, 1/3, side), medium shots, long shots, dolly zooms and stuff like that. Due to this I don't think I'm "totally off". But maybe a video about the conversation editor and how it's made to support typical camera shooting techniques might help to clarify this. Unless I got something totally wrong in which case you are welcome to point out in detail to me where I messed up.

I personally don't like visual explanation because you can't skip them properly. Here you simply get the screen. You can read it and get the information you need or just click it away. In my opinion better than trying to get rid of visual tutorials which make it difficult to get rid of them. But I can take a look at it if enough people think visual tutorials is better. I'll certainly keep note of including tutorial text in a game menu sub menu.

Other than that the text is condensed here since it's the tutorial map meant to take the player by the hand. After that you are on your own. The self-talking is also player triggered (examine key). So if you are not much into examining objects for clues you won't hear them while those prefer examining anything in their reach hear more of them. This is though still design in progress how much you can examine and how much commenting is hidden there. In the end though conversation is one possible way to approach investigations. You can also totally reduce it to a minimum and play more "doing" oriented. It's up to the player to choose this.

Reply Good karma+1 vote
SinKing
SinKing

It just seems to me with all the subsequent text explanation, simple tasks such as opening a door are delayed a lot. I realize this is not gonna happen later, once you performed the actions in the tutorial, but some people might have already given up by then. Especially in a tutorial it is beneficial to keep explanations to a minimum and stretch them over some period of time.

About the shots. You actually use the "right" shots, but sometimes the cameras are at odd angles, other times the shots are a mixture of two shots or rarely used shots (like the Dutch Tilt). I suggest checking out the difference between Zoom and Dolly and when it is preferable to use either of the two.

I made a description of how I experienced the different shots.

Shots:

1.1 Overhead: fine
1.2 Close Up - character cut out of the picture, top of the head cut off. Confusion, because this could almost be the Dragon's POV. Why the overhead shot?
1.3 POV - usually a good way to see what a character sees - but it's long and zoomed (one thing eyes don't do is zoom)
1.4 Close Up (same as 1.2)
1.5 Medium Shot/ Dutch Tilt - unusual, because the Tilt usually indicated tension and eerieness; also we come to this shot after a POV of the same ~ confusing
1.6 Close Up (same as 1.2)
1.7 Medium Shot, Dutch Tilt
1.8 Close Up (...)

1.9 Medium Shot, Dutch Tilt
2.0 Close Up (...)
2.1 Close Up (on the Dragon) fine
2.2 Full Shot of the Dragon (usually you go the other way: full shot then medium shot/close up) -> this camera is too static for the action; should be a sequence of shots, instead.
2.3 Close Up - first time this is a "real" close up without cutaways; fine
2.4 POV; fine
2.5 Close Up; fine
2.6 Full Shot - too static for the action/remote
2.7 Close up; fine

If you cut off characters in a Close-Up, it becomes an Extreme Close Up - used to emphasize on the emotion of a character, especially on the eyes. It's a rare shot (e.g. used in Westerns/duels).

Reply Good karma Bad karma+1 vote
Dragonlord Author
Dragonlord

I didn't mention something about how the camera shots work.

All except the ladder scene use static camera shots. Static in this context means the camera shot is precisely framed for the actor. This means the targets are on the actor thus full control.

The other camera shots though are dynamic. Dynamic in this context means the camera is aligned dynamically between two anchor points, in this case the two actors involved. The dynamic shots are tricky since while the look-at axis is defined (from one actor to the other) the up-axis is not.

I used as a first version to align the up axis with the world up axis. The current problem with that approach is that for actors at an offset the camera tends to go a bit dutch. This is not intended but comes due to the dynamic nature of the shots. This has been done so actors can be standing at non-defined locations while still allowing the camera shots to work. For actors on the same level this works well but for extreme angles like in this one it's not optimal yet. The biggest question is "what is the right up-axis?". I have not yet found a good mathematical definition for what is good up. So I'm still working on getting a hand on the unwanted dutch angles in these cases.

I guess for the time being I can change the dynamic shots from close to medium. This should give more room for errors so the head is not cut.

Concerning the tutorials I can cut them down. What I'm not certain about is what amount is required. I general I hear people say games have too little or none so I gave a bit more in the tutorial section there. What amount you had in mind?

Reply Good karma+1 vote
CMDKeen
CMDKeen

That actually isn't that bad! Especially Sean's voice, considering you had to voice a young female dragon yourself. It's not release worthy, of course, but it's far better placeholder material than you could find elsewhere.

SinKing has a good point that big blocks of text in the tutorial are pretty boring. They are fine in the rest of the game where you can find interesting information on the game world and the plot, but in the tutorial, players want to start playing already instead of having to read several paragraphs. If you can, show and don't tell. If you can't, make the text short. Very short. A couple sentences at most. Also, several short hints are better than one larger block of text.

The new phone is a really interesting addition, but I could see it become annoying after having to deal with it for some time. Including some key shortcuts may be a good idea here.

Reply Good karma Bad karma+1 vote
Post a comment
Sign in or join with:

Only registered members can share their thoughts. So come on! Join the community today (totally free - or sign in with your social account on the right) and join in the conversation.

Follow Report Profile
Icon
Epsylon
Platforms
Windows, Linux
Developer
Team Epsylon
Engine
Drag[en]gine
Contact
Send Message
Homepage
Epsylon.rptd.ch
Release date
Game watch
Follow
News
Browse
News
Report
Report
Share
Related Games
Epsylon
Epsylon Adventure
Related Engines
Drag[en]gine
Drag[en]gine L-GPL
Related Groups
Indie Devs
Indie Devs Hobbies & Interests
Linux Gamers
Linux Gamers Fans & Clans
Team Epsylon
Team Epsylon Developer & Publisher