Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length

 
Advanced search

1027014 Posts in 41184 Topics- by 32792 Members - Latest Member: BobM

July 26, 2014, 11:14:10 AM
TIGSource ForumsFeedbackDevLogsEPIC
Pages: 1 2 [3]
Print
Author Topic: EPIC  (Read 3464 times)
motorherp
Level 2
**



View Profile WWW Email
« Reply #30 on: October 11, 2011, 02:36:15 PM »

Warning - mega text update approaching !!
Original devlog post here


--------------------------------------------------------------------------------------

Structuring The Universe


As interesting as spaceboxes and planets are, I decided I should start to spend some time laying down the framework for the game.  In particular I wanted to tackle how I would handle the structure of the game universe and it's contained entities since this would provide the foundations for everything else to sit on.  Given the scope of the game world I know that just blindly ploughing ahead with code will quickly get me in a mess and lock me out of wanted features without a major refactor, so better to have a good plan to begin with.

In the spirit of Elite, I want to create a huge game environment with thousands of different systems and planets and other objects where each entity in the game should be randomly decided upon to give a massive amount of possible combinations and variations.  Given the potentially huge scope, each system and entity should be able to be easily generated on the fly when requested and discarded when no longer needed since it would quickly become unfeasible to generate the entire universe at once at the start of the game and try to hold it all in memory and update it all at the same time.  Also, as well as being randomly generated, each system and significant entity must also be persistent such that when the player revisits them, the exact same one is generated again.  Lastly the framework should be ordered in such a way that the game is able to cope with the massive range of scales which will be present, from parsecs to millimetres, without being hampered by floating point inaccuracy issues or other such problems.

To try and achieve this I've planned on creating a nested tree of game systems which, in order from parent to child, consists of the universe system -> galaxy systems -> solar systems and deep space systems -> and finally planetary systems.  Each system will contain its children systems and a list of entities which exist within it.  Using a tree structure like this means that at any one time, only branches of the whole tree that contain the player need to be generated and stored and all other systems and their children and contents can be safely deleted.  Each system will also contain its own instance of the pseudo-random number generator (PRNG) used to determine its static content such as planets etc, and the first task of any system upon creation after determining its contained sub-systems will be to generate the PRNG seeds for those sub-systems.  This will ensure that the same static content for each system will be generated each time regardless of the order the systems are explored in and independently of what generations might be taking place in other active systems at the same time.  For generating dynamic content such as NPC trader ships and such, a global PRNG will be used instead since this is something you don’t want to be the same with each visit.  Finally, for most intents and purposes, each system will act as a separate self-contained game instance which helps me deal with the mathematical inaccuracy issues since each system can use its own scale appropriate to its size and only needs be concerned with the positioning of its own local contents.

So far so good.  With the above plan I should be able to create and populate a grander Elite style universe, but just like the original Elite it would lead to a universe that doesn't feel particularly alive or consistent in some ways.  For example, imagine jumping out of system and immediately after jumping straight back into it again.  You'd arrive to find all the dynamic content completely changed rather than similar to how you left it since the system will have been destroyed and re-created.  Similarly, imagine you follow an NPC ship after it jumps into another system by jumping to that same system straight after it.  You'd arrive to find it wasn't there since the system you jumped to didn't exist before you entered into it yourself and the NPC will have simply been deleted after it left the previous system.  Related to this problem is that I also know I wish for the player to be able to indirectly command multiple game entities that may or may not be in the same system as the ship the player is currently piloting so that they can potentialy control armies and such.

Clearly game entities in some circumstances need to have life-times beyond that of the player’s current system and need to be able to still extract information about their surroundings and interact with the system they are occupying in a sensible manner, at least for a limited time.  Thus those additional systems also still need to be created and stored in memory.  However, why bother consuming the time and resources needed to generate a planet texture, or have the NPCs' AIs calculate precise ship manoeuvres for that matter, if those things can’t be seen because they are happening in an external system the player cant see.  Therefore I've decided that systems and entities will have two levels of resolution, the macro and the micro.  All render objects and frame to frame logic and updates will exist in the micro instance and will only be generated when needed, and the macro instance will contain only statistics about the entity and high level logical updates.

