Jump to content
  • Advertisement
Sign in to follow this  
  • entries
  • comments
  • views

Ultra Violet

Sign in to follow this  
Poo Bear


Fost - Art

Violet Zemanova

Finished preliminary work on the first of Mr. Robot's human characters: Violet Zemanova, captain of the Eidolon (the space ship on board which Mr Robot is set)

I always end up spending more time on the characters than I think I will. It's often hard to justify the time spent on them - whilst they might add buckets in terms of the atmosphere and immersiveness of a game, they generally add nothing to its gameplay. I really love working on them, but at the end of the day we aren't making movies, so I can't justify too many hours on them.

You will be able to talk to the Eidolon's command crew - who are in a semi-thawed state (there's a better explanantion of this when you play the game - it makes sense - honest ;) ), but they are essentially incapacitated and can only offer advice. Humans in Mr. Robot spend most of the game in hypersleep and so take a bit of a back seat to the friendly robot characters you meet.
Mr Robot: Violet Zemanova


Mr Robot: Nanomeks

The Nanomeks are tiny worker robots. I love Huey from 'Silent Running' and wanted to make something along the same lines :D
I also thought it was nice to continue the inspiration of ZX spectrum games
- the nanomeks remind of the robots from Ultimate's PSSST!'

Can't say with 100% certainty exactly how the Nanomeks will feature in game - we are looking at some sort of lemmings/chuchu rocket style gameplay where you have to rearrange the room and let them go.
We've yet to build the levels (I built one which I thought was easy but it proved very hard!)

HUD Work

Generally, I'm a fan of minimalist HUDS, but Mark really wanted to have something substantial looking. I was a little against the idea - the obvious thing to do with robots is have rusty cogs everywhere - which never made much sense to me as they are electronic devices, not clockwork. Eventually we came up with the idea of everything looking a bit like Asimov's Personal Data Assistant, and I made a quick hand painted mockup:
Mr Robot: HUD Concept Art

I was really happy with the result, so I've been finishing most of that of for the rest of this month:
Mr Robot: In Game HUD
hopefully it looks a lot better than the placeholder image we've been using (Mark's programmer art ;) )
Mr Robot: Programmer Art HUD :(

Poo Bear - Programming

Bug Hunting

I've been getting the first zone playable and that means crunching any bugs that have surfaced. Some can be quite subtle like the rounding error that changed the size of the players collision volume by a tiny fractional amount, hard to spot and caused some very strange side effects. Others are a bit more show stopping, but none the less fun to track down, like these:
Mr Robot: Bugs
Why is every object in the world all in one room?

Mr Robot: Bugs 2

Why is every object in the world all in one room?

If you look closely at the images above you can also spot that there are some little displays in there now, we call these displays the HUD. Whenever I see these go in I know the game is well on its way to completion.

8bit Pain

A lot of old classic platformers/puzzlers were really tough, difficult challenges and one mistake and you're dead penalties. I've seen a lot of indie titles doing the same thing and I wonder if that is because the developers remember those old titles. In general this seems out of vogue now; I think Mario64 is the first platformer I remember that really went out of its way to give you a second chance and the possibility of getting some lives back too.

There is a fine line between so easy it's boring, frustratingly hard and the nirvana of a good challenge. Different people have different difficulty thresholds so the task can seem impossible. One way of dealing with it is to provide mechanisms for people to recover health, if you cannot stockpile health and it is found slightly off the beaten track then people know that if things are looking bad they can always go back a step and regroup without having so much health everything is too easy. The most obvious game that does that is FinalFantasy and I tried to do it Starscape too.

In Mr. Robot you will have 3 lives max, if you fall into the water you lose a life and if an enemy robot gets hold of you then you lose a third of a life and get bounced away. Collecting pickups restores a third of your health and if your health is full but you have less than 3 lives then you can start saving pickups for a new life. The end result is if you take your time and back off when you get down to 1 life then you shouldn't have a problem.

Doesn't that mean the slow steady approach is always going to work and be too easy? If we were computers then yes it would, but luckily we aren't that logical. Most humans hate slow and steady, they like to take "comfortable" risks. So when people go through a room they've seen before or when they have a full 3 lives then they cannot help but be a bit more adventurous, move a bit faster and jump a bit further. When people are doing that and it works then they are having fun, the adrenalin is flowing just a tiny bit, endorphins are being released (mmmm opiates :twisted: ) and their onscreen avatar is almost dancing across the screen. If they could do it constantly without danger then it wouldn't be fun, if it almost always resulted in death then that wouldn't be fun either.

Goober - Programming

DirectX Legacy

Up to now I had started developing the 3D technology we're using against the DirectX9 API when it first came out, under the assumption we would research DirectX 9 usage figures further into the project. The hope was that by the time we were ready to release anything using it, DX9 would be commonplace, but we knew there was a chance we would have to make the renderer more backwards compatible.

Well, that time has come, and it seems our hopes have been dashed. Poo Bear pointed out some statistics (can't remember where from now, darn) that pointed to the largest number of people with Windows computers using WinXP with service pack1, and having DirectX 8.1 installed. Which means that our graphics library just plain won't work on those systems, period. This is, quite obviously, a bad thing. Backed up by evidence that most people looking at online games won't make any effort to update versions of DirectX or their drivers (unless they're forced to by WindowsUpdate), this is quite serious.

That's my cue to write a DirectX8.1 compatible renderer (as well). The idea is that we have two renderers for a while, until we're confident that everyone is (or, most people are) switched over to DX9, at which point we can drop the DX8.1 support.

First up, I took a good look at the DX9 renderer to try to isolate those parts which were platform independant, and which were platform specific. The platform independant parts were ripped out into their own library (which broke things horribly for a while, thankfully it was only broken for me, Poo Bear and Fost could continue development oblivious to the horrors I was unleashing), and now I've started working on implementing the DX8 platform specific parts. Basically this boils down to setup of the DX8 device (device/mode enumeration, that sort of thing), management of DX objects (vertex/ buffers, vertex/pixel shaders, textures) and handling of our shader files. Thankfully DX9 is very similar in API to DX8. Yes, there are some differences, but essentially they are the same, albeit with slightly different object names. Which means that device enumeration and handling of DX8 objects was pretty simple to code up. The biggest challenge now is writing a shader compiler for the DX8 renderer that is happy to accept shaders designed for DX9 and just work. Mr Robot doesn't use much in the way of DX9 specific features (such as METs or MRTs, or shader versions > 1.1), so the plan here is to have the DX8 library just drop techniques that don't fit into DX8. Inside a shader we have multiple techniques that can be used to render the object, the shader system selects a technique based on its appropriateness (is that a word?) for the platform the game is currently running on. The idea then is to provide multiple techniques that the shader system can choose from, and always providing a technique which is targetted at DX6 class hardware (fixed function pixel pipeline, two textures maximum). Based on these assumptions we should always be able to find a shader that is appropriate for the DX8 system to use, and it saves us having to do nasty translation of shaders from some gargantuan VS/PS3.0 monster down to DX6 class hardware.

The DX8 shader isn't quite done yet, there's a huge amount of code to wade through, but it's getting there. It's a shame I hadn't thought of this when I first sat down to code up a renderer for us, but I guess you live and learn. It's ok for id/Epic/Crytek etc to target bleeding edge stuff, but indies can't rely on their users having installed the latest stuff.


Besides the renderer stuff I've been supporting the editor code to allow Fost and Poo Bear to edit rooms. Mostly this consists of me fixing bugs to adding features that make editing quicker/easier, although we have finalised the lighting system, which means that Fost can go in and light all the rooms to add that finishing touch.
Sign in to follow this  


Recommended Comments

Thanks for all your detailed updates, quite interesting this inside view. Good to know you guys got such a great artist, your game really deserves these wonderful visuals.

Share this comment

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!