From Spheriki

Contents 1 Spherena 1.1 Gameplay 1.1.1 Dealing damage 1.1.2 Energy 1.1.3 Chat/Input 1.1.4 Interface 1.1.5 Problems and Solutions with Gameplay 1.1.6 Game types 1.1.7 Game Speed and Process Delays 1.1.8 Overheating 1.1.9 Bonuses 1.2 Purpose 1.3 Data Bank 1.3.1 Robot Stats 1.3.2 Transmittors 1.3.3 Items 1.3.4 Primary Weapons 1.3.5 Secondary Weapons 1.3.6 Special abilities 1.3.7 Random Formulae 1.3.8 Function list. 1.4 Menu Plan 1.4.1 Main menu 1.4.2 Demo 1.4.3 Start Game 1.4.4 Options 1.5 Creating a Bot 1.5.1 Create Bot 1.6 Editing a Bot 1.7 Coding a Bot 1.8 Bot information 1.9 Disclaimer

Spherena

Virtual Robot Warfare.

Gameplay

Quick low-down. Players create and program virtual robots. These robots then enter a virtual arena and fight to the death, generally the last one standing wins. The arena will be a square and could possibly have various terrain/obstructions. There will be 5/10/whatever rounds in a game, and bots will be given points depending on where they finished (as in who died last). The bot with the most points wins and may unlock some bouses OOHHHH! So what does the player do? absolutely nothing, all the hard work goes in beofre hand. The player is left to sit back, relax, and cheer for his bot as it marches around the arena turning other bots into scrap metal.

If you're wondering about the title, it's what you get when you mix Sphere and arena. And It is pronounced Sphere-rena. Pretty much just remove the a from arena and say each word as a syllable. I know thats not how it's spelt, but I got to name it so no complaining.

Dealing damage

Each bot has a set amount of health at the start of the game, once this health runs out, it's nigh-night R2D2. The main method of creating carnage is of course for the bots to use their arsenal of weapons. Each bot has at least two weapons: primary and secondary, these are explained below. Some bots may have a third weapon as they're special ability. Using these weapons on other bots obviously damages their health, and hopefully renders them worthless. In addition to this, bots can be injured through several less extreme but nevertheless painful actions. These include running into walls/other robots, walking overlandmines, overheating, kamikaze attacks, and they'll probably be a couple more ways as well. But the main idea is for the bots to die in a wreckage of smouldering shrapenal.

Energy

Energy, like gravity, makes the world go round. Without it, nothing would happen. In this game all physical actions a bot can do, from moving around to launching a bazooka, require energy. Without it, your bot's about as useful as your PSP after you tried to install illegal malware on it. Serves you right ;). As all bots are solar powered, they gradually absorb energy from the environment and store it in their cells. Allowing them to replenish their energy. There may also be some fuel cells lying around the arena which juice your bot up. Basically energy prevents the amount of actions a bot can take. It's there to stop a player from using every single command every single turn. It creates a more strategical game, should I find a health pack? or kill that bot? If a bot runs out of energy it becomes immobile until it charges itself up again.

Chat/Input

Along the right hand side of the screen will be a chat box for players to communicate with other players. Make the game a little more fun. I am considering allowing the player to communicate with his/her bot too, and perhaps send some instructions to it. The focus would still be on programming the bot as instructions would be limited and would take a relatively long time to input, but perhaps things like FindHealth() or Attack(). Just to give the player something to do. I'll see how it goes

Interface

The arena will cover the entire left/right hand side of the screen and will have dimensions 240 * 240 (or 480 * 480 depending on the resolution) Players will be able to visually see the robots fight in here. It will show bots, obstructions, items, walls, gun shots, mines, transmisions, laser detection, everything. It will pretty much be a visual representation of what the bots are doing. As a representation it won't be a graphical masterpiece, but rather a practical design that allows the player to easily see whats going on. Don't get me wrong though - it will have some decent graphics. The remainder of the screen is devoted to robot stats and a chat/input box. The player will be able to see the stats of all robots and be able to access more detailed information on each of them.

Problems and Solutions with Gameplay

One of the biggest worries is that the robots would not actually get into a position to fight each, i.e, that spend all day on opposite sides of the arena. This is one of the reasons why I have encouraged movement so much with overheat etc... If the bots do not fight for like 10 seconds, then they will be randomly placed in new positions on the screen in the hope that this will cause some action. This process will be repeated twice. After this, all remaining bots will be placed either right next to each other in the center of the screen, or in a miniture arena. If this produces no result, all bots will self implode and be awarded 0 points for not fighting. Moral of the story? Get out there and kick some ass.

Game types

• Derby: 8 or so bots will all enter the arena and fight to the death every man for himself. Will not have player input.
• Multiplayer: Pretty much the same as derby expect players fight other players' bots + some computer bots over the net
• Team mode: Player bots will be on teams of like 3/4. With either other player bots or computer ones. Last team sanding wins. No player input.
• Others: capture the flag, asassain, sudden death etc..., these are only possibilities, not definites.

Game Speed and Process Delays

This program will run at 60-100 fps, to be experimented with. Each robot will have a seperate value called process which stores it's "processing time". Basically to prevent super mega huge scripts which slow down the game, robots will be penalised time delays for nearly every action they take. For example, moving may have a penalty of 1, where as checking energy could have a penalty of 3, or something like that. These penalties will be added to process, and when process exceeds a set constant (ROCESS_PENALTY), the robot will be not get to act that frame. Then process -= PROCESS_PENALTY. The result of this is that the robots will have different rates of action. For example, mindless bot #1 may act 58 or 59 times a second where as super duper mega computer may get to act only 30-35 times a second. The player then has to decide between complex design or simple effectiveness. A well scripted bot may make flawless decisions, but it will probably lose to something which can act twice as fast as it. This also encourages coding efficiency on the players part. It also prevents players from checking in every direction possible in a turn and silly stuff like that.

Overheating

Because it is the bright sunshine, robots will begin to overheat if they stay still for too long due to too much energy stored. It takes ten? seconds of staying still for a bot to overheat. And once it does so it becomes worthless junk. Generally this is not something you need to worry about as simply moving each turn prevents this. It's just here to prevent bots from staying in the same spot all day and not trying to fight/kill other bots.

Bonuses

Bonuses and pickups will be located randomly around the arena when the game starts and will appear randomly as the game progresses over time. There is a list of them below.

Purpose

The purpose of this is to create a fun game whih at the same time teaches new comers a bit about coding and to encourage people to use Sphere. One of the good things about it is it will be relatively simple and provide quick results - as in players won't have to spend hours setting up a framework before they can begin creating anything, but rather just write their code and hey presto. From related projects, I know that a decent bot could be created with about 10-16 lines of code (although admitedly it wouldn't match up to anything I make ;)), but nevertheless it would be a fairly easy, hopefully enjoyable introduction to programming. And the completed project should come with a couple of tutorials/walk throughs.

Data Bank

Stores information on the various aspects of the game.

Robot Stats

These are the planned aspects and properties of robots which the player will have control over.

• Name Obviously the most important, vital piece of significant information.
• Health: When this runs out, the robot dies
• Energy: Used to move/turn/weapon/most actions, gradually recharges due to solar power.
• Armor: Protection against atttacks, weakens after attacks, can be destroyed by certain things
• Primary Weapon: Main weapon, usually a mini gun or something that. Rapidly fires for small damage.
• Secondary Weapon: Secondary, more powerful weapon. Slower attack rate, bazooka, grenade etc...
• Special Ability: Could be anything, drop a land mine, teleport to random spot, heal bot, recharge bot, etc...
• Laser Detect: The range over which the bot can detect objects, obviously the higher the better.
• Primary Ammo Capacity: Ammo for primary weapon, usually unlimited.
• Secondary Ammo Capacity: Ammo for secondary weapon, generally between 1 and 10.
• Design: The style of the robot, doesn't affect it any way, - just aesthetics.
• Color1: Primary color for the bot - again purely aesthetics.
• Color2: The bot's secondary color. - I'm not gay.
• Speed: Affects how often the bot gets to act.

Transmittors

• Basic transmittor: Transmits location information to all bots.
• Intermediate transmittor: Transmits location and a message to all bots.
• Advanced Transmittor: Sends an "encoded" message that appears as jibberish to enemies, sends location information to all bots.

Items

• Mines: Damage robots that pass over them
• Wall: Surrounds the battlefield, damage robots that collide with them.
• Health packs: Restore robots health by various amounts.
• Fuel cells: Provide instant energy to robot.

Primary Weapons

1. Mini gun: Infinite ammo, weak damage, fire rate of 1/turn.
2. Gun type 2: Infinite ammo, slightly stronger than mini gun, slower fire rate.
3. MORE TO COME, ideas welcome.

Secondary Weapons

1. Shot gun: finite ammo, relatively high, like 100?, mid strength, fire rate of approx 1/30.
2. Bazooka, finite ammo, about 3 shells. high strength, fire rate of 1/300
3. Grenades, finite ammo, about 10, mid-high strength, fire rate of 1/120
4. MORE TO COME, ideas welcome.

Special abilities

1. Fuel cell: Recharges energy fully., grad over 2-3 sec.
2. Mechanic: Fully restore health, grad over 5-6 sec.
3. Kamikaze: extremely powerful suicide attack.
4. Coolant: reduces overheat to zero. lasts like 10 sec.
5. Mine: drops a mid-high strength mine.
6. Satelite dish: Can pick up any signals from the arena, regardless of strength.
7. GPS: gives arena dimensions, and lets the bot know where it's located (allies as well?)
8. Decoder: allows the bot to pick up enemy encoded signals.
9. Escape plan #13: teleports the bot to a random location.
10. Steroids: increase bots speed for a short period.
11. Camo gear: makes bot invisible. Will become visible when makes an action. fades after a while.
12. MORE TO COME, ideas welcome.

Random Formulae

Armor forumla.

Damage = Attack Strength * (1 - (Armor * .9:Damagefactor))
Armor Damage = Attack strength * Armor * 1/3:ArmorDamageFactor)

Function list.

• Move(direction)

Moves the robot in the direction specified.
- Direction is measured in degrees and should be between 0 and 360.
Numbers greater than this will experience the % 360 operation.

• Look(direction)

Looks in the direction specified and return what it sees.
- Direction is measured in degrees and should be between 0 and 360.
Numbers greater than this will experience the % 360 operation.
- Returns a integer value which corresponds to a specific constant.
Planned results are ALLY, ENEMY, WALL, OBJECT, EMPTY

• AdvancedLook(direction)

A more specific version of Look()
- Direction is measured in degrees and should be between 0 and 360.
Numbers greater than this will experience the % 360 operation.
- Returns the actual players name/object ype instead of a generic label.
It is better, but is more costly than ordinary Look().

• GetObjectDistance(direction)

Returns the distance to an obstruction in the specified direction
- Direction is measured in degrees and should be between 0 and 360.
Numbers greater than this will experience the % 360 operation.
- Returns an integer/point? value. If it cannot detect any objects
within it's range it will return 256.

• GetLaserRange()

Returns how far the bots detection laser is effective over.
- Return value is an integer.

• GetHealth()

Returns the robots current health.
- Return value is an integer.

• GetMaxHealth()

Returns the robots maximum health
- Return value is an integer.

• GetEnergy()

Returns the robots current energy.
- Return value is an integer.

• GetMaxEnergy()

Returns the robots max energy.
- Return value is an integer.

• GetArmor()

Returns the robots current armor.
- Return value is an integer.

• GetMaxArmor()

Returns the robots max armor.
- Return value is an integer.

• GetTemperature()

Returns robots temperature.
- Return value is an integer.

• GetMaxTemperature()

Returns the maximum temperature the robot can withstand before overheating.
- Return value is an integer.

• GetPrimaryAmmo()

Returns how much primary ammo the bot has.
- Return value is an integer.

• GetPrimaryAmmoCapacity()

Returns how much primary ammo the bot can store.
- Return value is an integer.

• GetSecondaryAmmo()

Returns how much secondary ammo the bot has.
- Return value is an integer.

• GetSecondaryAmmoCapacity()

Returns how much secondary ammo the bot can store.
- Return value is an integer.

• UsePrimaryWeapon(direction)

Fires the primary weapon in the direction specified.
- Direction is measured in degrees and should be between 0 and 360.
Numbers greater than this will experience the % 360 operation.

• GetPrimaryWeaponRange()

Returns how far the bots primary weapon is effective over.
- Return value is an integer.

• UseSecondaryWeapon(direction)

Fires the secondary weapon in the direction specified.
- Direction is measured in degrees and should be between 0 and 360.
Numbers greater than this will experience the % 360 operation.

• GetSecondaryWeaponRange()

Returns how far the bots secondary weapon is effective over.
- Return value is an integer.

• UseSpecialAbility()

Activates the bots special ability. Causes different results depending
on what is choosen.

• TransmitPosition(strength)

Sends a signal from the bots position. Any bots within range will recieve
the signal: allies, and enemies, so it's kind of a double edged sword.
Can be useful in team games. Not so much in single player games - unless
your just looking for a fight.
- strength: Sets how strong the signal is. The weaker the signal, the
less costly it is to use, and the shorter it's range is. Appropriate
values are between 1 and 256. Could be very strategical.

• TransmitData(strength, string)

Sends a signal and a message from the bots position. Any bots within
range will recieve the signal: allies, and enemies, so it's kind of a
double edged sword. Requires an Intermediate transmittor.
- strength: Sets how strong the signal is. The weaker the signal, the
less costly it is to use, and the shorter it's range is. Appropriate
values are between 1 and 256. Could be very strategical.
- string: The message to send, anything from "man you're ugly" to "theres
a health pack here". Whatever you feel like.

