This is a message displayed when the player finds magnetic boots on the ship. Now, the big question for the game designer/programmer is how do we show this upgrade to the player?

A few different solutions and their pros and cons

1. Leave the player avatar unchanged with no visual indicator that anything is different.

Pros:

• No extra animation work needed.
• No need to create an exponential number of sprite maps based on the different upgrade combinations. (Ex: Only a flashlight, only boots, flashlight and boots, etc.)
• No need for complex programming or storing multiple animations in memory, just change one flag indicating the possession of that upgrade.

Cons:

• Player has no way to tell which upgrades they have.
• Player can’t tell what the upgrades do if they forget after seeing the original message.
• Sense of accomplishment is fleeting as there is nothing reinforcing the fact that the player has more power/ability than before.

2. Change the player avatar to show the upgrade (flashy new boots).

Pros:

• Sense of accomplishment is reinforced as the player goes forward in the game and sees their character growing in power.
• Player can see which upgrades they have at a glance at any time without the need for a separate menu.

Cons:

• Player still can’t tell what the upgrades do unless the animations are very detailed and obvious.
• Extra animations are needed for every combination if using sprite maps
• Complex rigging system needed if not using sprite maps (drawing each part of the character including upgrades on a skeleton)
• Much more programming required

3. Have an “inventory” screen that shows all items the player currently has equipped.

Pros:

• Same sprite can be used from when the item is found for the item icon in inventory
• Details about the item are available when hovering over the item reminding the player of what it does.
• No extra animation work needed.

Cons:

• Some extra programming work needed for the UI.
• Only some visual indication of how powerful the player is, reinforcing their need to find more upgrades and proceed in the game.

4. Show a paper doll status indicator to show which upgrades the player currently has.

Pros:

• Very basic filled or not filled paper doll sprites can be used as indicator. No fancy animations or sprite art needed.
• Details about the item are available when hovering over the item reminding the player of what it does.
• At a glance reinforcement of the player upgrades.

Cons:

• Not as detailed as custom animations, may not be as appealing to some players.
• Takes up more space on the main UI, may make it seem cluttered.

As you can see, most of these solutions either put more pressure on the artists to create more game assets, the programmers to create a rigging system capable of displaying those assets, or the player in relying on their imagination and memory about the upgrades they have.

For an indie developer, and quite possibly any large studio developer, you never want to leave it to the imagination of the  player. This would rule out option number one, since it relies too heavily on the player to remember what upgrades they have acquired and what they do.

For an indie developer that doesn’t have any artists, creating a lot of art assets is out of the question. This pretty much rules out option number two. Unless you use a pre-built rigging system with a small number of sprites, and have experience using it already, this would take too much time to do.

Option three is good if you have plenty of time. Depending on how easy it is for the indie developer to implement another screen worth of UI, this may be the best and most engaging solution for the player as well. It would also allow for multiple upgrades in the same “slots” like multiple types of boots. It also reuses art assets, but in a way that would make sense to the player.

Option four is the best solution if time is of the essence. It has the least amount of work involved for the developer, while also providing immediate feedback and gratification to the player.

For my project, I will most likely end up going with option three. If I were to get an artist working on all the art assets for the game, then I would consider option two, as that is I think the best solution if given the resources to do so.

Here’s a little sneak peak at some of the art assets I created in my attempts at option two on my own. This is for a headlamp or flashlight that the player attaches to the helmet of their suit. These are four variations for the same upgrade.

Creation of debris art assets is my top priority for the art side of things. However, I took a break from that and drew out what I have outlined in my design document for the tutorial level of the game. I’ve always liked tutorials that are built into the story so it doesn’t break that immersion into the game world. In this case, to introduce the player to the movement, salvage, and repair systems, they start in a small shuttle that has just survived an attack. Their task is to repair the shuttle by doing a spacewalk, or EVA, to replace, repair, and salvage different systems.

And now what I’m sure everyone is waiting to see, a completed mockup drawing of the tutorial level.

