Jump to content
  • Advertisement
Sign in to follow this  
Angelic Ice

Organising Tile/Collision/Event-Maps

This topic is 939 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hey gamedev.net!

 

I am currently planning on how to structure my C++-engine (using lua as a scripting language) in terms of rendering (tile map), collision and triggering events.

 

Back then, I used to seperate collision and tile-instructions in their own binaries for fast loading. However I found this a little bit messy once the amount of level increases.

On the one side, I could put them in their own folders but this is still somehow awkward, especially because triggering events would happen within a lua-file.

 

So I wondered if storing collision and tile-information in one lua-file would be an option? Though I am afraid that this is an inefficient way and maybe even a bad concept?

On the other hand, according to what I talked about in the beginning, I could imagine to put the collision and tile-information in other files but let lua returns paths to C++. Sadly this would end in this rather ugly organisation.

 

If somebody knows an even better way to structure this, I would be happy to read about it! : )

 

 

 

Share this post


Link to post
Share on other sites
Advertisement

I'm not sure what you're asking.

Are you talking about the 2D tile map? Lua script callbacks/triggers? The collision shapes? Separate visual/physics layers?

If you're talking about the data and how it's stored, being separate shouldn't be "messy" at all, nor should combining the data be "inefficient" in practice.

Your editor could easily handle the separate files and present a cleaner interface to the user. The user is then presented with "a level" as the only UX concept and the file organization is a backend implementation detail.

Your asset pipeline could also split a single file. If you don't have a good editor, this allows you to have a single unified file that can be edited however you wish. The pipeline then splits up the data and converts it into efficient formats for runtime. This again means that "a level" is the only UX concept for designers and the actual runtime format is just an implementation detail.

Share this post


Link to post
Share on other sites

First of all, thanks for your answer!

 

Next, sorry for being so indirect and unclear.

 

I am talking about how to organise all the (2D) level related files which would include: Collision, tile map and event triggers.

 

Event triggers would describe what happens when the player/user enters or interacts with certain field on the level.

Therefore your guess was pretty much on the right way.

 


Your editor could easily handle the separate files and present a cleaner interface to the user. The user is then presented with "a level" as the only UX concept and the file organization is a backend implementation detail.

 

I am aware that there is no real problem with having multiple files. However I was afraid that this might be a bad design habit of mine.

There would be one lua file with the event triggers and two binaries about the collision and the 2D tile map.

 


nor should combining the data be "inefficient" in practice.

 

Not inefficient in terms of practise or even on a perfomance level? Is not iterating through a file - which merged collision and tile map - instead of working with seperated files slower?

 


Your asset pipeline could also split a single file. If you don't have a good editor, this allows you to have a single unified file that can be edited however you wish. The pipeline then splits up the data and converts it into efficient formats for runtime.

 

Would the splitting part address what I mentioned? Splitting unified data back into parts?

The editor is no problem at the moment, it is rather about clean implementation. Even when I am the only person who would see it, I just want to get rid off bad habits.

 

Is storing all the data within lua inefficient?

Share this post


Link to post
Share on other sites

Your editor could easily handle the separate files and present a cleaner interface to the user. The user is then presented with "a level" as the only UX concept and the file organization is a backend implementation detail.

 
I am aware that there is no real problem with having multiple files. However I was afraid that this might be a bad design habit of mine.
There would be one lua file with the event triggers and two binaries about the collision and the 2D tile map.


I see no reason why that would be bad. Most games typically have their levels split up into a few parts.

Don't think about files. Files are irrelevant. Think about your (sub)resources. The file structure is an implementation detail.
 

nor should combining the data be "inefficient" in practice.

 
Not inefficient in terms of practise or even on a perfomance level? Is not iterating through a file - which merged collision and tile map - instead of working with seperated files slower?


You would want to merge your entire set of assets into a single archive file. If you care about spinning disk performance, you also need to optimize the layout of said file based on the order resources are loaded.

That has nothing to do with how you author assets or how loose assets are structured on disk. 
 

Your asset pipeline could also split a single file. If you don't have a good editor, this allows you to have a single unified file that can be edited however you wish. The pipeline then splits up the data and converts it into efficient formats for runtime.

 
Would the splitting part address what I mentioned? Splitting unified data back into parts?
The editor is no problem at the moment, it is rather about clean implementation. Even when I am the only person who would see it, I just want to get rid off bad habits.
 
Is storing all the data within lua inefficient?


For implementation, separate your concerns. Physics data has little to nothing to do with graphics data. They should be separate resources.

So far as using Lua... it's efficient up to a point. Lua was originally designed as a data file format, not a scripting language, and it's still used in its data file capacities by its trio of authors.

For smaller games it'll work fine. As the size of your assets grows, you'll run into several problems using Lua as a data format for level assets:

1) Text is bigger than binary, though compression can somewhat muddle that distinction (text can be easier to compress, but it requires more of it). Bigger files take longer to stream off disk and into memory.
2) Lua has to interpret the data into its table structures while a binary format might need far less interpretation and manipulation.
3) With an engine-specific binary format, you can eliminate _all_ interpreation of the data and instead directly mmap or memcpy it into a chunk of memory in a ready-to-use format.
4) Lua is not as memory-efficient with its data structures as you might require if you're loading very large assets.

Again, those only really matter at larger scales. Smaller games can get by with Lua as a data format just fine. You'll probably want to zlib compress the files and pack them all into an archive file of some kind still, though. Edited by SeanMiddleditch

Share this post


Link to post
Share on other sites

Like Sean said, Lua was originally made to store data. At a studio I recently interned with they were still using Lua to store and initialize game-data. One thing that might be of help is using LuaJIT in the event you find Lua not quite efficient-enough for your purposes.

 

I think the option of one Lua file would work pretty well, especially since sequentially reading a file off of a spinning disk is much more efficient (in terms of seek time) compared to jumping around to different disk segments for various files. Optimizing seek times is probably not going to be a super important topic unless you're going to be distributing your game on physical disks. For example I recall reading about some seek-optimizations on the original xbox console, as getting data off of that slow disk reader became a huge bottleneck.

 

Another point is that if you're storing data in a Lua file, and *somehow* this becomes too slow (which it probably won't, in my own opinion), aside from LuaJIT it would likely be pretty easy to switch to another file format. If you have some nicely behaved Lua code it shouldn't be too much of a struggle to transform/migrate this to something else.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!