Posted: Mon Apr 03, 2006 3:12 pm Post subject: May-06: The Sentinel Returns
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.
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.
Airlock open: simple effect using stretched particles.
Last edited by Fost on Fri May 05, 2006 3:49 pm; edited 18 times in total
Joined: 14 Oct 2002 Posts: 4121 Location: Sheffield, UK
Posted: Wed May 03, 2006 9:22 am Post subject:
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 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). Refactoring something means to either rewrite it completely or to rewrite parts of it to improve the overall implementation. 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?
Joined: 08 Nov 2005 Posts: 556 Location: Bergen, Norway
Posted: Sat May 06, 2006 10:39 pm Post subject:
Great update again!
I feel kind of guilty for mentioning the menus in Starscape now. I know I don't have to explain myself since this is obviously something you've been thinking about before, but I feel the need to tell you I always thought they were functional enough, it was just the graphics and music that sort of irked me.
But, like you said, people have different tastes in music, so that's really not a good point (Woah. Deja Vu. I must have said that before here on the forums some time in the past. That, or there's a glitch in the Matrix... Oh no... Those MONSTERS! They've turned my tea into... COFFEE! *******!) but you know how it is.
The graphics look great as always, and the tech talk seems interesting as well. Again, I'm really happy about these insights into the different processes of making a game. Seems like a lot of this can be transferred to other kinds of projects. I really do hope you release them all as a PDF or something in the future, or maybe in printed form in some sort of Collector's Edition of the game (if you ever get really bloody huge.).
EDIT: About the possibility of making your own adventures, can you create story-bits, etc yourself as well as in creating a full story for it with dialogues etc?
What really sets Mr. Robot apart from pretty much every other game I've ever seen (including games from big studios with mega-budgets) is its unique almost hyper realistic "toy" like "feel" to the graphics. What I am trying to get at is the objects in the game, robots, consoles, etc. have this amazing toy like quality to them. Like say the amazing articulate robot toys you can buy, which are based on Jap Anime. When you look at them, you instantly feel the need to acquire them. Or the same effect Lego used to have (when they used to come out with really cool space craft leog stes). You just had to have them instantly. http://en.wikipedia.org/wiki/Lego_Space
I'm sure I haven't been able to explain it properly as I'm too drunk.
Anyway, the colors, the ambience of the environment, the articultae robots, all make me feel like putting my hand through the screen and touching them and playing with them. Again, I think I have failed in trying to get my point across.
There is some sort of visceral attraction to the art in Mr. Robot. Wouldn't my fellow forum members agree?
Keep up the excellent work. Ofcourse, it goes without mentioning that I'll be among the first in line to purchase Mr. Robot.
Joined: 15 Jun 2003 Posts: 177 Location: The Thirteenth Colony
Posted: Sun May 07, 2006 2:38 am Post subject:
The UI and the RPG will definitely be a hands-on thing before i can make any sort of solid comment on them. Just from experience though, a rpg can go from interesting and challenging to tedious and boring if not done right. Especially if the game is level based and you just spent an hour gaining enough money to buy randomsword3 and gained 18 levels in the process. This makes the next bunch of encounters a sort of button-mashing let-me-through-to-the-boss-so-itll-be-all-over ordeal that can put you off the game.
And on a tangent of a tangent related note, two pixel text doesnt display in firefox. Not a big deal warranting any attention, more of a fun fact of the week.
I feel kind of guilty for mentioning the menus in Starscape now.
Don't feel guilty - we agree! The UI is ok, but it was originally designed to work in a console manner, and so doesn't have any abilities you'd expect on a PC like tabbed menus, drag and drop etc. It was also designed around the screen being 640X480 (again, console compatible) and so looks a little bit filtered at 800X600; this might be something we can fix for 1.6 though. It was a major oversight on our part (we'd just come off xbox development, so you'll have to forgive us) but if you use it with a pad it makes more sense. I know that Poo Bear would like to redo the entire UI from scratch, but that's such as huge job I can't see it happening unless we become independently wealthy ;at which point, I think rebuilding Starscape just for the fun of making it updateable would be high on both our wishlists.
Mr. Robot still has some 'legacy' issues with the ui system that Poo Bear has been wrestling with, but this time it's been going through more iterations of the design process.
About the possibility of making your own adventures, can you create story-bits, etc yourself as well as in creating a full story for it with dialogues etc?
Right now, that's impossible because all dialogue is divided into conversation chunks with unique identifiers and stored in a single file. We have to do that so that we can support multiple languages. The conversation is launched by it's ID via a lua extension.
It 'might' be possible to write another function that takes a string rather than an ID and just displays it directly. It would mean you couldn't do a translation without replacing all the room lua scripts, but I'm sure multi-language functionality wouldn't be hugely important on anyone's wishlist.
I'm not sure there's any other way we could do it that would be flexible enough to write a story other than by using the lua scripts, because they give you the functionality to launch the conversation when certain criteria are met. I recognise that being able to write your own story would be a huge draw (Even I would be excited about it ), so it's something at the top of my update wishlist. It all depends how much time it would take for Poo Bear to write it though - there may be complications, for instance: lua scripts are only 'aware' of the current room, and (I think) global variables are hard coded between them in order to share data. So, we might also need some kind of global 'adventure' lua script.
I'm wondering how many people will be interested in utilising this functionality. Writing lua scripts gives you great flexibility, but of course, it's not for everyone. If enough people become interested, then there'll be reasons enough for us to support it with specific updates that address the needs of adventure writers.
Here's an example of a lua script in action, the startup script from the first room:
-- asimov is frozen, effect plays on his head,
-- he wakes up, hel tells him to get to work,
-- player gets control
--SET UP GLOBAL VARIABLES
g_timer = 0
g_state = DOWNLOAD
if( g_state == DOWNLOAD ) then
--stop him and wait a tiny bit
overrideAsimov( true )
sendMessage( "h1r1dummy", "SYSTEM", "WANDER", "2,0,7,0,7,8" )
g_state = INTRO_EFFECT
g_timer = getTime()
elseif( g_state == INTRO_EFFECT ) then
--play an effect on his head if( not timerExpired( 500, g_timer ) ) then
Asimov = getDynamicObject( "PLAYER" )
x, y, z = getDisplayPos( Asimov )
launchEffectSimple( x, y, z, "asimov_brain_download" )
g_state = START_CONV
g_timer = getTime()
elseif( g_state == START_CONV ) then
-- wait for the effect to finish if( not timerExpired( 3000, g_timer ) ) then
end -- play a conversation
name = "T01_asimov_wakeup"
playConversation( name )
g_state = WAIT_CONV_FINISH
elseif( g_state == WAIT_CONV_FINISH ) then
-- when the conversation finishes release asimov if( isConversationActive() ) then
overrideAsimov( false )
I've greyed out the unimportant bits; they set up shared variables and can be ignored for the purpose of discussion.
The rest of it looks complicated, but you can break it down as switching the room between various states. If we look at the function called 'sequence' - this is a special function which is executed every frame (think of it like 'main' in C++).
We can break it down like this:
If we are in the 'DOWNLOAD' state
This is the startup state. So we lock the player controls.
We set another robot (h1r1dummy) to wander about betwen defined points.
Lastly we set the state to 'INTRO_EFFECT'
if the state is 'INTRO_EFFECT'
We wait 500 milliseconds
we get the player's position
We run a particle effect at the player's position
we set the state to 'START_CONV'
if the state is 'START_CONV'
We wait 3 seconds (time for the previous particle effect to finish)
We run the conversation with ID "T01_asimov_wakeup"
We set the state to 'WAIT_CONV_FINISH'
if the state is 'WAIT_CONV_FINISH'
we check if a conversation is running
if it is not, we enable player controls.
Joined: 08 Nov 2005 Posts: 556 Location: Bergen, Norway
Posted: Sun May 07, 2006 4:39 pm Post subject:
Wow! Big, nice reply! Sounds pretty cool. I'd be interested in creating full stories in the game if it were made possible, though I've a long tracklist of unfinished projects, so I'm not sure I'm the best person to listen to.
Not a big deal warranting any attention, more of a fun fact of the week.
In Opera, you can specify the minimum font height. Bleh!
Oh, and I disagree with Imadoki on the graphics. Well, I think they rock, but I've stated this several times before. What I mean is that I don't think they necessarily look that ultra realistic, and neither do I think they look like toys. I think you've managed to do one of the most difficult things in game graphics; You've managed to make it unrealistic in a way that looks very believable. Like how, in a certain game I've compared you with before, characters wield gigantic hammers and armour, yet it looks natural. You don't really go "Hey, that's not very real.", and yet the game draws you in and just looks like reality anyway. like how, in Pixar films, they are ABLE to make things photo realistic, but they opt for making it looks a little bit extreme, which somehow ends up making it look MORE realistic than the less extreme stuff.
I think The Incredibles looks much more "real" and natural than what Polar Express does, and even more than that Final Fantasy film does. Maybe it's because we KNOW it's not real, so when you try to pretend your film/ game/ whatever is real, it just looks strange and unnatural.
Am I making sense? My point is that Mr. Robot looks real in an unreal way. That's part of what I like about it.
If the editor gets released then I'm sure you'll be able to use lua scripts. They work now - you just make a file called 'room name'.lua and it automatically uses it - all you need is a text editor
The trouble is - how many people will be interested in that level of scripting? and what could we do to make it easier (I'd have thought the easier it is, the more likely people are to use it). There's probably not a lot, and writing some really comprehensive tutorials and example scripts is possible all we can do.
The trouble is - how many people will be interested in that level of scripting?
I sure would be. Heck, if I could play with Archnid AI, I'd have done it six times over by now.
and what could we do to make it easier (I'd have thought the easier it is, the more likely people are to use it). There's probably not a lot, and writing some really comprehensive tutorials and example scripts is possible all we can do.
Personally, I wouldn't require any more encouragement than "Save your script here and press this button to load it. The main game interface can be determined from existing scripts. Lua.org has language documentation." I doubt I'm a typical case, though.
By the way, I really appreciate these dev diaries. It's fun to get a glimpse of what game development is like.
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum