Understanding (or lack of) maps and options to load maps.

[js_unit]

Hi guys

 

Old dev, but somewhat new to game and js in general.

 

I am working on an idea that is quite large, and I have a little team behind me. We are still in architectural phase, and already many difficulties are cropping up.

Not that it's a bad thing during design right?

 

This one is general is my biggest confusion / concern. Map loading.

 

I am not going to call it a map, it might not be the right word, let's say play area.

In our case, the play areas are huge (as huge as possible!). We don't want any world bounds to stop a player, they will be able to go as far as we can possibly allow.

Of course, integers have limited size, and reality sucks. The following two concerns pop up first.

 

1. How could I handle/visualise/realise map loading from a central server, if maps are this large and indeterminate.

2. If 1. is doable, how the heck do I know what coordinates to use for a player. A bounded world, have x,y pixels at the least. But what does a huge world have?

 

For 1. I considered the json way, but tiled maps are predetermined, and a map of 80 000x 80 000px, would yield a tiled json file of 4 MB already.

Is it really neccesary to use csv/json tilemaps? 

 

Considering a sandboxy persistent type game, starting with NOTHING, can we just use good old rendering of images and save these locations/coords (problem 2 above)  on the server side?

 

Tldr:

Do we have to use tilemaps or go free form?

How do we know what the player and object coordinates are.

 

I hope it doesn't seem like rambling. It's a real headache for me right now, as I start the loader code.

 

Cheerios

Marlon

 

 

 

 

 

 

 

 

 

[Deathspike]

A virtually endless world size? I presume you're not going to hand-craft it, so you'll end up with procedural world generation. In that case, I would generate chunks of the world as 'areas'. Say that each area is 10.000x10.000, and you will be able to stitch areas together by essentially making a tilemap of areas. Now when you place a player in an area, all he needs to know is the relative position in that area. When you get near an edge, just make the game client aware of the next area and have it handle transitions between the two areas smoothly. Once you're on the new area, you can just mark the player as being in that particular area with a new relative position.

 

You don't have to use a JSON format at all. You can create a tilemap with a given size and fill it yourself at run-time. Imagine taking the areas I mentioned previously, and transmitted the data over a binary websocket (gzipped, of course), and you'll end up with an area message of several hundreds of kilobytes at maximum. Just piece it together in Phaser with the tile setting functions and voila! You just transmitted a large area in a seemingly unbound world with very minimal bandwidth consumption.

 

In your case, it's going to be a major architectural hurdle to realize everything. Mostly specifically, the procedural content generation and a networking architecture using binary websockets. Other than that, it should be pretty much okay to do. Remember, it's just an up-front cost, a virtually endless generated world has many upsides for game longevity..

 

Not sure if this helps. I hope it do. Let me know otherwise.

[js_unit]

Hi DeathSpike

 

I appreciate the response a lot! In fact, it cleared up some worries I had to be honest. 

There is no problem with the architecture and networking, code we can handle easy. It was more the concept of largeness, which you mentioned.

 

Procedural generation, and storage is the tricky part (then loading and modifying as players 'change' the chunks). But it can be done.

 

Now that socket.io has p2p stuff, it'll just smooth things out even more (guess it's time to get NodeJS on the backend now).

 

Thanks again.

[Deathspike]

Wow. I missed out on the WebRTC news on Socket.IO! Thanks for bringing that to my attention!

 

I do have to wonder if you *want* do have P2P on, what sounds like, a MMO. If it's not, disregard this completely. But the timing issues and "who is in charge" issues will pop up and make for a very interesting cheating problem. I'm thinking of F.E.A.R. all over again (which has, or had, P2P multi-player; and was a disaster for it). If it's friendly games where you want to have a player "own" a world and others can join his world, then I suppose that's okay. But remember the cheating approach! 

 

Good luck! It sounds pretty interesting (like a massive 2D minecraft or something).