That’s the big question isn’t it.
Where do I draw the line as being beyond the scope of the project, determine what features need to be put in and which ones won’t work?
So to begin, BombBots is a 1-4 player game set in the virtual world of Second Life. BombBots is a real-time strategic board game.
- Real-time in the sense that the game progresses regardless of player interaction.
- Strategic in the sense that the players have to plan ahead the behavior of their bots on the board and anticipate the behavior of the bots programmed by their opponents.
- Board game in that the gameplay arena is broken down into a distinct grid (like chess). Thus implying that time and space are broken down into a set of distinct absolutes for each game (turns or clicks, and X & Y locations)
How It’s Played: Each player has access to Bots, with the purpose of detonating a BombBot on one of the 3 vulnerable squares in front of the other players. Each Bot must be programmed before being created onto the game board. Once a Bot is on the game board it is autonomous and the player has no control over it anymore. Bots are not intelligent and will only perform their program, even if that program involves running into walls, bots, or other self destructive actions.
How It’s Managed: The game system, should be self contained and reqire no constant maintenance. The game system should be intelligent to recognize it’s state and reset itself in case of abandoned games, and or give passerbys the ability to cancel an abandoned game in progess. However the admin should have the ability to configure overarching play configurations. Such as, but not limited to, pay to play settings, house taking a cut, and sweetening the pot in case of tournaments.
Object & Scripting Autonomy: Game components are to be self contained and inter object communications are to be kept to a minimun and Objects shall be aware of the game state and functionality (such as extra listens, link messages etc) shall be deactivated when they’re not needed in order to limit world script load.
Development Criteria: Everything will be written for worst case conditions, ie high lag and latency, redundancy systems will be put in place to prevent lag clicking and missed server updates. Well to the best of the ability to do so in LSL.
Feedback & Testing: Feedback from testing is high priority. Find and tweak what maintains fun and enjoyment. If it’s not fun it’s a waste of time.
That’s a good start. Any feature and or change which does not pertain/enhance the core game or the enjoyment thereof needs to be examined in great detail before consideration.
