View unanswered posts | View active topics It is currently Sat Nov 18, 2017 6:28 am



This topic is locked, you cannot edit posts or make further replies.  [ 1 post ] 
 Project Free Fall Unit Scaling and Map Guidelines [UDK] 
Author Message
Project Free Fall Developer
User avatar

Joined: Fri Mar 02, 2012 11:57 pm
Posts: 780
Location: San Francisco, CA
 Project Free Fall Unit Scaling and Map Guidelines [UDK]
48 units per 1 meter, 48000u per 1Km

524286 units per axis as defined in ZoneInfo.uc converts to 10.9Km(6.78mi) max per axis. This is far larger than should be needed for nearly any map. For scale, Necropolis(the map included with UDK) is roughly 0.5km long. The main play area should happen inside a ~1.5km(~72000 unit) or smaller region unless the map is meant to take a very long time to traverse.

343.3 m/s or 1236 Km/h is approximately the earth speed of sound at sea level at average earth temperature(20C). That said, absolute speeds achievable from skiing should be much lower. When creating terrain or objects for skiing, start with small heights and work up; the high gravity means that velocity gained from even the smallest slope shouldn't be underestimated. If you find you feel slow when using smaller slopes, try adding some obstacles of known size to better gauge if you really are going slow, or are just not noticing the speed.

A video covering scale pretty well... Powers of Ten

The collision cylinder of the current player pawn is 88 units tall; do not take this to mean that doorways can be 88 units tall(there will be collision issues), the smallest spaces should probably be no smaller than 3m or 144u.

Using the snapping system...
1m is 3 snaps using a x16 grid or 6 at a x8 grid
2m is 3 snaps using a x32 grid or 6 at a x16 grid
4m is 3 snaps using a x64 grid or 6 at a x32 grid
So on an so fourth...

Why 48?
UDK, like every other game engine, relies exclusively on floating point for position tracking. 48u per meter allows for 10Km of play with some margin for mappers, and also plays nice with the physics system. Epic uses a similar scale(if not the same?) and 48 works well with the snapping system. 48 also has 9 factors(1,2,3,4,6,8,12,16,48) which allows for easier math.

Can maps exceed 524286 units?
Maybe? Maps definitely can exceed the limit defined in ZoneInfo if level streaming is used, but level streaming only allowed offline for UDK. A giant map that does not use level streaming might be able to exceed the ZoneInfo limit, but understand that position accuracy degrades when farther from the origin.

Should maps need to exceed 10Km?
No. 10Km converts to 100 sq Km for a planetary map and converts to 1257 sq Km for a sphere map(when proper gravity volumes come into play). Maps can be big, but they don't and should not have to be. If a 10Km by 10Km map feels small and is deemed to be complex enough to properly restrict speed, the game will likely be balanced to rein in the absolute speed.

Target upper limit for speeds...
First, I need to note I'm not talking speed caps, I'm talking balance; the maps and code will have to coordinate together to maintain the target. Until gravity volumes can allow for looping maps, map balance will be very important in properly restricting player speeds.

When creating terrain, I suggest not aiming higher than ~200kph for ski runs that only use jets and skiing. Much higher and rocket jumps are kind of meaningless. Really, speeds can be much lower than 200kph while maintaining a feeling of speed; see next session about perception.

Time, Relative Size, and Absolute Speed?
Time is everything, Absolute Speed is meaningless. Trying to keep things simple, if a player has 1 second to adjust their trajectory in one situation, and has 4 seconds to adjust in another, the first situation will be felt as faster.

Real world examples: Petter Solberg Test VS Autobahn Racing. Which feels faster?(note I ask "feels" not "is")

What does the importance of time mean to mappers? Expected player velocity defines the feeling of speed for any given portion of a map. If a map area feels slow, it's likely because the area is lacks obstacles to engage players or is just too large; if an area feels too fast, the opposite is true. Relative Size is defined by expected player speed and time.

The combination of Relative Size and Time result in something of a player reaction spectrum. If the time is too great, the reactions required are slow and boring, if the time is too small, the required reactions are punishing. A Goldilocks Time will be worked out as explore what is definitely too slow and what is definitely too fast. For a map and the game as a whole to feel good, being near that Goldilocks Size/Time ratio will have to happen often.

Due to this thread being locked, related discussions will need to happen in another thread.

_________________
"Not every idea your gonna have is gonna be great, but I guarentee you every idea that doesnt work will somehow work into the idea that does." -Derek Waters

"It's a weird feeling being borderline addicted to gaming and not having anything to play that I can tolerate at the same time." -DejZant

"No longer are you justified saying that an idea in science is not true because it doesn't make sense." -Neil deGrasse Tyson

@Saccaed for updates and randomness...


Wed Oct 31, 2012 5:56 pm
Profile
Display posts from previous:  Sort by  
This topic is locked, you cannot edit posts or make further replies.   [ 1 post ] 

Who is online

Users browsing this forum: No registered users and 5 guests


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 post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group.
Designed by STSoftware for PTF.