• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
fir

what scale? metric or other

16 posts in this topic

I not quite agree with the opinions that if you chose exclusive convention for defining rectangles or inclusive, or chose righthanded coordinates or lefthandet it in not to much important - this is important for at least two reasons

1) different conventions have different properties

2) it is easier to communicate if sides of communication have the same choices

 

so as to two things mentioned i chose inclusive and right-handed but 

still I am not sure what scale to chose to descript a scene coordinates in 3d

 

there are probably two main options to chose

 

1) metric coordinates where 1.0 is 1 meter

2) other than metric, (i think for example about scale where 1.0 = 1 cm,

this has some advantake that this 1 as a cm is better for my scale of details

of the things - but has disadvantage that when using this numbers need to convert something like 23300 to meters (23.3) - so i really dont know, think that maybe metric can spare me a bit of headahe (?)

 

Has some person some opinion on that?

0

Share this post


Link to post
Share on other sites

I can back #Waterlimon's advice:


Unless your application somehow interacts with the real world, there is no reason to have any units at all - let the user decide what they want 1.0 units correspond to.

 

But something confuse me:


1) metric coordinates where 1.0 is 1 meter
2) other than metric, (i think for example about scale where 1.0 = 1 cm,

 

Are you writing that 1cm is not metric? because it is. 

1

Share this post


Link to post
Share on other sites

I can back #Waterlimon's advice:

 

 


Unless your application somehow interacts with the real world, there is no reason to have any units at all - let the user decide what they want 1.0 units correspond to.

 

But something confuse me:

 

 


1) metric coordinates where 1.0 is 1 meter
2) other than metric, (i think for example about scale where 1.0 = 1 cm,

 

Are you writing that 1cm is not metric? because it is. 

 

1 cm (as 1.0) is centimetric (scale)

 

Ass to correspondency, if you make something that resembles

a real world (like car tree etc) it in some way corresponds to reality, even if you make some junk spirals or something it 

also in some way corresponds to reality so I could say 

everything corresponds to rality

 

though i see yet two options 1) that holding strict metric corespondence is good 2) that it is bad and better is to forgot

about real world matrics and made the one of yourself 

 

i hesitate beetween metric and centimetric  (the other one when 

you just call 1.0 as an 1u (unit, where there i was no stating correspondence between this unit and real world at all) i consider now bad one i was using it before but i was getting lost in it)

0

Share this post


