FAQ Search
Memberlist Usergroups
Profile
  Forum Statistics Register
 Log in to check your private messages
Log in to check your private messages
Moonpod Homepage Starscape Information Mr. Robot Information Free Game Downloads Starscape Highscore Table
Apr 05: LUA Killed My Inner Child...
Goto page 1, 2, 3  Next
Post new topic   Reply to topic    Discussion Pod Forum Index -> Developer Diary View previous topic :: View next topic  
 Author
Message
Moonpod Developer Diary RSS feed -RSS Feed
Fost
Pod Team
Pod Team


Joined: 14 Oct 2002
Posts: 3734



PostPosted: Fri Mar 03, 2006 10:24 am    Post subject: Apr 05: LUA Killed My Inner Child... Reply with quote

Hub

As seen last month in placeholder art form, here's the final Hub Room (hopefully an improvement Wink )

We always thought it was important for the hub to be something special, and so every piece of art used in the hub is unique - you could even make a zone out of it if you wanted. Also all the control panels have little animated sections embedded in them. Some things just put a smile on your face when you see them, and all the robots walking around in the hub do that for me Very Happy

Mr. Robot: Command Hub

Decals

We are also starting to use overlay decals on the floor all about the game. These use a 'modulatex2' screen blend mode - basically grey does nothing, white doubles the brightness of whatever is behind it, and black goes black. We can drop these all over the floor to break up the regular patterns a little, and because they use a multiplicative blend mode, they work with whatever lighting is affecting the scene behind them. In the hub they are used to put the Eidolon Insignia on the floor, and zone symbols next to the doors. I'm working on more signage for the rest of the ship - it's something I've wanted to do for many years (wow, I'm sad!) after I saw the fantastic amount of background detail Ron Cobb put into the ship signage for 'Alien'. Ron Cobb has to be my favourite designer of space ship paraphenalia, and he's been a huge influence on me.Mr. Robot: Eidolon space ship signs




Top Tips!

This month's mini development tip - Since identifying one of my biggest time losses as being the act of finding files I need on my machine, I've discovered a quick way to get through files alphabetically. When browsing a folder, I always knew you could press any key on the keyboard to skip to that letter, but what I didn't know was that if you press another key quickly enough, it will skip to the first file beginning with that two letter combination. E.g: if you were searching for a file called 'needle.tga' you would press 'n' and 'e' quickly. Great when you are trying to get to one file in a folder full of hundreds. Probably been in Windows since win3.1 and everybody knows, but it was news to me Smile


Seizure Robots

