Fly Around and Zap Aliens Beta

I recently released a game on the Google Play store called Fly Around and Zap Aliens. It is currently in an open beta, so you are welcome to try it out, although I plan change some things in future. You can download it here: https://play.google.com/store/apps/details?id=com.kenningtongames.spacegame.

History

This game actually started back in high school. I had previously made a simple space game in Flash where you and another player orbit a planet, trying to knock each other out of orbit. When I was learning Unity, I thought I would try making a 3D version of the same game. However, I quickly ran into some serious design issues:

  • There’s a lot more space in three dimensions. Traveling from one side of the planet to the other felt like it took way too long, and it was hard to tell how fast you were going until you crashed into something, unable to slow down fast enough.
  • Your field of view is limited, since you are following a spaceship instead of getting a full view of the arena. This made the pull of gravity really confusing. Since there is no up or down in space, the pull of the planet onto the ship just made uncomfortable controls.
  • Multiplayer would be trickier than simply sharing a keyboard with a friend.
  • Boundaries are unclear. In 2D, it was simply the edge of the screen. In 3D, I needed a way to box players in and still have them experience the openness of space.

So I made an entirely new game with a similar-looking stage. There is still a planet in the center, and you still control a spaceship, but now you are defending the planet from aliens. You zap them instead of knocking them backward. There is no real gravity from the planet, but you still fly around it. I originally had a force-field for boundaries, but my force-field effect looked awful. The game was pretty much playable, though. I never could settle on a name. I then took a two-year break from game development and forgot all about it. More recently, I was looking through my old projects and re-discovered it. I had learned a lot since made it (it’s been about five years now), so I decided to start fixing it up.

The Game Now

I chose to port it to mobile because of the availability of tilt controls. Really, a platform like the Nintendo Switch would be more ideal, since it has a little more graphics power than a mobile phone while stile having the same tilt control, but Android is an easier platform to begin publishing for. The Asset Store has come a long way since I started this project, so I was able to make things look a lot nicer, but the game works in pretty much the same way. I did, however, change the boundaries, using a portal instead of a force-field. If you fly too far away from the planet, a portal appears, taking you to the opposite side of the planet, flying toward it instead of away from it. I released it recently to the Play Store, but it still has a few problems. For example, it is possible to dodge the portal and keep flying away. Most people I show the game are initially confused by the controls. It doesn’t take long to get used to them, though. Also, the end screen is kind of boring. I hope to fix these things and more. Still unable to choose a name, I chose the most concise way I could explain it.

The Plan

Between now and the full release, I plan to add the following:

  • Appearance tweaks (Already swapped out the spaceship models; just need to publish that change).
  • Fix the problem of dodging the portal and venturing into the void of space.
  • Add a leader board
  • Have the aliens come in waves instead of a steadily increasing rate.
  • A tutorial
  • Optimizations and device support (If you try the beta, and it does not work on your phone, let me know!)
  • An iOS port

These updates will come gradually as I make them, leading up to the official release. Please try it out and let me know what you think!

Player Motivations: for Novelty or for Sport?

There are many ways to classify players. I most commonly hear casual versus hardcore. This classification is not very useful, since it seems to describe the level of commitment to a game, not the type of commitment. I struggled to classify myself, since I enjoy both casual and hardcore games. I noticed, however, that I had a very different play style compared to many other players, in both casual and hardcore games. I realized that these differences in style could be explained by a difference in motivation. So I propose a new classification based on two kinds of player motivations: for novelty versus for sport. These two groups can be described like this:

Players for novelty (adventurers):

  • Believe games are about trying new things
  • Prioritize accessing new content
  • Care very little about metrics
  • Play recklessly
  • Embrace randomness and imbalance
  • Like things to change

Players for sport (competitors):

  • Believe games are about overcoming challenges
  • Prioritize winning
  • Focus on metrics
  • Play cautiously
  • Get outraged at randomness and imbalance
  • Like stability

This is a spectrum, and while many players will fall somewhere between the two, the direction a player leans will greatly impact the decisions that player makes during the game. I, for example, lean far on the novelty side, meaning I am more of an adventurer than a competitor. Even in physical sports, which obviously are designed more with competitors in mind, I would try to make the game more novel. Because of this, I wasn’t the most competitive. I remember one time in elementary school when I got bored during a game of dodge-ball and thought, “How long could I last without moving my feet?” The children on the other side of the spectrum thought I was being an idiot, since not moving my feet would obviously put me at a disadvantage. I didn’t care about the disadvantage; I just wanted to see what would happen.

Another example, this time with video games, is Super Smash Bros. I like to play timed battles with a random character, on a random stage (no stages removed from the random selection), with all items turned on and with the maximum number of players. Many Smash players probably cringed while reading that last sentence. This introduces tons of luck. You could end up winning a round, not because you have better tactics and reflexes than another player, but because the perfect item happened to drop right in front of you while your opponent is distracted by a random stage hazard, allowing you to deal a final blow a second before the clock hits zero. Many players try to avoid these situations by only playing stock mode on the simple Final Destination stage with all items turned off.  Such a player will feel satisfied that any victory was a result of his or her own skill, and nothing else. It is the pleasure of learning to overcome a difficult problem. Players like me, though, would look at this setup and think, “Why spend all your time playing only half a game?” Sure, the game is unfair and unpredictable with my preferred setup, but each match has a higher chance of seeing a combination of events I have not seen before, and for players like me, that means more fun.

You have two types of players who will judge your game in very different ways. One type wants more options. They are forgiving of bugs and glitches, and may actually appreciate them if if they do not completely block game progress. The other type wants games to be fair and predictable. They are more willing to replay the same or similar content without getting bored, but also more likely to complain about glitches, imbalance, and random number generators. They will prefer existing game mechanics to be deep rather than be introduced to new game mechanics.

Designing for Player Motivation

It is important to consider both of these kinds of players in game design. Many games support play styles preferred by both groups. In farming simulators, for example, players for novelty can focus their attention befriending villagers, collecting rare items, etc., while players for sport can focus on becoming millionaires. These differences can often make interesting gaming communities. An adventurer playing for novelty might discover a glitch in a game that is then used by a competitor playing for sport to set a new speed-running record.

Some game mechanics, however, tend to appeal to one side of the spectrum more than the other. Sandbox and open world games tend to attract adventures playing for novelty since they encourage discovery and do not have as clear of goals. Competitive and linear games attract players for sport because they are more controlled, more fair, and more clear about objectives. By considering these two kinds of audiences, we can tailor the details of a game’s design to the things our players most hope to find.

Of course every player is unique, so no classification is perfect. Most adventurers need at least some goals to get started. Most competitors will appreciate the occasional game changer. Nearly every game design will need to account for both motivations, regardless of the expected audience. Many game design decisions are highly controversial because they appeal more to one side of the spectrum than the other, earning game developers both praise and criticism. By knowing our players’ motivations and by designing for the different resulting play styles, we can design games that both can enjoy.

Where are you on the player motivation spectrum, and how has that affected how you play games? Do have any other ways you like classify play styles? I’d love to hear about it in the comments below.

Nebula Gladiator VR

A roommate of mine just got an HTC Vive virtual reality system, and that gave me an idea. One of the struggles with making Nebula Gladiator has been making smooth sword combat. In virtual reality, however, you get full control with how you swing a sword. So I began work on Nebula Gladiator VR. The game is simple: fight hordes of robots by slicing them with your sword. After a couple days of setting up my computer for VR development and playing with the SteamVR library for Unity, I used existing artwork from another project, Nebula Gladiator, to set up a simple arena scene.

The scene spawns a new robot every few seconds around the perimeter. The robots approach the arena, and thanks to BzKovSoft’s Object Slicer, you can split these robots in half with your sword. At this point, the robots are still harmless, so the next step is to introduce threats, but so far, it is very satisfying to swing a sword around and watch robot gore fly around you. The video doesn’t do the experience justice. Already, in this early stage of development, I and my friend testers find ourselves wanting to swing that sword around until we are exhausted.

Yet to come will be robot attacks that lower your health, a high score board, and increasing difficulty with time. Please leave a comment with any feedback. I’d love you hear your thoughts on the project and the demo.

How to model procedurally in Unity3D

Unity3D is not a modelling tool. It is usually easier to design artwork in an animation program like Blender or Maya, and then import them into Unity. However, for some things, especially procedurally generated content, you’ll need to dive into the drawing tools Unity provides in its libraries.

Note: This tutorial assumes you have a basic knowledge of the Unity Editor. If you do not, you should first go through Unity’s beginner tutorial.

First, create a new scene in Unity. Go to GameObject > 3D Object > Cube to add a new object to the scene, and position it at the origin. Then, in the Project window, go to Create > C# Script. Name the SimpleMesh, and then double click it to launch Visual Studio. Now we are ready to start coding.

We’ll begin by creating a Mesh object. This is what hold the shape of our object. We make a mesh by creating a bunch of 3D vertices and then connecting these vertices to make triangles. Unity does not have a built-in way of making pyramids, so we’ll make one with our SimpleMesh script. I’ll show the code and then explain:

using UnityEngine;

public class SimpleMesh : MonoBehaviour {

    void Start () {

        Vector3[] verts = new Vector3[16];
        //base
        verts[0] = new Vector3(-1, 0, -1);
        verts[1] = new Vector3(-1, 0, 1);
        verts[2] = new Vector3(1, 0, 1);
        verts[3] = new Vector3(1, 0, -1);

        //front wall
        verts[4] = new Vector3(-1, 0, -1);
        verts[5] = new Vector3(0, 2, 0);
        verts[6] = new Vector3(1, 0, -1);

        //back wall
        verts[7] = new Vector3(1, 0, 1);
        verts[8] = new Vector3(0, 2, 0);
        verts[9] = new Vector3(-1, 0, 1);

        //left wall
        verts[10] = new Vector3(-1, 0, 1);
        verts[11] = new Vector3(0, 2, 0);
        verts[12] = new Vector3(-1, 0, -1);

        //right wall
        verts[13] = new Vector3(1, 0, -1);
        verts[14] = new Vector3(0, 2, 0);
        verts[15] = new Vector3(1, 0, 1);

        //order the indices of verts in patterns
        //to make triangles
        int[] tris = new int[18] { 3,2,0,2,1,0,4,
                     5,6,7,8,9,10,11,12,13,14,15};

        //add the vertices and triangles to a new mesh
        Mesh mesh = new Mesh();
        mesh.vertices = verts;
        mesh.triangles = tris;

        //Assign the mesh to the MeshFilter component
        GetComponent().mesh = mesh;
    }
}

Everything will happen inside the Start() method so it will happen once when we play the game. This is what the script does:

  1. Create an array of 3D vectors to store our vertices. Our pyramid will have five vertices: the top and each of the four corners. Many of these vertices are duplicated in our array. This is because we want hard edges. Shared vertices mean there will be a smooth edge, like the surface of a sphere. Duplicated vertices mean it will draw a hard edge like a corner. We’ll come back to that later.
  2. Create and array to store triangle information. This may seem like a strange list of numbers, but each corresponds to an index in the triangles array. Every three numbers represent one triangle connecting vertices counter-clockwise. So the first triangle connects vertices 3, 2, and zero, the second connects 2, 1, and zero, and so forth.
  3. Create a new Mesh object. This stores both our vertices and triangles.
  4. Assign the new mesh to the MeshFilter. This component should already be on our object, since we are creating it from a Cube. It will also use the material already assigned to the Cube. The material tells Unity how to draw the shape on the screen based on textures and lighting. Materials can also be generated, but that is outside the scope of this tutorial.

Assign the SimpleMesh script to the cube object. If you press play, you should see something like this:

pyramid

You may need to adjust the camera position or pause the game to get a better view. The shape is right, but it still looks kind of strange. There is nothing to distinguish the edge, and the lighting is weird. This is because we have not assigned normals. Normals are direction vectors that are supposed to point away from the object. There is one for each vertex. When light hits an object, it reflects more light if it hits directly than if it hits at an angle. The normals give Unity a reference to decide what is considered direct.

normal_explanation

Normals are why we duplicated vertices. Unity blends between the normals to get smooth curves, like in the top diagram. At a hard edge, though, where would the normal point? With two vertices, we can have two normals, one pointing away from each wall that meets at that corner. There is no blending because we have two separate surfaces.

