Game Proposal: Space Explorers
ABSTRACT
The player explores the galaxy by moving through increasingly complex finite state machines. Each finite state machine is made up of stars for nodes, and the connections form solar systems. The player chooses a sequence of colored space ships that, based on their colors, can travel along various colored paths between stars.
The object of the game is to enter the correct sequence of ships that reach a specified goal. There may be multiple goals within a constellation, and the player can choose between them. Different goals may lead to different constellations, planets, solar systems, etc.
As the player progresses through the game, he/she can unlock new spaceships, as well as the option for longer sequences. Both of these options increase the number of maps available to the player.
BACKGROUND AND PROBLEM
The player will learn how finite state machines work, and will get a deeper appreciation for what inputs a specific finite state machine will accept. This will be disguised behind a game, so the player will not even realize how much they’ve learned because of all the fun they’re having!
The game is targeted at middle school children, and we assume no prior knowledge of finite state machines. Therefore, we will introduce the mechanics of finite state machines within the context of our game. This game will be effective primarily because the underlying concepts studied are hidden; students will not be intimidated by the theory because they will view it as a space adventure game. The game is designed to be played as an accompaniment to a class on finite state machines as per our discussion with the client; therefore, we do not need to make explicit the finite state machine concepts and terminology that the player is manipulating.
Our audience is split between students who like the computer science class a lot and those who are bored/uninterested. Ideally, we’d like to capture everyone’s attention by enticing them with JUICE and a core gameplay element that is fun.
COMPETITIVE ANALYSIS
Players sail between islands, with the goal of reaching Treasure Island. Each island has two departing ships, and the players have to choose which one to use. The players can’t see the departing ship and their destinations until they reach the island. The goal is to determine all possible paths that reach Treasure Island (or possibly the quickest path). One of the drawbacks of this activity is that the players are for the most part simply exploring the map blindly, not trying to “solve” it. Another drawback is that there is only one map to play, and no larger goal. Treasure Hunt is a game that you physically play in real life as a group.
Manufactoria is a finite state machine simulation game; it uses a manufacturing/robotic theme, with different manufacturing components to illustrate how to create a finite state machine that accepts a particular input. There are a number of levels that branch outwards in a tree-like structure, with different paths that the user can choose from to play the next level. The game has a steep learning curve; there is a tutorial, but it is very easy to skip. The early puzzles are too difficult, making it hard to engage with the game. Manufactoria is a Flash game that can be played on a website.
Kara is a game that teaches one how to program with state machines. The user programs a ladybug that can collect leaves and other things. The learning objectives of Kara are to teach the foundations of programming and finite state machines in a graphical program. The interface for programming the ladybug is fairly complex; the player essentially designs a FSM using state diagrams and state tables. Kara is a desktop program. The game designers claim that Kara is used successfully as an educational tool at many schools from secondary school to universities.
The next section explains our game design, which was developed with the problems of each of our competitors’ games in mind.
GAME DESIGN
The player completes his/her journey in stages, one solar system at a time. From the starting planet, the player must reach the goal planet to progress to the next solar system. The player’s first decision is to choose the proper fleet to reach a goal. The ships are color-coded, and the available paths between planets depend on the colors and combination of ships. The player’s fleet moves from planet to planet, one planet at a time. Planets are connected by colored paths, indicating what colored ships can travel along that path. When picking a fleet, the player must pick the order the ships are used in. The leading ship determines what paths are available; once the ship is used, it has to return to the starting planet to refuel, i.e. a given ship in a sequence can only be used once. The next ship then assumes leading position. If the player runs out of ships or reaches a planet without a possible departing path, he/she is stranded and has to restart the level.
For some levels, the player must collect a specified number of gems before he/she is allowed entrance to the goal planet. Planets containing gems can be found along many paths. Reaching certain planets unlocks new colored ships to add to the list of possible ships. New ships unlock new paths, making it possible to reach new, more complex solar systems. The player should be looking to collect gems and new ships whenever possible.
Above is an example of a potential level from Space Explorers. We have yet to complete our artwork, but this example contains the essence of the gameplay. The colored squares at the top of the screen represent the ship types the player has at his/her disposal. The player would click on a square to add a ship of that color to the fleet. The bar directly below contains the ships already chosen, with red being the first, blue the second, yellow the third, etc.
We are looking to expand the game for subsequent versions: new ships, new solar systems, and even new galaxies and game modes. New game modes could include mini-games between solar systems and the ability for the player to design his/her own levels to play locally or submit for public use.
REQUIREMENTS ANALYSIS
Functional Requirements
-Game loads to menu
-Interface to choose ships for fleet
-Planet nodes connected by colored paths corresponding to colored ships
-Ability to start/send out fleet
-Level restarts when user is stranded
-Levels are playable and winnable
-Ability to collect stars and gems
-Ability to save game progress
-Multiple levels to play
-Fleet follows path, and leading ship is easy to differentiate
-Scoring system/way to track progress
-Fun, interactive sound effects
Non-functional Requirements
-Fun to play (especially for middle schoolers)
-both the levels/solar systems themselves, and progressing/exploring more of the map/galaxy
-Helps teach and reinforce the concept of FSMs
-Simple, pleasant space-themed UI
-Easy to pick up and play for short periods of times
Problems/risks
-Creating a single, playable level
-Combining all levels into one interconnected map
-Making the game fun
-Making the game look and sound nice
-Artwork
-Planets, ships, background, menu, etc.
-Create an interface that is easy to use
-Learning Sprite Kit
-Any unforeseen issues with iOS 7
-Communicating with Nathaniel, our teacher
-Managing the scope of the project
DEVELOPMENT PLAN
We will be building our game using Sprite Kit, a new game-development framework released by Apple in iOS 7. We will be building our game from scratch rather than modifying or maintaining an existing one. The most critical limiting factor to what we can accomplish with our given tech stack and goals is the amount of time each team member will be able to contribute over the 10 week period during which we will be developing the game. With each decision we’ve made, we have struck a balance between what we hope to accomplish in this limited time and what we reasonably believe we can.
Tech Stack
iOS 7- With iOS 7, we are able to use SpriteKit, a new framework for 2D games that Apple has released as part of its native libraries. We have reason to believe that SpriteKit will take cocos2D’s place as the best 2D-game framework for iOS. In addition to its native physics and particle engine, SpriteKit’s documentation and maintenance is done by Apple, which is evidenced by the fact that its documentation now is more complete and readable than cocos2D’s.
Sketch- Sketch will make it easy for our artists to create vector graphics. Vector graphics can be scaled to any pixel count and still look good, which is important when we consider the slightly different screen sizes of iPads.
Github- Github is a reliable way to store and share our code.
Google Docs- Google Docs is a reliable way to store and share our documents.
Expected TimeScale of Checkpoints
-Alpha Build (4 weeks)
-Basic prototype with full game dynamics
-Beta Build (4 weeks)
-Add polish, art assets, juice, powerups