3D Rad - Free 3D game maker - Forum

This forum is now archived!

This forum is locked, and is a read-only version. A new community-ran forum can be found at classdev.net

News:

The 3DRad community can be found at classdev.net.

Pages: [1]

Author Topic: Beyond The Edge Of The World  (Read 670 times)

« on: December 02, 2013, 12:51:38 AM »
how many developers here have tried to make a flight simulator... or a space flight simulator... or a cross country driving or race game...

if you have, you've undoubtedly run into several brick walls... the most daunting of em most likely related to the creation of a vast, free roaming universe in 3DRAD...

first, there's the problem of creating a large scale vast landscape...  although we have an infinite terrain and ocean...  all of these are flat, repeating, featureless solutions...  no cities bordered by open plains, bounded by mountain ranges ending at a seashore... with maybe an island a few miles out...

the default terrain is only about a 3rd of a mile square... not really the vast expanse one would like to fly over in a plane... kinda small...

but even if a way to do this was somehow created tomorrow, we'd still run into another brick wall... a second big challenge...  the  limitations of 3DRAD game world, where... beyond a certain point the physics engine starts to fall apart on us and all our meshes start jittering wildly... all of our planes stop flying and just hang in space... all our cars stop rolling...

the reason i bring this up is because i've been looking at some old logic... dusting off some old code... seeking solutions for my own requirement for an expansive world to sail around in and under and to fly above, and i'd like to hear from others who are tackling something similar...

a small test those inclined might want to try...  add an airplane and a sky... a valueprint and a script to show the distance from the start point... then start flying in a direction and see how far you can go before strange things start happening...

or try the same thing with a car... use the infinite terrain resource, add a car to it... a valueprint and a script to show the distance from the start point... then start driving in any direction...

see how far you can go before the ibjects start jittering and then finally stop working at all...

post your results...

thx

--Mike
« Reply #1 on: December 02, 2013, 04:55:43 AM »
Sounds interesting; I may have to give this a go when I get the chance. I'd definitely like to see what happens if I set up something with an iFileValueWrite-type thing, then just leave it running overnight until it crashes  ;D
« Reply #2 on: December 02, 2013, 05:29:15 AM »
Man, Mike...

Quote
but even if a way to do this was somehow created tomorrow, we'd still run into another brick wall... a second big challenge...  the  limitations of 3DRAD game world, where... beyond a certain point the physics engine starts to fall apart on us and all our meshes start jittering wildly... all of our planes stop flying and just hang in space... all our cars stop rolling...

It sounds like a novel I would love to read. I'll give this a shot
« Reply #3 on: December 02, 2013, 09:36:23 AM »
beyond a certain point the physics engine starts to fall apart on us and all our meshes start jittering wildly... all of our planes stop flying and just hang in space... all our cars stop rolling...

You sure know how to make it sound dramatic!


But all jokes aside, I was intrigued by this. I took the default airplane demo, added the little distance meter and started flying. I didn't really fall out of the sky, but after exactly 10 000 meters my plane suddenly got a certain upward tendency. It steadily began to fly vertically.
I didn't have an unlimited terrain, so I couldn't actually test the physics.

But I suppose you're right Mike, 3D Rad might be a... Primitive engine.

However, I personally never came across these problems, mainly due to the fact that I've never (tried to) create(d) a game of such scale. Forest of the Undead and Rocket Rumble are both only small.
Rocket Rumble, a 3D Rad puzzle game:
http://www.3drad.com/forum/index.php?topic=9896.0
« Reply #4 on: December 02, 2013, 10:31:13 AM »
Quote
but after exactly 10 000 meters my plane suddenly got a certain upward tendency. It steadily began to fly vertically.


now try the same experiment, but add a few meshes attached to the plane rb (simulation passenger, instrument dials, etc)... you'll see a massive jittering start to appear looong before 10,000 meters distance...

Quote
3D Rad might be a... Primitive engine.
actually... i've found this to occur in other game engines besides RAD... some of the pretty advanced engines suffer from this anomoly...
i think (not sure) it has to do with the physics simulation being use...

