Jump to content
Sign in to follow this  
  • entries
    28
  • comments
    110
  • views
    40253

Pipe Mania

Sign in to follow this  
Poo Bear

1167 views

-------------------------
Poo Bear - Programming
-------------------------

This game has been worked on as a pet project for years on and off, so the first job was to replace the prototype world code with something more robust and stable so that objects could collide, fall and support one another when stacked. Once that was working I could start to use the collision system to push objects around properly.

I've implemented about 6 different types of robot so far, the idea is to make each one look and behave uniquely. Some are very simple like the patrollers that just move back and forth in a straight line between obstacles. Others are more complex like the stalker that comes straight after the player and circles around any obstacles that might get in the way.
Mr Robot: Multiple Robots
Multiple enemy robots patrol a room
(*No lighting here remember [wink] )


There are a lot of basic puzzle games and basic platform games kicking around that simply collate a large number of unconnected "rooms" in order of difficulty. I find the lack of purpose, plot or world spoils the whole experience and rarely play such games for long (apart from Tetris, fashion cents, bookworm and bejewelled of course ;) ). Classics like Mario and Sonic with a basic story, recognizable characters and a connected world are much more interesting. This is why Mr.Robot's rooms actually map together properly to make areas within a huge spaceship i.e. engineering and cryogenics. If we can build a proper little world then we have a better foundation to hang a plot from and also introduce an element of exploration and purpose.

There are a lot of bits and pieces still to put together, mundane but essential items like locked doors, teleporters, water hazards, lifts, etc, etc. Once all the bits are in place we can start to put it all together.

-------------------------
Fost - Art
-------------------------

I've been trying out a new working methodology: usually I work thus:
  • Make concept art (or model) and get any feedback.
  • Rework until I'm happy the model is heading in the right direction.
  • Finalise Model
  • UV Map
  • Texture
  • Animation (if required)
  • Any final shader tweaking and export

Generally, I've always tried to avoid the production line mentality that pervades many large game companies; I believe it stifles creativity. Of course, in large teams, this only works if all the artists are capaple of modelling+texturing+animating, and that's not always the case so you end up having to production line the whole process based on the varying abilities of your team (I've been really spoiled in the past by working with very talented art teams).

I thought I'd try an experiment though and see if I could speed up any of my workflow. Obviously I can't make much of a production line on my own :) but I can use some of the concepts. Basically I'm batching up sets of models and working on them as a group.

For example: I model 9 robot models, then I UV map them all, and then I texturing them all. This helps to some extent because I'm pretty slow to get into any particular task, and so modelling/mapping/texturing a big bunch of objects in one go helps cut out some of the time it takes me to get into the swing of things. I'm pretty sure it's helping out a little - I estimate I've saved about 2 days work so far on the robots.

The above does however mean that I go through long periods with little interesting to show: a bunch of UV mapped robots is a lot of work, but not very exciting to look at!

Mr Robot: Inferno
Inferno- HEL's chief 'henchbot'. Not a flying toy.[wink]

Mr Robot: Basic Enemy
Basic droid with simplest predictable AI (bounces between two points)

There's still some work to do on the robots because the final shader set we have agreed on isn't fully complete yet so I'll need to do a bit of finalisation work 'tarting them up' with some simple controlled reflection and texture scrolling effects as soon as Goober has a free minute to finish off the shader set.

I've also been building up a complete set of scenery for the Cryogenics zone (This is where the ship's cargo of colonists are held in cryogenic suspension). I went a bit mad adding pipe sections that can be criss-crossed and bent all about the room (Might be a bit of a nightmare to edit rooms in this zone!). I've also kept the wall edges straight this time - the storage zone walls have a slight kink in them, which means they need every part to be customised (probably a mistake on my part as it makes more work for me and makes the rooms harder to edit - but it looks nice :D ). Keeping everything straight means it's easier to put things like lift sections wherever you like.

Mr Robot: Cryogenic Zone Floors
Floor tile set for the cryo zone. These are far more complicated than the ones from the storage zone; essentially their surfaces form a complete '2D' tile set that can be used to change the floor pattern however you like (Even more hair loss when editing :D ).

