by date
Collisions- how design might change approach to tools
Collisions- how design might change approach to tools
| Name: | Radoslaw Marcin Kurczewski | ![]() |
|---|---|---|
| Date Posted: | Mar 19, 2008 | |
| Rating: | 4.0 out of 5 | |
| Public: | YES | |
| Comments: | YES | |
| RSS Feed: | or Subscribe with . | |
| Profile Page: | View profile page for Radoslaw Marcin Kurczewski |
Blog post
There is one good thing in being in this business- you got to play a lot and you call it "work". Recently I've been making quite extensive research on close combat systems. During night session with Prince of Persia "Sands of time" I had one of not-so-common "designer enlightenments".
As some of you know I am quite often working with levels for various engines and various types of games. Hammer, Quark, Constructor, Max, Maya, Blender- you name it. Each of those tools enforces certain approach, has it's own pros and cons. You can divide them into two large groups- dedicated level editors and 3d packages. Now- take a look at your Torque. In 95 % of cases your level designer will be using one of dedicated editors because it gives you two very important advantages: ideal (and rather fast) collisions and streamlined workflow, checked by thousands of others that did the same thing. I'll not deny both things are important but stop for a moment and think: what's trade off.
Everybody working with those editors knows they will produce shapes that can't really be called "modern looking"- and in fact that's to be expected, I mean: take a look at history. They are tools that appeared with development of FPS shooters- very, very specific games (or clones of one game to be honest) with heavy emphasis on fast and very accurate collision detection. Torque (with all TGEA versions up to now if I am correct- unfortunately I am not a member of their dev team so I have no idea about latest relases) still shows some of traits of design foundation laid down during times of "Tribes", legacy of a fast- paced shooter made for relatively small groups of players playing by lan. Did anything changed in type of tools provided through those... 8 years ? Do not take me wrong- i am not trying to say that GG is not evolving- exactly the same can be said for many many other engine developers. "Traditional" level editors are suitable for that kind of gameplay... and for that kind of gameplay it makes sense to use them. Now- if you are looking at other genres situation is quite different. Trading off good looks for THAT precise and THAT fast collisions hardly makes sense if you want to make any other type of game. Tomb Raider or Prince of Persia action adventure (I will not even talk about puzzle games like Siberia) ? Hell, you will NEVER want to allow player to get to certain areas. Sure, you will want to give them an IMPRESSION that they do have freedom but their choice will have to be limited (or your storyline will get down in no time), same goes for their interaction with environment and it means that last thing you will want will be precise and fast collision in those areas. Collisions- sure, they got to work without any doubt, exactly as you want them (and where you want them) but certainly they do not have to be so exact, thus your choice of tools and techniques can be much wider- if you will dare to try going your own path, instead of blindly following footsteps of - no doubt- great designers that had a wonderful idea streamlined for certain type of gameplay... 10 years ago.
To cut my ranting and show something different- here's a small progress pic on Salome character. Slowly getting there...

As some of you know I am quite often working with levels for various engines and various types of games. Hammer, Quark, Constructor, Max, Maya, Blender- you name it. Each of those tools enforces certain approach, has it's own pros and cons. You can divide them into two large groups- dedicated level editors and 3d packages. Now- take a look at your Torque. In 95 % of cases your level designer will be using one of dedicated editors because it gives you two very important advantages: ideal (and rather fast) collisions and streamlined workflow, checked by thousands of others that did the same thing. I'll not deny both things are important but stop for a moment and think: what's trade off.
Everybody working with those editors knows they will produce shapes that can't really be called "modern looking"- and in fact that's to be expected, I mean: take a look at history. They are tools that appeared with development of FPS shooters- very, very specific games (or clones of one game to be honest) with heavy emphasis on fast and very accurate collision detection. Torque (with all TGEA versions up to now if I am correct- unfortunately I am not a member of their dev team so I have no idea about latest relases) still shows some of traits of design foundation laid down during times of "Tribes", legacy of a fast- paced shooter made for relatively small groups of players playing by lan. Did anything changed in type of tools provided through those... 8 years ? Do not take me wrong- i am not trying to say that GG is not evolving- exactly the same can be said for many many other engine developers. "Traditional" level editors are suitable for that kind of gameplay... and for that kind of gameplay it makes sense to use them. Now- if you are looking at other genres situation is quite different. Trading off good looks for THAT precise and THAT fast collisions hardly makes sense if you want to make any other type of game. Tomb Raider or Prince of Persia action adventure (I will not even talk about puzzle games like Siberia) ? Hell, you will NEVER want to allow player to get to certain areas. Sure, you will want to give them an IMPRESSION that they do have freedom but their choice will have to be limited (or your storyline will get down in no time), same goes for their interaction with environment and it means that last thing you will want will be precise and fast collision in those areas. Collisions- sure, they got to work without any doubt, exactly as you want them (and where you want them) but certainly they do not have to be so exact, thus your choice of tools and techniques can be much wider- if you will dare to try going your own path, instead of blindly following footsteps of - no doubt- great designers that had a wonderful idea streamlined for certain type of gameplay... 10 years ago.
To cut my ranting and show something different- here's a small progress pic on Salome character. Slowly getting there...

Recent Blog Posts
| List: | 04/05/08 - Salome- textures (at long last) 03/26/08 - Salome- UV mapping and shader planning 03/23/08 - Salome goes TGEA 03/19/08 - Collisions- how design might change approach to tools 03/07/08 - Salome and swords 02/20/08 - Dragonbane... and some mumbling 10/05/07 - Constructor... and levels 08/16/07 - Levels... and other stuff |
|---|
Submit your own resources!| Brett Seyler (Mar 19, 2008 at 08:40 GMT) Resource Rating: 5 |
| Affectworks (Mar 19, 2008 at 14:04 GMT) |
Fredrik S
| jydog (Mar 19, 2008 at 16:06 GMT) |
| Radoslaw Marcin Kurczewski (Mar 22, 2008 at 01:50 GMT) |
Affectworks- I've heard about Polysoup but looking at forums I can see Constructor growing up as well so as a person not involved in dev process (nor even knowing how it goes for that matter) I can only guess. Thanks for info- I am certainly looking forward to see it working, although I am sure you realize that no new technology is necessary to make levels with a bit less complicated collision/better graphics- we do have collision shapes and such- it might just work and Polysoup- as far as I know (might be totally off base) is going to calculate collisions for entire shapes again so it's kinda similar to BSP level editors- you're not saving on- say- celling collisions. Anyway- I am drifting away too far, let's see how it works first and judge later on
Jydog- Low poly version (base mesh, as it got rigged for posing) is about 1700 faces with no dreadlocks and/or jewelry. What you see here is high poly version with all rings and jewelry sculpted and what not and its damn heavy- about 85 000 polys :)
You must be a member and be logged in to either append comments or rate this resource.



4.0 out of 5


