New levelformat

New level format

Postby acme_pjz » 04 Apr 2011, 13:28

In order to implement moving blocks and spikes, a change of level format is needed. I don't know if anybody have ideas and opinions ... How about you, Edward_Lii?
Some of my open source games on GitHub
User avatar
acme_pjz
 
Posts: 665
Joined: 10 Dec 2009, 15:32
Location: PeeKing, China

New levelformat

Postby Edward_Lii » 04 Apr 2011, 18:15

Hello all,

acme_pjz {l Wrote}:Now swapping block is implemented, and when you enter the checkpoint or swapping block, you need to press 'DOWN' key to activate them. Also added the sound effect. And ImageManager which prevents loading same image multiple time ... and a menu of editor ;)

acme_pjz {l Wrote}:Now breakable block is implemented, feel free to change or modify the graphics (or code) of checkpoint/swapping block/fragile block :) ...

Wow, impressive! :shock:
I really like the changes you made, I'm sorry that you can't submit your changes direct.
The ImageManager has a huge effect on the performance!

acme_pjz {l Wrote}:In order to implement moving blocks and spikes, a change of level format is needed. I don't know if anybody have ideas and opinions ... How about you, Edward_Lii?

To be honest I didn't even know the file format, but looking at it I see it's very basic.
I think it's better to change to a more complex but more extendible format.


Current format:
Currently it's just parameters on one row:
{l Code}: {l Select All Code}
800 600 0 0 0 0 0 50 0 0 100 0 0 150 0 0 200 0 0 250 0 50 250 0 100 250 0 150 250 0 200 250 0 250 250 0 300 200 0 350 150 0 400 150 0 450 150 0 500 200 0 500 250 0 550 250 0 600 250 0 650 250 0 650 200 0 650 150 0 650 100 0 650 50 0 650 0 3 600 200 1 100 200 2 50 200

It hard to read/manual edit and not easily extended.


Suggestion #1:
I prefer a more human readable format like this:
{l Code}: {l Select All Code}
size = 800,600
spawn = 20,20
spawn_s = 40,20
block = 0, 0, 0
block = 0, 0, 50
exit = 100, 200

New features can be added simple by adding a new type like:
{l Code}: {l Select All Code}
portal = 45,80

But the problem is that you can't easily extend an already existing block.
For example the moving block, it could be implemented like this:
{l Code}: {l Select All Code}
moving_block = 40,40,100,20,30,1

But you'll lose the connection with the already existing block.


Suggestion #2:
This one is a bit complexer:
{l Code}: {l Select All Code}
size = 800, 600
block(0, 50) {
    image = block1.png
}
death(50, 50) {
    image = spikes.2png
    #control = <TYPE>,<X-Movement>,<Y-movement>,<time>,<loopmode>
    control = move,100,20,30,1

    #Or:
    control(move) {
        movement = 100,20
        time = 30
        loopmode = 1
    }
}

The advantage of this format is that a level can be highly customizable.
For example: a block can simply be given a different image so that it looks different.
And when there are new features introduced it will be easy to add.

I used a format like the last one in PoA but I'm not sure if it's suited for M&MS.
Wondering if it is easy to implement in C/C++. :think:

Any feedback is welcome! ;)
From,
Edward_Lii
User avatar
Edward_Lii
MnMS Moderator
 
Posts: 777
Joined: 20 Dec 2010, 16:46

Re: Some ideas about new block types

Postby acme_pjz » 04 Apr 2011, 19:08

Now moving blocks/spikes is implemented, although moving blocks are buggy (the physics need to change a bit) ... Currently in editor press Ctrl+O to open file, press Ctrl+S to save file (you can also press ESC for menu :) ) and press ENTER key to edit the moving block's properties when the mouse cursor is on it ...

During playing, press Ctrl+E to edit current level (ripped from Frogatto & Friends ;) )

As for the file format, currently I changed the file format to:

{l Code}: {l Select All Code}
<LevelWidth> <LevelHeight> <LevelPropertiesCount> <LevelPropertiesName1> <LevelPropertiesValue1> ...  <LevelPropertiesNameN> <LevelPropertiesValueN>
<ObjectType> <ObjectX> <ObjectY> <ObjectPropertiesCount> <ObjectPropertiesName1> <ObjectPropertiesValue1> ...  <ObjectPropertiesNameN> <ObjectPropertiesValueN>
<ObjectType> <ObjectX> <ObjectY> <ObjectPropertiesCount> <ObjectPropertiesName1> <ObjectPropertiesValue1> ...  <ObjectPropertiesNameN> <ObjectPropertiesValueN>
... ... ... ...


A disadvantage is the property name and value can't contain spaces :| Anyway, the file format can always be changed :D

Edward_Lii {l Wrote}:Suggestion #2:
This one is a bit complexer:
...


Your suggestion reminds me XML or the file format of Battle for Wesnoth :D ... It's a little difficult to implement because we would likely to meet a lot of bugs :| ...
Attachments
meandmyshadow.7z
(387.25 KiB) Downloaded 290 times
Some of my open source games on GitHub
User avatar
acme_pjz
 
