Changing the map format

I was talking with watusimoto on irc about potentially changing how the map files are stored and delivered.

Currently, maps are distributed in *.level files, which are human-readable text files that bitfighter parses.
For those who are not familiar with the format, it looks like this:

  Code:

CoreGameType 8
LevelName Core03
LevelDescription ""
LevelCredits ""
GridSize 255
Team Blue 0 0 1
Team Red 1 0 0
Specials Engineer
MinPlayers
MaxPlayers
BarrierMaker 50 13.6 2.5 13.5 3 13.6 3.5
PolyWall 13.1 4.4 12.6 4.7 14.6 4.7 14.1 4.4
PolyWall 12.6 1.3 13.1 1.6 14.1 1.6 14.6 1.3
PolyWall 9.3 1.9 8.9 2 8.8 3 8.9 4 9.3 4.1 9.3 3.9 9 3.9 9 2.1 9.3 2.1
PolyWall 5 4.5 4.5 4.5 4.5 5.5 5.5 5.5 6 3.2 5 3.2
BarrierMaker 50 17.4 2.5 17.5 3 17.4 3.5
PolyWall 6.4 1.3 6.9 1.6 7.9 1.6 8.4 1.3
PolyWall 10.7 2 10.7 2.3 11.2 2.3 11.2 2.8 11.5 2.8 11.3 2.2
BarrierMaker 50 3.6 2.5 3.5 3 3.6 3.5
PolyWall 9.5 2.8 9.8 2.8 9.8 2.3 10.3 2.3 10.3 2 9.7 2.2
PolyWall 15.5 0.5 15 2.8 16 2.8 16 1.5 16.5 1.5 16.5 0.5
PolyWall 10.7 3.7 10.7 4 11.3 3.8 11.5 3.2 11.2 3.2 11.2 3.7
BarrierMaker 50 7.4 2.5 7.5 3 7.4 3.5
BarrierMaker 50 19 6 20 3 19 0 15 0 14.6 1 12.5 1 11.5 1.5 9.5 1.5 8.5 1 6.4 1 6 0 2 0 1 3 2 6 6 6 6.4 5 8.5 5 9.5 4.5 11.5 4.5 12.5 5 14.6 5 15 6 19 6 20 3
PolyWall 15 3.2 15.5 5.5 16.5 5.5 16.5 4.5 16 4.5 16 3.2
PolyWall 4.5 0.5 4.5 1.5 5 1.5 5 2.8 6 2.8 5.5 0.5
PolyWall 9.8 3.2 9.5 3.2 9.7 3.8 10.3 4 10.3 3.7 9.8 3.7
PolyWall 6.9 4.4 6.4 4.7 8.4 4.7 7.9 4.4
PolyWall 11.7 1.9 11.7 2.1 12 2.1 12 3.9 11.7 3.9 11.7 4.1 12.1 4 12.2 3 12.1 2
LoadoutZone 1 16.1 3.3 16.1 4.4 16.4 4.4 16.4 3.3
LoadoutZone 1 16.1 1.6 16.1 2.7 16.4 2.7 16.4 1.6
LoadoutZone 0 4.6 3.3 4.6 4.4 4.9 4.4 4.9 3.3
LoadoutZone 0 4.6 1.6 4.6 2.7 4.9 2.7 4.9 1.6
ResourceItem 10 2.5
ResourceItem 10 3.5
ResourceItem 11 3.5
ResourceItem 11 2.5
ResourceItem 10.3 2.5
ResourceItem 10.7 2.5
ResourceItem 10 3.2
ResourceItem 10.3 3.5
ResourceItem 10.7 3.5
ResourceItem 11 3.2
ResourceItem 11 2.8
ResourceItem 10 2.8
CoreItem 0 125 2.5 3
CoreItem 1 125 18 4.5
CoreItem 0 125 3 4.5
CoreItem 1 125 18.5 3
CoreItem 1 125 18 1.5
TestItem 10.5 3
CoreItem 0 125 3 1.5
Spawn 0 4 3
Spawn 0 4 5
Spawn 0 4 1
Spawn 0 2 2
Spawn 0 2 4
Spawn 1 17 3
Spawn 1 17 1
Spawn 1 19 2
Spawn 1 19 4
Spawn 1 17 5
Spawn 1 14 4
Spawn 1 14 2
Spawn 1 13 2
Spawn 1 13 4
Spawn 0 7 2
Spawn 0 7 4
Spawn 0 8 4
Spawn 0 8 2
Spawn 0 6 1
Spawn 0 6 5
Spawn 1 15 5
Spawn 1 15 1

It's a good, clean, and simple solution. Maps can also be generated with the assistance of Lua (Lua is a scripting engine that Bitfighter uses for various odds and ends).

This is all good, but it is fairly limited, because a map can only really have basic information. For instance, if we wanted to add a background to the map, or distribute the map with custom sound effects, it's impossible.

What I suggest is taking a java-ish philosophy and tossing all applicable map data into a zip file. Here is how it would look (names ending in a / are subfolders):

some-level.zip:

• yourmap.level
  
• scripts/
  
• sfx/
  
• textures/

So most of this is self explanitory, but I'll try and dig a little further into it.

First, yourmap.level, same .level file the server and client deal with, no game modification needed to read this.

Second, scripts/ folder. This can give an infinite set of possibilities, but here are the few I was directly thinking of:

• Map events and reactions to you, as well as telling the game which bots to load for the single player game.
  
• Change effects, textures, and sounds (background or weapon noises) for map

Third, sfx/ folder. Toss in any custom sound files you want to use in your map. Will be wired up with a script in the above scripts/ folder.

Fourth, textures/ folder. Want cool backgrounds? Want the walls to not just be blue? Toss in some textures, and tell the map which textures to use for which wall.

And, it all gets zipped, so anything that's not compressed will hopefully download a little quicker (not that we currently have huge maps yet...).

Thoughts?
-Beard

[sam686]

Only problem with sound effects and textures is if the client doesn't have them, they might have to be transmitted from server to clients.

Might be good idea to make the level more pretty, I have seen some maps trying to make it look good, but there is some limits without the ability to use textures.

One possible problem is that will make the install size bigger, and /getmap or uploading level will take longer.

[ZoombeR]

What will we do about /getmap? right now we can just use /getmap in game to download a map and instantly re-host it. Even if created, we can't get over the physical foundry of downloading huge map files without sacrificing bandwidth.

What will we do about /getmap? right now we can just use /getmap in game to download a map and instantly re-host it. Even if created, we can't get over the physical foundry of downloading huge map files without sacrificing bandwidth.

Well, there will be a few things in place to make map downloading as seemless as possible. Also, a lot of you are thinking that the average map-zip would be huge. I don't forsee a map download being more than 7mb, unless the author of the map-zip is insane, and I say this for a few reasons. First, the biggest thing I can imagine being part of the map-zip is a background music file. We can certainly do a few things to deal with this; lower the quality of sound, and limit the number of megabytes that a sound file can be. Take the current default background game music. It is 475kB (not even a megabyte!), it's 2 minutes long, and it loops, with a 32kb/s, 44100Hz rate, which is fairly high quality. The second biggest will be background images. This is highly dependant on the image quality, and the format/available compression. Since we want to go for the vector-graphics look, with a bit of pixelation, it would be fairly easy to have a stretched 800x600 PNG file with 0 compression is roughly going to be about 1.3mb (full compression, my test image went down to 200kB).
Scripts and *.level files will not take up much memory, they are plain text.

So, without being zipped, let's pretend I use three sounds, two effects (let's say about 100kB each) and one background (for argument's sake, let's say 1mb), two background image layers (each at 400kB), a script (maybe 100kB), and a *.level file (2kB), that gives us an UNCOMPRESSED total of 1.6MB.

It may be good to host the map files on the website so the game server doesn't actually have to distribute. In fact, with that sort of simple model, the server could even be grabbing the appropriate map data as needed. This could ensure that the server and client are always dealing with the same version of all the files.

This also introduces a few other potential problems and solutions. Do we use a caching model, and how will that take into account fixes from the main server?

This isn't a simple addon to the game, this could change how we deal with map and gameplay data in general, so it's good that I'm getting some feedback on this.

-Beard

EDIT: sorry, I didn't directly address /getmap
Basically every map you play the game would download and keep. In fact, any map on the website would be accessible to you in the ingame menus, and if you didn't have the map it would automatically download if for you.

You would be better off having the texture tile, or remain in a certain area, than to stretch the image.

I am going to add, I use to create maps for a game that ran on the Q3 engine. There is the obvious issue of huge map files, it was found that players abhorred large maps for quite obvious reasons. The solution was not in limiting maps, it was in the mappers themselves. There were tricks one could pull off to create a good looking map while not creating huge map files, however those tricks are irrelevant as they do not translate into a 2d game.

The point of this is that the people who create the maps will consider the size of the map. It was found, in that community, 20MB was about the maximum players would endure.

[watusimoto]

I'd like to get a better sense of what the backgrounds might be, so we can decide if this is where we want things to go (it might well be, though perhaps some sort of algorithmic vector background generator might be more in keeping with the game aesthetics). Once we are sure about what we want, it would then make sense to discuss the file format.

It seems we're putting the cart before the horse, just a tiny bit.