The whole mindcore zone is now starting to look extremely flashy, blinky and stroby (if that's a word Smile ). I really wanted to give the mindcore the feel of the ghost hack rooms; since this is where the two games finally come together. So that means lots of time spent fiddling about with texture animation and vertex shader values. we aren't doing anything particularly clever here, just lots of multi-layer texture scrolling combined in different ways. Take the following wall section from the mindcore as an example:



All the animation is created by scrolling this sinewave texture:
Mr. Robot: Filled Sine Wave Texture Animation
horizontally through the model. The texture is scaled massively along its horizontal axis (u) and scrolled incredibly fast. Each vertical bar is offset slightly and scaled differently so they all flick at different times.


Ghost Hack Sentinels

I've finally started to work on the enemies on ghost hack. They all use lots of morphing animation and texture animation (pretty much like all the backdrop scenery in ghost hack), so they take quite a while to make. Since we are supposed to be inside the ship's computer in data form, everything is represented by abstract shapes, including these attack programs which act like antibodies; cleansing the system of any unwanted intruders (i.e. you Smile ). Here's some animations of the current 'wait' states of the models.

*Note: you'll have to excuse the occasion flick in these flash animations - whilst the models loop in game, it's impossible to line everything up for a perfect looping video.




Controlled Specular Highlights
For a while, we've had a problem where specular lighting doesn't work in the game, but does in the viewer. It turned out to be the camera position being passed through to the vertex shader differently. Now specular highlights are in, I've gone through and re-exported all the robots so they have an alpha map that controls the reflection. In today's world of self-shadowed normal mapped per-pixel lighting this is a pretty aged technique, but I've always liked having the ability to separate out the specular lighting and control it using texture alpha. You can get a kind of controlled metallicism, and it can all be done in one pass. Basically we are now doing:

Stage1: diffuse lighting, Modulate2x with the texture. Pass through texture alpha to the next stage.

Stage2: specular lighting, modulatealpha_addcolor with current.

So, the texture alpha controls how bright specular highlights are. I think there may be some really old cards that don't support 'modulatealpha_addcolor' mode, but they are pretty much prehistoric. Smile
Pretty subtle result, but I like it, you probably can't see a massive difference in the shots, but it looks best in motion.

Mr Robot: Diffuse TextureMr Robot: Specular ControlTextureMr Robot: Specular Highlights OffMr Robot: Specular Highlights
Colour MapSpecular Control MapWithout Specular HighlightsWith Specular Highlights


I've constantly been surprised how well the lighting has turned out in Mr. Robot; now that it's possible to use high polycount models, there's far more subtle light differentiation across a mesh.


Last edited by Fost on Tue Apr 04, 2006 10:51 am; edited 27 times in total
Back to top
View user's profile Visit poster's website
Poo Bear
Pod Team
Pod Team


Joined: 14 Oct 2002
Posts: 4121
Location: Sheffield, UK



PostPosted: Fri Mar 31, 2006 10:16 am    Post subject: Reply with quote

We Just Clicked...

Stopping any sound effect sample at the wrong point can always generate a popping noise. What I normally do is fade a sample out over a few frames rather than stop it immediately, which seems to do the trick. However, we came across a problem with a fews samples - during normal playback they would loop perfectly, but now and then we could hear a popping noise. It turned out that this was caused as the sample started up; because the sample wasn't at zero amplitude at the loop transition, on start it would go from nothing to high amplitude instantly and cause a pop - even though it otherwise looped perfectly. We had to fix this by changing any sample loops to transition round zero amplitude.

Sample Loop with clicking
HIGH AMPLITUDE TRANSITION: This loops fine during playback, but clicks when it initially starts up.


Sample Loop with no clicking
ZERO AMPLITUDE TRANSITION: The sample now loops and starts up without clicking.

The Dark Side Of Scripting

Scripting allows you to control the flow of the game via extrenal text files containing Lua script. This means you don't have to re-compile the game code to change something. Great. A scripting language is said to be "higher level" than C++ which in itself is higher level than C or assembly or machine code. What that actually means is it takes less code at each higher level to do the same thing and you move away from the hard details of how something is done and begin to focus instead on what you want. The result is code that gets slower because you are relying on the compiler or other libraries to interpret what you've asked for and actually do something. So an assembly language program might require a thousand lines of code to do something, whereas a script might do it in two lines, but the assembly language version could be 10-100 times faster.

Of potentially greater importance is the time to get something working. There is a saying, if you have written more than 50 lines of code then there will be bugs and the chances of you finding every single one fall rapidly as the number of lines increases further. I've seen one example where an application was written in C++ and took 2 years to build with 100k lines of code. Soon after it was scrapped due to the inability of the authors to properly maintain and extend it. The app was redone using a scripting language in 3 months and only 5k lines of code. As the application's speed was not an issue the scripting language was more than up to the job. As computers get faster and projects get larger the speed disadvantage of scripts disappear, far outweighed by the ability to get things done quickly.

Scripting languages are also far easier to extend than C/C++ because they are typeless. What does this mean? Well typed languages like C/C++ require you to say exactly what all your variables/data are and what should be done with them before they are used. This means you end up with lots of bits of software that only work when connected to specific other bits. So you cannot just take something out of one game and use it another because chances are it relies on other bits of the current game to function and it only connects to other bits of the current game.

Scripting languages are also platform independant because they work at such a high level that they don't care about the underlying hardware. C and C++ do care about the hardware and great care has to be taken if you want to get things working on another platform.

So scripting languages are great then?

Well, not quite. Scripting languages are best described as glue. Strange term. What I mean is they cannot really do anything on their own. You have to write code in C/C++ called components, these are tools that actually make something happen i.e. display a button on screen, move your character, etc. The scripting language can glue these components together and coordinate them to make things happen. Like a conductor in an orchestra. Scripting languages aren't really setup to define complex objects, only control them. Unlike C/C++ which has powerful compilers, built in mechanisms for managing complexity and sophisticated debuggers.

So anything complicated, time critical or hardware specific cannot and should not be done in a script. All those tools need creating in components that the script can call. It's very difficult to keep your scripts small and you will very soon have a large component tool kit that quickly get out of hand.

Scripts aren't compiled like C/C++ they are loaded and executed when needed, which is both a blessing and a nightmare. Simple errors that are unavoidable only show up when the script executes. If that means travelling through 50 rooms to get to test the new one only to find it crashes due to a simple typo then you can waste a lot of time.

Scripts are typeless meaning any variable name can represent anything and there is no compiler to check what you are doing. So if you simply spell something wrong then the script interpreter will assume you want to make a new object. This object will then be automatically set to some valid default state (like zero or nil) and then everything will happily continue as though nothing is wrong. Half the time this causes a crash and half the time it doesn't, you'll just get behaviour you weren't really expecting and no obvious explanation.

Add this to the fact you have no debugger to check what is going on and you can get in very deep trouble very quickly.

It wont be too bad surely?

Still, the scripts are meant to be small and light, I'm a programmer so I know what I'm doing. It wont be too bad surely?

Part of the big attraction of scripting languages is they allow changes to be made to the game without a recompile. That implies you don't really need the programmer writing the script, I mean if I'm writing all the script why don't I just do it in C++? So now you have a very delicate error prone system being used by non-programmers. I would hope any programmer reading this would now be very scared.

It isn't all doom and gloom though:
  1. Make sure you spend a lot of time thinking about how you will debug scripts and how you can bullet proof them.
  2. Put a system in place so you can execute any new scripts as easily as possible i.e. a special menu that lets you skip to any point in the game, etc.
  3. If non-programmers are using the script then try and find tech-savy people, write very good documentation, test regularly and make sure these people stay with the project until the end as their experience is priceless.
  4. If a script has more than 50 lines in it then look at it very carefully because you probably need new component tools or to rethink the ones you do have.


Plus, even if the programmer is writing everything it is still worth considering scripts. Hard coding things into the game will have a tendency to make the game inflexible, it doesn't have to be that way, but its difficult to stop it happening. As soon as you start using scripts the tendancy will switch and it will feel easier and more natural to create flexible systems. The game becomes "data driven". This means you're creating the intruments not the econductor, he is sitting outside the game code in all those script text files. Scripts are no easy option or silver bullet, embrace them but be prepared!

What about the future?

Windows vista will ship with C# built in, this is a very powerful scripting language Microsoft created. They will also integrate it with Visual Studio which means it should have a powerful debugger just like C++ does now. C# also contains object orientated functionality like C++ which means it does have the ability to express and manage complex systems directly. It can also communicate with DirectX. All this means you could write your entire game in C# and it would run perfectly well. In theory that means you can get the same game in less time, wouldn't that be fantastic. Bear in mind that vista demands and encourages more powerful PC hardware i.e. it's a 64bit operating system with much better support for threads so all those 64bit dual core cpu's will finally get to stretch their legs properly.

There is also an update (will people see it as that?) for C++ called D, it takes a lot of advanced features from the standard template library and integrates them into the language, as well as doing away with explicit memory management by including a garbage collector. On paper it sounds great and when I heard about it I was surprised it hasn't been picked up by Microsoft or GNU and pushed harder (perhaps there are copyright or patent issues). The current implementation can call into C functions so it doesn't mean throwing all your old code and libraries away. It would be easier to use if you could call into C++ code too, perhaps that will be added one day. It is already in serious use too, I believe the new space station manager game shorthike is being developed with it, amongst others.

http://www.digitalmars.com/d/
Back to top
View user's profile Visit poster's website
Johnh



Joined: 06 Sep 2003
Posts: 160



PostPosted: Tue Apr 04, 2006 6:52 pm    Post subject: Reply with quote

I've always wanted to try out D, but never had the time. I especially want to compare it to C++ to see how much of the efficiency you can get out of C/C++ is retained in D.
Back to top
View user's profile
Fost
Pod Team
Pod Team


Joined: 14 Oct 2002
Posts: 3734



PostPosted: Tue Apr 04, 2006 7:32 pm    Post subject: Reply with quote

I'm learning some C++ in my spare time, and the things that annoy the hell out of me are pretty much fixed by D. Coming from scripting languages like maxscript and php, basic stuff like 'for each', strings, testing strings with switch statements, getting an array element count, are the things that are difficult for me to get my head round. Of course, the STL fixes most of these too, but then D does a whole lot more, and it's all built into the core language.

The big problem right now for D, is cross platform capability. Linux and Windows seem to be sorted out, and Mac is on the way, but (as far as I'm aware anyway) using D would immediately strike out any console release.
Back to top
View user's profile Visit poster's website
gnat



Joined: 12 Mar 2006
Posts: 5



PostPosted: Tue Apr 04, 2006 7:49 pm    Post subject: Reply with quote

Fantastic looking art fost! I love the look of the holograph eidolon. I also like how you implemented the decals, blending them onto the floor. Is 'modulatex2' blending part of opengl/d3d? or something you guys have created in house?

Also, I always wondered how you get the glow trail like the one shown in the 2nd ghosthack image. Is it an extruded part of the rotating triangle-shaped things, with a texture that goes transparent out to the back? Or are you using some sort of special effect/technique I don't know about?


As for Poo, I totally agree about what you said about the perils of scripting languages. I feel your pain man Mad

I've also been looking into D as it seems to look like an excellent C/C++ replacement. However i'm a little weary about the mac support offered as there is only 1 developer working on it (Although the gcc frontend does look good). If any D users here would like to enlighten a total D newb, I'd be happy to hear any comments on that.

Also, nice tip for the sound file clicking thing. I've had that exact thing happen to me before and will keep that in mind for my next project Wink

Edit: Not saying 1 developer working on a project is bad or anything. It's just that I wouldn't want to place the entire feasability of the mac port of my game on a single person who I know absolutely nothing about and has no ties to my project. If a big bug comes up that effects your project you may be waiting indefinitely for a fix
Back to top
View user's profile Visit poster's website
Johnh



Joined: 06 Sep 2003
Posts: 160



PostPosted: Tue Apr 04, 2006 8:58 pm    Post subject: Reply with quote

Fost wrote:
I'm learning some C++ in my spare time, and the things that annoy the hell out of me are pretty much fixed by D. Coming from scripting languages like maxscript and php, basic stuff like 'for each', strings, testing strings with switch statements, getting an array element count, are the things that are difficult for me to get my head round. Of course, the STL fixes most of these too, but then D does a whole lot more, and it's all built into the core language.

The big problem right now for D, is cross platform capability. Linux and Windows seem to be sorted out, and Mac is on the way, but (as far as I'm aware anyway) using D would immediately strike out any console release.


I myself am a little wary whenever whenever someone writes a new programming language and compares it to C++, showing how much prettier and easier the syntax is. But from what I've seen of digital mars' website, it seems like they have their stuff together (except their objective seems to be show that their language is better than C/C++, than to show an actual objective and unbiased comparison of D and C/C++)
Back to top
View user's profile
Fost
Pod Team
Pod Team


Joined: 14 Oct 2002
Posts: 3734



PostPosted: Tue Apr 04, 2006 9:10 pm    Post subject: Reply with quote

gnat wrote:
Is 'modulatex2' blending part of opengl/d3d? or something you guys have created in house?

It's standard fixed function pipeline stuff so you can do it any version of GL or D3D. With texture blending between texture stages, it's just written in the colorop as 'modulatex2' (this is actually how our lighting is done. Vertex colour lighting 'modulatex2' with the texture. Which allows us to overbrighten a little and avoid that drab 'PC game' look.) To get the same effect with screen blending though (how the entire polygon blends over things behind it) you have to change your source and destination blend renderstates like so:
Code:
srcblend=destcolor
destblend=srccolor

I'm pretty sure Quake II did multiple light passes this way.

gnat wrote:
Also, I always wondered how you get the glow trail like the one shown in the 2nd ghosthack image. Is it an extruded part of the rotating triangle-shaped things, with a texture that goes transparent out to the back?

Yes, that's exactly it - nothing particularly clever Smile I do have a shader that can 'lag' points based on a vertex weight, and also tint them (so you can fade them out too), but in this case it's not necessary, as the ghost trail is simple enough to animate with the model.
Back to top
View user's profile Visit poster's website
Anticheese



Joined: 17 Nov 2005
Posts: 159
Location: New Zealand



PostPosted: Wed Apr 05, 2006 4:14 am    Post subject: Reply with quote

Looking absolutly fantastic!

Could you please explain what the Mindcore is precisely? I gather its the dimension of HEL (Hehe, HAL), But do you have any more details?
Back to top
View user's profile MSN Messenger
Lothar
Starscape Jedi
Starscape Jedi


Joined: 21 Dec 2003
Posts: 522



PostPosted: Wed Apr 05, 2006 4:41 am    Post subject: Reply with quote

Sounds like an age-old mystery has been solved... since C came from B and B came from BCPL, people have long wondered whether the next language would be D or P.
Back to top
View user's profile
Poo Bear
Pod Team
Pod Team


Joined: 14 Oct 2002
Posts: 4121
Location: Sheffield, UK



PostPosted: Wed Apr 05, 2006 7:32 am    Post subject: Reply with quote

Anticheese wrote:
Could you please explain what the Mindcore is precisely? I gather its the dimension of HEL (Hehe, HAL), But do you have any more details?



It's the part of the ship that contains the main computer known as HEL, it's where the final showdown takes place and is the most challenging bit of the game.
Back to top
View user's profile Visit poster's website
Darth Dallas



Joined: 18 Oct 2003
Posts: 411



PostPosted: Wed Apr 05, 2006 10:49 am    Post subject: Reply with quote

I like that the symbols on the floor help with what direction a part of the ship is in. Ironically, the mission statement for the patch sounds like a kinder gentler mandate for the Arachnid and what they're all about.

I also like those ghost hack thingamabobs - could make some cool board avatars Smile
Back to top
View user's profile
Anticheese



Joined: 17 Nov 2005
Posts: 159
Location: New Zealand



PostPosted: Wed Apr 05, 2006 7:43 pm    Post subject: Reply with quote

The mission statement for the Archnid could be seen to be something like Expand,Exterminate,Escape.

When you think about it, The statement for the Eidolon could be seen as typically human, We all want our comforts and what Sci-Fi game is complete without a terraformed planet?
Back to top
View user's profile MSN Messenger
Flumpaphone



Joined: 18 Sep 2003
Posts: 86



PostPosted: Thu Apr 06, 2006 7:17 pm    Post subject: Reply with quote

Wow Shocked that was out quickly this month.

Another fantastic read; I would love it if they Mr. Robot diaries could be collated into a book when the game is complete. Perhaps there's a limited audience? I'd think it would be required reading for all the university game development courses that are popping up these days.


'The Making of Mr. Robot: An Epic in 3 parts'


Very Happy
Back to top
View user's profile
Anticheese



Joined: 17 Nov 2005
Posts: 159
Location: New Zealand



PostPosted: Thu Apr 06, 2006 7:53 pm    Post subject: Reply with quote

Just the dev diaries dont have enough meat in them to create a book, More like a PDF file.
Back to top
View user's profile MSN Messenger
Lim-Dul



Joined: 07 Apr 2006
Posts: 5
Location: Europe->Poland->Warsaw



PostPosted: Fri Apr 07, 2006 8:40 am    Post subject: Reply with quote

Holy macaroni! That's just pure awesomeness, guys!

The dev diary alone makes me want to preorder the game right away.

Which brings us to another question:

Will there even be a preorder package with some kewl gimmick attached to it? Like an Asimov figurine (there was a discussion about Mr.Robot toys some while ago I think)?

I'd order it even now. ^^
Back to top
View user's profile Visit poster's website AIM Address MSN Messenger
Display posts from previous:   
Post new topic   Reply to topic    Discussion Pod Forum Index -> Developer Diary All times are GMT
Goto page 1, 2, 3  Next
Page 1 of 3

 
Jump to:  
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


Powered by phpBB © 2001, 2005 phpBB Group