Fortunately, for a shape as simple as this, the normals can easily be calculated. Add this inside the Start() method after everything else:

mesh.RecalculateNormals();

That’s it!. Press play and you should see a pyramid that looks something like this:

pyramid2

PyGame Detective Game

Last semester, I took a class learning PyGame. Despite the outdated-looking website, it is actually fairly well maintained. It may not have all the bells and whistles that I am used to in other game engines, PyGame can be a good tool for making smaller 2D games. With the help of PyTMX, I was able to make a quick side-scrolling detective game.

In the game, you are thrown into this village where someone is supposedly plotting a murder. People walk around throughout the day, going house to house and interacting with the neighbors. Your goal is to get the information you need at the end of the day in order to stop the murder from happened. The roles and behaviors of the townspeople are randomized at the start of the game. However, if you fail to stop the murder, you can reset it to the start of the day, where people will act exactly as they did on the last try except where your different decisions might have influenced them. The game was mostly a proof of concept to see if I could make a game all about logical deduction.

detective

Abandoned Projects

I’ve been looking through some projects from years ago that I never finished or published. I’ve been experiencing some writer’s block, so I’ve been thinking about revisiting some of these. Below is a list of some of my less awful projects. If any of these sound good, I’m willing to revisit them to either finish or scrap for parts. Please tell me what you think.

Crazy Lander: Abduction

This was a sequel to the very first game I published back in seventh grade. You go back and forth between a mothership and a farm, dodging toxic clouds and angry farmers as you try to steal cows. Different clouds have different negative effects on your ship. After each run, you earn money for upgrades. It is mostly functional, but lacking decent artwork. I made it in Flash, which is sort of dying, so if I fixed it up, I would probably port it to Unity.

cla_screenshot1
The rope snags onto the cow. Then you carry it up to the mothership and drop it off. If the farmers sees you, he will shoot.

Handsome Taco

It is a side-view puzzle game. Try to get to the obstacles using blocks, portals, fans, etc. It even includes a level creator. It is a bit glitchy, and also in Flash, but it could be redesigned.

ht_screetnshot1
One of the first levels. The blue spots are teleporters. Yellow is a locked door. The red box moves clockwise when you are atop it. The crate can be pushed.

Energized

This turn-based multiplayer economic strategy game was showcased a few year ago at the annual showcase for the Center for Advanced Research and Technology. We set up multiplayer LAN games where people could try it for themselves. The hexagon tiles are rated for certain natural resources used to build alternative energy sources. Each player is a competing energy company that must buy land,  collect resources, but energy sources, and deliver the power to cities. Players are also able to buy and sell land and resources to other players. Whoever has the most money at the end wins.

energized_screeenshot1
The color tells you who owns the tile. This one has a wind turbine with power lines connecting it to a third city for extra money.

Earth Defense Whirl

Ported for Android, this game features two game modes. In the main Earth Defense mode, you fly around earth, zapping alien spacecraft before they reach our home planet. The goal is to hold off the aliens as long as you can. In training mode, you fly forward in a never-ending tunnel, avoid obstacles and not letting any targets get past you. If you fall behind too much, the game ends. The goal is to get as far forward as you can.

screenshot3
The arrows point to alien spaceships. You zap them when in range.

Super Rainbow Racers

As an end-of-the-year class project, our game design class recreated our classroom and made it into a shrunken cart racing game. They chose the name, not me. The physics were a little glitchy, but it did prove itself fun. Perhaps the framework is still salvageable for another cart racing game.

super_rainbow_racers_screenshot1
We only got this track working. I thank my classmates for the artwork.

Haunt

You enter a haunted mansion with nothing but a crossbow. Your job is to hunt and shoot all the monsters hiding throughout the building. There are paintings that change each time you look at them, man-slug-things that pop out of closets, and masked ghost patrols. This was my only attempt at a first-person shooter.

haunt_screenshot1
Two masked ghosts hovering toward the player.

Sphere Distort

Next time you want to make a game with small planets, save some time and effort from modeling scenery around a sphere. Sphere Distort takes regular Cartesian meshes and wraps them around the surface of a sphere. Now you can recycle some models from your non-spherical projects.

Check it out on the Unity Asset Store.