Posts: 665
Joined: 10 Dec 2009, 15:32
Location: PeeKing, China

Re: Some ideas about new block types

Postby Edward_Lii » 04 Apr 2011, 19:22

Hello acme_pjz,

acme_pjz {l Wrote}:Now moving blocks/spikes is implemented, although moving blocks are buggy (the physics need to change a bit) ... Currently in editor press Ctrl+O to open file, press Ctrl+S to save file (you can also press ESC for menu :) ) and press ENTER key to edit the moving block's properties when the mouse cursor is on it ...

During playing, press Ctrl+E to edit current level (ripped from Frogatto & Friends ;) )

As for the file format, currently I changed the file format to:

{l Code}: {l Select All Code}
<LevelWidth> <LevelHeight> <LevelPropertiesCount> <LevelPropertiesName1> <LevelPropertiesValue1> ...  <LevelPropertiesNameN> <LevelPropertiesValueN>
<ObjectType> <ObjectX> <ObjectY> <ObjectPropertiesCount> <ObjectPropertiesName1> <ObjectPropertiesValue1> ...  <ObjectPropertiesNameN> <ObjectPropertiesValueN>
<ObjectType> <ObjectX> <ObjectY> <ObjectPropertiesCount> <ObjectPropertiesName1> <ObjectPropertiesValue1> ...  <ObjectPropertiesNameN> <ObjectPropertiesValueN>
... ... ... ...

I think it could do for now, but I think we could also go for an XML like format.
Maybe we could use a C/C++ xml parser?

acme_pjz {l Wrote}:A disadvantage is the property name and value can't contain spaces :| Anyway, the file format can always be changed :D

Edward_Lii {l Wrote}:Suggestion #2:
This one is a bit complexer:
...


Your suggestion reminds me XML or the file format of Battle for Wesnoth :D ... It's a little difficult to implement because we would likely to meet a lot of bugs :| ...

I know, in PoA I loop the lines and trim the line to check if the property is recognized, if so then I can both use the trimmed and untrimmed.
But this didn't work correctly so I changed it to _ for spaces and ; for linebreaks, here's why it didn't work:
{l Code}: {l Select All Code}
description =[b][u] [/u][/b]Description bla blah blah

As you can see there's a white-space to much on the beginning although this isn't to bad there could also be multiple white-spaces.
There's also a problem when it's combined with multiple parameters:
{l Code}: {l Select All Code}
thing(1, Description with whitespaces, 102)

So the best solution is to replace certain characters.

BTW, the current format can't handle white-spaces at this moment since the second word is interpreted as a new value.

P.S. I'll submit your changes ASAP! ;)
From,
Edward_Lii
User avatar
Edward_Lii
MnMS Moderator
 
Posts: 777
Joined: 20 Dec 2010, 16:46

Re: Some ideas about new block types

Postby acme_pjz » 04 Apr 2011, 19:27

Edward_Lii {l Wrote}:I think it could do for now, but I think we could also go for an XML like format.
Maybe we could use a C/C++ xml parser?


XML parser is possible, for example libexpat ... But I think the question is do we need to use XML file format? If we use XML then the level file will be much larger IMHO :| ...

About white-spaces, I have a bad idea that is unescape the whole string, for example convert to hex like 203A3E4F ...

BTW, a good news is I managed to config the SVN client to use the HTTPS proxy ... and now I can and would like to join the project :) My SourceForge user name is acme-pjz ...
Some of my open source games on GitHub
User avatar
acme_pjz
 
Posts: 665
Joined: 10 Dec 2009, 15:32
Location: PeeKing, China

Re: Some ideas about new block types

Postby Edward_Lii » 04 Apr 2011, 19:33

Hello acme_pjz,

acme_pjz {l Wrote}:XML parser is possible, for example libexpat ... But I think the question is do we need to use XML file format? If we use XML then the level file will be much larger IMHO :| ...

It would become larger but it's in my opinion flexible and readable.
But I'm open for any other format. :)

acme_pjz {l Wrote}:About white-spaces, I have a bad idea that is unescape the whole string, for example convert to hex like 203A3E4F ...


acme_pjz {l Wrote}:BTW, a good news is I managed to config the SVN client to use the HTTPS proxy ... and now I can and would like to join the project :) My SourceForge user name is acme-pjz ...

Good to hear, I'm sorry for the trouble it caused you in the begin, you've been added to the project and can commit to the repository.
I didn't commit your last change yet so you can do it to test if it really works. ;)
From,
Edward_Lii
User avatar
Edward_Lii
MnMS Moderator
 
Posts: 777
Joined: 20 Dec 2010, 16:46

Re: Some ideas about new block types

Postby acme_pjz » 05 Apr 2011, 06:03

Hi Edward_Lii,

I have committed the code and it works :)
Some of my open source games on GitHub
User avatar
acme_pjz
 
Posts: 665
Joined: 10 Dec 2009, 15:32
Location: PeeKing, China

