Project Overview - Programming based game

Overview

This game aims to fill a niche market which does not compete with most professionally developed games. The target market is the typically affluent computer professional. A minimal knowledge of JavaScript is required to play the game, something most computer professionals have some experience with.

To explain the concept: consider the Mars Rovers, Spirit and Opportunity. These robots operate on another planet, but real time control is impossible as it takes ~9 minutes for a signal to reach Mars. Instead operators write out a set of instructions (a program) at the beginning of each day and upload them to the rover. The rovers execute the program throughout the day. That same concept is the basis of this game.

The player will have an API to control their robot. Things such as shields, weapons, movement, scanning the environment, following beacons, etc. will be performed by writing JavaScript code to control the robot (the player API is intentionally simple so that the player focuses on strategy, and not complex programming).

The player will also control the style of robot that they send on missions. For example they may choose a large, heavy frame capable of carrying much cargo (gathered by destroying another bot in combat for example), many weapons, contains stronger armor, but it cannot move fast. Or they might opt for a small frame, fewer weapons and accessories, but a fast moving bot. The combinations create a complex environment in which the player truly controls their strategy. Most components will use the same API commands so, for example, exchanging one weapon for another does not require complex code changes by the player.

Abbreviated Example Storyline:

I call this an example storyline because the finished product may deviate from this, but it gives an idea of its direction:

In 2090, almost fifty years after scientists had confirmed the existence of wormholes in space, the first one was finally found. It linked to a solar system in an unknown region of space. Travel through the wormhole, however, was no piece of cake. May forms of energy and radiation never before encountered ran violently through it. It was determined that earth life forms would not be able to pass through.

Unmanned probes were sent through to explore the area. A nearby planet, named Zelphi, was discovered for exploration.

At nearly the same time breakthroughs in fusion and power containment technologies made a breakthrough. This enabled just about any hot-shot millionaire to put their own probe into space. With the world economy doing well many such millionaires put together small teams who sent their own probes and equipment to Zelphi. Soon orbital communications infrastructure and on planet bases were formed on the planet via remote control. And from that natural competition and cooperation evolved to the form that we know it today.

With interference from the planet’s atmosphere, we are able to communicate with the base reasonably quickly, thus as long as our remote bots are in base we can control their activities. However, when they leave base they can only run under their own command. How well they operate on their own is up to each owner.

Game Architecture

A key feature of the game is that, as in the real world, it continues without the player’s involvement. The player may be offline, but their bot is still engaged in the game world. This is the case because the game logic all plays out on the server. Every bot executes in a 3D environment maintained on the server. When the player is online to watch the action (the player may not interact with the bot unless it has returned to base), they watch the action in real time as it plays out on the server.

The server simply fires events to the UI client to indicate what has occurred. For example, when a bot moves an event is sent to the client to update its location at a particular time. When a weapon is fired an update is sent to the client to play an animation of that weapon firing.

The client game does not require any logic, it is more like a real time movie player. It receives events to tell it what is happening on the screen at any given moment, but there is little interaction that the player has.

The game UI does provide the player with the ability to: control what missions the bot goes on, edit it’s configuration, edit the code it executes, etc. These actions all send updates to the server, but none are real time controls.

The UI is currently hosted in a flash environment (using Away3D as the 3D engine, and a combination of Flex components for the UI and embedded code editor).

The Server is using SmartFox server for the networking component, Rhino as the javascript engine, and Terracotta to enable the game to cluster to many servers as user load increases.

Attractions of the game

Below are some of the key factors that will attract and keep players

• The player’s evolution in the game is dependent on their own skill, not on how long they spend online. This will encourage players who may not play regularly to continue their membership
• Tamagotchi style play. The player maintains a robot in a continuously operating environment. When things happen to that robot the player will be notified and pulled back into the game at regular intervals.
• Both player vs. player combat, player vs. environment, and team vs. team play are all natural forms of play under this platform

Other notable features of the game

