space – Zesix

Articles Tagged with: space

August 3, 2017

2D Space Shooter Design

For the past 3 years, I worked on a top-down 2D space shooter prototype. I recentlyÂ decided to suspend its development to focus on my primary project, a tactical online card game called Zems. In this post I share the major lessons learned while working on that prototype.

Visual Considerations

Is It Necessary?

(Screen from a very earlyÂ build)Â Ships have no visible thrusters, only gun and missile mounts.

Early on, I wanted a visual thruster effect for each way a ship could turn and move. For example, if a ship was turning left, thrusters would fire on the right side. In testing,Â the “flickering” of thrusters actually distracted the player’s eyes away from vital graphics like enemy fire. I decided to cut the feature and ask the following question for all visual ideas moving forward: Is it necessary? Another way to phrase it is, What is the minimum amount of visual effects needed to convey this specific information?

Space Needs References for Position

Players need a point of comparison to feel like they are moving in the vast expanses of space. Foreground and background elements like dust clouds, stars, and planets are commonly used as points of reference.

Color to Convey Information

Color mask. White indicates areas we color to depict friendly, hostile, or neutral.

Color mask. White indicates the areas we color to depict friendly, hostile, or neutral.

If your game has shields, coloring them is one of the easiest ways to identify a ship’s relationship to the player. However, shields eventually deplete under fire, so it’s good to have either colored lights on the ship or stripes on the hull to always indicate the relationship.

Specifying Incoming Missiles

Missiles do more damage than any other weapon in my prototype, but with so many projectiles moving on the screen it can be difficult for the player to know which enemy missiles are locked onto his or her ship. My solution was to draw a line from homing missiles to the player’s ship. The animated GIF shows an early implementation of this.

User Interface

UI for a fast-paced game is tricky. You want the player to easily access vital information like health and shields without being blocked from seeing enemies and bullets.

In my space shooter, IÂ discovered players spend most of their time looking around their ship in the center of the screen. Thus, I opted to put our UI elements in this area, with reduced alpha to minimize obstruction to gameplay.

For other examples of space shooter UI, see my Space Shooter UI post.

Interaction Needs Feedback

Shooters are about shooting, which includes the visceral feel of aiming and firing as well as feedback. It’s important to have visual effects such as screenshake and impact effects. If you’re developing a space shooter and wondering why it doesn’t “feel” right, weapon feedback might be the source of the issue. Some say say games should feel fun without fancy VFX, but effects tied to a core game mechanic shouldn’t be skipped when evaluating a prototype.

Sometimes a small visual addition can drastically change the feel of gameplay. Impact buildup is one such featureÂ – if weapons fire is concentrated on an area, show a buildup of visual impacts around that area.Â The result is a visually pleasing effect that lets the player know how precise he or she is at hitting the target.

Gameplay Implementation

Weapon Firing MatchesÂ Mount Orientation

Homing missiles pointÂ at the same angle as their firing mounts when launched.

If you have weaponsÂ with ‘smart aim’ or homing capability (usually missiles), you can make them more interesting by matching their firing orientation to their weapon mount. This adds an element of skill to the game by giving the player a higher chance of dodging guided weapons because they have to turn toward the player.

Resource Management Flows withÂ Intended Gameplay

One difficult aspect of game design is ensuring mechanics engineer the intended gameplay. I wanted players to cycle between intense combat and moments of re-positioning (or retreating). My original design gave all weapons a static cooldown, such as 1.5 seconds per bullet volley. In testing, this clashed with the flow I sought – moments of intense combat seemed artificially restrained by the static cooldown while moments of repositioning seemed to have too much shootingÂ because there wasn’t good reason to still aim in the general location of the enemy and fire.

The solution I found was to replace cooldowns with an overheat system: Firing a weaponÂ generates heat, and if a player’s ship overheats then it becomes unable to fire for a few seconds.

This is the last problem I solved before refocusing my efforts on my tactical card game, Zems.

Conclusion

As game designers, we often have an idea in our heads of how a mechanic might work, only to later discover that we are struggling with how to convey the minimal amount of information needed to teach it to the player. Most of the lessons here are the result of numerous failed ideas intended to solve that problem. I hope my findings help you in some way as you work on your own projects.

Here is one final GIF showing an early version of the game from 2015. It’s come a long way!

June 19, 2016

Space Shooter UI

There are a lot of ways to handle UI in a space shooter. I present the most common methods here, as well as their advantages and trade-offs.

Edge-Based

This is where the UI elements are primarily on the edges of the screen:

Taken from https://play.google.com/store/apps/details?id=com.frimastudio.android.SpaceShooter

The main advantage to this approach is a clear separation between gameplay and interface – the UI will never interfere with what is happening in the gameplay area. However, this has many disadvantages from a UX perspective:

If the player wants to see vital information such as health, he or she must look away from the game action to obtain this information.
UI updates will detract from gameplay because UI VFX and changes will happen on the edge of the screen.

Almost all UI is edge-based to some extent. The following examples will showcase UI that utilizes the edges to separate less important information from immediate data.

HUD-Based

$From Fractured Space: https://www.fracturedspace.com/$

From Fractured Space: https://www.fracturedspace.com/

HUD-based may not be the best name for this. I define this type as a UI that is near the center, but not at the center. This is best suited for games where the player’s ship is in the center of the screen. In the above image, the two rounded lines to the left and right of the ship provide vital information such as health and shields.

Surround and Follow Player

From Waves2: http://store.steampowered.com/app/217120/

Waves2 is not technically a space shooter, but it is a twinstick shooter that shares gameplay elements with arcade shooters. You can see how the UI follows the player’s character so the player can more easily determine his position based on the larger space taken up by the UI (easier to track in peripheral vision). Less important information such as player score, multiplier, and lives are placed on the edges.

Cursor-Based

From SPAZ: http://minmax-games.com/SpacePiratesAndZombies/

SPAZ does a great job of recognizing the player’s eyes will be on the cursor the majority of the time. This means information such as weapon power (shots until cooldown) are displayed on the cursor itself.

The Best UI Provides ‘Easy UX’

The most optimal UI for a game differs depending on the game’s setup, especially how the camera moves in relation to the player. When coming up with a set of rules for UI design, a good rule to follow is the UI should make vital information easy to obtain. The UI should display a conscious understanding of what data is most important from a gameplay perspective and position its elements accordingly.

July 1, 2015

1GAM 2D Space Shooter – Wrapping Up

With June over, I am writing this post to say my 1GAM experiment was a failure. There are many reasons why, but I also believe the 1GAM concept is only effective for certain game types and likely not the kind of games I prefer to invest my time in.

Can You Really Find Fun In One Month?

The heading presents the heart of the problem: It’s not that we couldn’t develop the necessary parts of the game in a single month, but instead that I could not settle on core gameplay I found to be fun. Part of this is because the core gameplay could not be adequately tested without AI, and when you iterate gameplay you must also update the AI.

The Vision: Fun, 2D space combat.

What We Tried: AI ships flying in formation and patrolling. They break formation when the player gets within a certain range and engage the player. We tried this in small quantity, and while it was cool, it wasn’t fun.

Most of the month was actually spent on the AI. We messed around with different times to break formation, different behaviors like strafing and flying backward, to even changing the whole feel of the game from tight controls to momentum-heavy ‘drifting’ and we’re still not certain what we need to do to make the game feel fun. The only conclusion we came to was that ‘drifting’ felt a lot more fun than tight controls, so we plan on keeping that.

Ideas Worth Trying

Floating Asteroids That Damage Ships

Technically, this was supposed to be part of the original implementation for June, but we ended up spending so much time trying to figure out the AI that we never got around to this. Will adding asteroids as a dynamic make combat more fun? I think so.

Bouncing Collisions and Shields

This is actually more work than it sounds since we are not using the Unity physics system, but instead precisely controlled movement with artificial (controllable) drifting. We didn’t want to use Unity physics because we wanted to be able to better tune the gameplay ‘feel’ and so when we add shields and the ability to bounce off objects, this should add more liveliness to gameplay.

Friendly Wingmen

Even if they’re AI-controlled, the idea of being a lone space fighter against a bunch of enemies is pretty unappealing unless you have some really badass capabilities. We’ve developed our game with Factions in mind and adding AI wingmen that follow the player and assist in engaging enemies shouldn’t be difficult, although it will require a refactor of our AI combat code that currently only looks to engage one enemy target.

Finding Fun

We use gut feeling to measure fun. Fun is different depending on who you talk to, but as a developer I know that if I don’t find the game to be fun then I will not have the desire to continue working on it. Therefore, the game needs to be fun to us first.

When we get around to trying the above, the main question we will ask each time is not “Does it feel fun now?” but instead, “Does this feel more fun than before?” Fun in games often is not a spontaneous discovery, but rather an iterated process. This brings me back to my main point – 1GAM is an interesting experiment, but due to my personal standard of never developing an unfun game, I don’t think it’s for me. Games with simple AI requirements or don’t require any AI at all are much better suited for 1GAM, as the amount of experimentation required is much lower. Perhaps if we extend the time to two months (1G2M), we will have ample time for fleshing out fun in games where AI is at the forefront? It’s worth a try.

May 31, 2015

1GAM Space Shooter – Firing Bullets While Preserving Momentum

