Author: Oneiric Worlds

Hello everybody,

Today, I’ll speak about… saves! So this post won’t have a lot of screenshots, mainly boring text 😉

As I want to be able to build up a complete version of my game as early as possible (even if it’s only on 1 level), I have to implement eveything the final game will need. And recently, I thought about the “game over”. What happens when the player fails?

I – Problems

Well… This question is a lot trickier than it seems. Because when the player fails, the game must bring him/her back at some point where (s)he is OK.Thus… we must save this “some point where he is OK”. Hence a few questions come up:

• Does the player choose when to save? If so, he can ideally save whenever he wants, and there is absolutely no difficulty to the game. Moreover, technically, this means being able to dump everything that is in the RAM, resulting in hundreds of Mo of data (maybe many Go). This makes the save and load process rather slow. And by the way, who cares about the exact position of a bird in the sky that you may not even have seen?
• What happens if the player saves during a battle? How to manage all the timers, the physics engine running in background and all the objects in an unstable state? What happens if the player saves when (s)he’s dead? (Yes, there are some games where it’s possible…)
• If the player doesn’t choose when to save, does he still control the saving process? That is to say, are there some visible “checkpoints” at which the player can save its game?
• The other way around is that the computer manages everything and performs automatic saves completely hidden from the player. But in this case, it means that if a crash occurs, the player may totally lose his game. Moreover, if many players try the game during the same period, the game should be able to manage different “profiles” in order to accept different players.
• If the computer manages the saves, I don’t want them to happen everywhere. I have to chose some “safe places” (ie without too much interaction around) and at strategic points (beginning/end of a quest, before difficult parts…)
• There are some games where, when you die, you don’t go back to your latest save, but to some automatic checkpoint that you didn’t even notice. This avoids a lot of frustration to the player if it’s been a loooong time that he couldn’t save. But of course, if you quit the game and you come back later, this automatic checkpoint does not work anymore. You start from your last save. Is it an interesting mechanics for my game?

Hence, those questions sum up in “when, what and how do I save?”

• when: everywhen vs checkpoints
• what: everything vs only a few states (player position, inventory…)
• how: player vs automatic

And there are some more-or-less inevitable links, for example: everywhen => everything, automatic => checkpoints, everything => slower and space eater, automatic => difficult crash recovery, …

II – My chosen solution

So I considered using some kind of “old-school” save system: There will be checkpoints, and the player will manage saves him/herself. At the moment, I allow 5 save slots for testing purposes but this number will likely raise. Here are the main advantages:

• This enables many players on the same computer, and/or many different saves (I usually liked old games when you could keep a save just before a cool boss).
• The saves will be dumped on the hard drive in different files (slot1, slot2, slot3… etc). Hence, one can copy-paste saves to keep them after removing the game,
• It’s also possible to share saves with friends!
• It enables to have various saves in case one crashes
• Furthermore, this system may be compatible with some “automatic checkpoints” too. Maybe I’ll add some at any point where I don’t want a “game over” to be too harsh.

III – Implementation

While implemeting this system, I had lots of problems, especially with regard to the software design (I’m not that good in software design). I won’t detail everything here, but amongst other (this is a bit technical):

• The “save” data is implemented with static attributes (some kind of “singleton class”), which enables me to easily reach/modify it from every object in Unity. As soon as the character makes actions/complete a quest, everything is registered in the save object.
• At save points, I dump the save object on the hard drive using XML serialization, but, static attributes are not serialized, I had to code this myself.
• Hence, that means there is only one “save” object in memory everytime, which is problematic when you want to list all the saves that are accessible from the hard drive… Because when you want to load a save, you want to know what’s inside. This means the game has to read them all, and display a few relevant information (place, time played, inventory stuff…).
• The dumped files may be edited with an hexadecimal editor… I tested it, and it seemed I corrupted the file, so I had to add some kind of validity check before effectively loading a save.
• And of course, I also had all the classical problems of GUI: menu navigation, font and button resizing, toggle character control when you’re in the menu, differentiating main menu and in game menu…

Well , that’s all for today! See you next time guys!

Peace!

Hello,

This week, I worked on putting together the first level of the game. Beware, spoilers below 🙂
As usual, I’ll try to explain what my goal and constraints are… So I hope you don’t mind if I get chatty 🙂

OK! First, I must think about a simple goal for this first level that may fit within the universe/world, the global story (because yes, there is a global story), and my guidelines (humour, freedom, oneiric).

I – Technical constraints

This is the very beginning of the game, and the player doesn’t have a lot of skills at the moment. This level will more or less be a tutorial, but without instructions, just to see if he got all the basic moves, and if he’s able to combine them in new ways. At this point, the moves are mainly platformer-like (no fight yet, but this will come 😉 ).

II – The world

I want the game to take place in a world where there are many different islands (in the sea… or floating in the air). Why different islands? Because…

• This is fun to have many islands to explore, there is a feeling of freedom while moving from one to the other, and islands often sound like “paradise” (even if that’s not always the case).
• Technically, this is much easier to manage: while navigating through the islands, the levels can be dynamically loaded and unloaded without the player noticing it too much (well, theorically… We’ll see if I achieve this in practice).
• In terms of design, this is a natural partition of levels: adding a new level/environment can be done by adding a new island without having to think about all the connections to the other environments.

III – The story

The goal in this first level will be to use the thief skills of our hero to get an egg on the Eagle Islands. The Zoological Institute has watched this place over the past weeks and has noticed that one egg is not brooded anymore, maybe the mother eagle disappeared. The goal is to get this abandonned egg  and bring it back so that the Institute can take care of it. However the place is not easy to approach because of all the brooding eagles.

So in this setup, we’ve got platformer components with floating islands, stone walls, jumps to make, rocks to climb and the first lively ennemy: eagles. Eagles can add a good value to the oneiric feel :). They are just peaceful beasts, but don’t get too close to their eggs!

IV – Prototyping the platforms

This is actually not that complicated. A few cubes here and there, and let’s see if it forces the player to practice all the basic moves he’s been taught, and a few more that he will have to imagine. The most important thing to test is that there is no hack to avoid those particular move combinations.

V – Steven the Eagle (yes, this pun seems to work with all bird names)

Creating the first lively enemy has been a great challenge… I started with the model of the seagull that I corrected to make it look like an eagle. Of course, I kept the few flying animations to add flying eagles around the level. But the BIG difference with the seagull is that I want it to be on the ground too. And I was a bit unaware of the difficulty to make an animation of a bird folding/unfolding its wings. It’s such a mess! See for yourself:

And then I had to add some “logic” to its behaviour. I want it to be an obstacle to the player, but the player has to be able to find a way around it without using any fight skills (he doesn’t have any at the moment). I won’t detail here the tricks I used to design this eagle enemy (how to make the player understand there is a danger? How to make him understand how to counter it? Do I help him a lot? Not at all? What is the sanction?), but you’ll see the final result in the next demo (surely at the end of the month).

Wow! I’ve written a lot, and I didn’t speak of everything yet (adding some pickable items,  tracking bugs, adding a few sounds, adding variety to the look of the eagles, including an albinos one… for a secondary quest). Well I guess that will be for another post 🙂

Peace 🙂

Hi everybody,

Today, here is a little post about the Graphical User Interface (GUI) of the game. More specifically about what is called the HUD (Head Up Display), which is the interface displayed WHILE PLAYING (this is NOT the menu). You will see I ask myself looooots of questions even for a “simple task” like this one. But… I have to, because this HUD will always be visible on screen during the whole game. It has to be the best possible (help the player without disturbing him/her from the actual game).

Of course, when I try to create a video game, my first reflex is usually to look at how other people do it and try to understand/analyze it. So I checked out the HUD of a few of my reference games: Beyond Good and Evil, Zelda (2 different episodes), Assassin’s Creed, Okami, Torchlight and Darksiders.

I – Problems

First of all, while designing an interface, the first thing to think about is “What do I show to the player”? This is highly dependant on many things:

– Game “rules”: does the hero have a life/energy information? Does he have other equipment that may need this kind of representation (shield energy)? Can he use many different equipments (bow, knifes, gravity gun, love gun, whatever…)? If so, can he use many at the same time and how can I show efficiently which ones are selected?

– Design choice: Do I want a very simple representation (but easily readable) or do I want something more elaborated (hence less readable), but that may fit better with ingame graphics and improve immersion? How can I represent this information (Numbers? Letters? Colored bars/drawings? Icons?)

– Help level: Do I want a very complete HUD that explains everything to anybody who plays for the first time, or something aimed at people who are already familiar with gaming? The first one is more complete but eats more space on the screen… This may highly impact the difficulty level of understanding the game, but also the difficulty of the game itself (imagine I don’t show the hero energy bar… This may be very stressful for the player).

– The control choice: Do I want my game to be playable with only one action button? or two? or three…? More action buttons = more complex actions (jumping while aiming at some guy with a bow for example, which is cool 🙂 ) = more complex HUD to explain it (show the target cursor + explain how to shoot an arrow + how many arrows are left?).

II – (A) Solution

Of course there is no “perfect answer” to this problem (as it is usually the case for a lot of problems). Only compromises… depending on the kind of audience, the kind of game… and above all my time and abilities/skills.

Thus, I chose something simple and quite “modern-looking”:
– On the upper-left corner, I show characteristics related to the hero him/herself: life and force. The player may understand which one is which by playing and seeing them evolve. It enables less cluttering information. It’s not very difficult to understand, and once you get it, the representation is minimal and doesn’t bother you during the 99% rest of the game. And why the upper-left corner? Because this is most important information and it the first thing you see when you try to “read” the HUD… in the normal reading way (left to right, top to bottom).
– On the upper-right corner, I show equipment information (one for each mouse button). Why right-side? Because usually mouse is on the right-side of the keyboard, hence it is easier to identify that this info is linked to the mouse (sorry for all left-handed people… 🙁 ). Maybe I’ll use a third one with the middle mouse button… I’ll see if this is necessary later. You may notice that the “main” equipment (left button) is bigger, because used more often.
– On the lower-left corner, I display… money.
– I chose to lower the dialog box size, because it took too much space on the previous version (you can check the tutorial demo to see it). Moreover, it is easier to read lines when there are not too many words on the same line (check your favourite book, you’ll see ;), and that’s why newspapers present texts in many columns.