Mr Robot: Cryogenics Floors Set Example
An example of the floor tiles fitting together, and a cryo chamber with sleeping crew member.

Mr Robot: Cryogenics Wall Sections
Cryo zone wall sections - there's too many parts to show so I've just built a little diorama here that illustrates how they fit together. Each pipe variation requres different bends/splits/junctions etc.

The last cryo zone image above illustrates one of our unsolved issues: we need to find some way to cap off objects at the edges so you don't see any outlying geometry. This would not have been a problem with the 2.5D isometric games of yesteryear, but we are obviously fully 3D so there's a new set of problems. I'm sure we'll think of something :D

I received an email from someone who really likes the texturing style (thanks :D ) asking if I'd show some more texture examples and how I build them up. I'm not sure how much use it will be, but I thought I'd include the Photoshop file too.

Here's a basic crate texture;
(not the most exciting of textures though!):
Mr
Mr Robot: Equipment Crate Final Composite
I try to keep highlights and shadows on a separate layer so they are easy to balance. If you fill a colour dodge layer with black it creates nice blooming effects over any colour that isn't totally pure (i.e. red slightly brightened up). This is how colour dodge layers worked in old versions of photoshop, for some reason, in later versions, if you don't fill the layer with black first it doesn't have the bloom side effect.
Download the photoshop file (700k)

-------------------------
Goober - Programming
-------------------------
Thankfully, with Poo Bear taking on the main game development of Mr Robot, I'm freed up to concentrate on our reusable engine and the Mr Robot editor. Currently my tasks revolve around providing enough editor functionality to allow Poo Bear to continue working on his tasks without having to wait around or change to something else. The editor, while somewhat clunky and quirky in its operation, is reasonably usable. Of course, there's always ways to improve its user-friendliness, but the tool is for in-house use only at the moment, so we're concentrating on getting things working and working robustly before concerning ourselves with making it particularly nice to work with. Should there be opportunity I'll improve the way things work.

On a side note, I stumbled across an entry in the MSDN describing a couple of interesting compiler switches that can be set in MSVC, /Gh and /GH. What these do is tell the compiler to call into two specific functions at the entry point and exit point of all functions in projects compiled with these flags. Use of this facility is a little bit weird because while in the _penter and _pexit functions you write, you cannot call any other functions if there's the possibility they've also been compiled with the /Gh or /GH switches, because that will end up calling back into the function you just came from and you can wave goodbye to your stack.
Why is this useful? Well, for one you can track which functions are called in your application, it's a simple matter to get the return address from the stack and fix that up so that it matches the addresses in the linker map file. It's also possible to implement a simple profiler by getting the CPU timestamp counter at the start and end of a function and working out how many clock cycles expired while in that function. Obviously it's a little more complex because you have to take recursive functions into account, but it's possible, and could be easier to work with than how we traditionally profiled our code using g_profiler.Start( blockname ) and g_profiler.End( blockname ) type calls. Explicit calls are ok, but they do require the programmer to mark the entry and every exit point of a function. By having the compiler do it for you, you reduce the possibility of silly mistakes.

What this culminated in was a very simple sort of profiler that we can use to tune our applications. Currently the output is very primitive, consisting of a function address, total clocks spent in the function, number of calls into the function and average clocks per call. What I'm planning on doing is writing an app to parse the linker generated map file and the profiler output and display the information in a friendlier way (i.e. having something resembling a function name), and being able to export to .csv file or something similar. It's not VTune, but it'll give us enough information for us to be able to pinpoint bottlenecks and work out solutions to performance problems.
Sign in to follow this  


7 Comments


Recommended Comments

Wow, that looks very good. How long have you been in development, and when are you planning to release it ? Will it be free, shareware, or fully commercial ?

Share this comment


Link to comment
Quote:
Original post by Ysaneya
Wow, that looks very good. How long have you been in development, and when are you planning to release it ? Will it be free, shareware, or fully commercial ?

Thanks! (That means a lot coming from yourself! I've been following infinity's development since the beginning and it looks awesome!)

We've been working on Mr Robot for almost a year now (I'm posting up a backlog of diaries here over the next few days), but I'd been toying with the idea of the game for more than 5 years (I love all the old Ultimate filmation games + Head Over Heels and Batman on spectrum :) ). Of course, code tends to stagnate, so there wasn't a lot of the old work that was useable, although a surpising amount of it has made its way into the game.

We should (although, it's always hard to be certain!) be releasing it early next year, and it will be shareware (I suppose that's the best description, although it's not entirely accurate these days.) We already have one game complete ( Starscape ) that we sell online this way.

Share this comment


Link to comment
That's very nice. I thought of mentionning Head Over Heels in my previous post, but i thought nobody would know what i'm talking about. It was one of my favorite games on my old Amstrad CPC. I've even recently installed a PC remake (with better graphics, but same gameplay, levels and puzzles). I'm always nostalgic of this kind of games. They're quite simplistic compared to today's blockbusters, but they're always a bowl of fresh air to me.

Share this comment


Link to comment
Quote:
Ysaneya Wrote:
That's very nice. I thought of mentionning Head Over Heels in my previous post, but i thought nobody would know what i'm talking about.

Probably the greatest example of that genre ever, and has big fanbase amongst anybody who was around in the 8bit era I'm sure.
Quote:
Ysaneya Wrote:
They're quite simplistic compared to today's blockbusters, but they're always a bowl of fresh air to me.

Yes, I think the main thing I notice these days is how punishingly difficult they are! I think we've gotten used to the way games these days often manage to ease you in and you don't need to read the manual, Hopefully this is something we can bring to Mr Robot.

Share this comment


Link to comment
Quote:
Originally post by Poo Bear, on behalf of Goober
On a side note, I stumbled across an entry in the MSDN describing a couple of interesting compiler switches that can be set in MSVC, /Gh and /GH. What these do is tell the compiler to call into two specific functions at the entry point and exit point of all functions in projects compiled with these flags. Use of this facility is a little bit weird because while in the _penter and _pexit functions you write, you cannot call any other functions if there's the possibility they've also been compiled with the /Gh or /GH switches, because that will end up calling back into the function you just came from and you can wave goodbye to your stack.
Why is this useful? Well, for one you can track which functions are called in your application, it's a simple matter to get the return address from the stack and fix that up so that it matches the addresses in the linker map file. It's also possible to implement a simple profiler by getting the CPU timestamp counter at the start and end of a function and working out how many clock cycles expired while in that function. Obviously it's a little more complex because you have to take recursive functions into account, but it's possible, and could be easier to work with than how we traditionally profiled our code using g_profiler.Start( blockname ) and g_profiler.End( blockname ) type calls. Explicit calls are ok, but they do require the programmer to mark the entry and every exit point of a function. By having the compiler do it for you, you reduce the possibility of silly mistakes.

What this culminated in was a very simple sort of profiler that we can use to tune our applications. Currently the output is very primitive, consisting of a function address, total clocks spent in the function, number of calls into the function and average clocks per call. What I'm planning on doing is writing an app to parse the linker generated map file and the profiler output and display the information in a friendlier way (i.e. having something resembling a function name), and being able to export to .csv file or something similar. It's not VTune, but it'll give us enough information for us to be able to pinpoint bottlenecks and work out solutions to performance problems.

We need an article on this, if and when you've got the time. I'd be more than willing to do the heavy lifting in terms of writing the article up in English, but a distillation of your experiences would be very useful to the community.

Share this comment


Link to comment
I'm still getting though our backlog so we are a few months behind with these diaries. Since finishing off the engine code and tools for us, Goober has moved onto bigger things, and has a job writing an engine for Xbox360 and PS3 :).

The timing code was useful at the start to him, but everything seems pretty stable now and it's not something I have any personal experience with, so I'm not sure what I could say that would be much benefit.

We do have some friends who developed the same thing much further than we ever did though. I'll get in touch with them and see if they are still using it. :)

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.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!