Welcome, Guest. Please login or register.

Pages: [1] 2 3 4
Print
Author Topic: Map layout etc...  (Read 26463 times)
maximinus
Community member

Posts: 694



View Profile Email
« on: March 28, 2009, 02:24:34 PM »

Hi all

I'm starting to write some code to deal with maps. According to our current design (http://wiki.parpg.net/Proposals:Game_engine_rules#Interfaces) we need 2 maps - basically a global world map and a local map.

Anyhow, I'm just posting here to get some feedback about what the maps need to represent. I have a reasonable idea, we need a 'ground' layer and an 'objects' layer; the size of the ground layer tiles is fixed by the the graphics, but the resolution of the objects layer could vary.
But, nothing is set in stone yet, and all can be varied; I'd just like to know if anyone has any ideas. Please note that I'm posting in the game mechanics forum; I'm looking for game ideas, not code ideas. Fire away - any comment is good!
Logged

Science is open-source religion
zenbitz
Moderator
Community member

Posts: 1164



View Profile
« Reply #1 on: March 28, 2009, 05:08:09 PM »

The global map is pretty well defined, look in the graphics section.  It's huge though. (1000 km^2 I think, maybe 1500).

The local maps we were just chatting on IRC about...   Probably on the order of 500-1000m square -- to handle long range rifle fire.   If the artists panic, maybe 300-400m instead.  70px diagonal square tiles, 1x1m.

I think further discussion should be in "Graphics". 
Logged

We are not denying them an ending...
We are denying them a DISNEY ending - Icelus
eleazzaar
Community member

Posts: 255


attempting lucidity


View Profile
« Reply #2 on: March 29, 2009, 12:18:06 AM »

but the resolution of the objects layer could vary.

What do you mean by that?  Different pixel resolutions, or or object that take up a varying number of tiles?

* Did we decide to abandon the idea of non-faked elevation?  It would be cool, but add a ton of work.


The global map is pretty well defined, look in the graphics section.  It's huge though. (1000 km^2 I think, maybe 1500).

Actually if we go with the episodic content, then there is no need to show the whole map at once.  Presumably any particular episode will take place in a subsection of that area.  The "map" may be nothing more than a convenient graphic, that an episode can grab a piece of to act as the graphics for it's map.


The local maps we were just chatting on IRC about...   Probably on the order of 500-1000m square -- to handle long range rifle fire.   If the artists panic, maybe 300-400m instead.

It would be good to allow large maps, but i don't think they should all be the same size.
Logged
maximinus
Community member

Posts: 694



View Profile Email
« Reply #3 on: March 29, 2009, 02:44:34 PM »

but the resolution of the objects layer could vary.

What do you mean by that?  Different pixel resolutions, or or object that take up a varying number of tiles?

Sorry, I'll make myself more clear. The resolution of the graphical ground or floor tiles (atm) is fixed, 1 tile = 1 meter. However, you can have several layers in fife, so if, for example, the 'objects' layer was twice the resolution of the ground layer I could have four objects each in a different place on the same ground tile. So the size of the ground map would be 4x4, whereas the object layer would be 8x8 but they fill the same size space.

The global map is pretty well defined, look in the graphics section.  It's huge though. (1000 km^2 I think, maybe 1500).

Actually if we go with the episodic content, then there is no need to show the whole map at once.  Presumably any particular episode will take place in a subsection of that area.  The "map" may be nothing more than a convenient graphic, that an episode can grab a piece of to act as the graphics for it's map.

+1. At the moment, unless we start procedurally generating large map areas I don't see the global map as representing anything too complex. Of course things may change, but it's easy to add code later. Best not to start with tricky stuff,we can get the basics working and then build on from that.
Logged

Science is open-source religion
zenbitz
Moderator
Community member

Posts: 1164



View Profile
« Reply #4 on: March 30, 2009, 03:20:43 AM »

* Did we decide to abandon the idea of non-faked elevation?  It would be cool, but add a ton of work.

I hope not.  I think it's at least as important as weather, etc.    Where do you see the additional work load having a great impact?
Logged

We are not denying them an ending...
We are denying them a DISNEY ending - Icelus
eleazzaar
Community member

Posts: 255


attempting lucidity


View Profile
« Reply #5 on: March 30, 2009, 04:10:16 AM »

* Did we decide to abandon the idea of non-faked elevation?  It would be cool, but add a ton of work.

I hope not.  I think it's at least as important as weather, etc.    Where do you see the additional work load having a great impact?

Code and graphics and AI.  Unless of course, FIFE already supports elevation?
Logged
maximinus
Community member

Posts: 694



View Profile Email
« Reply #6 on: March 30, 2009, 05:49:24 AM »

Fife only seems to support one level of height, however each tile does have a z value in the map files  Huh
Logged

Science is open-source religion
maximinus
Community member

Posts: 694



View Profile Email
« Reply #7 on: April 21, 2009, 02:36:16 AM »

After (much!) experimentation I cam to the following conclusions. You may disagree, which is fine, but please post a valid argument as to why (and I would genuinely like to know).

The local map (that is, the one you will be looking at most of the time) will be built up of the following layers. The first one is the first drawn, and the last is the last drawn:

1: A ground layer, that contains all base ground tiles and graphics.
2: One or more transition layers which hold all the tiles needed to render the tile transitions. These tiles are generated by the computer, so you don't need to fiddle with the editor.
3: An objects layer, which holds all of the object graphics that can be moved.
4: The blocking layer, which contains the PC, NPC's and all blocking items. It is possible to set a tile here as blocking after the map has loaded, so we can have blocking, moveable objects.

Builidings will of course be bigger than one square; the engine will automatically split the graphic up into several different squares and then put them together again in the game.

When you enter a building, we actually cheat and move to a seperate map which is the interior of the building (this saves an awful lot of work such as removing roofs and blocking walls).

And finally, I don't really like this for some reason but it's sure easier than the alternative for now:

You are able to rotate the map to change your world-view (as in the rio demo). This increases the graphics space by 4x!! However, the alternative is that spend a lot of time drawing and erasing all of the things that cause gfx blocking (like say, when the PC is behind a big building).

Code status is that the transition tiles utility is 95% complete (it only renders for grass tiles now, but really I'm only waiting on better tiles and more gfx from the gfx dept).
Code to split buildings into individual tiles I will start today.
The rotation code I will add to the current demo very soon (should be very easy, since this is supported by Fife).

This means the map class code should be complete by the middle of next week. I hope to update the current code so that it shows a building which you can walk into and out of.
Logged

Science is open-source religion
zenbitz
Moderator
Community member

Posts: 1164



View Profile
« Reply #8 on: April 21, 2009, 04:10:48 PM »


When you enter a building, we actually cheat and move to a seperate map which is the interior of the building (this saves an awful lot of work such as removing roofs and blocking walls).

All buildings?  What if they are really small?  So we cannot shoot to the outside from a building?  This seems like a very large restriction...

[/quote]
Logged

We are not denying them an ending...
We are denying them a DISNEY ending - Icelus
maximinus
Community member

Posts: 694



View Profile Email
« Reply #9 on: April 21, 2009, 05:27:44 PM »


When you enter a building, we actually cheat and move to a seperate map which is the interior of the building (this saves an awful lot of work such as removing roofs and blocking walls).

All buildings?  What if they are really small?  So we cannot shoot to the outside from a building?  This seems like a very large restriction...

I'll be strictly honest here and say "I'm not too sure". I'm currently in the process of implementing such a building and then we can see fully what the options are. One of them, of course, could be 'we move to another map that is *almost exactly the same* as the first map - except for the building internals - so we could preserve shooting outside of the building.

I'm not in the business of reducing the options available to us but I am in the business of getting the game written. But I see your point. Give me a week or so and you should be able to try for yourself in the latest SVN  Wink
Logged

Science is open-source religion
maximinus
Community member

Posts: 694



View Profile Email
« Reply #10 on: April 22, 2009, 04:45:23 PM »

Well it turns out I can 'cheat' quite a lot, and I don't need to split up the tile graphics for a simple building. Now I have this up and running in SVN  Cool



You can walk around this image but not into it. Excuse the awful graphics but that's why I'm a programmer!
Logged

Science is open-source religion
mvBarracuda
Admin
Community member

Posts: 1308



View Profile Email
« Reply #11 on: April 27, 2009, 01:01:15 PM »

Hmm I would favour buildings that you can enter without loading a separate map. It's possible to implement it by splitting up the buildings (and larger objects in general) into tile-wide pieces.

Furthermore we should consider to rather leave out the extra blocking layer and let all the blocking happen on the object layer. The FIFE pathfinding code supports blocking of objects anyway via the blocking attribute so we don't need to add extra blockers for every object on an extra layer.
Logged
maximinus
Community member

Posts: 694



View Profile Email
« Reply #12 on: April 27, 2009, 01:30:18 PM »

Hmm I would favour buildings that you can enter without loading a separate map. It's possible to implement it by splitting up the buildings (and larger objects in general) into tile-wide pieces.

Mmmm.... well I was thinking that this new map would be amazingly similar to the previous one and would essentially just be a patch used to 'cheat' a little. When I've finished splitting up the building tiles you'll see what I mean (and actually, so will I, since it's all in my mind right now).

Furthermore we should consider to rather leave out the extra blocking layer and let all the blocking happen on the object layer. The FIFE pathfinding code supports blocking of objects anyway via the blocking attribute so we don't need to add extra blockers for every object on an extra layer.

This is now how it is handled.
Logged

Science is open-source religion
egalor
Community member

Posts: 94


View Profile Email
« Reply #13 on: April 30, 2009, 07:48:52 AM »

BTW, will there be a fixed number of tiles per one map? If so, which number exactly?
Logged
maximinus
Community member

Posts: 694



View Profile Email
« Reply #14 on: April 30, 2009, 08:29:27 AM »

It's the usual non-answer for this sort of question:

TECHNICALLY, you are only limited by the size of the machine RAM, so you can have really really bug maps if you like.

However, debugging those big maps would hard since we have a so-so editor (that is based around the needs of FIFE, not PARPG), and the base map format is a massive XML file that is not user-friendly.

I think I also saw something in the FIFE forums about the engine not scaling up very well. But then again, nobody on the team has done any real tests yet.

How big were you thinking anyway?
Logged

Science is open-source religion
Pages: [1] 2 3 4
Print
Jump to: