Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Orpheon]

Well, we'd really like a Python map build for Pygg2. We want to move completely away from GM.

Meh. cspotcode's is Java, the language really shouldn't matter.

I was using Java because it's easily cross-platform, has killer GUI libraries, and I thought the most realistic GG2 rewrite would happen in Java.  I was using the Netbeans Platform, which is mega-powerful for implementing complex editors, but also has a big learning curve.

I'm not opposed to Python but I'd have to research cross-platform GUI libraries.  They probably won't be as 'mega-powerful' as the Netbeans Platform, but having the speed of a scripting language is a plus.

@Terry: I also hate the old map format, I'll post some of my new ideas.

It would probably be beneficial that the map editor and the game were in the same language. For multiple reasons.

[notajf]

Well, we'd really like a Python map build for Pygg2. We want to move completely away from GM.

Meh. cspotcode's is Java, the language really shouldn't matter.

I was using Java because it's easily cross-platform, has killer GUI libraries, and I thought the most realistic GG2 rewrite would happen in Java.  I was using the Netbeans Platform, which is mega-powerful for implementing complex editors, but also has a big learning curve.

I'm not opposed to Python but I'd have to research cross-platform GUI libraries.  They probably won't be as 'mega-powerful' as the Netbeans Platform, but having the speed of a scripting language is a plus.

@Terry: I also hate the old map format, I'll post some of my new ideas.

It would probably be beneficial that the map editor and the game were in the same language. For multiple reasons.

To reduce code duplication etc etc. Yes.

That doesn't mean we'll rewrite it in Python.

[Orpheon]

Well, we'd really like a Python map build for Pygg2. We want to move completely away from GM.

Meh. cspotcode's is Java, the language really shouldn't matter.

I was using Java because it's easily cross-platform, has killer GUI libraries, and I thought the most realistic GG2 rewrite would happen in Java.  I was using the Netbeans Platform, which is mega-powerful for implementing complex editors, but also has a big learning curve.

I'm not opposed to Python but I'd have to research cross-platform GUI libraries.  They probably won't be as 'mega-powerful' as the Netbeans Platform, but having the speed of a scripting language is a plus.

@Terry: I also hate the old map format, I'll post some of my new ideas.

It would probably be beneficial that the map editor and the game were in the same language. For multiple reasons.

To reduce code duplication etc etc. Yes.

That doesn't mean we'll rewrite it in Python.

What? You want to import python code of the engine and stuff in Java? Why?

Also, why make everything more complicated for a new/GML-only modder? Why two three languages instead of one two?

[notajf]

Well, we'd really like a Python map build for Pygg2. We want to move completely away from GM.

Meh. cspotcode's is Java, the language really shouldn't matter.

I was using Java because it's easily cross-platform, has killer GUI libraries, and I thought the most realistic GG2 rewrite would happen in Java.  I was using the Netbeans Platform, which is mega-powerful for implementing complex editors, but also has a big learning curve.

I'm not opposed to Python but I'd have to research cross-platform GUI libraries.  They probably won't be as 'mega-powerful' as the Netbeans Platform, but having the speed of a scripting language is a plus.

@Terry: I also hate the old map format, I'll post some of my new ideas.

It would probably be beneficial that the map editor and the game were in the same language. For multiple reasons.

To reduce code duplication etc etc. Yes.

That doesn't mean we'll rewrite it in Python.

What? You want to import python code of the engine and stuff in Java? Why?

Also, why make everything more complicated for a new/GML-only modder? Why two three languages instead of one two?

No, I'm saying just because we *should* avoid having seperate languages does not mean we are going to trash perfectly good existing work just because some people want it done in Python.

[Orpheon]

Well, we'd really like a Python map build for Pygg2. We want to move completely away from GM.

Meh. cspotcode's is Java, the language really shouldn't matter.

I was using Java because it's easily cross-platform, has killer GUI libraries, and I thought the most realistic GG2 rewrite would happen in Java.  I was using the Netbeans Platform, which is mega-powerful for implementing complex editors, but also has a big learning curve.

I'm not opposed to Python but I'd have to research cross-platform GUI libraries.  They probably won't be as 'mega-powerful' as the Netbeans Platform, but having the speed of a scripting language is a plus.

@Terry: I also hate the old map format, I'll post some of my new ideas.