To facilitate this I've come up with a list of entity statuses and associated rules which will determine when and how micro and macro level instances and updates for entities and systems are created and destroyed.  The entity statuses are:

    minor - entities that are inconsequential to the player at the current time.

    static - a special case of minor for entities which are persistent such as space-stations and planets which can store persistent data.

    significant - minor entities are upgraded to this after being actively observed by the player (through an observer status entity or currently watched witness status entity).  This status only lasts a limited time period after leaving the current scope before being downgraded again.

    witness - an entity owned by and under indirect control of the player and is therefore capable of transmitting information about its current surroundings to the player although the player cant directly view its system.

    observer - an entity capable of directly viewing its system such as the players piloted ship or remote cameras.

Each active entity will exist in its macro instance by default and its micro instance will only be active as long as there is another entity of observer status in the same system.  Similarly, systems will only have their micro instance active if they contain an observer status entity, they will activate their macro instance if they contain any entity with significant, witness, or observer statuses, and will destroy themselves and their contained entities if they contain none of the above.   Finally significant, witness, and observer status entities are all capable of spawning systems they jump into, whereas minor status entities will be destroyed upon leaving their current system.

Hopefully these plans will be enough to create a large scale universe which appears to be living and breathing even without the direct influence of the player.  Now for the hard bit, I have to code it all up.  Sorry for the big wall of text and the lack of pictures but I've been doing a lot of thinking and planning and not much else recently.

 

Thanks for reading.
« Last Edit: October 11, 2011, 03:07:51 PM by motorherp » Logged

motorherp
Level 2
**



View Profile WWW Email
« Reply #31 on: October 27, 2011, 12:07:35 PM »

Long time no update.  Most of the developments on EPIC have been in the back end recently so there's not been much to show.  Here's what I've managed to put together since last time:

  • I got the game structure I talked about in the last post implemented and working
  • I've made a first pass at a dynamic resource management system
  • I implemented a system which periodically set the camera to the world origin and repositions the universe around it.  This helps to combat render accuracy issues given the scale of the systems and how far away from the origin the player can roam.  Fortunately this turned out to be simple since I have everything structured in a hierarchy anyway so I only needed to reposition the root node and everything else follows automagically.
  • Implemented camera fades for smoother transitions.
  • Started putting together a map implementation which will allow the player to navigate the universe

I should hopefully have something more interesting to show once the map and navigation systems are finished since you'll then actually be able to move around the Universe and it might actualy start to feel somewhat like a game  Smiley.

I also took a bit of a brake from EPIC in the last couple of weeks to knock together a little something for my girlfriend.  It's a dynamically arranging music box, pretty cool, although it turns out not the easiest thing to implement using Unity.  Check it out here if you want to:

http://forbiddenfunction.com/main/?page_id=396



Now I'm done with the first pass of that though I'm going to return to EPIC for a while so hopefully should have something exciting to show soon  Smiley
Logged

Chromanoid
Level 10
*****



View Profile
« Reply #32 on: November 25, 2011, 04:11:18 PM »

a link i found in my favorites, when i saw it, i thought of your project. maybe it's new and interesting to you Smiley:
http://www.projectrho.com/rocket/index.php (topic list top right corner)
Logged
wzl
Level 1
*



View Profile WWW
« Reply #33 on: November 25, 2011, 05:06:18 PM »

Hey motorherp,

i just joined here and i find it nice to see some familiar faces Coffee
(redwater from shmupdev)

This is an interesting project you've been working on. Eventhough i have never played the orignal Elite, so i'm kinda clueless on how the gameplay will work. Are you in a commander kind of view switching from planet/system to another, or actively flying around in a ship?

I'm really impressed by the work you've put into your skyboxes and planet surfaces, and it is amazing how elaborate and detailed you are in your posts! cheers for that.

Good work sir Gentleman

Logged

Long pork is people! wzl's burrow
motorherp
Level 2
**



View Profile WWW Email
« Reply #34 on: November 26, 2011, 04:44:41 AM »

@Chromanoid :  That's a really cool link, I'm enjoying that, cheers for thinking of me hehe  Smiley.  The stuff about dispelling sci-fi myths was interesting, particularly the stuff about stealth space combat.  In my mind I'd always imagined that if space combat became a reality then it would be more akin to submarine warfare but apparently that's not entirely correct.  When it comes to epic though I dont mind bending the laws of physics in the name of gameplay and fun though.  For me I'd rather try to re-create something which takes me back to my childhood dreams of space acventuring rather than creating a simulation.  There's still lots of good inspiration there though.  Cheers.

