LIAV Enhancements

From EQUIS Lab Wiki

Contents 1 Purpose 2 Motivation 3 Improvements 3.1 Edge of the World 3.1.1 Objectives 3.1.2 Optional/Additional Objectives 3.2 Day and Night 3.2.1 Objectives 3.2.2 Optional/Additional Objectives 3.3 Climate 3.3.1 Objectives 3.3.2 Optional/Additional Objectives 3.4 Villager motion 3.4.1 Objectives 3.4.2 Optional/Additional Objectives 3.5 Tree Growing 3.5.1 Objectives 3.5.2 Optional/Additional Objectives 4 Progress 4.1 Edge of the world 4.1.1 Technical 4.2 Day and Night 4.2.1 Structural Technical 4.2.2 Technical 4.2.3 Visual technical 4.3 Climate 4.3.1 Technical 4.4 Detail Diagram 5 Milestones 6 Interaction with other groups

Purpose

The purpose of this project is to enhance the existing game of Life is a Village to add different elements and fix existing problems that will at the end increase the realism of the game.

Motivation

Through the years of this game getting enhanced, each enhancement project specifically focused in one area or feature of the game to add in. Depending on the outcome of that project, the enhancements are either accepted or rejected to carry through to the next year. From this, a problem can be observed. That many of the past project’s goals have been too uniquely focused in one area of the game, giving the game’s new feature a personal taste to that of the developer. Because giving a game that’s too unique to personal taste to new developers to work on restricts their choices in what enhancements they can add to the game, that the enhancements were never added to the game. This leads to the problem that the game as a whole doesn’t improve as the years pass by. I want to make changes that are lasting to the game, therefore I want to make changes that focuses mainly on problems that exists currently in the game, and other changes that will not give the game too much purpose which will restrict future developer that will work on the game. Another reason why I choose this project is because this will allow me to look at all the different aspects of the game, allowing me to learn more about how the game functions.

Improvements

There are many aspects of the game that can be improved to add more realism to the game, each of which could possibly not be something big enough as a project itself. Therefore instead of trying to find one enhancement that’s suitable as a project, I will list different elements that I will work on. I will work from the list and continue to add to the list until the end of the term. Should I find one enhancement too simple, I will simply complete that one and move on to the next task. Because of this reason, this proposal will possibly not contain all the different enhancements that I will end up adding to the game. The list of enhancements will be posted on the wiki, and updated as the project proceeds. This will allow others (art students) to pitch in when they see an opportunity.

Edge of the World

There exists a problem where if the player continues to walk in one direction, eventually the edge of the world is reached, and continual walking across the edge will bring the player outside the landscape of the game’s world. To fix this problem, a fog could be added around the edges of the world. This fog should be thick enough such that the edge of the world will not be noticeable. The game should also prompt the player when the edge of the world is reached, and prevent the player from walking across the edge. The message could be for example “The mist is too thick for you to walk forward” or “A mysterious mist prevents you from moving forward”.

Objectives

-Stop Player from walking off the world
-Add Fog to prevent seeing the edge of the world

Optional/Additional Objectives

-Loop player around the world
-Darken as well as fog
-Random teleport player after walking off the world
-Some sort of notice as to what has happened to user when reaching the edge of the world

Day and Night

Currently, the game’s setting is only day time, there is no concept of a day and night in the game. Since there is the concept of time in the game (as I saw the timer on the game), that time should be used to divide up time for day and night. The light sources should be adjusted, so that it would seem that there is a sun moving across the day during the day. During dawn and sun down, a reddish color should be added to add realism. At night time, minimal light should be used to resemble the world lighted by the moon, perhaps with a tint of light blueish color. The moon will have to be modeled by something, perhaps a 2d billboard that always faces the player. For simplicity, the moon will move across the sky the same way the sun does (even though it’s not how it really moves, it’ll be enough for the game world). Since at night, everything is lighted minimally, the player should have the option to turn on a light source for operation during nighttimes. There are several choices of light source that could be implemented. A flashlight or a lamp would be the best choice, but this would require some modeling of the light source and a way for the player model to carry this model. To avoid the carrying of model problem, the second and third choice will take a more magical root. Either activating a magical globe that floats around the player, or perhaps activating a magical light-up jacket, which would in turn make the player the light source.

Objectives