• TransmitEncoded(strength, string)

Sends a signal and a message from the bots position. Any bots within
range will recieve the signal: enemies however will recieve a jibberish
message, so it's good for communicating with allies.
- strength: Sets how strong the signal is. The weaker the signal, the
less costly it is to use, and the shorter it's range is. Appropriate
values are between 1 and 256. Could be very strategical.
- string: The message to send, anything from "man you're ugly" to "theres
a health pack here". Whatever you feel like.

• CheckAirwaves()

Recieves signals sent out by other bots.
- Returns an array of signal objects. See below.

• signal_objects

Stores useful information on signals picked up for processing. Properties are:

signal_object.strength

The strength of the signal recieved, useful for determining position
Is an integer between 0 and 256.

signal_object.direction

The direction from which the signal was recieved, useful for determing
position. Is an integer betwwen 0 and 256.

signal_object.message

The text transmitted. A string of up to 256 characters. Common values are:
 "I'm here!" - The string sent by the basic transmittor.
 "36@4h$34" - Or some jibberish like that, value when it is an enemy
 encoded message.	

Finally an example of how to use signal_objects.

var incoming = CheckAirWaves();
//Tries to find who sent out the signal.
Look(incoming[0].direction);

Menu Plan

Main menu

• Demo
• Start Game
• Options
• Create Bot
• Edit Bot
• Quit

Demo

Plays a demo fight with 8 computer bots and 3 rounds. Just to show newcomers what it's all about.

Start Game

• Derby
• Multiplayer
• Team game
• Other
• Back

Options

• Graphic detail:
  1. Is a simple image colored differently for each of the robots.
  2. Is a mid detail image, with some flashey stuff.
  3. Is a complex two image mash, has several different stages relating to health. Uses all the special effects.

• SFX Volume
  1. No noise
  2. Low noise
  3. Mid noise
  4. Max Noise

• BG Volume
  1. No noise
  2. Low noise
  3. Mid noise
  4. Max Noise

• Framerate
  1. 40
  2. 60
  3. 80
  4. 100

• Resolution
  1. 320 * 240
  2. 640 * 480 Higher detail.

Game must be restarted after changing resolution. In Multiplayer, all players must have the same resolution.

Creating a Bot

Although players will program their bot in a text editor of their choice (hopefully sphere's IDE). The robot must be created in game, this is to set up the correct overhead and to assign it's stats. The player will have to go through 4 screens to create a bot and it should hopefully only take 3-4 minutes. To create a bot, select Create Bot from the main menu.

Create Bot

• Select Name
• Select Base Design.
• Select Primary Color
• Select Secondary Color

---

• Select Primary Weapon
• Select Secondary Weapon
• Select Special Ability

---

• Assign points to: (2*4 grid)
• Speed
• Armor
• Health
• Energy
• Primary Ammo
• Secondary Ammo
• Laser detect
• Transmittor

---

• Write Description
• Select Filename

Editing a Bot

Allows a player to change the properties/design of an already create bot. To do this just go to Edit Bot on the main menu, and you will go through the same four screens as when you create a bot. To edit the script of a bot, you must open up the script file bot.snas in an appropriate text editor and modify it.

Coding a Bot

All programming is done in Javascript, which is one of the purposes of creating this, to give newcomers some experience, and can be done using any text editor although I would reccomend sphere's IDE. The player cannot use Spheres predefined functions when programming their bot. i.e. CreatePerson(), LoadSound(). None of them will work. Instead the player must use spherena's functions (listed above). The player will be able to use the entire javascript language and functions as supported by sphere.

The players code will not be directly, but altered slightly to prevent it from accesing anything out of it's scope. Simply because it would be way too easy for the players to mess it up otherwise. Instead it will be passed through a verifier which ensures there are no syntax errors in it and does some other checks. So no cheating here. The verifier will create a seperate file bot.snae which will be opened and run when a bot enters the arena. All bots must be verified before competing. This will probably definately be the hard part.

Bot information

A Bots information will be stored in at least three seperate files, bot.snad which stores the bots stats/data. bot.snas which stores the bots primary script. bot.snae which stores the bots execution file. Each bot will have it's own folder and all of these will be stored there, as well as possibly another file which stores the bots fight stats, and a log file for the bot which shows the player what it did.

Disclaimer

Also, this is nothing more than a concept at the moment, there is not even so much as a folder for it on my computer, and there never will be!. Just joking, I intend to start on this around easter and have a working version complete via August. I've just got other things at the moment (school and the cg) and it would be unfair on them for me to start this now. If anyone has any ideas/suggestions/would like to work on it/thinks I'm crazy, then pm me - K9