Fost - Mr. Robot Art
More Ghost Hack Sentinels
The ghost hack sentinels have been eating up all my time this month. Creating the shader and moddelling them is fairly swift, but animation can get complicated. Since they are just abstract entities, some are created from a few hundred smaller primitives, which can become unweildy to animate.
- click images for flash animations...
Luckily, they only require 5 states:
WAIT | DAMAGE | ICE ATTACK | PROGRAM ATTACK | DIE
The player avatars in ghost hack need a few more: victory celebration, disabled, and they can also use items and protect themselves with virtual shields. I've now got all of Asimov's ghost mode animations out of the way, but the rest of the team are a fat slice of animation waiting in the wings :)
Content Management Server
As Poo Bear rakes over the front end, we have to discuss what direction we might take with Mr. Robot in the future. As anyone who reads the forum knows, Starscape is written in a way which makes it difficult to update, and this has severely limited the speed at which we can do things. We are hoping to make future games more easily extensible, basically because we love updating our games :). As we discussed the possibility of releasing the editor, we also talked about having a way for users to share the adventures they create. The idea is that the game would connect to the web server and download a current list of user created adventures, which you could then select and play. In turn, the editor would also have the ability to upload a user created adventure - each user having server space to store their adventures and share them with the rest of the world. A fantastic way we'd be able to support the community if there were enought people interested.
It's a great idea, but it's a lot of work. To justify the effort involved, you'd first have to assume we had released the editor with the game (still not a given, as there's a lot work to do on it to make it end-user friendly), and that lots of people start using it. There's no point having an adventure sharing system, if nobody is making adventures to share :) - more than likely when you consider that as an indie developer, we only have a limited audience (World of Warcraft has about as many server clusters as we have forum members!), and that the editor is not likely to be the easiest thing to use, having been designed for internal use only. The problem is, you can't just say "we'll do that in an update if enough people start to use the editor". Whilst that makes a lot of sense from a scheduling point of view, the reality is that shoe-horning features into a system that wasn't designed for it takes a disproportionate amount of time (see Starscape ;) ). In particular, extending or re-arranging things in the front end is a nightmare.
We realised we needed to plan for this and do the groundwork if it was ever going to be a possibilty. Poo Bear has completely redesigned how the front end works so it can support multiple user created adventures, and also extended the file updater (which we already use to get updates from within the game), so it automatically downloads files and resolves any naming conflicts. I've also set up the content manager on the web server side of things. This takes uploads from the game, renames them and saves them in the appropriate place, and adds some information about them to a database. The game can then query the server for a list of user created adventures, and create a list with a short description and picture for each adventure.
Considering this feature might not ever make it into the game, and certainly won't be in version 1, it probably sounds like a bad idea to work on it now, but if we don't do the groundwork, it would probably preclude us from doing the work at a later date.
Odds and Ends
Ghost Hacking Console- click image for flash animation...
Airlock open: simple effect using stretched particles.- click image for flash animation...
Poo Bear - Mr. Robot Programming
User Interface Design (or: The dreaded front end!)
Most programmers view a game's menu system as a necessary evil, a blip on the way to the meat of the game. The problem is the UI is the bridge between the human player and the machine, if it isn't perfect then you're damaging the gaming experience. Sometimes it isn't much of a problem as the game doesn't have much of a UI at all, just hit the go button and you're off. Then the only worry is that you've implemented an intuitive and friendly control system.
With Starscape (our last game) the UI let the game down somewhat as time constraints forced corners to be cut that with hindsight shouldn't have been. MrRobot is even more UI heavy than Starscape so this time we need to get it right. So the approach i'm taking is to rapid prototype the front end, which means to get it functional as quickly as possible, test it and then refactor it as many times as is necessary (or we can afford). It goes against the grain to throw away code, especially if you do it multiple times, but I just don't think there is any other way. This isn't necessary with everything, but some parts of the game are just very experimental and it is quite hard to create a specification without seeing something tangible and "playing" with it.
This is how the full process goes:
- Discuss what the player needs to control while doodling on a big white board, this is sometimes called brain storming. Repeat.
- Create a rough set of screen sketches on paper annotated with instructions and descriptions. Discuss. Repeat.
- Create a more detailed specification on paper. Discuss. Repeat. If the subject is familiar or simple then we can go direct to final implementation.
- Create a rough prototype implementation. Discuss. Repeat.
- Code the final implementation. Discuss. Tweak.
The "discuss" reference is critical, you must involve other people and their comments can be painful (as they usually mean more work to do). Initially I only involve Fost in such discussions as lay people cannot make constructive criticism when the implementation is very rough as they are not developers and therefore need something more tangible. As the implementation becomes more complete it then becomes essential to involve "civilians" as developers always come with preconceptions and built in understanding that "normal" people just don't have.
Here is the main ghost UI screen which is at stage 5, but still undergoing some tweaks. This screen acts as a hub, off of which hang all the other ghost UI screens.
The downside to all this is it becomes very difficult to accurately schedule how long things are going to take and in general things just do take a long time to implement.
Customising your ghost
This month I've finalised the set of core items for ghost hacking; these are the things that allow you to customise your ghosts and build a unique fighting style. The point of a turn based battle is to provide enough variety of tools that the player can make interesting choices about how to tackle the enemy; it's called strategy :). In Starscape the fun comes from learning how the ships and weapons handle and then throwing your weight around relying on your reflexes with hopefully a little adrenalin running. Ghost hacking is completely different (which is great, programming different genres is fun) the fun comes in evaluating the situation, understanding how all your different pieces fit together and then smiling as your plan works and the enemy are annihilated. I think it's a fairly obvious compliment for the puzzle based platform jumping game mode although I don't remember ever seeing another game do it? Not that I'd ever think for a minute I had a new idea, don't ever think that, never forget: "there are no new ideas, there are only new ways of making them felt" - Audre Lorde.
Anyway, the drawback is you need a rich crop of equipment and functionality with which to develop your strategies and careful balancing must prevent a single strategy always being sufficient. This is why the ghost battle system is designed to be easily extended and modified; adding new ghosts, enemies and equipment just requires editing some text files and writing some new AI with the lua scripts. So initially we just need a simple core set, get everything up and running and then add more where necessary. I expect a lot more will be added to ghost hacking after release based on player feedback.
Below is a table of what we have so far. You can see how certain functions like "energy restore" are common to different types of object. Did we just run out of ideas almost instantly and start repeating ourselves? No, there is method to this madness. Different ghosts are better at doing different things to give the player meaningful choices, but if important core functions only exist in one ghost type then all choice is removed, I have to take one. So if I decide not to take a repair bot then how do I get repaired in a battle? The answer is to slightly change your equipment and play style, search out weapon upgrades that have a restorative effect or perhaps spend more time building up cash reserves and buy off-the-shelf one-shot restoratives. Don't like attack bots? Maybe a crate of data grenades will do instead?