-Create a system to handle the concept of time
-That system will keep track of game time
-That system will adjust environment due to change in time
-Sun/moon going across the sky
-Color of sky changes during dawn and sun down

Optional/Additional Objectives

-Shadow
-Night will add option of a light source
-Villagers go to sleep

Climate

A random climate engine could be added, where it determines when a different climate will occur in the world. Adding a rainy or cloudy climate would be an interesting addition to the game, making the world feels more real. Cloudy day could simply be added by changing the lighting and changing the sky texture. Rainy day would need further research, as I do not have an approach how to achieve this effect.

Objectives

-Create a mechanism that will randomly determine a weather status
-that mechanism will have to manage that weather (see through the weather status will last to the end)
-For each weather type, create the appropriate environment

Optional/Additional Objectives

-create rain effect

Villager motion

An obvious problem is the orientation of the villagers when they walk and when they chop down the trees. It would make the game look better if they walk and chop better.

Objectives

-Have the villagers face what the thing they chop down

Optional/Additional Objectives

-Have the villagers walk in a more realistic matter

Tree Growing

Give each and every tree life by letting them grow during the game. A system could be setup to have the tree model scale from a small to big as time passes by. Upon reaching a certain size, a different model could be used, and continue to scale bigger. For example a tree could have three models used for different stages of its life (where a grown up tree doesn’t age afterwards), first a small tree that grows, when it grows big enough it swaps model and reaching second stage of its life, then it continues to grow big, then lastly with the last model to represent a “grown” tree. This may prove to be difficult to find an efficient way to implement this feature, because this could load down the system if not implemented efficiently.

Objectives

-Build a mechanism that allows growing of any objects

Optional/Additional Objectives

-Add in option to have the object either grow (size change) or just a simple model swap

Progress

In the most brief summary, parts of "edge of the world", "Day and Night", and "Climate" are being worked on, and each of the parts have their own results to show. The reason why these three enhancements are all simultaneously being worked on is because of the way I have approached these problems. To explain the reason behind the approach I took, I will report my progress starting with the "edge of the world" problem.

Edge of the world

Edge of the world is defined as the borderline in which beyond that line the player will no longer be in the playable area of the game. In this game, that is the edge of the given terrain on which the player traverses in. There are several ways to prevent the player from moving beyond the edge of the terrain, one is to simply stop the player. I felt that this will give the player a feeling of trapped, like a fish in an aquarium. A solution suggested by fellow students is to teleport the player to a random location if the player walks out the edge of the world. This approach I feel will make the player feel lost, not knowing where they have been teleported to. The approach chosen to solve this problem is to make the world seamless by connecting the edges of the world with the opposite edges. When the player walks outside of an edge, he will walk out of the opposite side of the world. In order to add to the seamlessness of this effect, fog is used to blend in the edges of the world, where fog is increased near the edge of the world so that the physical edge is hidden from the player.

The end result of this is as one could imagine, the edge of the world does not exist in the game anymore. But this approach has an unpleasant effect, where if the player starts walking along the edge of the world, since the fog is used the blend the edges, the player will continue to walk in the fog, never finding the way out. To remedy this problem, instead of having the rectangular edge of the terrain define the edge of the world, the biggest possible circle is drawn in the given terrain, and has that be the new edge of the world. Also with this edge, when the player crosses it, not only the player appears on the opposite side of the circle, but also will be facing the center of the circle. This allows the player, who is walking in a straight line, to always end up back in the center of the terrain.

Technical

The way the player is stopped from moving into objects is by steering. This is accomplished in the "updateAvatar" method in the "CAXGameState" class to stop the player from walking into a building. The new/next position of the player is fed into this method, and it will update that new/next position of the player depending if the player is walking into a building or not. Using the same approach, I've created a method so that if the player walks off the edge of the world, the player will be given a new position at the opposite side of the world. This method requires knowing where the edge of the world is. Inside the "CAXGame" class there are methods for finding out the X/Y/Z extent of the terrain, seeing that this method performs operations in the same area of the game, I've created the new method "moveToNotOutOfWorld" in the "CAXGame" class. This method's operation is to find where the edge of the world is (the best fit circle given the terrain), find out what is the radius of the circle, find out how far the player is from the edge of the world, and move the player to the opposite side of the circle if the player is outside of the circle.