Please note that the final game will probably look a bit different than this, but it should give you a good idea as to my goals for the game. Also note, that I will not be giving any spoilers regarding how to beat different puzzles in the game on this blog. Considering this is just the tutorial level, there will be guidance given towards completing it within the game itself… that is another thing I want to save as a surprise until the game’s beta release.

What follows is the technical information of how I created this image and some of the thoughts behind it.

Layers

• Background
• Clouds
• Astronaut
• Engine Glow
• Ship
• Antenna
• Tanks
• Smoke
• Tanks Compartment
• Tanks Hatch
• Line
• Electrical Hatch
• Electrical Compartment
• Electrical Compartment Objects

Method of Creation

I started my drawing with the astronaut on his own layer. He started as a small white blob with barely any definition or detail that indicated it was a person in a suit. I then defined his shape more while zoomed into the pixel level.

Then, I added the black background with blue haze to give it a basic environment. The background can’t have too much going on or it would be too difficult to see all of the foreground objects.

The ship was created next. I drew a basic shape at first and gave it a single color. I then went back and gave it a kind of manual gradient from light to dark top to bottom. I created an airlock on it’s own layer so that it can be animated with an open and shut door animation. Every part of the ship that isn’t the hull or window is on it’s own layer so that they can be removed or replaced easily.

The line connecting the astronaut to the ship was next, again on its own layer. Originally it was all red, but I added a black line to the bottom of it. I can’t determine yet if it should be considered two cables, a red and black, or just a shadow on the underside of the red line.

I added the blue engine glow using pressure on the pen tip to determine opacity. Same method for the oxygen and smoke being expelled from the tanks at the bottom of the ship.

The satellite dish will most likely be replaced with a fancier looking communications array of some sort. It was all I could think of at the time to be a kind of placeholder. I also experimented a little with shading to see if I could get a more detailed/realistic look to it.

The hatch near the front of the ship contains 4 circuit boards. I know it’s hard to tell with them being so tiny. There is a zoomed in version that has more detail though. This is one of the items that I have as “debris” that can be collected throughout the game. Having each component in their own layer makes it very easy to separate things out and reuse them elsewhere.

Last of all, the hatches were created by selecting a part of the ship, copying it, flipping it vertically, then lining it up or throwing it out into space as the case may be and adding details to it. If I remove those layers and the components within the hatch layers, the ship appears to have no access hatches on it at all.

I hope you enjoyed this little preview of my game! I know that I’m loving every minute I spend working on it.

I’ve chosen the following game libraries for my first real 2D game:

• SFML – Simple and Fast Multimedia Library – http://www.sfml-dev.org/
  
  • Sprite-based graphics
  • Audio
  • Networking
• Box2D - http://www.box2d.org/
  
  • Gravity
  • Collision detection

I plan to release my game on the PC at first, but want the ability to release it onto other systems in the future. Both of these libraries are very portable and allow for this. They both have very excellent documentation and are easy to dive right into.

They may not be the industry standard, but they will serve me just fine in my first real game as a certified C++ programmer.

How do I decide what can be made into a technology?

In general, the more technologies and equipment introduced, the more complicated the technology tree will be. I’m evaluating what parts of the gameplay can benefit from a technology level structure and I’ve found that the following are good indicators for branches in the technology tree.

• Active Equipment: An object used repeatedly in a task to meet game goals
  Example: Harvest Moon Series – Farming tools can be upgraded and allow the player to complete tasks in a shorter amount of time.
• Passive Equipment: An object  that increases stats or improves a gameplay feature without the need to be activated by the player
  Example: World of Warcraft – Larger bags allow the player to hold more items at once.
• Gating Technology: A technology that prevents progression in the game until it is discovered.
  Example: X-Com Series – Capture and interrogation of alien leaders allows the player to find the location of the alien homeworld and finish the game.

How do I decide how many technology levels there should be?

After defining what types of technologies will be available, I’ll have to decide:

1. What range of power will each technology have?
2. What affect will the lowest and highest value have on gameplay?
3. How many levels should there be between the lowest and highest?
4. Is each level enough of an improvement and does it provide incentive to seek out the next?

For example, in Harvest Moon, there is a watering can the player uses to water their farm’s field each day. If the player can water their field in 10 minutes with the first level watering can, how fast do I want them to be able to water their field with the top level watering can? If I want them to be able to water it in 1 minute at the top level, they will get 9 minutes to do other things in the game and it will feel less monotonous as a result.

Next, I would start off with more levels than I think I’ll need and reduce the number of levels until play testing found a good balance. In this case, I would start with 10 levels, where each level reduced the time to completion of the activity by 1 minute.

After play testing, I might end up with 3 levels, each reducing the time to completion by 1/3rd.

Should there be a required technology level to complete the game?

This goes back to the idea of the gating technology in games. If there is no technology path that must be followed, there must be something else that limits the player’s progress. If there’s nothing preventing the player from immediately going to the end of the game, where is the challenge and reward from experiencing what the game has to offer?

Two options:

• Require a technology that works with the storyline to allow the player to progress to a final encounter or objective in the game.
• Don’t require a technology, but require another objective not based in following the technology tree that would be difficult to complete without at least following some of the technology tree’s path.

Here are the results:

Starfield created with Photoshop

Planet created with Photoshop

Starfield with planet overlay

What these assets mean for the game design

In the prototype for the game, when the player moves their ship to the right or left side of the screen the planet moves the opposite direction very slowly. This is what game developers call a parallax scrolling background. It gives the illusion of depth and simulates a 3D space. It also gives the player a point of reference so they have some idea of how far left or right the ship has traveled. The further left the planet is on the background, the further right the player has traveled in the game space and vice versa.

Next steps for development

I’m working on ship hull textures and creating an animated sprite for a player controlled ship. I’ve also decided to use the Torque Game Builder that uses C++  and TorqueScript to put everything together.

I have played this game at least ten times over the years but have never finished it. While studying game design, I decided to think about why I never finished this game and what caused me to lose interest before reaching the end.

What draws me in as a player

• Story
• Characters
• Galaxy map and universe size
• Resource collection mini-game
• Combat mini-game
• Art style
• Initial discovery of unique items and plotlines

What causes me to lose interest as a player

• Not much replay value
  (Map isn’t randomized, resources, events, unique items, races, all in the same locations every game)
• Difficult to track where you’ve been and what you’ve already found
  (Map needs to show more information about what resources have been found and what systems have been explored)
• Time-based events
  (Prevents me from exploring the galaxy at my own pace, gives a sense of urgency that isn’t necessary to enjoy the game)

From this information, I’ve come to the conclusion that i lose interest due to the complexity of tracking where I have and haven’t been and what I need to do next. It becomes more of a chore than a game which causes me to lose interest enough to stop playing. With a few modifications to the UI to show more information rather than forcing the player to draw up a map outside of the game, this game could be much better and keep players like me interested long enough to finish.

Download the free open source version of the game called The Ur-Quan Masters: http://sc2.sourceforge.net/

I’ve decided to split it up even more into small mini-game segments to work on as separate games. At the very least I’ll be able to scrap them if I find that they aren’t up to par with what I think the game should be in the end.

I’ll be unemployed next week. This will give me TONS more time to work on the game. I’ve been researching engines, tools, plugins, API’s, etc. to get this thing rolling. So far the list looks like this:

Engine – Torque Game Builder – For 2D platformers

Physics Module – Havok

Sound and Music – FMOD

Coding – Visual Studio 2008

Graphics – Photoshop CS3 and/or GIMP

Design Book – The Art of Game Design: A book of lenses by Jesse Schell.

Enjoy my awesome art skills!

I’ll be starting classes again in a week, so I don’t expect to have very much time to work on this side project too often. The time I do spend on it however will not be wasted. I’m very excited to develop a prototype and get it out there to friends and family to check out.

Teaser information and tidbits are sure to follow…

Here’s a video of the game as it is (with placeholder art and all):