• 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
  • entries
    7
  • comments
    17
  • views
    9781

So I created a universe with 10,000,000 stars today...

Sign in to follow this  
Followers 0
NickUdell

1173 views

Surprisingly it actually kept running interactively without stuttering for about five minutes before crashing. According to google our galaxy contains about 300,000,000,000 stars which is only 30,000 times more than what I've got! Not bad, if I do say so myself. Of course, really this is a limit on objects in general, as my universe won't just be made of stars. There'll be planets, asteroids, rings, nebulae, supernovae, etc.

Looking at the stats it took up approximately 12 gigabytes of RAM. I can probably optimize that later a little bit. Not to mention the fact that probably only 1/100,000 of that was on screen at any one time (draw distance was set to about 10,000km), so some sort of off-loading to disk would be best too. Maybe I'll work on that next, I've never done compression before - could be interesting. Anybody out there know any good articles on compression techniques?

Might publish a proper journal entry tomorrow about the gravitation system and the octree, if I have time. I'm also meant to be going to a ball with my girlfriend.

0
Sign in to follow this  
Followers 0


4 Comments


Or you could generate it in little chunks on demand.
We ([url="http://pioneerspacesim.net"]http://pioneerspacesim.net[/url]) do galaxy generation a "sector" at a time and keep a cache of local sectors to avoid regenerating them. The local cache is only 3 sectors across at the moment but should probably be bigger :)

Anyway, it means you are only generating what you need - when you need it, and you can easily generate more as you scroll across the map etc.
0

Share this comment


Link to comment
That's a good idea, the only struggle will be correctly applying gravity to the offloaded chunks so they don't whizz off in weird directions.

Although if I apply gravity currently using Bayes-Hut, then I can reverse the process and apply gravity to an entire OctreeNode and then when I load chunks from inside that node, I apply the total gravity to it. It won't be exact, but it should be fairly close, and will drastically increase the potential universe size.

Now all I need to do is work out some way to make a skybox out of the major celestial bodies from the off-loaded chunks. And make it quickly too...

EDIT: The more I think about this, the more I think it might be perfect for Pigment. I previously wrote a simple Managed DirectX Minecraft clone (just infinite procedural block terrain using 3D perlin noise - nothing too special) that offloaded and reloaded chunks, so a lot of that code can be borrowed.
0

Share this comment


Link to comment
that's a lot of stars! Even if the player can see a different 1/100,000th of the objects each second it would take them about 28 solid hours to see them all, so generating on the fly is probably a good move if only to prevent the generation of stuff some players will never see/visit.

Have you thought about a brightness limit for rendering rather than a depth limit? Nearby planets and dim stars might be too small to be seen, but a really bright supernova you might be able to see from the other-side of the galaxy? If you use any kind of depth limit you end up drawing a lot of invisible objects, and not drawing a lot of very bright ones that should be visible.


"That's a good idea, the only struggle will be correctly applying gravity to the offloaded chunks so they don't whizz off in weird directions."

Could you get away with not simulating gravity between stars? I am not certain but I suspect the movement of distant stars relative to one another through gravity, given the sheer distance between them typically, is so slow that no-one will notice if they were fixed. I guess you'll have to test it once you increase the distances to see if having it on/off makes any noticable difference.

Also here's an issue you might be aware of already but it's probably critical for what you are doing given the severely large distances you might work with:
[url="http://randomascii.wordpress.com/2012/02/13/dont-store-that-in-a-float/"]http://randomascii.w...hat-in-a-float/[/url]

If you scroll down there's a table that shows the precision drop-off when using a float to store distances in meters. It mentions that at 1 billion meters, 1.4x sun radius, you only have precision of 64 meters. So you can't increase the value of a float holding 1,000,000,000 by less than 64 meters, preventing you from perhaps accurately moving ships or slow objects. Could be catastrophic if you try to move something 20 meters in a frame and it doesn't move at all because it cannot be represented in floating point. Using double floating point would help, but it would only delay the problem to larger distances. If you plan to represent a real scale galaxy at something like meter precision for ship movement, then storing ship/planet positions in meters relative to an origin point could result in very strange bugs later. A solution would be to store positions relative to local points (eg relative to the nearest star), or relative to the nearest "gridpoint" or something to prevent storing coordinates so big they cause precision to drop too low.
0

Share this comment


Link to comment
That's a very good point on both issues.

I've been working on calculating the correct luminance of a star / body based on its size and temperature recently, so until now I've only really had position as a framework for it. I think the issue here isn't going to be brightness though - as I intend to swap stars with billboards and eventually a single backdrop as they physically start to take up fewer pixels on screen. This then becomes more of a relation of how big the object is combined with how far away it is, as opposed to how much it flares up (which is actually done post-process, so even a single pixel on a backdrop can flare massively). I'm still working on this, so I might write a journal entry on it at some point when I believe I've found a satisfactory answer.

I hope to allow the player to actually fly at some impressively high speeds. Not only will I allow them to approach light-speed, I will also be implementing a slightly exaggerated time dilation feature so that as they speed up, the passage of time speeds up too. I'm aware that's not strictly speaking how time dilation works, but it should serve to simulate it fairly well, and be a boon to interstellar travellers.

As for positions, I think a relative position would work best. I already have the positional gridpoints stored as the centres of my octree nodes, so simply changing position to be an offset from there will save me a hell of a lot of precision, and since I don't move octree nodes (I only recalculate them occasionally), they're free to be fairly low precision. I could probably store their positions in 3 floats.

This does, however, impose a limit of using distance as my octree metric.
0

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