To add the effect of seamlessness, the distance from the edge of the world is sent to another method which will add in the appropriate effects. When this method was first built, it was another method inside the "CAXGame" class. Later on, in the "Day and Night" section, this method is moved to another class, which will be explained in the next section. This method takes the "fog far" value, and sees if the player will be able to see the edge of the world. If the player's "fog far" has reached the edge of the world, the "fog far" and "fog near" value will start to decrease, effectively hiding the edge of the world from the view sight of the player. This is done gradually, so the fog builds up as the player walks toward the edge, and in reverse, the fog decreases as the player walks away from the edge. This build up is done exponentially, so that the totally fogged up period is minimal. In addition color of the fog is darkened to add visual effect.

Day and Night

Day and Night is a new concept in the game, but seeing how there is already a game elapsed time existing in the original game, that time can be used as to drive the 24 hours time. Once the game’s 24 hours time is completed, appropriate effects are added to make the game look like it’s going through the day and night time. This new enhancement doesn’t have many alternative choices in the way how it is added it to the game or have many problems that need to be solved. The difficulty of this enhancement lies in the way in which one would technically add this to the game to make it the most efficient and easy for maintenance, unlike the “edge of the world” problem, where there are many decisions made on the problem itself.

Structural Technical

This new component’s operation is very much different from the other components of the game, therefore a new class called “CAXTimeManager” is created which will handle all of the timing operation and day/night effects handling. In order to let have this class effect the visual of the game while keeping the default values of many variables, many of the default values are first saved as another variable in this class. Seeing that in the “edge of the world” approach, the default fog default values are also saved before they are modified, I find that this is not the best approach. Taking a step back and looking at the all of the enhancements being added to the game, enhancements like “edge of the world”, “day and night” and “climate” all affects the visual effects of the game, if they are all implemented separately, some of the visual effects will overlap each other. For example, the fog from the “Day and Night” doesn’t match the fog from the “edge of the world” giving a sudden change in the fog when the player walks towards the edge of the world during a certain time of the day. To fix this problem, the “CAXTimeManager” class is changed into “CAXEnvironmentManager” class.

The “CAXEnvironmentManager” class takes on new role of handling all parts of the game that affects changing the visual effects of the game. This class naturally also initializes all the initial visual settings of the game, this removes the need to make backups of the default value of the many settings, because all of the values are handled inside this class. This brings all of the visual effects code into one common place in the game which will make future enhancements that has to do with visual effects much easier. Ogre objects that are needed when changing visual effects (ie SceneManager) are all accessible from this class, making visual effect changes easier to implement. When this new class was made, the method that changes the fog effect when approaching the edge of the world is removed and integrated into this new class, keeping visual effect changes all in one place. The “moveToNotOutOfWorld” method only needs to tell the “CAXEnvironmentManager” class the distance the player is from the edge of the world, and the internal update method will calculate and give the according adjustments to the general (and now common) fog. For example, the many parameters to setting the fog are now multiplied by many “modifier” variables. These “modifier” variables normally have the value of 1, which will not affect the original fog. When external factors affect the fog, like “edge of the world” or “day and night”, these “modifier” variables will change in their value affecting the fog. Since all the “modifier” variables are changed gradually, the fog of night time near the edge of the world will blend in naturally with no abrupt changes.

Here is a picture of the new CAXEnvironmentManager class added to the game structure:

As seen, the "initEnvironment" method now replaces all of the initial visual settings which were done in the "CAXApplication" class.

Technical

The 24 hours time is done arithmetically. Most games that involves an actual game time, has the game time sped up compared to the real time to not bore the player from waiting. First a factor is decided in which how big the difference is between the game time and the real time. Afterwards, the game elapsed time (now ticking by the seconds of game time) is modded (modulus), so that seconds is translated to minutes and hours. Then after given a starting time of the game (defaulted to noon), the game now have a new 24 hours time. The GUI display of the game time is also changed showing the 24 hours time of the game instead of elapsed time.

To give the effects of day switching to night, many different “modifier” variables are calculated arithmetically based on the time of the game. For example, the effects like the angle in which the sunlight shines are changed by two “modifier” variables, one changing the Y in the angle and the other the Z in the angle. These “modifier” variables vary their value from 0 to 1 to 0, or -1 to 1 to -1, at different times of the day depending on their needs. For example, the Y angle modifier is 1 at midnight (pointing up), 0 at 6:00, -1 at noon (pointing down), and 0 at 18:00. And Z angle modifier is 0 at midnight, -1 at 6:00 (pointing from “east”), 0 at noon, and 1 at 18:00 (pointing from “west”).

