|
Snjohus - Games, Apps and More
|
Welcome to Snjóhús, makers of games and software apps. We’re just starting our endeavor so most of our projects are at the planning stage or under development. We aim at giving our visitors a glimpse at the game and software development process with news articles, tutorials and discussions on programming and on art creation so stay tuned for updates.
|
|
A very early playable version of Rotor
|
Written by: Ágúst
19.04.2012
EARLY ALPHA VERSION OF ROTOR
Here’s a very early but playable version of Rotor. I just finished all the enemy behaviours but have not yet balanced and adjusted them to work well with each other which is the next step along with creating a UI and finishing the bosses.
Also keep in mind that these are all mostly placeholder graphics!!
Controls: Arrow buttons move around, space to shoot main weapon, z to shoot secondary weapon.
|
|
|
Making things look more natural
|
Written by: Ágúst
15.03.2012
LERPING AND SLERPING WITH ROTOR
When programming games, it’s often necessary to simulate some of the phenomenon we experience in real life, often this has to do with motion and animation. One good example of this is that in real life, there’s really nothing that goes from being in motion to being stationary instantaneously. There is always some, however short, time in which an object will slow down or speed up before reaching a stationary position or its full speed.
One good way to simulate inertia in moving objects in games is to Lerp. This strange sounding word is a contraction of Linear Interpolation. Lerping is the simplest way to make objects appear to slow down or speed up, but it also has many other uses.
For the simplest form of Lerping, you’ll need 3 things: a start value, an end value and a range between 0 and 1. The final value works really well if you have a time span, such as 2 seconds, in which you want the Lerp to take place. Let’s take a real example of a space ship that we want to take from its top speed down to 0 in 2 seconds, you would place the main line in your Update function:
const spaceShipStopTime = 2
const fullSpeed = 200
...
var currentSpeed = Lerp(fullSpeed, 0, (accumulatedTime / spaceShipStopTime))
spaceShip.speed = currentSpeed
accumulatedTime += deltaSeconds
...
When this Lerp procedure starts, the accumulated time divided by the total time the slowing down is supposed to take will be 0, that is the animation has progressed 0% and the ship’s speed will be set to fullSpeed. After 1 second however, the accumulated time will be half of spaceShipStopTime and the Lerp call will produce a number right in between fullSpeed and 0. This is what is meant with linear in linear interpolation, if you were to make a graph of the change, it would be a straight line. For a more interesting graph, such as one that changes slowly at the start and quickly towards the end you might want to look into some of the trigonometric functions such as cosine, or use fractional powers, but that’s a topic for another day.
Slerping is a similar thing but rather than working with points, it works with spherical geometry, or simply put, rotation. It is most often used to interpolate between two quaternion rotations instead of points or coordinates. Its use is very similar to Lerp, but the Slerp function would most often expect a pair of quaternion values instead of floating point values or vectors.
Here’s a fun enemy I made for Rotor that uses Lerping a lot. First, the warp-in effect is a pure Lerp function going from a really fast speed to 0 as the enemy approaches its pre determined stop position. At the same time, its shape is being lerped back to a normal shape from a kind of squashed form on the x and y axis, further strengthening the appearance of a warp-in effect. Third, I use Slerp to rotate the enemy towards the player’s ship and fire torpedoes. The last bit of lerping that’s going on, also a Slerp, is the tracking functionality of the torpedoes as they try to aim towards the player’s ship.
The standard "work in progress" applies to all the art assets.
|
|
|
A quick video grab of Rotor’s progress
|
Written by: Ágúst
21.02.2012
A QUICK VIDEO GRAB OF ROTOR’S PROGRESS
Here’s the current Rotor progress. Today was all about refactoring. I won’t bore you with the details but I had to move some stuff around and make things pretty behind the scenes.
Rotor now has 6 enemies and 10 “AI” enemy behavior implemenations, although some of them do need to be polished up a bit.
Here’s a video that shows enemy model number 6. It’s using an un-finished behavior model which is why the enemies don’t do anything more than slowly move down the sceen. I usually test each enemy by itself thoroughly beore moving on, which is why there’s only one enemy type in the scene. Btw, the choppyness is caused by the video recording software, the game itself is actually quite smooth.
The standard "work in progress" applies to all the art assets.
|
|
|
Starting a New Video Game Project
|
Written by: Ágúst
15.02.2012
THINGS TO THINK ABOUT
Unity3D makes many of the tasks of creating a computer game easy and enjoyable. You don‘t have to worry about the nitty gritty like collision detection, 3D rendering and other stuff that has been solved many times over and will not benefit from you personally implementing them again. Instead it lets you focus on your game idea and mechanics.
Before I begin I‘d like to point out that I don‘t use all of Unity‘s built in features. I like to code my own things because usually when using a service or a package I find out later that what I wanted to do is not quite possible or that the package wasn‘t designed to do quite what I had in mind, limiting my flexibility.
When I start a new project I begin by implementing a game controller. A game controller is an agent who monitors the state of the game and decides when and what should happen such as when a level should be finished, which level comes next, which cut scene to display next and so on. The easiest way to begin is to write a small MonoBehavior class that does 3 things: Displays a selection menu at the beginning, switches to the “main game” when the user selects the correct menu entry and displays a “game over” screen when the user loses (the user always loses in my first implementations!). The “game over” screen has a button that takes the user to the main menu again, creating a seamless circle. Here‘s a short method that is the heart of the GameController:
private GameState state = GameState.MainMenu;
private void OnGameStateChanged(GameState newState)
{
this.state = newState;
if(this.state == GameState.MainMenu);
this.menuManager.RenderMenu(this.state);
else if(this.state == GameState.Lost)
this.cutSceneManager.RenderCutScene(this.state);
else // playing
{
// Do game mechanics stuff (although this class should not do that)
}
}
You can then implement other serivces to handle the details, such as a menu manager to handle all the menus and a cut scene manager for all the cut scenes. I‘ll be talking more about these in future posts. For Rotor I implemented a space ship controller for the main space ship (Rotor) which is able to interpret inputs and knows how to react to stuff that happens to the player‘s space ship such as not to go outside the screen bounds, how to react to enemy fire, collisions, ammunition and so on. SpaceShipController is only active when the game is in the correct GameState.
But what changes the game state? Triggers and events. In Rotor, the thing that triggers a cut scene is the destruction of a boss. It‘s up to the boss‘ base class to notify the main game controller about this though, which is not so bad since it‘s located in just one place and happens in the BlowUp function. Actually there‘s a chain of events that happens when the boss blows up: 1) The boss blows up and emits a bunch of resources and goodies, 2) When all the resources are gone (off screen or consumed by Rotor) then Rotor accelerates upwards and out of the scene, 3) When Rotor is off the screen, a cut scene appropriate for the level is displayed. For this chain of events I‘ve implemented a EndOfLevelController which monitors all these activities but it is still initiated by the boss blowing up.
Follow me in my next post where I‘ll talk about how to create prefabs and load objects dynamically into the game during active gameplay.
Click here for Rotor’s back story and status.
|
|
|
The Back Story of Rotor
|
Written by: Ágúst
12.02.2012
EPIC ARCADE STYLE ADVENTURE GAME
|
Introduction
Introducing Rotor, a 3D version of the classic top-down arcade space ship shooter. Rotor features a fast paced shoot-em-up, arcade style game play with lots of explosions and visual candy. As you go through the game you collect resources and upgrade to ever more powerful weapons.
Rotor Back Story
Rotor takes place on and around an alien planet, the home of the tiny colony of Spim. Founded by adventurous and freedom seeking Krokodilar settlers who were tired of the overcrowded conditions on their established home systems little over 80 years ago. The colony is far away from the safety and comfort of the core systems of the Krokodilar empire and are as such not recognized by it. Life on Spim is hard but rewarding for the colonists who have built a peaceful little community for themselves in Spim.
Peaceful until one day the harmony got blasted out of the sky by hordes of unidentified space ships of varying build and shape that came apparently from nowhere. At first the fleets of ships only seemed to be making rounds around the planet but soon they started randomly tearing away at the planet, destroying mountains, forest and entire ecosystems at seemingly random. It was only a matter of time before Spim would be in the way, an occurrence that would mean certain destruction.
Since all attempts at communication have been ignored, Spim’s only hope now is to send Krokur, the best (and only) pilot in the colony, on Rotor, the last of the space worthy vessels around since the planet was colonized by the Krokodilar. Most of the advanced defense systems have been neglected and will have to be left behind but hopefully something can be found or salvaged during the mission. Krokur must try and find out why the aggressors have come to this planet and try to stop them before Spim and the planet are destroyed for good. His best chance is to reach the old communication hub on the outskirts of the solar system and contact the mother empire for emergency help.
Current Status!
The game is currently under development, being in the main phase of implementation. It will be ready for balancing and beta testing in around 2 and a half months and will be released soon afterwards on the iPhone and Android platforms.
Follow the Implementation of Rotor!
I plan on documenting the process of making this game so stick around for some interesting information on how games are made. I’m using the Unity3D engine, with C#. All the art is made by Ben Chompers aka poopinmymouth, a rather famous 3D artist, check out his site here. I’ll post screen-shots from the game (it’s playable right now) in the coming days!
|
|
|
|
|
|
|
|
|
|
|
|
|
|