@wzl : Hey dude, good to see you getting your project about.  Like in the original Elite, in Epic you'll mostly be flying around in a ship, trading, pirating, taking on military missions etc.  However I really want to push the concept further by not restricting the player to the confines of an individual pilot.  I'd also like for the player to be able to command multiple ships and armies also and give them the freedom to jump into the body of the pilot of any ship they own.  This will allow the player to orchestrate large operations whilst at the same time also being able to focus their attentions and jump into the action however they wish to so they can experience many different aspects of their own large scale space saga.  How exactly that will work in game I haven't decided yet but its something to work towards.


Well its been a while now since I've updated this devlog so whilst I'm here I figure I should say a few words about the project.  To be honest I haven't done a large amount of work on this project recently and what has been done is mostly behind the scenes work on the program structure and supporting systems so there hasn't really been anything visual to show.  This project is starting to get a bit intense and the code-base large and complicated so work is slowing down since its not so easy to just dip in and out.  I also let myself get distracted a bit with creating a small rogue game using libtcod to give myself another side project which was much simpler for times when I wanted to work on something small.  I haven't stopped on Epic though, I just need to get over the hurdle of getting all the foundations in place and solving some of the core issues and then things should get more fun and pick up pace again hopefully.
Logged

motorherp
Level 2
**



View Profile WWW Email
« Reply #35 on: February 29, 2012, 12:50:41 PM »

original dev log post here

---------------------------------------------------------------------------------------------------------------------------------

So its been a while now since I've posted anything on this project, or in fact done much work on it at all.  I've been doing some research recently though and so I've decide its time to pick things up again.  Therefore I'm going to be focussing in on some of the more interesting aspects of the project rather than getting bogged down in leg work and hopefully rectify some issues I wasn't too happy with when I last left the project.

To be specific I'm going to be looking at planet generation again, and although I think I made some good progress last time I wasn't massively satisfied with the results.  In particular, the noise mixing methods I was using ended up giving results which looked good at a glance or a distance but on closer inspection they were rather bland lacking any specific details.  Also the image qaulity degraded significantly as you got closer to the planets, and although I dont intend for people to be able to enter the atmosphere or anything like that since I dont want to deal with terrain generation issues, I would still like for the players to get close enough for the planets to make impressive backdrops rather than just distant objects.

As a result of this post analysis I've decided to tackle planet generation in a different way.  This time I'm going to use traditional sample textures rather than proceduraly generated ones as a starting point so I can capture easily the types of details I'm after.  Since I'd still like for each planet to look different I then aim to use texture synthesis, tiling, and combination techniques to transform these starting textures into unique planets.  By using tiling I'll also be able to increase the resolution of the planets without massively increasing the texture budget to allow the camera to get closer without noticable bluring.  This all came about as a result of studying several planet texture tutorials designed for artists working in photoshop and I've been thinking of ways to break the various steps down into generative automated methods that hopefuly might produce similar results.

My first step on this path was to find a way to turn small texture samples containing the texture detail I desired into something more usable by the system for generation.  After reading some techinal papers I've decided to give image quilting a try, a method which takes many little samples from your source texture and 'quilts' them all together to create larger textures which resemble the details of the sample.  The reason for doing this is that having then generated a larger texture composed completely of the desired details this can then be used for generating wang tiles which will be my next step.

Therefore I've spent the last couple of night writing a texture quilting extension for Unity and I think the results have turned out alright.  The tool takes any texture as the source and then from that generates the quilt texture with the user specified width and height.  Since the generation can take some time I also made the generation part muti-threaded so that the tool doesn't lock up Unity whilst its working allowing me to continue doing other things.  After generation you can click on the small quilt texture preview to pop up a full sized preview and if you're happy with the results you just need to click the save button.  Simple.  Here's what the tool looks like:



And here's an example of the result.  The small image is the starting texture sample and the large image is the generated results (click for full size):





The next step will be to write a tool which turns these into wang tiles, but I'll leave that for another post.  Thanks for reading.
« Last Edit: August 14, 2012, 02:08:39 AM by motorherp » Logged

Pages: 1 2 [3]
Print
Jump to:  

Theme orange-lt created by panic