You may see I used some 50% transparent black rectangle backgrounds with white text/icons. This ensures at least a 50% contrast readability whatever is displayed behind, because HUD must be readable in every virtual place of the game. At the same time, it enables you to see through it which improves immersion.
I also use some simple orange “circles” to add some kind of “techy-modern” look to the interface. Orange is a color I may have chosen because I like the interface of Blender (a 3D software I use), and it has some kind of visual uniqueness (not very used, except in the very stylish Remember Me). Maybe I’ll change the theme in the future… For representation of information, I chose to use a lot icons because it is very easy to understand, and it doesn’t need any translation. For example, I used a credit card icon to represent the money information… which (to my surprise) may be seen as the € symbol with the orange circle around it. Fun 🙂

That’s all for this… huge post. Thanks for reading until here and I hope it was intructive for some of you 🙂

See you!

Hello,

Today, I’m going to talk about… dialogs (haha). Yes! There will be some dialogs in my game because I want to propose some kind of story (surely a simple one). So, I want the characters to talk, explain, … live. In addition, dialogs/explanations are useful for the tutorial phase.

I – Localization

First problem: I want to release my game to the whole world (I shall reign over it 😀 Mouahaha)! And, even if I speak English, I can make some mistakes. I can’t sell a game where there are mistakes. Hence, at some point, I’ll need the help of some translators (by the way, if you’re interested, you can contact me). But translators are not really into programming ;). I can’t ask them to modify source code. The easiest way I found to handle this is to create a simple google spreadsheet/excel document with French sentences and their English (or Spanish, or Italian, or …) translations. Something like this:

This translation management is called “Localization”. Here, I use one sheet for each game level. When everything is OK, I save each sheet in a simple TXT file that my game is able to load. According to the global language setting, it will show the good translation for each sentence.

In another localization file, I keep all the “global” names/information that I want to be able to access in all levels of the game: the character/place names, the menu labels, the help hints…

II – Dialogs

You can notice that in the localization file, there is no logical information about which sentence is the first, and what answer a character should give if the player asks him such or such thing. This “logical part” is stored in another spreadsheet file. It looks like this:

 

This file stores the information of the sentence sequencing. For each sentence (line in the file), we can find the corresponding ID in the localization file, the character who is speaking, the next dialog ID (NOT the localization one), a flag to know if the dialog should end after this sentence, and some action to execute (that the game can understand and perform). For example: when you speak with a character, you may earn an item, or money, unlock a quest, or go to the next level… You can see that there are a lot of other field/information that I do not use at the moment, but that I may use one day: camera position, animation to play for a character, music, audio…

This “mini-program” can’t run alone. It needs to be called by the game with a given start line. At the moment, the tutorials start these dialog programs according to some actions of the player. Actually, we usually speak about a “dialog tree” because the user choices may influence the behaviour of the other characters, leading to different possibilities. For example, you may see lines with “WellDone” and “Failed” IDs, which, as you may expect, are run when the player succeeds,… or fails. However, those very specific and sometimes complex tests must be coded. So, I can’t do everything with those simple text files, but it still offers a nice freedom, and it’s not that complicated.

And…

Soooo that’s it for the dialog system. You may wonder why I didn’t put the sentence translations directly in the dialog file. There are two reasons for that: first, not every single line of text is included in a dialog (menus, hints, descriptions of objects…). Second, I don’t want translators to accidentally destroy the behaviour of non player characters by modifying logic fields. I will only share the localization file. This will avoid mistakes.

I hope this little post :p was interesting to some of you! Take care, and see you next time.

Hello everyone,

This is the first post about my actual work on the game. Recently, I worked on a few graphical/art style tests as you can see below:

The idea was to test different ways of mixing textures (tiling and blending). Unity can only handle 2 different sets of UV textures which might be annoying for environment design… 🙁

I also worked on GPU shaders to create post-processing effects (cartoon-like edge rendering, underwater effect, colorize and oil-paint effects…), but I still don’t know which one(s) to choose for the final look of the game.

I also (and mainly) totally re-implemented the controls, because there are a lot of bugs on the demo for the moment. The moves are basically quite the same (run, climb, jump and slide down slopes), but I hope they are a little bit more reliable. Debugging is not over however, I guess I’ll have to fix a lot of things “on the fly” when adding new levels. Initially, I planned to code basic moves in 2/3 days. I spent more than 2 weeks on it. I created a test level to track bugs on the climbing and sliding moves:

I created a lot of “mountains” with various forms and slopes to assess my algorithms. It’s a very long process to test every situation… Those are simple forms, and yet there are a lot of issues especially on edges. Of course this is not very pretty, and it won’t be in the final game. It’s only for tests!

That’s all for the moment!

See you next time 🙂