my problem is that a B-52 (something i'm working on)  take off and climb out will take up a lot of space...  just for the takeoff phase... by the time i reach unstick speed i've already used over 2000 meters... then the climb out... at speed takes maybe 10 times that much space...

so... it looks like another case of easier said than done...  avoid out how to avoid having this happening seems my next 3DRAD challenge...   

the solution to avoiding this is obvious... make your game world smaller than the maximum distances that'll cause this to happen...

i did something a while back that i'm currently revisiting... something where every object in the game world is reset to a position inside the allowable game space (including the views) so that the illusion of traveling is still there, but the scene objects are constantly being set back to a game world center...


i'm also working on a  streaming terrain idea to go along with the bomber game... but the only idea i've got for this was a clue that someone gave me a while back in a discussion of iObjectRefresh()...

--Mike




« Reply #5 on: December 03, 2013, 04:34:52 AM »
I was also thinking of the pushing the whole environment back idea Mike, but wouldn't that cause things to jump around a bit a little when the terrain is moved?
« Reply #6 on: December 03, 2013, 08:18:32 AM »
Unity suffers exactly the same at 10km by 10km, apparently its a common floating point limit
« Reply #7 on: December 03, 2013, 09:14:43 AM »
based on some old code along these lines i've got something up and working last night...

i flew my helicopter over 32,000 meters from the world center...

actually, the chopper never went more than 2500 meters from the world center... every 2500 meters the entire world was reset... it seems to work with only a hardly noticeable flicker...

a simple algorithm keeps track of the virtual position and makes it possible to measure distances as if they were the actual measurements...

all you have to do is link any object you want tracked in the virtual worldspace (hey, that's a good name for this stuff! :) )  to the script and it is automatically tracked...

i added my NavBeacon add-on to the project and linked it to the script, and without any modifications it allowed me to home in and return back to the starting "airport" when it was wayyyyy past visual range...


right now i'm using my infinite terrain addon, but eventually (when i can figure a practical way to stream in terrain blocks) i'll replace that with 2200x2200 size terrain blocks...

also...

probably later today, i'm going to test high speed ai controlled moving objects such as a homing missile fired from a spot far away in the virtual worldspace...


still got to see how this would work in a multiplayer game as well... always something  ;D


--Mike


« Reply #8 on: December 03, 2013, 01:20:50 PM »
Sounds quite interesting...
New 3DFoundry:3DFoundry.tk
« Reply #9 on: December 03, 2013, 05:00:08 PM »
I know at one point I got a car to go 100 000m from the center when doing that test to see what the max supported speed of PCar is before falling apart. (never really found a limit, just became impossible to steer without launching it off the road. fixed with a slider joint, then I ran out of road)

I took the default airplane demo, added the little distance meter and started flying. I didn't really fall out of the sky, but after exactly 10 000 meters my plane suddenly got a certain upward tendency. It steadily began to fly vertically.

That would probably be caused by the G-force object's default setting to have an effect around a 10000m radius. Try changing it or making it follow the plane.

Currently using 7.22
« Reply #10 on: December 03, 2013, 05:38:40 PM »
I made a solar system scaled down but with to scale distance so, I'm not sure how many Rad meters it was but it was however many billion scale miles to Pluto -where light from the Sunlight Object started making SkinMeshes 'flicker'
-So there's lighting issues too I think.
3D Rad: The best abandonware ever!
« Reply #11 on: December 22, 2013, 12:37:34 PM »
@flish

 haha you visited Pluto..

I wana visit there too.. :P

Thats just one of the many project ideas i've had that will never see the light of day.

One of them was a remake of an old ANSI text game called Trade-wars

this is from John Pritchett, i believe one of the original coders of the game.
Quote
John Pritchett
Site Admin


Joined: Sun Dec 24, 2000 3:00 am
Posts: 3150
Location: USA
   
Unread post Re: Tradewars for Android and iPhone?
I recently added support for a new-old feature, running limited access games. Back in the old days, maybe even when you played, the game wasn't interactive. So you'd log in, play a few minutes, then log out for the day and hope you survive to play the next day. That's a bit more like the casual experience most mobile users are going to want. So it might make sense to focus on that game play mode. I don't see most mobile players being in a position to drop what they're doing and engage in a fight when they're invaded, and having that ability, people will feel like they have to in order to be competitive. Having limits on time and interaction may seem too restrictive, but it really is liberating in a lot of ways.

I was am totally visualizing this played in a vast 3D world created in 3Drad.

But looking at Johns comment above, i believe he has the right view on the game play, being that it may be more interesting to people that have limited time, like business people on lunch break etc..

It still gives you an interactive game play, but turn based, and time limited per day ( all of which the server host can change as desired ).

This sort of defeats the whole 3Drad world idea, well not really..

Tradewars was originally very low graphic resolution, ANSI text/text animation based game.

If the graphics were updated to 3Drads visual style, but retained the game play/ time limited, per day play style...

Well, i think it would / could be very popular indeed.

A few requirements, a server host look-up option, that allows a player to have different accounts on different servers to compete on.

The game by design is limited in size, but future versions did expand the original 500 sector universe to 1000 to 5000 sector based worlds.

The universe by design also needs to be enclosed, meaning the player can't stray out of the known universe and get lost, or required to reset to get home.

There also needs to be a player limit per game, so it doesn't get overloaded to badly which would destroy the finely balanced game play.

Game play -

You move through the universe from start sector to end sector, with only so many moves allowed per day.

You can buy more moves, with the currency you earn from trading product on each of the planets strewn all over the universe.

On each planet you have a maximum of 3 products available -
#1. Ore
#2 Equipment
#3 Food Products

Each planet has a production level that varies with each product & the amount of trading on that planet.

The universe has a Bully race called the Cabel, they roam around the universe fighting with players space ships, stealing there cargo, and even killing a player forcing him to start over .

There is 1 super roaming planet ( call it what ever name ) that when found all most always has enough cargo and all free, to fill your ship up.
The trick is finding it, because it moves every night during maintenance.

Maintenance is a nightly script process that updates the world system, calculates the planets cargo manufacturing , the Cabel  battles , causality's etc.

The project needs to lock out players at some point before the maintenance run to guarantee the universe is updated before each daily play.

There's more to it, but i think you get the idea..

Image the 3D graphics as high resolution worlds and time warp type graphic as your ship is traveling from sector to sector, once you arrive, you may find a squad of Cabel waiting to fight you, or another player, who you may also engage in battle, maybe killing him or just harming him and stealing his cargo.

Or you may be killed, or just injured, and loose some or all of your cargo.

An ideal play would allow you to find a sector, that's somewhat hidden, where you can park at night ( not gona reveal the exact detail here, you need to learn this in the game to help extend your life), that has a planet with good production levels.  You would order a squad of your fighters to defend this sector & planet, to keep it all for yourself.

This is basically the goal...

Roam the universe, trading on found planets, to make money, to buy fighters to defend sectors or groups of sectors.

When any given player, reaches a "value" level ( total universe's defended by total number of fighters, planets value in those defended sectors ) they win the game.

The game ending type is selected per server, and can be -

#1; Time based ( most valuable player when time runs out wins)

#2: First to reach a Value level wins.

#3: Unlimited ( the host decides when to manually reset the universe, the most valuable player wins at that time )

Using #3: style, the host usually will send a game wide message alert, warning the game will be reset in 1 week from today @ 2:30pm PT.

( this is done by the nightly maintenance script, which prevents the host from helping players who maybe ahead in the game, so others at least have a chance to play harder, knowing the universe is ending really soon :P ).
« Reply #12 on: December 22, 2013, 03:18:10 PM »
Best way to overcome this is ... scale. Set at default like stated the 3DRad terrain is kinda small. Well just scale all your models as small as possible without detail loss so the terrain actually grows larger. this is the trick used by Rockstar for the vast open world games of the GTA series. you can make the standard terrain go from a kilometer to 100 kilometers this way.
 Think of it like ... "Honey I Shrunk the kids" the back yard went from a small plot to a huge jungle.
"This town is infested with Killer Cockroaches!"

You have 3 options: Good, Fast, and Cheap. Pick TWO.
« Reply #13 on: December 22, 2013, 04:40:16 PM »
Quote
Well just scale all your models as small as possible without detail loss so the terrain actually grows larger. this is the trick used by Rockstar for the vast open world games of the GTA series.

yeah... i tried this a while back think it was the first thing i tried to get more room... for some reason it didn't work out... i cant remember exactly why right now...

--Mike
Pages: [1]