Adding ship firing was supposed to be easy: Just instantiate a bullet prefab at the location of the gun, set the direction to match the gun’s rotation, and then apply a force. But something was bothering me – the bullet looked like it was flying off at an angle every time. It turns out if your camera is set up to follow an object, anything that moves in a straight direction from that object will appear to fly off at an angle as long as the object is moving.

The solution? Add the moving object (gun) momentum to the bullet.

The Setup

I have a ship object with several child objects. One of these is the spaceship sprite, and another is an empty game object whose transform is positioned on the ship’s gun.

The bullet spawn location is placed in front of the single gun sprite so bullets do not spawn on the ship itself.

Attached to the PlayerShip parent object is a FireProjectile class, which is attached to every object in the game that could fire a projectile:

using UnityEngine;
using System.Collections;
 
public class FireProjectile : MonoBehaviour
{
    // Where the projectile should spawn from.
    [SerializeField]
    Transform gunMount;
    // The projectile prefab.
    [SerializeField]
    Rigidbody2D projectile;
    // The parent transform for the projectiles.
    [SerializeField]
    Transform ProjectilesParent;
 
    [SerializeField]
    bool debugRay = false;
 
    public void Fire(float speed , Vector3 direction)
    {
        Rigidbody2D shot;
        shot = (Rigidbody2D)Instantiate(projectile, gunMount.position, gunMount.rotation);
        shot.AddForce((gunMount.up + direction) * speed);
 
        // Set shot parent
        if (ProjectilesParent != null)
            shot.transform.parent = ProjectilesParent;
 
        // Debug raycasting
        if (debugRay)
            Debug.DrawRay(transform.position, (gunMount.up + direction) * speed, Color.red, 5.0f);
    }
}

Each object that fires bullets has its own ProjectilesParent object:

Right now, only the player ship fires bullets.

Each object that is a ProjectilesParent has a FollowTarget script that forces the parent object to match the target’s transform position, which makes the bullet appear to fly in a straight line instead of at an angle due to the camera being centered on an object that is moving.

The FollowTarget script:

using UnityEngine;
using System.Collections;

// Follows target position
public class FollowTarget : MonoBehaviour {
    // Control parameters
    [SerializeField]
    Transform target;

    // Executed each physics simulation frame
    void FixedUpdate () {
        transform.position = target.position;
    }
}

In a nutshell, here is what is happening:

Projectiles are being instantiated like normal.
Projectiles, upon instantiation, are parented to an empty game object.
The empty game object’s transform is set to match the ship’s transform every FixedUpdate(), which causes projectiles to match the ship’s momentum instead of ignoring it.

As you may have noticed, this is not ideal for all weapons – only for those that need to also have the firing object’s momentum, which generally includes all projectiles.

The Result

January 18, 2015