Re: Some ideas about new block types

Postby Bodsda » 05 Apr 2011, 15:02

Hi guys,

If you are planning on changing the level file format, in my opinion, it would be far better to spend a good amount of time doing it properly; creating something robust, customizable and extendable, rather than mashing something together that works for now.

I personally like the style of Suggestion #2 from Edward_Lii

Bodsda
User avatar
Bodsda
OD Moderator
 
Posts: 195
Joined: 18 Feb 2010, 08:19

Re: Some ideas about new block types

Postby acme_pjz » 05 Apr 2011, 15:42

Bodsda {l Wrote}:If you are planning on changing the level file format, in my opinion, it would be far better to spend a good amount of time doing it properly; creating something robust, customizable and extendable, rather than mashing something together that works for now.


I know :| I prefer XML format, but some people says that XML is not good for game file format ... Anyway, in my own project TurningPolyhedron I use XML format :) I have already written a simple and buggy XML reader/writer/DOM, but it's in Visual Basic, not C++ ... so I think we should try some existing XML library ...
Some of my open source games on GitHub
User avatar
acme_pjz
 
Posts: 665
Joined: 10 Dec 2009, 15:32
Location: PeeKing, China

Re: Some ideas about new block types

Postby Edward_Lii » 05 Apr 2011, 16:14

Hello Bodsda and acme_pjz,

Bodsda {l Wrote}:If you are planning on changing the level file format, in my opinion, it would be far better to spend a good amount of time doing it properly; creating something robust, customizable and extendable, rather than mashing something together that works for now.

This is most definitely true, not only for file formats but for almost every part of the game.

Bodsda {l Wrote}:I personally like the style of Suggestion #2 from Edward_Lii

Me too (because I use it in PoA ;) )!

acme_pjz {l Wrote}:I know :| I prefer XML format, but some people says that XML is not good for game file format ... Anyway, in my own project TurningPolyhedron I use XML format :) I have already written a simple and buggy XML reader/writer/DOM, but it's in Visual Basic, not C++ ... so I think we should try some existing XML library ...

I have nothing against XML in games, but somehow I prefer a more human readable format.
But using an existing xml-parser will reduce bugs in the loading, since you don't have to write it yourself, on the other side it adds another dependency to the project.

I think the question is if we need a format like XML as acme_pjz said.
Although the level isn't complex, only some blocks, spawnpoints and level dimension, it will get complexer the more features we add.

Which level format suite us best?
From,
Edward_Lii
User avatar
Edward_Lii
MnMS Moderator
 
Posts: 777
Joined: 20 Dec 2010, 16:46

Re: Some ideas about new block types

Postby acme_pjz » 06 Apr 2011, 06:06

Edward_Lii {l Wrote}:
Bodsda {l Wrote}:I personally like the style of Suggestion #2 from Edward_Lii

Me too (because I use it in PoA ;) )!


Well, I admit that I don't know your format at all :? Do you have reading/writing module already?

Edward_Lii {l Wrote}:
acme_pjz {l Wrote}:I know :| I prefer XML format, but some people says that XML is not good for game file format ... Anyway, in my own project TurningPolyhedron I use XML format :) I have already written a simple and buggy XML reader/writer/DOM, but it's in Visual Basic, not C++ ... so I think we should try some existing XML library ...

I have nothing against XML in games, but somehow I prefer a more human readable format.
But using an existing xml-parser will reduce bugs in the loading, since you don't have to write it yourself, on the other side it adds another dependency to the project.


IMHO XML is human readable too, compare with other formats...

As for the parser, use a self-written simple XML parser is not bad (but not good enough), although it doesn't support all XML features ...

[Off topic] At first I think if we can switch to a binary file format, which is completely not human readable :D
Some of my open source games on GitHub
User avatar
acme_pjz
 
Posts: 665
Joined: 10 Dec 2009, 15:32
Location: PeeKing, China

Re: Some ideas about new block types

Postby Edward_Lii » 06 Apr 2011, 14:17

Hello acme_pjz,

acme_pjz {l Wrote}:Well, I admit that I don't know your format at all :? Do you have reading/writing module already?

Yes, but it's written in Java and porting it to C++ won't be so easy.
If we want to go for this approach the best is to write a reader in C++.

The concept is pretty straight forward, first you loop the file with a while loop.
In Java I use these lines:
{l Code}: {l Select All Code}
//Open the scene file.
BufferedReader reader = new BufferedReader(new FileReader(new File("Data" + File.separator + "Scenes" + File.separator + name + File.separator + name + ".scn")));
//The current line.
String line = "";
//Read every line of the scene file.
while((line = reader.readLine()) != null) {
   //Remove all white-space in the line.
   line = line.trim().replace(" ", "");
   
   //Check the lines.

}

The while loop sets the String line with the new line and checks if it isn't null.
Then I trim the line to remove indents and remove the spaces.
The checking for properties is simple, here's an example of the night property:
{l Code}: {l Select All Code}
if(line.toLowerCase().startsWith("night") && !line.toLowerCase().contains("color")) {
   //Set if the state has a night (time).
   state.setNight(Boolean.valueOf(line.split("=")[1]));
}

This one is a little bit special because it has two conditions in the if statement, this is because there's also a property called nightcolor.
In most other cases it's just the startsWith("") method.

The same way is with new blocks like "control(move) {" in my second suggestion.
The only difference is that I create a new while loop which will fill the line String and check if the line doesn't contain "}".

As you can see I rely on a lot of Java methods including trim(), replace("", ""), startsWith(""), toLowerCase(), etc..
So I don't know if there's an easy way to do this in C++?

BTW, I don't have a writing module since I still write my scene files by hand. :|
I hope I'll find the time to make an editor for PoA soon!

acme_pjz {l Wrote}:IMHO XML is human readable too, compare with other formats...

As for the parser, use a self-written simple XML parser is not bad (but not good enough), although it doesn't support all XML features ...

I agree, XML is human readable but a property/value approach is more human readable. :)
Eventually it doesn't matter if the XML parser is self-written or not, the goal is to load the data you need.
And not supporting every feature of XML isn't a disaster as long as it doesn't cause problems. ;)

When compiling I had some problems with the itoa() functions, although I succeeded in getting it to compile it might be worth it to consider using an alternative?
As stated here http://cplusplus.com/reference/clibrary/cstdlib/itoa/ itoa is not part of C++:
cplusplus.com {l Wrote}:This function is not defined in ANSI-C and is not part of C++, but is supported by some compilers.

A standard-compliant alternative for some cases may be sprintf:
From,
Edward_Lii
User avatar
Edward_Lii
MnMS Moderator
 
Posts: 777
Joined: 20 Dec 2010, 16:46

Re: Some ideas about new block types

Postby acme_pjz » 06 Apr 2011, 15:30

Edward_Lii {l Wrote}:...

The concept is pretty straight forward, first you loop the file with a while loop.
In Java I use these lines:

...


Maybe you can post an EBNF description of your file format, or I can invent one after observing your examples ;)

And a question:

{l Code}: {l Select All Code}
move,100,20,30,1


Does this mean an array of strings, or just a string and its value is "move,100,20,30,1"?

Edward_Lii {l Wrote}:As you can see I rely on a lot of Java methods including trim(), replace("", ""), startsWith(""), toLowerCase(), etc..
So I don't know if there's an easy way to do this in C++?


Don't laugh, when I'm using Visual Basic, I heavily use these functions, too :D Of course if we want to write a universal reader/writer we don't need to use these function, because the parser is scanning the input stream consecutively, and put the data read to different buffer depend on what character it read. Finally, a tree-like hierarchical data structure is built.

Edward_Lii {l Wrote}:BTW, I don't have a writing module since I still write my scene files by hand. :|
I hope I'll find the time to make an editor for PoA soon!


I don't know Java at all, so I can't help you ;) ...

Edward_Lii {l Wrote}:When compiling I had some problems with the itoa() functions, although I succeeded in getting it to compile it might be worth it to consider using an alternative?
As stated here http://cplusplus.com/reference/clibrary/cstdlib/itoa/ itoa is not part of C++:
cplusplus.com {l Wrote}:This function is not defined in ANSI-C and is not part of C++, but is supported by some compilers.

A standard-compliant alternative for some cases may be sprintf:


So ... I think itoa() is in stdlib.h, and I don't know whether it's in cstdlib, too ... At least in Visual Studio it works, although produce a lot of warning, too ... I have to admit that I have a bad habit that mixing C headers with C++ headers :| ...
Some of my open source games on GitHub
User avatar
acme_pjz
 
Posts: 665
Joined: 10 Dec 2009, 15:32
Location: PeeKing, China

Re: Some ideas about new block types

Postby Edward_Lii » 06 Apr 2011, 16:13

Hello acme_pjz,

acme_pjz {l Wrote}:Maybe you can post an EBNF description of your file format, or I can invent one after observing your examples ;)

I have no idea how to make an EBNF of my file format.
I'm afraid it isn't easy to do since some parts aren't so consistent.
In general I use a structure like this:
{l Code}: {l Select All Code}
block { //No additional parameters
    property = value //Properties of the block.
   
    block(parameter0, parameter1) //Sample block without parameters
    block(parameter0, parameter1) {
        property = value //Properties of the block.
    }
}  //Closing block

I'll try to explain it as good as possible. ;)
When a block doesn't require parameters the () part can be omitted.
If it does require parameters it means that it requires some values to be initialized, for example in PoA when I initialize a puzzle I need to know the location and the name of the puzzle.
Here's an example:
{l Code}: {l Select All Code}
puzzle(6, 19, ConnectPuzzle) {
   images = green.png, green_done.png
   condition = TreeWater,false,true
   
   notification = While_you_bind_the_roots_together,_the_water_begins_to_rise.
      
   parameters = Tree
      
   #Field size
   parameters = 1, 2, 20, 20
      
   #Marker <X> = <startX>, <startY>, <goalX>, <goalY>
   parameters = 2, 5, 15, 19
   parameters = 2, 10, 20, 18
   parameters = 1, 15, 25, 17
      
   #Obstacles
   parameters = 1, 7, Plank.png
}

