PJ The Game : C++ Section
Printed From: Pixel Joint
Category: The Lounge
Forum Name: Programming
Forum Discription: Game programmers unite!
URL: https://pixeljoint.com/forum/forum_posts.asp?TID=1477
Printed Date: 24 April 2026 at 8:50am
Topic: PJ The Game : C++ Section
Posted By: Crash_universE
Subject: PJ The Game : C++ Section
Date Posted: 22 January 2006 at 9:46am
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.
------------- One universe.. One Brain..
CrashTheuniversE
|
Replies:
Posted By: randomblink
Date Posted: 22 January 2006 at 10:12am
Excellent Crash...
Way to go! I like it...
As for the flash guys moving ahead... I am pretty sure that nothing is
set in stone... So if you have an idea? Let us know, I am sure it could
be incorporated still...
Well, keep up the great work...
And for all you coders out there? If you know how to build tools? Let
Crash know, he needs a solid team of coders so we can see this game
move ahead...
Well, that's all from this Ninja Squirrel...
peace out
------------- www.randomblink.com
I am me... no! Really!
|
Posted By: imaxcs
Date Posted: 22 January 2006 at 12:54pm
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. 
------------- Don't let the dark side take control of you...use smileys!
---
http://everlands.imaxcs.com/ - http://everlands.imaxcs.com/
|
Posted By: kwigbo
Date Posted: 22 January 2006 at 2:47pm
Nothing in the flash version is set in stone except for the fact that
because of performance issues it has to be tile based with 16 x 16
tiles.
------------- http://www.kwigbo.com">
|
Posted By: initial_reality
Date Posted: 22 January 2006 at 3:20pm
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.
|
Posted By: kwigbo
Date Posted: 22 January 2006 at 3:28pm
I can code games in flash but that all looks greek to me.
------------- http://www.kwigbo.com">
|
Posted By: initial_reality
Date Posted: 22 January 2006 at 4:03pm
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.
|
Posted By: randomblink
Date Posted: 22 January 2006 at 4:19pm
Originally posted by kwigboI can code games in flash but that all looks greek to me.
Don't you mean to say... "It all looks GEEK to me"... (?)
chuckle...
Yeah, so I laugh at my own jokes... get over it...
Peace
------------- www.randomblink.com
I am me... no! Really!
|
Posted By: Monkey 'o Doom
Date Posted: 22 January 2006 at 7:09pm
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.
------------- http://pixelmonkey.ensellitis.com">
RPG is numberwang.
|
Posted By: Crash_universE
Date Posted: 23 January 2006 at 4:04am
To initial_reality :
Well, If your tool can make better then mappy even of the background layers editing, then i'd like to see it. About the file format usually that's agreed with the engine coder since you have the data on the native format and that's only the way you export the data that changes, for me instead I could lack some information.
As kwigbo is doing, I would better like to have XML as well for all the game logical structures, instead of dedicated file formats. Mappy isn't able to do that as well, so if you think that's easy for you, maybe using TinyXML or any Builder built in support for it, let me know. Otherwise we'll keep on with our own fileformat for now, and see later an exporter/loader for XML.
Essentially I would like to talk more indepth with you and see the work in progress of the tool. Take in account the file format is going to be somewhat complex. No panacea of simplicity, but the right amount of complexity. For example I would like to avoid the flags for collisions and such. I'd rather use a collision map with 1 to 2 bytes per tile. I'll explain the reason of this on the dev site, or on MSN.
Take in account that if we agree to go on with the internal file format, we could run early tests this week, and some things will have to change.
imaxcs :
Can you start showing something using SDL? That's the library we will be using for the first game driver (maybe OpenGL or DirectX will come later). Either a sprite movement system like the one made by the flash section friends, or a particle / special FX test will be fine.
------------- One universe.. One Brain..
CrashTheuniversE
|
Posted By: imaxcs
Date Posted: 23 January 2006 at 9:03am
|
Originally posted by Crash_universE
Can you start showing something using SDL?
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. :-)
------------- Don't let the dark side take control of you...use smileys!
---
http://everlands.imaxcs.com/ - http://everlands.imaxcs.com/
|
Posted By: initial_reality
Date Posted: 23 January 2006 at 5:14pm
@Monkey: try mingw-gcc
@crash: I added you to my MSN. My editor is very simple right now. Can I send it to you by e-mail ? I'd like to know why you say collision maps are better than one flag per tile. To me it's rather expensive.
Also, I can make a XML exporter but I think it's worthless if kwigbo is not gonna use it.
|
Posted By: kwigbo
Date Posted: 23 January 2006 at 5:40pm
|
Originally posted by initial_reality
Also, I can make a XML exporter but I think it's worthless if kwigbo is not gonna use it.
It all depends on how the xml is structured.
------------- http://www.kwigbo.com">
|
Posted By: Crash_universE
Date Posted: 27 January 2006 at 8:58am
initial_reality:
Yes, send me by e-mail what you're up to, so I can check it. Up to now I'll be still favourable to the Mappy editor, but I want to see what we can get out of your work. For the collision at 1 byte, is to store up to 255 different behaviours. For example 1, collision, 2 trig a sound, 3 deal 10 damages per second, make player bounce, slick, and so on, or set a specific event tag. 255 should be enough anyway, Sometimes i use 16bits maps for more complex games. Someone could argue about using logic objects like sprites with void graphics and area effect, but I've seen sometimes that's a pain at level editing time to use them exclusively, so a nice mix would be optimum.
To all the others: I still seek help, I've layed down a structure of the engine, with classes for renderer, rendering targets, sprites, surfaces, text and sprite text, ogg and wave playback, system handler and logger, and some more. I will provide a doxygen early documentation, a simple project setup doc (with libs needed) and the project itself. Once I'm up to a neat introduction I'll show the .exe as well. The engine will be released as opensource once done and in wip, so everyone can ask for it.
See u guys!
------------- One universe.. One Brain..
CrashTheuniversE
|
Posted By: Ork
Date Posted: 28 January 2006 at 1:44am
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...
|
Posted By: initial_reality
Date Posted: 28 January 2006 at 1:31pm
Ok, I'll just post it here. Ask for features. Give me feedback.
http://www.upshack.com/./uploaded-files/200601/Oh-no! 0.1.zip - Oh-no! 0.1
EDIT: I forgot to say you can use the keys 2,4,6 and 8 to move around the tiles image.
|
Posted By: Monkey 'o Doom
Date Posted: 28 January 2006 at 3:00pm
You forgot to include borlndmm.dll 
------------- http://pixelmonkey.ensellitis.com">
RPG is numberwang.
|
Posted By: Brian the Great
Date Posted: 28 January 2006 at 3:03pm
http://www.dll-files.com/dllindex/dll-files.shtml?borlndmm - Get it here.
------------- http://www.twoschizos.com">
|
Posted By: Crash_universE
Date Posted: 30 January 2006 at 11:53am
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!
------------- One universe.. One Brain..
CrashTheuniversE
|
Posted By: Ork
Date Posted: 30 January 2006 at 12:16pm
heh i express myself not so clear;)... for example i could supply the
physics/graphics in form of static library. meaning a kind of separate
project from the main game and i would be doing it independently,
filling your needs tho, but having the "power of decision making" about
it's solutions, license(freeware)...
...actually i've been playing with physics lately, heres a small 2d
demo, optimized for tilebased maps (note it tests only edges, not
vertices yet...) http://koti.mbnet.fi/satte/dl/MPF_Physics2D.zip - http://koti.mbnet.fi/satte/dl/MPF_Physics2D.zip
...and im always thinking huge;)
-------------
|
Posted By: initial_reality
Date Posted: 30 January 2006 at 2:24pm
@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!
|
Posted By: Crash_universE
Date Posted: 02 March 2006 at 11:44am
Guys, I know I disappeared for a long time. I have no words to beg you all pardon for this fade away from the scenes. I talked to Randomblink some minutes ago on MSN. Unluckly in the last three months a lot of things changed and since I'm back from USA I changed job, and I spend a lot of time out of Italy. I don't want to bore you all with the details, but for example, I came back home only on monday, after almost 3 weeks out of Italy, from london to rome back to my house... and didn't either find the time to see my girlfriend yet! (Yes I told this to randomblink as well...).
I can only apologize on more time for what I'm saying next, that is, unluckly the situation is not going to change in the next months limiting my spare times to almost 0. That's why I must resign from my position. I know I should have told this earlier, but I thought I would have been able to find the time still to code, but I keep on carrying work at home, and spend some nights over it.
I loved the project, and I joined it with the best spirit to complete it. Unluckly this things happen, and you can't forecast it sometimes.
I saw there are other people like Ork, those are talented and could keep on with my current position, moreover the flash section seems to run very well.
I will keep on look at the forum, posting from time to time. I really hope you can understand guys, and find a way to pardon me.
Thank you all very much, keep up with the good work, my gratz.
CrashTheuniversE.
------------- One universe.. One Brain..
CrashTheuniversE
|
Posted By: randomblink
Date Posted: 02 March 2006 at 11:58am
and so... Ork... If you would like to carry the torch from here... Let me know!
------------- www.randomblink.com
I am me... no! Really!
|
Posted By: Ork
Date Posted: 04 March 2006 at 3:45am
crash: that's life...at least you got one;)
randomb: i'll try.
initial_reality: you still there?
everyone: ...hoping to get lots of input from you, be it anything;)
---
so... i'm a bit late here, but still i would like to go back to some basics:
Screen size:
is 320x240 ok? It is small enough to work with, it's somekind of a
standard (QVGA) + it scales nicely to full screen with double sized
pixels as snader requested;)
(Flash screen size is still controlled by flash department)
Tile size:
I talked with Kwigbo and it should be okay to make another change to
the sizes. 32x32 seems too big to me compared to other objects (look at
the mockup, there's 32x32 and 24x24 side to side as gray blocks)
Another thing is, that not too many big tiles fits on screen (look at
mockup again;). I hope it wouldn't be much work to redraw the current
ones? Or should it remain 32x32?

And finally, i think it would be best to concentrate on just one single
level at the beginning, programming-wise. Ocean seems to contain
most of the pixels atm...so underwater we go?
that's it...(except i tried to turn dp's shell into an enemy;)
|
Posted By: initial_reality
Date Posted: 04 March 2006 at 7:17pm
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 :)
|
Posted By: miau
Date Posted: 05 March 2006 at 12:00am
32x32 tiles on a 320x240 resolution definitely seems a bit awkward You could also increase the resolution.. but I favor 320x240 as well  If you still need coders in the c/c++ section... I could help with small things and probably even with larger and more time-consuming ones. SDL should be no problem. Also, I've been messing around with sprite/particle engines etc. quite a bit.
------------- ...
|
Posted By: Ork
Date Posted: 05 March 2006 at 7:22am
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.
http://koti.mbnet.fi/satte/pj/release/PJGame_rel0001.zip - 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...
|
Posted By: Boder
Date Posted: 05 March 2006 at 10:52pm
Are the two games going to be very different from each other? I think you are going to want to share tiles and sprites with the flash game. That means 32x32 tiles.
http://pixeljoint.com/forum/forum_posts.asp?TID=1456&PN= 1
|
Posted By: Ork
Date Posted: 05 March 2006 at 11:02pm
|
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."
|
Posted By: miau
Date Posted: 06 March 2006 at 11:30am
I'd have to get a bit into particle systems again to be able to provide a more professional one than in my own sloppy game attempts. Well, this would probably the case for everything else as well.. Usually I do things based on personal logic and programming experience because there is no way I'll ever release any of my projects (especially not its source code)  Atm I'm taking a peek at GBA development.. seems to be a lot of fun. If anybody has got plans on making a gba branch of this game I'd be glad to help <3 Although 24x24 still seems to be an enormous tile size for its 240x160 LCD screen.
As a matter of course we should aim at creating easily portable code anyway.
------------- ...
|
Posted By: randomblink
Date Posted: 06 March 2006 at 1:38pm
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...
------------- www.randomblink.com
I am me... no! Really!
|
Posted By: Shark
Date Posted: 06 March 2006 at 1:58pm
if that happened i might by a DS, even tho there sh*te compared to psp.
------------- Snark, we love yuu.
|
Posted By: initial_reality
Date Posted: 06 March 2006 at 2:43pm
If GBA / DS is considered, a tile size of 16x16 would be even better.
@Ork: I'll add something place objects.
|
Posted By: Ork
Date Posted: 06 March 2006 at 11:47pm
|

here's your mockup for GBA size. Smaller tile is ok here if taken out of the context, but other objects seem to get quite big.
I'd suggest, forget the screen size for now and choose a tile size which has the best look and feel compared to the other graphics in the game? 16x16, 20x20, 24x24, 32x32 are the nominees.
|
Posted By: miau
Date Posted: 07 March 2006 at 5:09am
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 =(
------------- ...
|
Posted By: randomblink
Date Posted: 07 March 2006 at 6:50am
Here's a thought... What does everyone think about doing a double size? I don't really know how badly this would affect a time-line / schedule, but we could pick two sizes, 16x16 AND 32x32 or whatever. Then all tiles, sprites, etc would have to be done in dual sizes? Or we could do a mid-size between the two and resize larger for one and smaller for the other...?
Just thinking out loud... Either shoot it down with good reasons NOT to do it? Or tell me WHY you like it...
------------- www.randomblink.com
I am me... no! Really!
|
Posted By: Ork
Date Posted: 07 March 2006 at 7:32am
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;)
|
Posted By: Ork
Date Posted: 07 March 2006 at 9:52am
...meanwhile...
There's the second release (contains only executables and data). Has tilemap and some other tests;)...
http://koti.mbnet.fi/satte/pj/release/PJGame_rel0002.zip - PJGame_rel0002.zip
|
Posted By: d-p
Date Posted: 08 March 2006 at 2:07am
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.
------------- http://iso.webmonk.de"> http://cc.webmonk.de">
|
Posted By: imaxcs
Date Posted: 08 March 2006 at 11:32am
|
There's the second release (contains only executables and data). Has tilemap and some other tests;)...
Would you mind showing the source? I'd like to take a peek...
------------- Don't let the dark side take control of you...use smileys!
---
http://everlands.imaxcs.com/ - http://everlands.imaxcs.com/
|
Posted By: Ork
Date Posted: 08 March 2006 at 1:40pm
http://koti.mbnet.fi/satte/pj/release/PJGame_dbg0003.zip - PJGame_dbg0003.zip (Source included)
http://koti.mbnet.fi/satte/pj/release/PJGame_rel0003.zip - PJGame_rel0003.zip (Exe only, contains some fishes...hmm;)
dp: thanks... i hope that the case is closed very soon...
|
Posted By: miau
Date Posted: 09 March 2006 at 5:44am
Nice! =) At this rate the game will be finished in no time  ..guess I'll take a closer look at the source when I come home
------------- ...
|
Posted By: pixelblink
Date Posted: 09 March 2006 at 8:18am
|
Originally posted by d-p
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.
Maybe I don't fully understand... why can't the tile sizes be the same size on both platforms??
-------------
|
Posted By: randomblink
Date Posted: 09 March 2006 at 8:26am
They actually can... We just need the two team-leaders to organize and discuss amongst themselves...
Kwigbo and Ork... which is it gonna be...? Let's pick a size...
------------- www.randomblink.com
I am me... no! Really!
|
Posted By: Shark
Date Posted: 09 March 2006 at 9:11am
i want something set in stone!
------------- Snark, we love yuu.
|
Posted By: randomblink
Date Posted: 09 March 2006 at 10:16am
Amen brutha
------------- www.randomblink.com
I am me... no! Really!
|
Posted By: kwigbo
Date Posted: 09 March 2006 at 10:47am
24 x 24 is the tiles size set in stone. As agreed on by ork and myself.
------------- http://www.kwigbo.com">
|
Posted By: Ork
Date Posted: 10 March 2006 at 12:03am
|
Cool, so we can move on;)...
Now, some remarkable things about c++ side:
- If your FPS ever drops below 64, be alarmed (for example i'm not
sure if everything works in fullscreen, regarding vsync...) If this
happen please let me know... - If you want to help with the
code, don't be frightened of the current source: we'll set
up an environment where you can start from the clean table. Here's
some examples you could be doing: AI for enemies, cutscene
animations, particle effects, user interface..
or an entire minigame from the minigames threa?... pm me or post here...
|
Posted By: Ork
Date Posted: 11 March 2006 at 11:30pm
another update..basic movement added...
http://koti.mbnet.fi/satte/pj/release/PJGame_rel0004.zip - PJGame_rel0004.zip
|
Posted By: Boder
Date Posted: 12 March 2006 at 12:08pm
Ork, maybe you could explain a little bit more about the code and content pipeline.
Like how the .gfx files are made, what MPF is, what the other dependencies are.
Also, what file format are we thinking of for storing level data and user preferences? Text, binary, XML, or SQL?
One thing I would definitely suggest is to put the tiles on one image that is size power-of-two and use bounding rectangles for drawing instead of having many small images. This sort of thing makes it very portable across engines/libraries that use OpenGL or Direct3D. I have seen some of the ugly things that result from switching from SDL to OpenGL.
|
Posted By: initial_reality
Date Posted: 12 March 2006 at 6:02pm
|
Originally posted by Boder
Ork, maybe you could explain a little bit more about the code and content pipeline. Like how the .gfx files are made, what MPF is, what the other dependencies are.
I feel the same way. Were is the tile map stored rigth now?
About my editor: I can place objects in the map but I have to write the code to save'em to the map file.
Ork, can send-me your msn?
|
Posted By: Ork
Date Posted: 12 March 2006 at 11:44pm
|
I have started a technical document here. If it doesn't answer your questions now, it will later;) http://koti.mbnet.fi/satte/pj/doc/PJGame_Tech.txt - http://koti.mbnet.fi/satte/pj/doc/PJGame_Tech.txt This will be maintained in the debug package from now on.
> Boder: Also, what file format are we thinking of for storing level data and user > preferences? Text, binary, XML, or SQL?
I prefer binary. it's fast and simple. Formats must be discussed though...
> Boder: One thing I would definitely suggest is to put the tiles on one image > that is size power-of-two and use bounding rectangles
I'll change it for you
> Initial_Reality: Where is the tile map stored rigth now?
Look at GameWorld.cpp .. contains some ugly hardcoded hacks Note that everything starting with TEST-keyword will be removed/changed...
I'll setup MSN. don't have account yet...
|
Posted By: Boder
Date Posted: 13 March 2006 at 1:14am
I'm going to vote for text files. There are some very good reasons for this.
Binary files are very opaque so you have to document them like initial_reality did in this thread. Text files can be somewhat self-explanatory and digestable by humans 
Binary files are not as flexible. I have a feeling throughout the game we are going to want to make many little changes. With a well designed text file you can simply drop in a new section and still be backwords-compatible. Binary files are less forgiving between versions.
Easier to debug.
With binary files, you have to be concerned with endianness. Best to play it safe.
Binary files load faster, but I don't think you'll notice the difference. Remember, "90% of the time is spent in 10% of the code"
|
Posted By: imaxcs
Date Posted: 13 March 2006 at 8:53am
XML-files all the way. In combination with TinyXML, it's really simple to use and yet very powerful. :)
------------- Don't let the dark side take control of you...use smileys!
---
http://everlands.imaxcs.com/ - http://everlands.imaxcs.com/
|
Posted By: miau
Date Posted: 13 March 2006 at 11:51am
I always used binary files in my projects as well.. I was too lazy to code a decent parser/invent a decent syntax scheme for a text file format.
Well, why reinvent the wheel if TinyXML takes care of most of that? Although I'm not too acquainted with XML itself, but I guess it would be a good choice... Implementing an XML based format in Flash should be no problem so level data could be shared easily, right?
Well, I messed around with bg layers and sprites on GBA recently.. merely for self-education, not going to continue it and nothing special. Just to see how PJ would look on the GBA.
http://web1.vs5122.vserver4free.de/meow/PJtest.gba - PJtest.gba
Works well with VBA and any other emulators... probably :S
------------- ...
|
Posted By: kwigbo
Date Posted: 13 March 2006 at 1:20pm
The flash game will be using XML. Something to think about if ya wanna try to use the same level structure. Instead of making the levels twice once for each game.
------------- http://www.kwigbo.com">
|
Posted By: Boder
Date Posted: 13 March 2006 at 3:14pm
I think it is something we want to think about! 
We would only need one level editor. Has someone started on a level editor in flash?
|
Posted By: Ork
Date Posted: 13 March 2006 at 11:05pm
|
XML is fine and TinyXML does the job.
Kwigbo, do you already have any plans or specs on the level structure? Could you write an example of a small level so we can investigate further?
|
Posted By: kwigbo
Date Posted: 14 March 2006 at 7:14am
I will post something tommorrow on the xml structure. Today is my day away from the computer. For the most part.
------------- http://www.kwigbo.com">
|
Posted By: randomblink
Date Posted: 14 March 2006 at 9:24am
I am currently working on an XML structure that works. However, I am building it with my knowledge of Flash behind me... So I will need some feedback from the C/C++ team so we can make it all work together.
If you would like to see the structure as it is coming together? http://www.kwigbo.com/ninjasquirrels/FlashFiles/PlatformEngine/xml_structure.xml - http://www.kwigbo.com/ninjasquirrels/FlashFiles/PlatformEngi ne/xml_structure.xml
I am going to create an explanation sheet to go with it. If you have any questions, please direct them to your team leader...
C/C++ Team Leader: Ork Flash Team Leader: kwigbo
I believe that does it for this post... Peace out one and all...
------------- www.randomblink.com
I am me... no! Really!
|
Posted By: Shark
Date Posted: 14 March 2006 at 9:38am
random: perhaps put many of the decisions from this topic eg the
XML choice, in with your stickied topic that isnt for discussion.
------------- Snark, we love yuu.
|
Posted By: randomblink
Date Posted: 14 March 2006 at 12:36pm
great idea as well... thx
------------- www.randomblink.com
I am me... no! Really!
|
Posted By: Ork
Date Posted: 14 March 2006 at 10:57pm
|
Randomb: Nice. So this xml describes all the levels and the actual tilemap data is in separate file? (..makes sense..)
|
Posted By: randomblink
Date Posted: 15 March 2006 at 6:30am
I will be putting together a description file to go with this once I get it perfected. The idea behind it is basically that by creating this XML file, AND having the related files necessary, the game should be able to create each map, level, character, etc...
SO... I am working as fast as I can. Creating / Editing the actual classes in Flash as I go. Peace
------------- www.randomblink.com
I am me... no! Really!
|
Posted By: initial_reality
Date Posted: 30 March 2006 at 5:59am
hey guys
I think I won't be able to work in my editor for a couple of months .
I just moved and I don't have a computer to work. A tool to place
obects in the map is almost finished. If someone wants to work on it, I
can send the source files. It's a Builder 3 project wich can be ported
to Builder 6. Otherwise, feel free to use another editor.
Good luck!
|
Posted By: ElvenProgrammer
Date Posted: 20 April 2006 at 5:33am
I was trying to compile it with mingw but... Where are GetSystem and APP_ASSERT declared? Thanks
------------- http://themanaworld.org - http://themanaworld.org
|
Posted By: Boder
Date Posted: 21 April 2006 at 1:44am
I've been working on a tile editor that can be used in the game for a while. It uses OpenGL and GLFW, so it should be 100% portable, and it currently uses text files which helps with the portability.
Features: * smooth scrolling controls * 2-levels of tilemap (foreground and background) * load map from text file * Zoom from 4x to 0.25x * Message Feedback * Unlimited Undo/Redo * Eraser * Right-click tile select * Tile Select Mode * Area Fill
Soon: * save to text file * level boundary marker * increase map dimensions * background layer * load image command
Future: * collision map layer * static object placement * parallax layers front and rear * game entity placement and attribute adjustment
|
Posted By: Boder
Date Posted: 28 April 2006 at 11:59pm
Here is a link to the editor, try to make a nice background if you dare! The background has to be power-of-two 2,4,8,16,32,64,128,256
http://boder.us/temp/TileEditor.zip - Download Link
Forgot some controls: W,A,D,S - movement NUMPAD+ - zoom in NUMPAD- - zoom out
|
Posted By: Boder
Date Posted: 02 May 2006 at 10:54pm
Posted By: Souly
Date Posted: 03 May 2006 at 8:59am
|
Oh, I noticed if you hold shift you can make a large filled square. It's looking good, I'm thinking that you'll be making the tile selection in the next update?
OK so I decided to read the readme... and I noticed that by holding spacebar you can select the tiles...

------------- http://punky.ensellitis.com">
I am the jesus of PJ.
|
Posted By: ElvenProgrammer
Date Posted: 29 May 2006 at 1:06am
Has the development of this game stopped? If not is there any way I can contribute? I could share some time and help with the programming part.
Regards
------------- http://themanaworld.org - http://themanaworld.org
|
Posted By: Demon
Date Posted: 29 May 2006 at 1:45am
Ya, but if we switched over to Java, we could both have run at developing it.
------------- "At least we killed some boredom..." - Death Note.
|
|