A Simple Unity (C#) State Machine For Dummies

I’m surprised how many people do not know what a state machine is or have never implemented one in Unity. Granted, a state machine is not required for many games and in fact not recommended for many real-time games (can you imagine how many states an RTS game would have?). However, states are interesting not just for game flow but for things such as simple AI.

Case in point, one of my first games I created in HTML5 was a space shooter featuring both enemy aliens and asteroids. Asteroids damaged both aliens and the player ship, and they spawned and initially moved in a random direction at the start of each game (there are a few checks to make sure they don’t spawn on top of the player or aliens). Alien AI, however, revolved around 4 major states:

Far from asteroids but close to player.
Close to asteroids but far from player.
Far from asteroids and far from player.
Close to asteroids and close to player.

I had an internal distance specified for what I considered ‘close’ (it was equal to how far the alien could shoot), while anything beyond the ‘close’ distance was considered ‘far’. The AI handling was a state machine that basically worked like this:

Far from asteroids but close to player: Shoot at player while moving away. The moving away part is important because I didn’t want the alien ships to seem ‘dumb’ and just crash into the player.
Close to asteroids but far from player: Shoot at closest asteroid while moving away from closest asteroid. This made the alien seem somewhat smart in navigating around and destroying asteroids that were close.
Far from asteroids and far from player: Fly toward player. There’s no point shooting anything if both asteroids and the player are outside of the alien’s range.
Close to asteroids and close to player: Shoot whatever is closest while moving away from whatever is closest.

The actual AI behavior is far from perfect as the aliens do crash with asteroids (and the player) from time to time due to changing direction while still maintaining a forward velocity toward an asteroid (or the player). Note that at all points in the game, each alien ship would fall into one of these four AI states until it is destroyed (ship destruction is not an AI state, but it is a state my game checked for).

Here’s a link to the game, but be warned it is incredibly unoptimized (there are audio issues on some browsers) and you may need to reload the page if you can’t play initially: https://www.zesix.com/html5/IcarusWA/

But let’s dive into how a simple state machine would be constructed in Unity using C#.

Firstly, if you haven’t worked with enumerations (enums for short) before, just know that they’re basically a name-denoted type. Suppose you want to store days of the week, then you could have an enum such as:

private enum Days { Sunday, Monday, Tuesday, Wednesday, Thursday, Friday, Saturday };

The reason why this is handy is because sometimes you want to refer to things by name instead of number but don’t want to mess with the complexity of an array or dictionary.

Let’s suppose I was to implement the three AI states mentioned earlier in Unity. I would start by making an enum declaration at the top of my Alien class, along with a variable to ‘hold’ the enum:

private enum AIState { CloserToPlayer, CloserToAsteroid, CloseToBoth, FarFromBoth };
private AIState currentState;

For the sake of simplicity, let’s assume ships are spawned at the start of the game (in my game they spawn in waves, but I won’t go into that sort of complexity in this post). In the Start() function for every class, you would assign a ‘default’ AI state:

void Start () {
    currentState = AIState.FarFromBoth;
}

I chose FarFromBoth because in this behavior, the AI will begin flying towards the player. Since I’m making a simple case here, let’s assume you already check the state of the alien ship every frame. Your Update() function would then need to be able to switch states, which is as easy as:

void Update () {
// Assume we already have code checking the AI state and setting it. 
// Refer to the code in the Start () function above on how to set the AI state.
Â Â Â  if (currentState == AIState.CloseToBoth) {
Â Â Â Â Â Â Â  BehaviorCloseToBoth();
Â Â Â  } else if (currentState == AIState.CloserToAsteroid) {
Â Â Â Â Â Â Â  BehaviorCloserToAsteroid();
Â Â Â  } else if (currentState == AIState.CloserToPlayer) {
Â Â Â Â Â Â Â  BehaviorCloserToPlayer();
Â Â Â  } else if (currentState == AIState.FarFromBoth) {
Â Â Â Â Â Â Â  BehaviorFarFromBoth();
Â Â Â  }
}

I’m also assuming there are functions for handling each of the AI states (the functions with ‘Behavior’ in their name) in the class somewhere. I’m not going to go into them for the purposes of keeping this post simple. Hopefully this post has been useful to someone.

April 7, 2013

04/07/2013 Update on the Space Game – Now Called Icarus

I’ve finally come up with a name for the space game: Icarus. Icarus was the son of Daedalus in Greek mythology who dared to fly too close to the sun. The name itself doesn’t bear any meaning right now, but later on it will make more sense so just stick with it for now.

You can play the latest version of the game here. Note that it’s not the same link as the previous two blog posts!

Game Updates

There have been a plethora of game updates, even though the game doesn’t seem to have changed much when you play it.

Bugfix: Player ship no longer has continuous movement after a collision. I’m not entirely sure why this happened, but it should be fixed now.
Enemy ships are always moving. Previously, enemy ships that were calculating AI pathfinding remained immobile and fired randomly. Now they will move as the AI is working.
Asteroid chunks now fly away from the object that hit the original asteroid. In other words, whenever you shoot an asteroid, the chunks fly away from your bullet, whereas previously they flew off in random directions. This update also works if your player ship or an enemy ship collides with an asteroid.
Health power-ups spawn 2% more often and only after an enemy ship is destroyed.
Enemy ships move at variable speeds. This might still need some tweaking, as they still bunch up and move like a ‘hive mind’ at times.
Physics has been overhauled, meaning enemy ships now “bounce” from collisions.
Starfield scrolling occurs in direction opposite to player movement. Due to the game taking place in a fixed window, I may remove this feature.
Enemy health reduced from 5 to 4. A number of people complained the enemy ships took too long to destroy.
Player ship is now more responsive. The ship will no longer ‘drift’ after an acceleration, and ship turning also speeds up as the left or right arrow keys are held down (up to a max turning speed).
Gameplay audio is now randomized across three Clearside songs. Many thanks to them for allowing me to use their music.
A sound will now play when the player ship is shot by an enemy.
A sound will not play when an enemy ship is shot by the player.

Graphics Preview

I’m still working with the artist on the final art assets for the game jam, but for now here is a preview.

The Near Future

Most of what I want to accomplish for the game jam has been implemented. For now, I am waiting on the artist to finish the art assets.

Replace placeholder artwork with the final artwork.
Implement touch-based controls.
Enemy ships leave debris behind after destruction.
Player ship can pick up debris and will gain bonuses as more debris is picked up over time.
Add shield power-up.

I have also gotten in touch with some sound artists who have expressed interest in contributing to the project, but haven’t really heard back from many of them so I am uncertain as to whether there will be any new sound assets when I submit to the game jam.