Link to post
Share on other sites
Personally I always use 1.0 unit in my code/ data is 1 meter and degrees 0 to 360.
Keeping it simple and to prevent mistakes (ps: I'mvfrom europe).

For assets in max I therefor also use 1 = 1 meter
1

Share this post


Link to post
Share on other sites

Yeah, if you dont have any performance or other implementation dependent reason to not use 1 engine unit = 1 meter such as:

-You are simulating very small or big things (atomic level/universe), might be better to use another scale

-You have some very important element which is some specific size, might make sense to make that size equal 1.0 (eg in tile based game you might want 1 tile = 1.0 units even if the tile would not be 1 meter)

 

You should probably use meters. If you think 1 cm is better as 1 unit instead of 0.01, might as well use it for aesthetic reasons.

 

Of course, you can always use multiple different scales for different systems but that would probably overcomplicate it.

1

Share this post


Link to post
Share on other sites

Ultimately, you can use whatever you like, but unless you have a reason not to, 1 unit = 1 metre is the one that'll be least surprising to future coders that use your codebase. If your game world is particularly large/small, then use something more appropriate - e.g. my current game is at a global scale, and you can't zoom in to a more human scale (think Civilization), so I have made one unit equal 1000km.

 

Centimeters are a bit odd, because they don't fit into the pattern of 10^3 increments that are used for SI units, so if I were doing a game that was very zoomed in, I would probably go for millimeters rather than cm. Not that it's likely to be a problem once you're used to it.

 

I'll never forget the pain of having to use imperial measurements from a legacy codebase though, trying to figure out someone elses physics code is hard enough without having to deal with feet and slugs.

0

Share this post


Link to post
Share on other sites
We call them “game units” because they are arbitrary.  1 inside the game means “whatever the artists making assets for the game decided it should be.”
 
Before a project the artists gather around and the lead artist says, “Look, newbies, I’m the LEAD artist.  I OWN YOU AND YOU WILL… [insert long lecture about his or her greatness] …AND SO IN THIS GAME 1 = 1 METER IS THAT UNDERSTOOD MAGGOTS?  I CAN’T HEAR YOU.”
 
 

i hesitate beetween metric and centimetric  (the other one when 
you just call 1.0 as an 1u (unit, where there i was no stating correspondence between this unit and real world at all) i consider now bad one i was using it before but i was getting lost in it)

It’s not your choice what 1 is.  It’s up to the egomaniac lead artist for each game by each team.
Leave it alone and drop the issue. It’s none of your business, and it doesn’t even make sense that your API would itself define the length of 1. What are you planning to do with that “knowledge”? Limit the viewing distance? The only thing that you could possibly accomplish by assuming the length of 1 unit is to add flaws to whatever you are making.


L. Spiro Edited by L. Spiro
0

Share this post


Link to post
Share on other sites

Unless your application somehow interacts with the real world, there is no reason to have any units at all - let the user decide what they want 1.0 units correspond to.

It's mainly a concern for the artists - when they build a human, do they make them 1.8, 180 or 5.9 units tall (m/cm/ft)?
 
However, it also affects some of the programmers on the team too. Is the value for gravity 9.8, 980, or 32.17? When designing the physics system, what size object can you define as being too small or too large, and then be able to make the simulation behave in a stable way by assuming that most objects will be in this range of sizes? How does the audio guy implement the doppler shift on moving sound sources -- are those velocities in m/s, km/h, ft/s, etc...? The guys designing the streaming world system need to know what range of units they'll be working with -- the floating point accuracy of positions that are 10km from the origin differs wildly depending on whether you're using cm, m, km, etc... Whether or not they need to use hierarchical or 64-bit coordinate systems may depend on the choice of units!
 

So it's pretty important for everyone on a game team to have a common understanding of what the game units are. A good engine will let you change these choices from game to game though. 

It’s not your choice what 1 is.  It’s up to the egomaniac lead artist for each game by each team.

In my experience, the technology lead has made the decree of universal scale, forcing the art teams to adapt to His will laugh.png

Edited by Hodgman
2

Share this post


Link to post
Share on other sites
I believe that the game unit should be bigger than the engine unit to avoid having the camera see through meshes when very close to them.

While it is easier to define that "1 game unit maps to 1 engine unit," this would mean that if the camera is closer than one unit to a mesh (which is moderately far away), the near-plane of the camera will intersect the mesh and see through it, as usually one defines the camera near-plane distance as 1 engine unit.
In case you are thinking "why not make the near-plane distance less than 1.0," there is a considerable loss of precision with smaller values: http://www.sjbaker.org/steve/omniv/love_your_z_buffer.html

Something like "1 game unit maps to 10 engine units" will allow you to get closer to meshes with the camera, which is especially useful in case you have cutscenes with dramatic close-ups.
With a metric abstraction, this could mean that 1 game unit is 1 metre, and that 1 engine unit is 1 decimetre.
1

Share this post


Link to post
Share on other sites
One clarification: Setting 1=1cm is perfectly "metric".
 
From the Wikipedia page on Metric System:

The centimetre gram second system of units (CGS) was the first coherent metric system, having been developed in the 1860s and promoted by Maxwell and Thomson. [...]


You seem to be confusing the metric system with the International System of Units. Edited by Álvaro
1

Share this post


Link to post
Share on other sites

streaming world system need to know what range of units they'll be working with -- the floating point accuracy of positions that are 10km from the origin differs wildly depending on whether you're using cm, m, km, etc... Whether or not they need to use hierarchical or 64-bit coordinate systems may depend on the choice of units!

 

 

I do not know exactly what is the source of this accurracy

errors.. doesnt just using doubles instead of floats not resolves

them? Float indeed with 23 bit precission (8M) with 1 cm resolution should fire up over the range of 80 km (?)

(when using 1.0 as base 1 cm it could mean that indead i could use milimeters of precission too sometimes maybe so it could be

8 km world)

but double is 29 bit more (512M) so even 8 km * 512 M = 4 * k *k * k *k meters, it is compared to earth-sun distance which is 0.15 kkkk meters 

That should be enough to very large scenes 

 

can some numeric errors appear on doubles?

0

Share this post


Link to post
Share on other sites

We call them “game units” because they are arbitrary.  1 inside the game means “whatever the artists making assets for the game decided it should be.”
 
Before a project the artists gather around and the lead artist says, “Look, newbies, I’m the LEAD artist.  I OWN YOU AND YOU WILL… [insert long lecture about his or her greatness] …AND SO IN THIS GAME 1 = 1 METER IS THAT UNDERSTOOD MAGGOTS?  I CAN’T HEAR YOU.”
 
 

i hesitate beetween metric and centimetric  (the other one when 
you just call 1.0 as an 1u (unit, where there i was no stating correspondence between this unit and real world at all) i consider now bad one i was using it before but i was getting lost in it)

It’s not your choice what 1 is.  It’s up to the egomaniac lead artist for each game by each team.
Leave it alone and drop the issue. It’s none of your business, and it doesn’t even make sense that your API would itself define the length of 1. What are you planning to do with that “knowledge”? Limit the viewing distance? The only thing that you could possibly accomplish by assuming the length of 1 unit is to add flaws to whatever you are making.


L. Spiro

 

Im doing home projects so i choice and control everything on my own

 

I think choice of scale can have some psychological properties and thus is (ot at least can be) some kind of meaningfull

 

(same as choicing argument names in DrawLine(int px, int py, int qx, int qy) ;/ this is maybe mosty aesthetic but it can be important too and i like to consider things in details - you seem to suggest that it is good to out of aesthetic choices and go to raw working plane? this is some option to [but now i got enough time and coul try to get a carefull (hopefully good, though good here is not so easy definable) choices])

Edited by fir
0

Share this post


Link to post
Share on other sites

1) as usually one defines the camera near-plane distance as 1 engine unit.