Inside the puzzle block you'll find a few properties which are "optional", if not defined it should use a default.
In practice this isn't always true, PoA will crash when there are no images defined. :( (Will be changed somewhere in the future).

There's also a workaround in the puzzle block because it depends on the type of puzzle which and how many parameters it needs.
So I added the parameters property which can be used to add additional parameters.
If I however follow my definition above the property parameters should contain "1, 7, Plank.png", but it contains all parameters concatenated.

acme_pjz {l Wrote}:And a question:
{l Code}: {l Select All Code}
move,100,20,30,1

Does this mean an array of strings, or just a string and its value is "move,100,20,30,1"?

Well in PoA it will be split into an array of strings which will eventually be converted to Integer, float, boolean, etc..

acme_pjz {l Wrote}:Don't laugh, when I'm using Visual Basic, I heavily use these functions, too :D Of course if we want to write a universal reader/writer we don't need to use these function, because the parser is scanning the input stream consecutively, and put the data read to different buffer depend on what character it read. Finally, a tree-like hierarchical data structure is built.

Most of the methods I use are part of Java's String class, which means it should run in every VM, but I think it's a different story with C++.

acme_pjz {l Wrote}:So ... I think itoa() is in stdlib.h, and I don't know whether it's in cstdlib, too ... At least in Visual Studio it works, although produce a lot of warning, too ... I have to admit that I have a bad habit that mixing C headers with C++ headers :| ...

The most important part is that it works, BTW I replaced the itoa() functions with sprintf() which seems to work, not 100% sure. ;)
From,
Edward_Lii
User avatar
Edward_Lii
MnMS Moderator
 
Posts: 777
Joined: 20 Dec 2010, 16:46

Re: Some ideas about new block types

Postby RedReaper132 » 06 Apr 2011, 18:07

Hello there. I have just compiled the game and I must say you really did some great work on it. You are really good, impressive. Also if you are going to use XML then I suggest TinyXML. It's a great XML parser made for C/C++ and it's easy to implement. You also could add a makefile to the source because using cmake is ... well strange. I also have a question, how hard is it to read my code?

Keep up the good work. :)
RedReaper132
 
Posts: 2
Joined: 06 Apr 2011, 17:51

Re: Some ideas about new block types

Postby MCMic » 07 Apr 2011, 07:41

Cmake is great, what is your problem with it oO
User avatar
MCMic
 
Posts: 723
Joined: 05 Jan 2010, 17:40

Re: Some ideas about new block types

Postby acme_pjz » 08 Apr 2011, 19:31

I have invented the file format which is slightly different from your format ;) And upload a reader to SVN. The file format (more or less) is:

<file> ::= <node> --- if bLoadSubNodeOnly=false
or <file> ::= ( <node> | <multiple_node> | <attribute> )* --- if bLoadSubNodeOnly=true

<node> ::= ( <string> = <string> ( , <string> )* | <string> = "(" <string> ( , <string> )* ")" )
{
( <node> | <multiple_node> | <attribute> )*
}

or <node> ::= <string> = "(" <string> ( , <string> )* ")"

<attribute> ::= <string> ( , <string> )* = <string> ( , <string> )*

<multiple_node> ::= (<string> , )* <node>

The string may directly write in the file (can't contain spaces), or enclosed with quotes (can contain spaces, and quotes in string must escaped with two quotes).

Example file is:

{l Code}: {l Select All Code}
size = 800, 600
1,2,3=4,5
1,2=3,4,5
1,2,3=4,5,6
7,8,9=l,k,s,c,t{
  LK=SCT
}
block(0, 50) {
    image = block1.png
}
block(100,100)
death(50, 50) {
    image = spikes.2png
    #control = <TYPE>,<X-Movement>,<Y-movement>,<time>,<loopmode>
    control = move,100,20,30,1

    #Or:
    control(move) {
        movement = 100,20
        time = 30
        loopmode = 1
    }
}
puzzle=6, 19, ConnectPuzzle {
   images = green.png, green_done.png
   condition = TreeWater,false,true
   
   notification = "While you bind the roots together, the ""water"" begins to rise."
     
   parameters = Tree
     
   #Field size
   parameters = 1, 2, 20, 20
     
   #Marker <X> = <startX>, <startY>, <goalX>, <goalY>
   parameters = 2, 5, 15, 19
   parameters = 2, 10, 20, 18
   parameters = 1, 15, 25, 17
     
   #Obstacles
   parameters = 1, 7, Plank.png
}


The parser result is:
{l Code}: {l Select All Code}
AttributeName=size
AttributeValue=800,600
AttributeName=1
AttributeValue=4
AttributeName=2
AttributeValue=5
AttributeName=3
AttributeValue=
AttributeName=1
AttributeValue=3
AttributeName=2
AttributeValue=4,5
AttributeName=1
AttributeValue=4
AttributeName=2
AttributeValue=5
AttributeName=3
AttributeValue=6
AttributeName=7
AttributeValue=l
AttributeName=8
AttributeValue=k
NewNode
        NodeName=9
        NodeValue=s,c,t
        AttributeName=LK
        AttributeValue=SCT
EndNode
NewNode
        NodeName=block
        NodeValue=0,50
        AttributeName=image
        AttributeValue=block1.png
EndNode
NewNode
        NodeName=block
        NodeValue=100,100
EndNode
NewNode
        NodeName=death
        NodeValue=50,50
        AttributeName=image
        AttributeValue=spikes.2png
        AttributeName=control
        AttributeValue=move,100,20,30,1
        NewNode
                NodeName=control
                NodeValue=move
                AttributeName=movement
                AttributeValue=100,20
                AttributeName=time
                AttributeValue=30
                AttributeName=loopmode
                AttributeValue=1
        EndNode
EndNode
NewNode
        NodeName=puzzle
        NodeValue=6,19,ConnectPuzzle
        AttributeName=images
        AttributeValue=green.png,green_done.png
        AttributeName=condition
        AttributeValue=TreeWater,false,true
        AttributeName=notification
        AttributeValue=While you bind the roots together, the "water" begins to rise.
        AttributeName=parameters
        AttributeValue=Tree
        AttributeName=parameters
        AttributeValue=1,2,20,20
        AttributeName=parameters
        AttributeValue=2,5,15,19
        AttributeName=parameters
        AttributeValue=2,10,20,18
        AttributeName=parameters
        AttributeValue=1,15,25,17
        AttributeName=parameters
        AttributeValue=1,7,Plank.png
EndNode
Some of my open source games on GitHub
User avatar
acme_pjz
 
Posts: 665
Joined: 10 Dec 2009, 15:32
Location: PeeKing, China

Re: Some ideas about new block types

Postby Edward_Lii » 09 Apr 2011, 07:02

Hello acme_pjz,

acme_pjz {l Wrote}:I have invented the file format which is slightly different from your format ;) And upload a reader to SVN. The file format (more or less) is:

Looks good, now it's time to define the property names and blocks used in M&MS.
I assume we both agree that for the size of the level we use the property size:
{l Code}: {l Select All Code}
size = <width>,<height>

And a block can stay an block:
{l Code}: {l Select All Code}
block(<x>, <y>) {
    image = <image-file>
}

Then there are the spikes, we could handle it as a special block like this:
{l Code}: {l Select All Code}
block(<x>, <y>) {
    image = <image-file>
    deathly = <boolean>
}

But then again, in M&MS it's handled as a different object type so this would make sense to:
{l Code}: {l Select All Code}
death(<x>, <y>) {
    image = <image-file>
}


acme_pjz {l Wrote}:
{l Code}: {l Select All Code}
1,2,3=4,5
1,2=3,4,5
1,2,3=4,5,6
7,8,9=l,k,s,c,t{
  LK=SCT
}

Although I like the way that 1 is assigned to 3 and 2 to 4,5 I think the use of it is insignificant.
For me it would make more sense if some writes this:
{l Code}: {l Select All Code}
p1,p2=3
p3,p4=3,3,4

That both p1 and p2 will be set to three and in the second example both p3 and p4 will be set to 3,3,4. ;)
What do you think?
From,
Edward_Lii
User avatar
Edward_Lii
MnMS Moderator
 
Posts: 777
Joined: 20 Dec 2010, 16:46

Re: New levelformat

Postby acme_pjz » 09 Apr 2011, 09:08

Edward_Lii {l Wrote}:I assume we both agree that for the size of the level we use the property size:
{l Code}: {l Select All Code}
size = <width>,<height>

I'm sorry, but I don't quite agree "size = <width>,<height>", I prefer "width = <width> height = <height> LevelName= <LevelName>" :| Anyway, "size = <width>,<height>" is not bad ... so it's a deal ;)

Edward_Lii {l Wrote}:And a block can stay an block:
{l Code}: {l Select All Code}
block(<x>, <y>) {
image = <image-file>
}

Then there are the spikes, we could handle it as a special block like this:
{l Code}: {l Select All Code}
block(<x>, <y>) {
image = <image-file>
deathly = <boolean>
}

But then again, in M&MS it's handled as a different object type so this would make sense to:
{l Code}: {l Select All Code}
death(<x>, <y>) {
image = <image-file>
}


IMHO every type of objects share a common node name is better, say: tile(<type>,<x>,<y>){ <additional parameters> } , for example:

{l Code}: {l Select All Code}
tile(block,50,50)
tile(spike,50,100)
tile(playerstart,200,200)
tile(movingblock,300,300){
MovingPosCount=3
x0=...
y0=...
t0=...
...
}


Edward_Lii {l Wrote}:Although I like the way that 1 is assigned to 3 and 2 to 4,5 I think the use of it is insignificant.
For me it would make more sense if some writes this:
{l Code}: {l Select All Code}
p1,p2=3
p3,p4=3,3,4

That both p1 and p2 will be set to three and in the second example both p3 and p4 will be set to 3,3,4. ;)
What do you think?


I think probably we will never use this feature, at least in file writer this format can't appear :) ...
Some of my open source games on GitHub
User avatar
acme_pjz
 
Posts: 665
Joined: 10 Dec 2009, 15:32
Location: PeeKing, China

Re: New levelformat

Postby Edward_Lii » 09 Apr 2011, 09:56

Hello acme_pjz,

acme_pjz {l Wrote}:
Edward_Lii {l Wrote}:I assume we both agree that for the size of the level we use the property size:
{l Code}: {l Select All Code}
size = <width>,<height>

I'm sorry, but I don't quite agree "size = <width>,<height>", I prefer "width = <width> height = <height> LevelName= <LevelName>" :| Anyway, "size = <width>,<height>" is not bad ... so it's a deal ;)

Oh, I think they are equal enough to put into one property.
The same with location, I'd write a spawnpoint like this:
{l Code}: {l Select All Code}
spawn = <x>,<y>

And not like this:
{l Code}: {l Select All Code}
spawn_x= <x>
spawn_y = <y>

But let's keep it "size = <width>,<height>"! :)

acme_pjz {l Wrote}:IMHO every type of objects share a common node name is better, say: tile(<type>,<x>,<y>){ <additional parameters> } , for example:
{l Code}: {l Select All Code}
tile(block,50,50)
tile(spike,50,100)
tile(playerstart,200,200)
tile(movingblock,300,300){
MovingPosCount=3
x0=...
y0=...
t0=...
...
}

You're right, maybe it's better to call them all tile.
But I think we should allow to add an image property to every tile, like this:
{l Code}: {l Select All Code}
tile(block,50,50)
tile(spike,50,100)  //Default spike image is used
tile(spike,100,100) {
    image = spike2.png //Default spike2 image is used
}


acme_pjz {l Wrote}:I think probably we will never use this feature, at least in file writer this format can't appear :) ...

Ok, lets keep it this way.

One thing, when do we use capitals?
I prefer starting properties without an capital:
{l Code}: {l Select All Code}
size = 800,600 //No problem only one word
movingPosCount = 3 //We could start the following words capitals.
movingposcount = 3 //Or completely lower case.
moving_pos_count = 3 //Or even add an underscore between the words.

Which one do you think we should go for?
From,
Edward_Lii
User avatar
Edward_Lii
MnMS Moderator
 
Posts: 777
Joined: 20 Dec 2010, 16:46

Re: New levelformat

Postby acme_pjz » 09 Apr 2011, 12:04

I have commited the converted file, and the size is "size = <width>,<height>" :) Due to the limitation of file writer, the actual properties are "size"="800","600" , a bit ugly ... Anyway, if you write size=800,600 the reader can still read the data correctly, so if you have spare tile feel free to fix this bug ;)

About the image property, currently it's unsupported, but keep an unused property in file won't cause compatibility problems :)

As for the capitals, if you want to change them, you have to update all level files again :(
Some of my open source games on GitHub
User avatar
acme_pjz
 
Posts: 665
Joined: 10 Dec 2009, 15:32
Location: PeeKing, China

Re: New levelformat

Postby Edward_Lii » 09 Apr 2011, 13:35

Hello acme_pjz,

acme_pjz {l Wrote}:I have commited the converted file, and the size is "size = <width>,<height>" :) Due to the limitation of file writer, the actual properties are "size"="800","600" , a bit ugly ... Anyway, if you write size=800,600 the reader can still read the data correctly, so if you have spare tile feel free to fix this bug ;)

I'll see what I can do! ;)

acme_pjz {l Wrote}:About the image property, currently it's unsupported, but keep an unused property in file won't cause compatibility problems :)

I understand, we can always implement it later.

acme_pjz {l Wrote}:As for the capitals, if you want to change them, you have to update all level files again :(

In PoA I check the properties against a lowercase version this way the capitals don't matter.
But for the style convention I use no capitals at the beginning of a property.
Let's keep it how it is, it isn't to important. :)
From,
Edward_Lii
User avatar
Edward_Lii
MnMS Moderator
 
Posts: 777
Joined: 20 Dec 2010, 16:46

Re: New levelformat

Postby Edward_Lii » 09 Apr 2011, 15:09

Hello acme_pjz,

Edward_Lii {l Wrote}:
acme_pjz {l Wrote}:I have commited the converted file, and the size is "size = <width>,<height>" :) Due to the limitation of file writer, the actual properties are "size"="800","600" , a bit ugly ... Anyway, if you write size=800,600 the reader can still read the data correctly, so if you have spare tile feel free to fix this bug ;)

I'll see what I can do! ;)

Committed a fix, it's only one line long and it seems to work.
I added this line in the ReadString method:
{l Code}: {l Select All Code}
switch(c){
   case ' ':
      break;  //Instead of returning we just suppress this character.
   case EOF:
   case '\r':
   case '\n':
   case '\t':
      return;
   case ',':
   case '=':
   case '(':
   case ')':
   case '{':
   case '}':
   case '#':
      fin.unget();
      return;
   default:
      s.push_back(c);
}
c=fin.get();
...

I hope this doesn't break the loading system in anyway, from the tests I did it seems to work fine.
I started changing it in leveledit.map, only the first few lines.

Oh and there was a problem I had when compiling.
I got this error:
{l Code}: {l Select All Code}
/home/edward/Programming/MeAndMyShadow/src/TreeStorageNode.cpp:81:31: error: cast from ‘void*’ to ‘unsigned int’ loses precision

This only happens on 64-bit systems, I changed it into this:
{l Code}: {l Select All Code}
unsigned int i=(intptr_t)lpUserData;


BTW, how do you define which of the three different solid blocks a tile is? ;)
AFAIK you only say tile("Block", <x>, <y>)
From,
Edward_Lii
User avatar
Edward_Lii
MnMS Moderator
 
Posts: 777
Joined: 20 Dec 2010, 16:46

Re: New levelformat

Postby acme_pjz » 09 Apr 2011, 15:30

Edward_Lii {l Wrote}:
...

Committed a fix, it's only one line long and it seems to work.
I added this line in the ReadString method:
{l Code}: {l Select All Code}
switch(c){
case ' ':
break; //Instead of returning we just suppress this character.
...

I hope this doesn't break the loading system in anyway, from the tests I did it seems to work fine.


Unfortunately, it DOES break the loading system (but don't worry, it won't make mistake if you just restricted to read the file which is writer generated), because In my design the following file:

{l Code}: {l Select All Code}
aaa=bbb ccc=ddd eee=fff


is equal to

{l Code}: {l Select All Code}
aaa=bbb
ccc=ddd
eee=fff


After your change everything goes wrong ... Anyway, The write can't generate this kind of file ;)

As for the "bug" I mean there should be some improvement in file writer: the writer should first check if the string contains character which need to escape, for example whitespace, "(" ")" "=" "," "{" "}" and so on ... if it contains, then the string must enclosed with quotes, otherwise it doesn't need. So after the patch the writer should generate size=800,600 instead of "size"="800","600" ...

Edward_Lii {l Wrote}:Oh and there was a problem I had when compiling.
I got this error:
{l Code}: {l Select All Code}
/home/edward/Programming/MeAndMyShadow/src/TreeStorageNode.cpp:81:31: error: cast from ‘void*’ to ‘unsigned int’ loses precision

This only happens on 64-bit systems, I changed it into this:
{l Code}: {l Select All Code}
unsigned int i=(intptr_t)lpUserData;



There is really a problem, even in Visual Studio it produces a warning, too ... Maybe I'm too lazy, I think that the pointer type can contains an integer, so I reused the pointer, avoiding create a new variable ...

Edward_Lii {l Wrote}:BTW, how do you define which of the three different solid blocks a tile is? ;)
AFAIK you only say tile("Block", <x>, <y>)


I just didn't changed the block load code, now it's still depending on random number :| And I think it's convenient to use random number instead of reading from file ... I have an idea: the picture will be random if you don't specify the picture file, otherwise it will use the given picture file. Is it OK?
Some of my open source games on GitHub
User avatar
acme_pjz
 
Posts: 665
Joined: 10 Dec 2009, 15:32
Location: PeeKing, China

Re: New levelformat

Postby Edward_Lii » 09 Apr 2011, 15:58

Hello acme_pjz,

acme_pjz {l Wrote}:Unfortunately, it DOES break the loading system (but don't worry, it won't make mistake if you just restricted to read the file which is writer generated), because In my design the following file:
{l Code}: {l Select All Code}
aaa=bbb ccc=ddd eee=fff

is equal to
{l Code}: {l Select All Code}
aaa=bbb
ccc=ddd
eee=fff

After your change everything goes wrong ... Anyway, The write can't generate this kind of file ;)

Oh I see, I think this fix is good enough, it just restricts the use of multiple property/values on one line.
I don't think this is a very big problem. :)


acme_pjz {l Wrote}:There is really a problem, even in Visual Studio it produces a warning, too ... Maybe I'm too lazy, I think that the pointer type can contains an integer, so I reused the pointer, avoiding create a new variable ...

It has something to do with casting a void* to an int, which will fail on 64-bit systems since an int can't hold an 64-bit pointer.
But I searched for a solution and using intptr_t should solve the problem and it did! ;)

acme_pjz {l Wrote}:I just didn't changed the block load code, now it's still depending on random number :| And I think it's convenient to use random number instead of reading from file ... I have an idea: the picture will be random if you don't specify the picture file, otherwise it will use the given picture file. Is it OK?

That's a good idea, the default behaviour would be random and if you don't want that for whatever reason you can specify it, I like it. :cool:
From,
Edward_Lii
User avatar
Edward_Lii
MnMS Moderator
 
Posts: 777
Joined: 20 Dec 2010, 16:46

Who is online

Users browsing this forum: No registered users and 1 guest

cron