Visual technical

One thing that the tutorial mentioned is that the lighting on the terrain using the “TerrainSceneManager” cannot be changed simply. The author of the tutorial did not mention the details of what would be involved to change the lighting programmically with the “TerrainSceneManager”, but suggests that lighting should be changed directly on the texture for simplicity or use the “PagingSceneManager” which provides better support. Given that this enhancement is just to add day and night effect to the game, to further dig into how to change the lighting of the terrain will eventually turn this out of scope, so I’ve decided not to dwell further into this matter but to use fog to give the night effect as the tutorial have shown.

I have done much investigation into how to gradually change the skydome from the cloudy sky into a starry sky. To do so involves using “Shader” which will blend two different textures as one material, and be able to programmically change the blend factor swapping between the two textures. I have found many sample codes in doing so, and have also tried to integrate it into the game. But I have not succeeded in using the sample code, as I have encountered two problems. First, after using the newly created material, no texture will be shown in the game (sky will stay white). Second, on runtime, the game will complain that the blend factor variable of the material cannot be found, so unable to change the blend factor in the game. Once again, I feel if I dwell on this problem further, it will not be productive, I could have instead added more enhancements to the game during that time.

There are several other approaches in which people working with ogre has used to achieve the day and night time look. One involved using multiple layers which overlay each other. Each of the layers is used for a different purpose, like one layer is for clouds or stars, and another layer is for the plain background color for sky. Skydome doesn’t support these multiple layers, most likely work is done once again on the material, and “Shader” is used to blend in the different layers. Another approach is to use a third party engine called Caelum which handles all of the visual effects of day and night, and also other weather effects.

I feel that seeing how both problems are very graphically involved technical problems, they should be problems solved in a graphics course, but not in a gaming course. I think that as a gaming course, I have done what I needed to do in this enhancement. That is have built a component that handles all of the environment issues in the game, which allows others to now easily use that component to add in their own enhancements pertaining to game environment changes.

Climate

In adding climate to the game, a component is needed that will control the whole weather system of the game. That component needs to determine the current weather status, and keep that weather status on for a period of time until the next weather status is triggered.

Technical

Changing the climate involves changing visual effects to the game, therefore all of the climate control codes are all inside the “CAXEnvironmentManager” class. A new method called “WeatherGenerator” is created in the class. This method is triggered once each time the “CAXEnvironmentManager” updates the visual effect of the scene. A random number generator is used to determine the weather type that is initiated based on the different probability of each weather type. When a new weather type is initiated, a weather elapsed time is also randomly determined. The weather status will last until the weather elapsed time runs out. The “WeatherGenerator” method will check first if the weather elapsed time has elapsed to 0, if so, it will generate the next weather type.

For the rain effect, the particle engine is added into the ogre as another plugin. By using the particle engine, rain is defined using a .particle file, which defines how the rain is being emitted from the sky. The rain droplet is just another material file. All of the rain effect is defined by external files (non-compiled) just like material files, the kind of rain wanted in the game can be changed without recompiling the game. The rain is attached to a node, which is a child of the avatar node. Imagine a room size shower head hovering on top of the player.

Detail Diagram

Here shows the generalized operation of the “CAXEnvironmentManager” class in respect of the other classes:
The entire operation is initiated by the “frameStarted” method from the “CAXGameState” class. In terms of the “edge of the world”, “moveToNotOutOfWorld” method updates the player position in “updateAvatar” method and sends the distance from the edge of the world to the “CAXEnvironmentManager” class. For “day and night”, the “retrieveGameTime” uses “retrieveGameElapsedTime” and calculates the 24 hours time. “updateEnvironment” method, which updates all of the visual effects of the world, uses the “retrieveGameTime” method and makes all the changes needed for the different time of the day. For “Climate”, the “updateEnvironment” method calls the “WeatherGenerator” method, and it will handle all the weather related issues.

Milestones

March’3 – Progress report
March’9 – Finish “climate”
March’16 – Preliminary “Tree growing”
March’23 – Finish “Tree growing”
March’30 – Add finishing touches/fix bugs/testing
April’5 – Final report

Interaction with other groups

Most of the enhancements done in this project are mostly ones that do not require additional art works. Only enhancement that may require an art model is the “tree growing” enhancement.