1) One does?


Yeah, I'm going to question that as well. On OFP the camera's near clip was set to 0.03 (or 3cm), although the far was only set to 333.33 meters out to maintain the precision we were after. (For the 'near' pass; far pass started at 333.33 and went out much further).

(This was also a game with crazy requirements where 1km = 1024 pixels on a texture because artists; this gave us some interesting conversation numbers in the engine. Physics was largely unaffected however as they ran a different tile size and update rate to the rest of the world. As I recall they shifted 'world centre' every 512m where as the renderer worked in 1km wide tiles.)
1

Share this post


Link to post
Share on other sites

 


Yeah, I'm going to question that as well. On OFP the camera's near clip was set to 0.03 (or 3cm), although the far was only set to 333.33 meters out to maintain the precision we were after. (For the 'near' pass; far pass started at 333.33 and went out much further).

(This was also a game with crazy requirements where 1km = 1024 pixels on a texture because artists; this gave us some interesting conversation numbers in the engine. Physics was largely unaffected however as they ran a different tile size and update rate to the rest of the world. As I recall they shifted 'world centre' every 512m where as the renderer worked in 1km wide tiles.)

 

I got also terrible issues with planes flickering where card supportet only 24 bit depthtbuffer, Today i suspect 32 is absolute minimum probably,Can more be assumed?

0

Share this post


Link to post
Share on other sites
23300 to meters (23.3) - so i really dont know, think that maybe metric can spare me a bit of headahe (?)

Since 23300cm is 233m, not 23.3m, yes. Using meters will save you a bit of headache, if you do that kind of conversion in your head. Fewer conversions means fewer occasions to get it wrong. By only ever using straight SI units (no multiples, and in particular no "weird units" like feet and pounds), you somewhat reduce the likelihood of pulling a Mars Climate Orbiter.

 

The nice thing about SI is that things make sense, and things are intrinsically "graspable". Interestingly, both the meter and the kilogram were born out of political intrigues rather than science and in quite dubious times and circumstances. And still, something very sane and practical came out of it.

 

The accounts of Delambre and Méchain, who by the way did their trip 70 years before... (who are Maxwell and Thomson?), well, the guys who did the trips to Barcelona and Dünkirchen through civil wars, the Spanish-French war, partisans and rebels, and arrests for espionage with strange instruments... are well-documented, and a quite fun story, much like a Three-Musketeer tale.

It's amusing in particular because Méchain was well-known for being the most accurate, pedantic, anal-fixated living person of his time, but after having nearly completed his work, he realized that he did the calculations for the base point wrong by a few hundred meters (well, not meters at that time). So he didn't dare returning home for nearly two years out of shame. Though the difference was well outside the technical capabilities of that time anyway, nobody would have been able to tell if the prototype meter had been 0.01mm too big, nor would they have been able to manufacture it that precisely.

 

On the other hand, as long as you are firmly confident with the units that you are handling, it doesn't matter even if you use kellicams. Usually, not you will be doing the conversions, but the computer. So as long as the conversion is correct once, there's no headache.

Edited by samoth
0

Share this post


Link to post
Share on other sites

Setting 1.0 to a SI unit will not do any harm in the future, while anything else bares a risk of complications. Setting 1.0 to a centimeter, what is not a SI unit, but only its multiplications (0.01m), will for example brake Newton force unit or anything else dependant on SI (1N=kg/(m/(s*s))). You can ofcourse remultiply your application 1.0 calibration. A SI unit is by standards a second, kilogram, meter, volt and so on, and all units derive from them (force N,speed m/s, aceleration m/(s*s), and so on)

0

Share this post


Link to post
Share on other sites

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
Sign in to follow this  
Followers 0