It would probably be beneficial that the map editor and the game were in the same language. For multiple reasons.

To reduce code duplication etc etc. Yes.

That doesn't mean we'll rewrite it in Python.

What? You want to import python code of the engine and stuff in Java? Why?

Also, why make everything more complicated for a new/GML-only modder? Why two three languages instead of one two?

No, I'm saying just because we *should* avoid having seperate languages does not mean we are going to trash perfectly good existing work just because some people want it done in Python.

That mostly depends on the size of the work done in Java. But yeah, whatever. Do what you guys think is best.

[Phantom Brave]

Off-topic, but one idea I thought of was that the GIF format would be good for GG2 maps. It's a simple format, 256-color, and its multiple frames support could be used for bg/wallmask/foreground image/item placement.

PNGs can be palletized/indexed too, easily, as well as a hard 256 color restriction being bad for map makers.

[NAGN]

also I think that PNG was chosen because of its layering system, which I don't think was actually used for the wallmasks as its just translated into bits and written directly into the metadata

[cspotcode]

also I think that PNG was chosen because of its layering system, which I don't think was actually used for the wallmasks as its just translated into bits and written directly into the metadata

No, I didn't choose PNG for layering, I chose it for metadata support and because it was a sensible, common, lossless image format that could be displayed in websites.

Of course, now I think that the whole "use images as maps" idea was a bad one.

[nightcracker]

My idea is just a .map format. It's just a zip file with two .png's in it (foreground and wallmask), and potentially some .metadata files or something. You get bundling for free, aswell as compression. Python (and I think Java too, but I'm not sure) can read/write zip files with the standard library.

Also, one thing that you must keep in mind, PyGG2 will be using the PNG alpha channel for alpha, and not the green key color. (Yes, this also means you can get semi-transparent sprites).

I also had a (random) idea for the metadata, instead of making it some sort of text file we could make a third image instead. Bright red means RED's spawn, blue means BLUE's spawn, grey means bullet wall, yellow is left-to-right bullet wall, orange is right-to-left bullet wall, you get the idea. This way you also can easily overlay the maps and quickly spot any errors.

[MedO]

My idea is just a .map format. It's just a zip file with two .png's in it (foreground and wallmask), and potentially some .metadata files or something. You get bundling for free, aswell as compression. Python (and I think Java too, but I'm not sure) can read/write zip files with the standard library.

+1

Also, one thing that you must keep in mind, PyGG2 will be using the PNG alpha channel for alpha, and not the green key color. (Yes, this also means you can get semi-transparent sprites).

This is already possible in GM as well.

I also had a (random) idea for the metadata, instead of making it some sort of text file we could make a third image instead. Bright red means RED's spawn, blue means BLUE's spawn, grey means bullet wall, yellow is left-to-right bullet wall, orange is right-to-left bullet wall, you get the idea. This way you also can easily overlay the maps and quickly spot any errors.

Not hugely in favor of this, it would be difficult to work with entities which are supposed to overlap.

[nightcracker]

I also had a (random) idea for the metadata, instead of making it some sort of text file we could make a third image instead. Bright red means RED's spawn, blue means BLUE's spawn, grey means bullet wall, yellow is left-to-right bullet wall, orange is right-to-left bullet wall, you get the idea. This way you also can easily overlay the maps and quickly spot any errors.

Not hugely in favor of this, it would be difficult to work with entities which are supposed to overlap.

Ahh yes, NVM then

I also had another idea. You can actually put different game modes in the same map. Basically here's what the zip would look like:

Code: [Select]

random_name.zip
 |- cp_foreground.png
 |- cp_wallmask.png
 |- cp.metadata
 |- ctf_foreground.png
 |- ctf_wallmask.png
 |- ctf.metadata
But that also is, a random idea.

[Phantom Brave]

Game modes should be individual to one map file.

[MedO]

Interesting, but I don't see a big advantage over just distributing the modes as seperate maps, and as a disadvantage it couples the different game modes for updates, so if a map changes only one game mode or adds a new one, you will either have to download the entire map file again - even if the mode you actually want to play didn't change - or you will end up with lots of versions of the same map on your disk, depending on how the map system will work.

...so, what wareya said.

[Nukleus]

Why do we have to change from the current system?

[Phantom Brave]

current map system is unsustainable and thrown-together-like