And just an additional thought -- if people are able to distribute music via the game, it might, possibly, open us to some sort of problems if people decide to use pirated music as their soundtracks (as they inevitably will). So far, we've avoided issues like this by distributing the music ourselves, so we can make sure it's properly licensed.

I'd be less concerned with a system that lets level designers pick music from a predistributed set of music, or, perhaps, downloaded on demand from a central server.

Given the difficulty we've had finding appropriate music, I'm not even sure custom music is a good idea! (Though I am still happy to explore it.)

I'd like to get a better sense of what the backgrounds might be, so we can decide if this is where we want things to go (it might well be, though perhaps some sort of algorithmic vector background generator might be more in keeping with the game aesthetics). Once we are sure about what we want, it would then make sense to discuss the file format.

It seems we're putting the cart before the horse, just a tiny bit.

And just an additional thought -- if people are able to distribute music via the game, it might, possibly, open us to some sort of problems if people decide to use pirated music as their soundtracks (as they inevitably will). So far, we've avoided issues like this by distributing the music ourselves, so we can make sure it's properly licensed.

I'd be less concerned with a system that lets level designers pick music from a predistributed set of music, or, perhaps, downloaded on demand from a central server.

Given the difficulty we've had finding appropriate music, I'm not even sure custom music is a good idea! (Though I am still happy to explore it.)

As for backgrounds, I agree, we do need more ideas about how we want to approach that. I thought doing z-layered parallaxed backgrounds would be cool, because it would be possibly to have different star and planet layers (each layer would "scroll" at a different speed giving the illusion of distance), BUT it would be easy to create something that went 100% against the style. Generating backgrounds sounds neat, we'd need to discuss which algorithms and colours would be appropriate.

A thought I had last night after I logged off was maybe ditching the idea of a map zip-pack and maybe using sound and texture packs. Our map format could easily add some directives like:

  Code:

IMPORT SFXPACK sfxpackage
SET SOUND BGMUSIC sfxpackage/cool_bgmusic.ogg
SET SOUND WALLCOLLISION sfxpackage/smashing_glass.ogg
IMPORT TEXPACK sometexturepackagename
TEXTURE sometexturepackagename/customtexture.png
PolyWall 15 3.2 15.5 5.5 16.5 5.5 16.5 4.5 16 4.5 16 3.2
# This next polywall won't have a texture, TEXTURE should only deal with the immediately next PolyWall.
# We'd need a way to map the texture, too...
PolyWall 15 3.2 15.5 5.5 16.5 5.5 16.5 4.5 16 4.5 16 3.2
 

Then as mentioned, we'd need a way to know we are getting licensed music that we can distribute OR music without a license with the sound packs. I don't know if that's really 100% a dev responsibility, since there is no real way we can know, BUT we could have a flagging system that people can report if the music (or textures) are offensive or copyrighted.

Just some thoughts,
-Beard

[bobdaduck]

I'm against being able to put music and pictures into maps.

I'm against being able to put music and pictures into maps.

I appreciate your response. Any reason in particular?

-Beard

[bobdaduck]

Well first, obviously people could put in inappropriate pictures/sounds which we don't really have any way of moderating, and building in a moderation system for that doesn't seem like a worth-it idea.

If we added custom textures and things, it could easily lose its bitfighter feel. The lines between what is a barriermaker and what isn't could become fuzzy... And ghost walls would pop up again, if someone put into the level, say, a screenshot of a barrier. Players could fly right through it.

I also think that forcing map makers to be creative in their decoration produces some really innovative results. It forces map making to become more skill based than it would be otherwise, and can highlight mapmakers with real talent.

Well first, obviously people could put in inappropriate pictures/sounds which we don't really have any way of moderating, and building in a moderation system for that doesn't seem like a worth-it idea.

While I do agree with you, it's almost like you're saying, "we can't invent paper because people will write bad things." So far, I've noticed the bitfighter community to be fairly tame, and I don't see an immediate problem, and we can always rely on community moderation to know whether or not people are trying to mess things up.

If we added custom textures and things, it could easily lose its bitfighter feel. The lines between what is a barriermaker and what isn't could become fuzzy... And ghost walls would pop up again, if someone put into the level, say, a screenshot of a barrier. Players could fly right through it.

People don't have to use textures at all, they could just use the default colours, and it wouldn't make a difference. As a developer, I don't have a moral responsibility to map creators - this is something the community would have to actively moderate if you want to keep games from having invisible barriers.

I also think that forcing map makers to be creative in their decoration produces some really innovative results. It forces map making to become more skill based than it would be otherwise, and can highlight mapmakers with real talent.

With or without textures and sounds, people will still be able to instinctively know which maps are awesome and which are just glam.

I think there is some muddled line here between implemented features and forcing features on bitfighter players. From a map maker perspective, it would be absolutely possible for me to make a map with the exact same look and feel as what we have right now. There is no need to add any extra sounds or textures.

I hope that clarifies a few things.
Even though I disagree, I do find your point that you don't want the feature valid. I know I can see aggressive when I disagree, but I'm just trying to show a balanced view of this. Sorry if it felt like I was attacking your opinion,
-Beard

[bobdaduck]

Nah you're fine. I'm fairly sure I'm the senior player here (maybe shadowx.loner has played slightly longer than me) So I like to think I have a fairly good feel for how things are going to affect the game.

The main problem I've been noticing lately is an excess of superlative features. I feel like the devs keep adding features that add nothing to the game, half of which seems just experimental. And for everything, the rationale is "if you don't like it, we'll just add an on/off option." or "we can always take it out later if people complain." but the problem is no one is going to complain because the community is too passive. bad features are never gonna get removed, and everything has so many on-off switches that I'm convinced the game is going to become a sandbox instead of a game before release 022. Which is why I get fairly critical about new feature ideas.

[Skybax]

no one is going to complain because the community is too passive

I complained about the removal of sticky loadouts.
Maybe there aren't a lot of complaints because everyone likes the current features?

Nah you're fine. I'm fairly sure I'm the senior player here (maybe shadowx.loner has played slightly longer than me) So I like to think I have a fairly good feel for how things are going to affect the game.

The main problem I've been noticing lately is an excess of superlative features. I feel like the devs keep adding features that add nothing to the game, half of which seems just experimental. And for everything, the rationale is "if you don't like it, we'll just add an on/off option." or "we can always take it out later if people complain." but the problem is no one is going to complain because the community is too passive. bad features are never gonna get removed, and everything has so many on-off switches that I'm convinced the game is going to become a sandbox instead of a game before release 022. Which is why I get fairly critical about new feature ideas.

I've spent years playing customized maps for many 3D games, I only ever came across two maps that had obscene things. One of which clearly stated in its name that it contained obscene things. The other was only in a small corner of the map. That was a game who has a far larger comunity than bitfighter. Unless we're advertising bitfighter in bars I see no real threat.

[Little_Apple]

3d maps are much harder and time consuming than making levels for bitfighter. A troll wouldn't go out of it's way to make an entire 3d map just to have an obscene shape in it.

[sam686]

and everything has so many on-off switches that I'm convinced the game is going to become a sandbox instead of a game before release 022.

That is sort of going to We've used "just let people turn it on and off" for ...

Me and probably some other players thinks Bitfighter currently don't look very pretty. All levels have 100% blue walls, i think that is using too much blue color. A little more different colors could help, and textures can make it look pretty. I have seen some level tried to make it look pretty, and can really help if those level had textures or pictures in it.

3d maps are much harder and time consuming than making levels for bitfighter. A troll wouldn't go out of it's way to make an entire 3d map just to have an obscene shape in it.

Well the issue is not obscene shapes, it is pictures. It takes little effort to create a horrible 3d map with obscene textures. While we're at it someone could easily make an obscene shape in bitfighter as is.

[watusimoto]

Generating backgrounds sounds neat, we'd need to discuss which algorithms and colours would be appropriate.

Somewhere deep in the bowels of the game is an #ifdef that will change the stars to hexagons, part of a start towards these ideas I made years ago. You can find this and activate it, and see one possible idea.

Well first, obviously people could put in inappropriate pictures/sounds which we don't really have any way of moderating, and building in a moderation system for that doesn't seem like a worth-it idea.

This is my concern as well.

I also think that forcing map makers to be creative in their decoration produces some really innovative results.

Sometimes greater constraints leads to better results. I've seen so many amazing levels that blew me away from the aesthetic point of view, things I never would have guessed possible. I don't feel that we have exhausted the creative potential of what we've got now.

Which is why I get fairly critical about new feature ideas.

If I could just pop in here for a moment -- I have nothing against anyone who is critical of any feature suggestion. In fact, I think all features ought to go a rigorous examination to be considered valuable that enhance or impact the game.

However, what I (and others have agreed with me) are not okay with is when criticism becomes hostile, rude, or impatient. I'm not saying you are guilty of this, but it has cropped up in the past from various forum members and the last thing we need is drama. If someone has criticism, fine, but post it in an understandable and kind way. Also please be specific in your response, detailing why it's not good for Bitfighter right now, and possibly providing suggestions on what would make the idea better. Finally, let's be sure to give all users a fair chance, even if the proposal is ridden with bad spelling/grammar... give them a chance to explain their ideas.

Sorry for this being a little off-topic, but I think it was important to state.

[watusimoto]

However, what I (and others have agreed with me) are not okay with is when criticism becomes hostile, rude, or impatient.

Hear hear!