• Each bot will be part of one of many bases. These bases form a team of players that can work together, chat, and interact. Missions requiring multiple players from the same base to work together will be available, such as mounting an attack against another base, or defending an attack against your own base.
• As players progress they will be able to move to more advanced bases with more advanced missions in the surrounding areas.
• All bases execute in the same world, facilitating interaction between base players and teams, however higher level bases will be physically distant from the lower level bases.
• As players progress in level move advanced weapons, systems, and accessories will be available. The APIs that control the more advanced weapons will be more extensive as players advance. The player can choose the technologies that they invest in as they progress.

People involved (and who's needed)

I (David Parks) am the primary developer. To date I have worked alone to create the prototype, everything from the server to the UI. However I have primarily tested individual pieces. I can do all of the programming, but I am no artist when it comes to making things look good.

I am looking for a partner, which means that you have some risk up front in terms of your time, effort, and optionally, money; but, presuming a successful deployment, you will be paid far better than the equivelant full time job. On top of that you will build a portfolio of your work which can be used to boost your value in the marketplace regardless of the outcome of the project.

One or two other people will be involved: primarily the need is for someone to own the UI component. That involves creating the game UI in flash, and creating the 3D models and animation for the gameplay.

I am open to finding partners in this area from many walks of life (college, game professionals, hobbyists, etc).  I am open to someone needing to learn some components. Of primary need is someone who can develop the artistic side of the game, and who is interested in helping build the interface.

This person should also expect to be intimately involved in the evolution of the gameplay.

Financial plan

The current plan is to provide initial gameplay for free, but to limit how far in the game the player can progress. For example, limiting the level that they player can attain, or limiting their movement to a move advanced base once they’ve grown to a certain level in the current base. Once hooked, they will be required to pay a monthly fee expected to be in the range of $10 per month.

A few different options for payment, shared ownership of the resulting company, etc. are possible. While this area is open for discussion two possibilities stand out in my mind:

• Post go-live profit sharing. In this model a partner would agree to a statement of work describing their involvement and would receive a percentage of the profits post go-live for some time period after go-live (example: 30% profits for 7 years after go-live). They would not have any financial responsibility, and would only be responsible for the work agreed upon up front. Thus their involvement would be discreet and limited. Their risk of time and effort would be rewarded by a significant residual income. In this model I would assume full financial risk.
• A full share ownership. In this model partners would maintain a full percentage of the resulting company, they would be responsible for some percentage of the up-front costs, and some form of continuing involvement would be assumed as part of their shared ownership.

Screenshots of the prototype

The following screen shots give some indication of the direction of the game. However the UI designer will have control over how the final version is constructed, so this should be considered an example of features.

In the screenshot below the Base configuration is shown on the left in which the player can configure their bot based on what components they have in storage, choose which missions that they go on, engage in tournaments and other “special missions”, and configure options such as notifications. Typical actions at base are listed below:

• Send their bot on missions around the base
• Join player-player tournaments
• Join cooperative team missions
• Set up different configurations for their bot based on components they have purchased or obtained through gameplay
• Manage their level (upgrade, select new technologies)
• Purchase and sell components through a marketplace
• Edit preferences such as notification options

Below the base configuration is the inter-base chat window.

On the right is the primary game window. This will show the player’s bot as it interacts in the world. A typical heads up display will provide information about the bot, its damage, power available, etc. The only control the player has over the bot in game play is to destroy it (and thus have it returned to base at the cost of the damage incurred).

Below the game window is a system messages window. As the bot operates it may post trace messages which will be displayed here. Other system messages such as gameplay updates will be posted here.

In the next window the base management window has been closed to the left side of the screen. The gameplay window is shown on the left, and the code editor is opened on the right. The players will edit the bot code in game, and can do so while the game is playing out, or while working in the base configuration.

The last screenshot simply shows the base and code editor window open with the gameplay window closed. In the current form of the prototype all 3 windows can potentially be open on screen at the same time by simply sliding the windows open or closed (or resizing them).

The Left side shows a partial mockup of the Bot Configuration screen in which the user would select various components for their bot from those that are in their stock.

Contact info

Feel free to contact me about this project if you have any interest or questions @ davidparks21@yahoo.com