Jump to content

  • Log In with Google      Sign In   
  • Create Account

We're offering banner ads on our site from just $5!

1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


Engine for huge strategic map - some architectural dilemas


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
4 replies to this topic

#1 ossaltu   Members   -  Reputation: 190

Like
0Likes
Like

Posted 17 January 2014 - 02:35 AM

Recently we have formed a team and started developing a strategic game. We all are in IT industry for some time but it is first time when we are developing a game. The reason I am writing this post is that we want to hear an opinion about architectural decisions we have made from people who are game industry professionals.

First I give a screenshot so it would be easier to understand what I’ll be talking about: https://skydrive.live.com/?cid=AC26DC9D4B0CE3E5&id=AC26DC9D4B0CE3E5%212005&v=3

 

Basically we to develop a huge hexagon based map which would contain cities, roads, woods, etc.

 

This is how we have approached the problem till now: we have divided the whole map into regions (currently 20x20 tiles). Each region is represented by region object. We have used quad trees to determine which regions are on screen at the moment. If the region gets to screen for the first time, it gets loaded asynchronously – terrain geometry is generated based on map tiles (we have decided not to save terrain geometry on disk because it would take a lot of space), roads, territory markers are generated and everything is placed to region object including vertex buffers and other data needed to latter render the region.

 

Whole generation of objects is done by updater objects, which get regions passed, do the generating stuff and places generated data on region.

 

When something changes in map, e.g. new city is added, updaters get regions passed which are involved in update, generate data with changes and places it to region object.

 

There is a set of renderers, which get list of regions to render and draws them on screen based on data placed in region objects.

 

So, my questions are: is this similar to the techniques game developers approach that kind of problems? If not, then how usually people approach them? Are there any flows you may notice in such design?

 



Sponsor:

#2 ferrous   Members   -  Reputation: 2075

Like
0Likes
Like

Posted 17 January 2014 - 12:31 PM

I don't see why this is posted in coding horrors, I'll assume it's a mistake and get moved.

 

That sounds mostly fine, though do you ever unload regions once they've been loaded?



#3 greenpig83   Members   -  Reputation: 326

Like
0Likes
Like

Posted 17 January 2014 - 08:24 PM

This is how i used i. My current eninge terrain. Quad tree for decide which tiles to draw on screen. Divided large map into regions, so we can update things change every frame. But only the part that changed not the whole map

#4 ossaltu   Members   -  Reputation: 190

Like
0Likes
Like

Posted 20 January 2014 - 03:06 AM

Thanks for the feedback.

 

That sounds mostly fine, though do you ever unload regions once they've been loaded?

 

Yes, regions are unloaded after some time off-screen, or when region limit is reached.



#5 wodinoneeye   Members   -  Reputation: 861

Like
0Likes
Like

Posted 20 January 2014 - 09:53 PM

You may have to split your data between strategic simulation factors (to keep in memory and continue the simulation) and the remaining area details (which can roll out of memory).

 

Alternatives (depending on your game mechanics and area interdependancies)  is to have the area 'development' prorated and run-forward on reloading into memory.   Even with the split data mentioned above, updating the detailed data on reload can be done.    

 

If you have 'units' which cross between area boundries, then you also have to deal with the transition between the 'realized' (in-memory) units to their 'abstract' (rolled out area) form.


--------------------------------------------Ratings are Opinion, not Fact




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS