Sorry for the long wait.
Last week I came back from USA, and had one those weeks in your life where you feel you don't have time neither to breathe.

Anyway, I'm not away, and I hope that from now on, I'll be able to carry on with the project at a more interesting pace.

During this period anyway I had the time to check around and try to solve the most important problems from my point of view and experience those are bound to the prototyping stage.

They are : finding suitable formats for the levels and level editing, judge what level of scripting / event handling is needed, see what format all the ingame data should use.

Set those key elements the development can go on smooth.
I would have suggested to use for both the versions a unified file format set to make the data platform independent, but I saw the guys from the flash version are setting their standards.

For the moment I'm evaluating the WinMappy tool for level editing. It has a not so difficult way to cope with level editing.

Anyway that's not true when it comes to edit the position of enemies, bonus, sensible hotspots for event trigging, musics and sfx linking.

It lacks even entities property editor (for example for every enemy to set how much energy, set of actions, kind of objects droppable and with which probability).

I would say specific tools for this task will have to be coded, since I wasn't able to find suitable ones.

I read somewhere, someone was trying to make a level editor. That could be interesting to discuss it togheter and set export file formats, and some features.
Ingame code is easy to make, it's the toolset, and the initial decisions that will avoid wasting 80% of development time (there is an engineering rule that says 80% of the time will be spent trying to solve problems arising from the other 20%, or something like that).

Everyone willing to help with tools coding, or with ingame code, will please post here, with a short description of their attitudes.
If you can, post an MSN contact so I can keep up with everyone easily.

Thanks for your time and help.

Hi!

I have one year of experience with C++ and with programming games. I would like to help as I am not motivated to continue working on my own game ATM.

Hey Crash,

As I said before, I can help with the C++ coding part. I'm doing my own level editor because I wasn't very happy with Mappy or TileStudio.

Here's the simple file format I came up with:

uchar id[3] = "MAP"
uchar file_version
uchar bmp_name_length
uchar bmp_name[length]
ushort bmp_tiles_per_row
ushort map_rows
ushort map_cols
uchar tile_width (in pixels)
uchar tile_height (in pixels)
uchar map_format = 0 or 1

if map_format is 0 then the map is written as a sequence of uchars:

uchar map_array[map_rows * num_cols]

(we can have a maximum of 255 tiles. It's useful if we have few tiles like in a background with some mountains and clouds)

if map_format is 1 then the map is written as a sequence of short integers:

short map_array[map_rows * num_cols]

(this is good when we need alot of tiles, animated tiles like dancing flowers or compound tiles)

and finally we have:

ushort num_tiles_in_bmp
uchar flags[num_tiles_in_bmp]
uchar end_of_file = 0

I don't know if the guys will understand that. If you need more explanation, just tell me. It'll be good to agree on a common file format.

So, basically, map data is kept separate from the graphics. For example, for the first level, we'd need the folowing files:

level1-background.map
level1-background.bmp

level1-foreground.map
level1-foreground.bmp

Animated tiles and compound tiles are not yet implemented in my editor.
I'm open for discussion on wich file format best suits for the game.


Edited by initial_reality

Then I'll try to explain it a little better:

uchar stands for unsigned char. It's a variable that goes from 0 to 255 and occupies one byte (8 bits) in the file.
ushort stands for unsigned short integer, it occupies 2 bytes (16 bits) and goes from 0 to 65535.
short is a signed short integer, it also occupies 2 bytes and goes from -32767 to +32767.

When you have something after the variable name, between square brackets, it really means you have a sequence of variables of that kind. For example, in:

uchar flags[num_tiles_in_bmp]

if there are 100 tiles in the bitmap then the num_tiles_in_bmp is 100 and we have a sequence of
100 uchars in the file. In C, we can write/read any value to/from this array using an index between the square brackets:
flags[0] = 1

I forgot to say that flags are used to detect collision between sprites and tiles. For example, if the first bit is set, then the sprite cannot go through the tile, from the left to the right.

I understood it, but I've never coded a format before so I dunno if there're any problems or not. With the general coding, I can make source but my compiler is gay, so no .dlls or .exes for me.

Sorry, but then I am out! I have never done anything with SDL, but worked with Allegro /AllegroGL all the time. But if you need tools or something else where no SDL is involved, I am in. :-)


Edited by imaxcs

It all depends on how the xml is structured.

Crash: i might be able to help. what are the open positions? (yes, positions with responsibility and power, i'm not looking for any random tasks coming from above;)...

what kind of open source license are you thinking of?

...and i would like to take a peek at your engine structure/codebase/coding style, just for interest...

You forgot to include borlndmm.dll

To the level designers:
About the tool. Well that's a beginning. But at this point I would ask the help of the people from the level design part. I don't want to force anything, and I would like to hear others opinion. So do not hesitate to post your comments so I can clarify my mind about the tool argument.

initial_reality:
essentially, that a very early stage. I hope you are taking in account many things that could result in a pain later on. I saw you trying to contact me, but unluckly it seems our timings are completely out of sync. That's why if everyone agrees in going on with your tool, we should write a public document with the feature set to be implemented. For personal notes, for example, I would like to know if you are taking in account observers, purging, and actions for do/undo cycling. At this stage that's early to see anything on the program, so I'm asking. By the way, if we agree, we could start with the document. This way we could work out the export format, (there is time for an XML exporter later by the way), and start running some tests. Take in account there are plenty of level editors, but there is a lack of "game editors". And that's towards what we should head. On my half I can support by writing some pieces of code, or some libs if we find we need some specific ones. For my experience the tool is a huge task like the engine, so do not hesitate to ask and talk before everything else. For me keep up with the good work, and go with your tool but I want to hear everyone else. See you soon, mate!

Ork:

Well, man, I'm not thinking about all those hieararchy stuff. That's overall a simple project, I don't think there is a big deal about "power holding" positions. That's simplier, I mean, I'm not thinking about something "huge", just making up what's needed for this game to run, and what comes out could be opensource. But maybe, I misunderstoond what you meant, so please clarify the point for me.

randomblink:

I'm testing some functionalities of the code, I usually have a lot of coding even before I see a single pixel on the screen. When you are on msn by the way, i'd like to show you something for amusement.. eheh. See you !

To all the others involved:

That's really nice how everything is shaping up. I'm glad we are working together!

@Crash: Sure we can write a document on wich features are to be implemented.
Some I'm planning to add to version 0.2:
- brush locking to width/height (so they don't overlap)
- undo/redo actions
- PNG support
- opengl rendering (maybe)
- multiple brushes (like in WinMappy)
If you think you need collision maps and an exporter, I can do it too. My english is not very good, so maybe you should start the document ? I hope the map designers are aware of my editor. Cause I need to know what they think, and what tools they need to make the best map ever!

@Ork: That's fun man!

and so... Ork...
If you would like to carry the torch from here...
Let me know!

Yes, I don't post alot but I'm always checking for the game progress. And I can tell it's leaving the grounds :) My map editor hasn't evolved much tough, I have a new job too, and I haven't found much time to program the editor. However, it's not hard to make an exporter to some format if kwigbo wants it. I don't know were he is with his map editor.

It would be good to focus one level at time so there's a demo ready for the first level. Instead of people contributing here and there with graphics, they could focus on a single level to get it ready. I think tiles of 32x32 pixels are too big. But those are just my ideas :)

initial_reality: i think the minimum requirements for the editor is a little bit more than just the tiles. At least objects (enemies, items...) are needed. Do you think it would be possible?
Of course it would be nice to have full wysiwyg (play at the same time you edit;), but i understand you probably want to keep your editor as a standalone program so that it's not dependent on the game itself...

miau: that's great!... no need to know SDL at all, it's completely hidden behind interfaces. if particle (effects) is what you like to do, then particles will it be;) we'll get back to this...

first release: The base framework.
i've used visual c++ 6.0 to manage the project. if you have any other IDE, let me know and we'll figure out how to get it work.
PJGame_rel0001.zip

Directories in the package:
bin/              contains the executables and data.
code/            source code (currently only 4 files)
lib/               external libraries we will be using
VCProject/    project file

...next, i will put up some example code how to load images etc, all the basic stuff you'll ever need...

...ps. i would like to hear opinion from the graphics guys about screen and tile sizes?
edit: and yeah, trying to contribute graphics for mainly one theme sounds like a good idea...



Edited by Ork

Boder, good point. To make it clear, here's couple of quotes:

Randomblink said:
"There are two different branches, but I do want the game to play similar for both systems. The biggest thing I want is that when we have a manual on how to play, it works for both systems. Little things like screen size and what not, no worries... those can be different. Sprites and Tiles sizes should be either worked on to match..."

Kwigbo said:
"As for the tiles 24 x 24 shouldnt be a problem. I am trying to make this engine as flexible as possible so I can reuse it. When i'm done i'll be able to use any sized tile. If 24x24 is what you need you got it. Although the tiles already made will have to be altered to the new size."

miau: I myself have looked into and considered doing some GBA development... I would LOVE to see this game make it into GBA / DS development... THAT would be sweet...

If GBA / DS is considered, a tile size of 16x16 would be even better.

@Ork: I'll add something place objects.

I'd go with 24x24 since it would not be too small for the flash version and not too big for the C++ port, i.e. we could stick to a relatively small resolution (I suppose we still want to use the same tile sizes for every branch?)
20x20 seems rather unusual and when thinking about the GBA it would lead to problems since tile dimensions should be divisible by 8 on it.

On the other hand I'd like the other objects to be resized as well so 16x16 would look ok and thus porting it to the GBA would be no problem. Dunno if that's up for debate =(

whoa, lots of work. at least it shouldn't be mandatory for the artist.

Let's keep the current sprite set (with 24x24 tiles?) and if someone wants to start a conversion project to smaller scale, he's free to do so? GBA is cool, but majority of people still use pc;)



Edited by Ork

Looks cool Ork, I like the logo intro. Im getting confused about the tile size discussion here. Someone should make a sticky topic with all sizes when the discussion is done. I still hope you don't think too big with all the different platforms. I want to play this in the near future.

PJGame_dbg0003.zip (Source included)

PJGame_rel0003.zip (Exe only, contains some fishes...hmm;)

dp: thanks... i hope that the case is closed very soon...

Edited by Ork

Maybe I don't fully understand... why can't the tile sizes be the same size on both platforms??

i want something set in stone!

24 x 24 is the tiles size set in stone. As agreed on by ork and myself.

another update..basic movement added...

PJGame_rel0004.zip