Saturday, December 10, 2011
Monday, November 28, 2011
Monday, October 31, 2011
Up to now, we have finished all of the requirements in Alpha Version:
Procedural generation of tunnel
Distribution and generation of obstacles and accelerators
Collision between character and obstacles
We have also implemented some of those in Beta Version:
Webcam based movement control
Dizzy and motion blur effects
In the next few weeks, we will be working on:
Other Beta Version requirements, including dual game mode, diverse bonus/ obstacles and custom shaders, etc.
We will also optimize the existing mechanism and graphic effects according to the feedback.
We want to Create Really Simple but cool HUD in game to show the current score and speed level of the player. Because our game is pretty like the racing game, the idea of build a speedometer like HUD comes to our mind first.
Rotate the Pointer:
We started to add our HUD from a Unity GUI Texture, but the problem is, it is not allowed to rotate any non-3D GUI Textures in Unity, while we definitely don't want to use mesh textures because that is not cool...
So one way to rotate the GUI Texture is like that:
posPointer = new Vector2(transform.localPosition.x - sizePointer.x * 0.5f, transform.localPosition.y);
rectPointer = new Rect(posPointer.x - sizePointer.x * 0.5f, posPointer.y - sizePointer.y * 0.5f, sizePointer.x, sizePointer.y);
pivotPointer = new Vector2(rectPointer.xMin + rectPointer.width * 0.5f, rectPointer.yMin + rectPointer.height * 0.5f);
GUI.matrix = matrixBackup;
It Rotates a Texture2D like the OpenGL way, and the result is pleasing.
Here is a screenshot of our HUD:
We have also added some more detailed animations to the menu, for example, the button will "stand up" when a user puts the mouse on it. Light will also be turned on and gear will spin before the door opens.
Thursday, October 27, 2011
Tuesday, October 18, 2011
In Sliding in the Deep, the core development task is to procedurally generate the tunnel. In our design, the tunnel has two varying parameters, the longitudinal direction and latitudinal curvature. We want to make our tunnel turn left/right/up/down randomly. And its shape can also vary between a complete circle and a plane. Player will move inside the tunnel if its curvature is positive and outside the tunnel if its curvature goes negative. We want the tunnel direction and curvature change smoothly.
The basic idea is to derive a section of tunnel from a procedurally generated cubic Bezier curve, namely, the guide curve. This guide curve will determine the general shape of this section of tunnel. Its start point coincides with the end point of last guide curve. Its end point is randomly picked. We want our tunnel to always develop along the +z axis, so we keep our tangent of two endpoints be (0, 0, 1) * constant.
The basic idea is easy and straightforward. But we did meet challenging problems when implementing this idea:
1. How to describe the tunnel’s curvature?
Most of the time, the tunnel is an arc of a circle (or a complete circle). But things goes messier if current curvature is 0, which means the tunnel degenerated to a plane. We can no longer treat it as arc since its radius will be infinity.
2. How to ensure uniform speed?
The speed of player moving along the curve is an essential element in our game. It will only be affected by the interaction between player and obstacles or accelerators. We actually want our player move a contestant length of curve in each step (If it doesn’t get accelerated or hit an obstacle). If using Bezier curve, the naive method to deal with player movement is to use the Bezier parameter t. But for Bezier curve, uniform change in t doesn’t mean uniform speed.
3. The workload of tunnel generator is not uniform. Next section only needs to be generated if player get near to the end of current section. But the generating process needs heavy computation. Simply call the generating function when player move towards the end will make the game get stuck for a very short time. This is annoying and will make our user experience quite bad.
The method we used to solve those problems and more implementation details will be given in the following blog.
Sunday, October 16, 2011
Friday, October 7, 2011
And I change the render setting, zoom in the z-far clip plane, attach a small keyboard control script to the camera.
The demo shows the result:
Wednesday, October 5, 2011
In this game, players are controlling the height of the helicopter by clicking the left button of mouse.
There are many similarities between our game and this one:
1. One degree of freedom.
2. Endless stage.
3. Dynamically generated scene.
4. Obstacle avoidance
5. Main goal of the game is getting higher score (by keeping the avatar not die...).
The difference between ours and the helicopter are:
1. We have 3D scenes and fancy graphics effects.
2. We provide body movement controllers.
3. We add more elements like acceleration strips, dynamic bonus/obstacles.
4. We have physical-based effects.
We think sticking with classic game ideas is a good start.
All we should do is adding a lot of new elements to a simple concept.
-Keep the concept easy and make the game fun by adding more elements. That's the guideline we always want to follow.
Hope you enjoy the helicopter game:)
Tuesday, October 4, 2011
The only difference between polygon tunnel and cylindrical tunnel is the former has rapid changing corners. And my assumption is people get sick from integrate the corner change.
But from the implementation aspect of view, polygons are easier to use if we want generate dynamic game scenes, and low-polygons are always cheaper for rendering.
Inspired by last source in optical illusion, we decide to change the texture pattern in the tunnel and see how we can decrease the dizzy effects in the polygon tunnel.
And here's the result, let's test our eyes again. (These two shares the same mesh structure, the only difference is the texture)
I just pick some related results to our game design. Basically the reason of the following illusion is called by inappropriate edge smoothing and integration by human eyes.
The café wall illusion consists of a black and white checkerboard pattern with alternating rows shifted one half of a block and with thin gray mortar lines separating the rows. The pattern creates the illusion of the horizontal mortar lines being tilted. The effects of smoothing on the pattern can explain this illusion.
If we take a closer look at the pattern, we find that the horizontal gray lines create two different types of edges because of their proximity to the black and white blocks. There are gray lines between white and black solid areas (type 3 edges) and there are gray lines between two black areas or gray lines between two white areas (type 2 edges).
(If you want to look up what is type 2 edge and type 3 edge, please go to http://www.cfar.umd.edu/~fer/optical/smoothing1.html)
If we smooth the image and then apply edge detection, we obtain edges as shown below.
As you can see, the smoothing distorts the edges to bulge where the horizontal mortar line is between two areas of the same gray value and to come closer together otherwise. A local edge detector produces small edge segments, which are tilted in the same direction as perceived. These edge elements are then linked by more advanced computational processes into lines of longer extent. Assuming that these processes are computationally approximations using as input the position and the orientation of the short edge elements, they will derive tilted mortar lines.
Based on the understanding of how the illusion works we should be able to counteract the effect by introducing new elements into the picture that balance out the illusion. We do this by inserting white and black squares into the corners of the tiles. As you can see, this greatly reduces the illusion.
If we zoom in and look at the edges we notice that the added squares compensate for the drifting of the lines. There is still “waviness” to the edges, but it is too weak to be perceived.
Monday, October 3, 2011
- Highly Immersed Game Experience: We allow players use body movement to control the avatar, together with the first person camera to make players wholly immersed. We are not going to use Kinect because we would like to use least expensive devices but still bring the users maximum involving experience. We will capture the user’s face position and trace it during the game to control the avatar.
- Diverse Bonus/Obstacles: There are many kinds of obstacles with different shapes and sizes which will make benefits/troubles to players.
- Fancy Graphics Effects: Smooth and appealing visual effects give players the best sense of speed. Players will get dizzy when hit the obstacles. The view will be blurred when get accelerated. The textures of the tunnel, sliding speed of the player and the locations of the obstacles will be carefully designed to avoid inconvenient feelings.
- Dynamic Scene Generation: Game scenes are generated randomly and dynamically. Players will never get tired because they can never enter the same tunnel again.
- Undo IT When Things Go Wrong: We provide a flashback function which gives players limited opportunities to restart at some previous time. Hope they won’t make the same mistake again.
- Dual game mode: We will implement two game modes, classic mode and time mode. In classic mode, players have limited lifes, once they collide with some obstacles, they lose a life and game is over if they lose all the lifes. In time mode, game will ends after certain time, and players are spurred to run as much far as possible.
- Highly accurate and interesting control method
- Fancy visual effects
- Dynamically generated scene
- Flashback function
- Dual game mode
Hot: Fast action. Hints disappear and more obstacles come up with various shapes, sizes and combinations.
Deep: Even faster if the player hits a accelerator. The tunnel will change more dynamically. Obstacles might move instead of stand still. Other tools are also available to create special effects like convert left/right direction.