Current Project: RPG Toolkit, codename "M3"

[Destructionator XV]

As a couple of you know, my current programming project is writing a cRPG (console style role playing game) engine and creation toolkit.

In this thread, I will be explaining some random thoughts that come to mind, and also take people's opinions on subjects. I estimate in about 4-6 more weeks I will have the bulk of the code finished, and will release the first beta. Hopefully about a month after that, 1.0 will be ready to go along with my first game demo.

Recently, I have made a couple changes to my initial plan. I was thinking about making the on screen resolution 640x480, which is what the Playstation used by default. However, earlier today, I started to think that was too high.

See, M3 is a toolkit and engine for creating 2d cRPGs, similar to the SNES era Final Fantasys. Dungeons in these games were created by mapping together tiles. Tiles have the advantage of being easy to make, easy to use, easy to code, and low on memory requirements. Heck, the NES used 8x8 tiles for ALL its graphics because they offered several advantages. The tile is the atom of a map.

The tiles in M3 would be 16x16 pixels, and could be full color, including transparency, and animated. This size is small enough to give detailed maps, but large enough to be useful (a 1x1 pixel tile would give arbitrary detailed maps, but would be a hell of a time to make, likewise, a large tile gives little map detail but is easy to lay out).

At 640x480, 40x30 tiles would be displayed on the screen at once. At first glance, that sounds good: you could have huge, detailed maps. But it also has several disadvantages:

1. Huge maps take a long time to design and create. More detail means more time your artists and level designers need to spend to finish something. At that size, even simple little caves could take days to complete!
2. With that many tiles displayed on screen at once, the player would be able to see a huge section of the cave at once, unless it is obscenly big (see point 1 for the troubles there). Remember lots of the fun of cRPGs is finding your way through the mazes alive. Dead ends are pretty useless if you can see them as soon as you enter the dungeon!
3. In the program, that would be at least 1200 animations running at once. It would not be too big of a memory problem, since the animation code shares most its frame data, which eats most memory, but it would be a display problem, especially on slower processors. Every 50 milliseconds many of those animations will need to be redrawn to keep up with real time. That means 1/24 of a millisecond for each animation to be drawn in worst case! Modern graphics cards and computers are fast, but that is alot to ask on older machines.

Realising these problems, I decided 640x480 was too high of a resolution, and started looking into alternatives.

I could go back to the 320x196 resolution of M2, but that seemed too small. I started to look at some of the games with which I hope to compare when I am finished.

Final Fantasy 4 and Chrono Trigger on the SNES both ran at a tiny 256x220 and looked fine. Phantasy Star 4 on the Genesis, a graphical beauty incorporating most the look I seek to acquire, ran at a measly 320x224!

Seeing those numbers, I decided I could slash my resolution in half and be better off for it. M3's game window will now be 320x240 pixels, which is 30x15 tiles: much more manageable for content creators and 450 animations being drawn is much easier for older computers to handle

A resolution of 320x240 is unheard of in modern gaming, but it is excellent for 2D style sprite and tile games. I am certain this decision will be better when the game becomes playable.


Also, looking farther down the line, I am pondering the battle system. Should I go with ATB, like Final Fantasy 6? A turn based moving battle like Lunar? Classic turn based like Dragon Warrior 3? Or perhaps a combination of ATB and moving characters, similar to Growlanser?

Or, of course, I could make multiple engines or a whole new innovative combat system. Any opinions on preferred combat systems?

[Ra]

This all sounds very fascinating. While I obviously know next to nothing about code and all that, creating a cRPG game sounds like it would frankly be loads of fun.

As for the battle system, I suppose a more classic turn-based style would be less "memory-intensive" than a live-battle sytem like BG II used, but any method would be fun, IMNSHO. Like, what gaming rules is the project gonna use? Something like FF, or more D20-ish?

Nevertheless, please keep us updated. You've certainly gained my interest, Adam.

[Ace Pace]

Adam, not to ignore old computers but I think in this case the ability to play in a non teeny resolution of 640x480 should be kept,if only as stretching the tiles.

[Destructionator XV]

Like, what gaming rules is the project gonna use? Something like FF, or more D20-ish?

Haven't decided yet, but probably Final Fantasyish. The specifics will be something I decide when I finally get to writing character code, which is still at least a few weeks away.

Adam, not to ignore old computers but I think in this case the ability to play in a non teeny resolution of 640x480 should be kept,if only as stretching the tiles.

Well, the game resolution is just for the game itself internally and a number to keep in mind when creating content: when you play the game or run the creation tools, you can set the window to whatever size you want, and the content will be scaled up.

[Ace Pace]

Good to hear, as I pretty much can't play on anything that small.

[Kreshna Aryaguna Nurzaman]

Real-time combat, but let the party members control their own action like in Ultima VII (or Dungeon Siege), so the player will only concerned with controlling the party leader.

Of course, there should be a pre-selected formation/tactic like in DS.

[Ace Pace]

I think Adam is aiming abit more at recreating FF7/CT. Which is definetly turn based after a fashion.

[Kreshna Aryaguna Nurzaman]

I think Adam is aiming abit more at recreating FF7/CT. Which is definetly turn based after a fashion.

Well if that's the case, then make it like Fallout; simply the best turn-based combat system I've ever played.

[Ace Pace]

I think Adam is aiming abit more at recreating FF7/CT. Which is definetly turn based after a fashion.

Well if that's the case, then make it like Fallout; simply the best turn-based combat system I've ever played.

Again, I'm not sure if Adam will or will not implement a combat system differant then CT.

Which is the only old game I'll say is fun.

[Destructionator XV]

I don't care much for real time combat systems in cRPGs. They just become button mashing. The turn based systems (either pure turn based, like Final Fantasy 1 and the Dragon Warriors, etc or ATB, like Finam Fantasy 5-9 and Chrono Trigger) make you decide on more strategy, with pure turn based being the greater of the two. ATB has its advantages though, forcing you to think and input commands quickly.

So I am certainly going turn based, but it is the details that are still up in the air. Will the character's locations make a difference? Stuff like that.

[Destructionator XV]

Well, since the animation system is mostly complete, I am going to move on to coding the next thing required to start building a game: tiles.

A tile, as I said above, is the building block of a dungeon. It needs to contain a number of important in-game-related data members:

• A graphic. This will be an animation, 16x16 pixels in size, and is displayed in game to make up most of what you see on screen.
• A battle background. This is a full screen sized animation (320 x 240 pixels) that is displayed as the background when you enter a random battle on this tile.
• The random battle counter decremention value. For this to make sense, I will explain how random battles work.
  
  First off, a value (let's call it `x') is randomly generated. This number is between at most 255 and at least 1 (the actual max and min values are dependent on some other factors, more details will be explained when I explain the random battle system in detail).
  
  With each step the player takes in a dungeon with random battles enabled (i.e., not a town but a cave, etc.) the tile's counter value is subtracted from x. When x becomes less than or equal to zero, a random battle begins. After the fight, a new x is randomly generated and the cycle begins again.
  
  
  So a tile would have a decremention value (I call it xdec in the code, meaning ``by how much to decrease x"). If this value is large, then fights occur often on this tile. If it is small, then fights occur less often. Generally, the xdec value is betweem 1 and 8, with 1 being on grass or roads, and 8 being deep cave tiles. A value like 4 would be apporiate for forests, since fights happen rather often in them.
• A set of flags describing how the character is allowed to walk, or otherwise move, on this tile. There will be a flag for each type of vehicle the engine supports. So far, I have the following flags:
  
  • Can walk: determines if the character can walk on the tile without any vehicle. (This is good for grass, forest, etc. Bad for mountains, water)
  • Can sail: determines if the character can take their boat on the tile. (Good for ocean water tiles)
  • Is boat dock: determines if the character can dock his boat on this tile. Boat dock tiles should usally be walkable too, but not always. Remember Final Fantasy 1, and how you had to dock at either rivers or docks: this flag is used to recreate that experience.
  • Can canoe: this flag is set if you can "canoe" on the tile. The name is obviously inspired by Final Fantasy 1's canoe, and is intended for use on river tiles. You could also use it to recreate something similar to Final Fantasy 7's Tiny Bronco.
  • Is canoe dockable: determines if you can get on and off your "canoe" on this tile.
  • Can low airship: If this flag is set, the character can fly over the tile with a low flying airship. This flag was inspired by Final Fantasy 5's dragon, which could fly over many things, but not mountains. This could also be used for a black chocobo type "airship".
  • Can low airship land: If this flag is set, you can land your low airship on this tile. Inspired by Final Fantasy's black chocobo, which could only land on forests.
  • Can airship fly: This flag would probably be set by all tiles, as if it is set you can fly your high airship over it.
  • Can airship land: You can set this flag to allow your airship to land on the tile. Can be used to create things like Phantasy Star 3's airfields, Final Fantasy 1's airship, or just an all powerful airship that can land anywhere.
  Keep in mind that while I named certain vehicles here, the content creator would not be locked into my idea of a game; he can change those flags to make all kinds of magical vehicles, or ignore most them altogether.
• Cover character flag: if this flag is set, the tile is drawn on top of the character's feet, rather than under it like normal. This would be used to make effects like the forests in Final Fantasy 6.
• Poison tile flag: this flag would reduce a character's hit points when he steps on it. The amount of damage could be set in the main game config. Inspired by the damaging tiles in Dragon Warrior.
• High damage flag: this would do more damage when you step on it. Again, inspired by the greatly damaging tiles in Dragon Warrior.
• Script. This script would be executed each time a character steps on this tile. Should be used for generic effects, like extending the idea of a damaging tile, perhaps adding status effects to them. It should NOT be used to make teleportation squares in most situations, but it is possible (those things should be covered by events, which I will explain later). This member would carry the name and arguments of a function from the main library that you want to call. (More information on scripts will be explained when I write a section on them.)

Also, I would like to add capability to the tiles to change their apperance based on the in-game time, similar to the day night cycles in Dragon Warrior 3. I did this in M2 for DOS by permitting alternate color palettes for all tiles, but since this version supports 32 bit color (red, green, blue, alpha for each pixel), a palette swap is not really an option. I am considering either pixel shaders to change the look of the tile, or perhaps alternate animations that you can select based on time of day.

Right now, I am leaning towards alternate animations, since it offers more flexability. Sure, it increases creation time for the tile, but I think it will be worth it. Day / Night is a cool effect in a game.


Also, while tiles will be 16x16 pixels, I want to create an option that I am currently calling "complex tiles", which would be multiple tiles strung together to make a bigger tile. This feature would be part of the map editor, to speed along map creation. Along with the idea of complex tiles, I want to add "auto-fix", which means you can select a generic tile and place it on the map, and the map editor will automatically select a better tile for that situation (for example, if you place a water tile next to a land tile, the map editor will automatically change it to a shore tile).

I am not sure if I want this functionality to be part of the tile editor, the map editor, or a seperate function. I will probably make this decision once I start to see how the actual code is progressing.

[Destructionator XV]

Another question on my mind now is shall I permit diagonal movement? Diagonals make the game look prettier, and have a feel of more modern movement than the strictly 2d movement of the older games (see Lunar and Chrono Trigger for some diagonal movement done well) Allowing it opens up a couple problems though. One is that the map creator will have to remember diagonals are a possibility. The art will have to reflect it, and walls will need to be filled in at the corners. Also, the character sprites will need 4 more images, to show the character walking in a diagonal direction. Lastly, maze design will have incorporate it: many dungeons are designed so you have to walk in straight lines to increase the number of steps needed, hence causing more random battles. While some may see that as lazy level design, it is a rather big deal.

That brings me to one other potential pitfall. Remember the Ice Cave in Final Fantasy 1, where you got the Floater? The room with the floater was designed somewhat like this (forgive the crude text art):

Code: Select all

=============
|   AOOOOO  |
|   OTOOO   |
|  O E   O  |
|  OOOOO O  |
|     OOO   |
|           |
=====| |=====

The O is a hole, the T is the treasure box, the goal of the dungeon, and the E is the Eye, the monster guarding the box. The A is a marker for my discussion, but the tile itself is normal.

In the game, since you couldn't move diagonally, you had to fall down a hole, then climb through the rest of the dungeon to get back, fight the Eye, then grab the treasure.

If diagonal movement were possible, it would be possible to avoid the holes easily, and just grab the treasure without doing the fight (by moving down right from the place labeled 'A')!

This means more work by the map designer to avoid this situation, making the diagonal tile a hole too, which also needs more artwork than the simple circles FF1 used.

The fight with the Eye could be moved to the treasure box event. FF1's system didn't permit that: treasure boxes were just treasure boxes, but M3's event scripting system makes that child's play.

I think what I will do is make diagonal movement an optional flag in the game master config file: if the artists want to spend the time to make the graphics good enough to work with diagonals, I will support it, and if not, I will not force it on them.

[Ra]

I love all these ideas, especially the optional diag movement concept.

So would the program's sprites be creator-designed? Like, say I wanted to make a thief PC, I drew the sprite myself, or would it use like templates (say, a human male template, or an elf female template)?

[Mayabird]

I think Adam is aiming abit more at recreating FF7/CT. Which is definetly turn based after a fashion.

Well if that's the case, then make it like Fallout; simply the best turn-based combat system I've ever played.

Well, it did get a bit tedious during the big battle at the Boneyards. The thing took like thirty minutes because all those townsfolk had to run around and get shot, too.

Would there be a way of having tiles for, say, a road? It'd be similar to the river for the canoe, but you'd only be able to get off at towns, perhaps. Either that or the road could be accessable anywhere, but without encounters. It'd be a fast way to travel before getting something flying.

Could there be any healing tiles or saving tiles?

[Ace Pace]

I imagine the latter would be easy to work. Maybe the

High damage flag: this would do more damage when you step on it. Again, inspired by the greatly damaging tiles in Dragon Warrior.

Concept can be generalised then flagged as either a + or a - to HP.

Saving tiles again shouldn't be hard to implement.

[Destructionator XV]

You would draw all them yourself. I'm not a very good artist myself, so the best I would provide is a sloppy stick figure or plagarize someone else's work, which is obviously unacceptable.

You would first draw PNG files for all the sprites, backgrounds, and tiles. You can draw multiple frames too. Then import each frame into the M3 Animation Editor. Those animations make up the game.

Also the Animation Editor supports script based animations, so you can make animations with subsprites easily. One example I have been using for this is birds flying overhead.

First, draw a sprite of a bird in your favourite image creation tool (mspaint, gimp, whatever you want). Save it as png.

Crack open the M3 Animation Editor, make a new sprite based animation for full screen. Import your bird png file, then make a script that shows it flying across the screen. Easy to do, like this:

Code: Select all

var bird;
function init(){ // is called when it is time to create the animation at run time
 bird = new Sprite(0); // sets bird to equal a new sprite. the 0 means you want to use image 0 (in this case, bird.png)
}

function tick(){ // called once every tick of time (this amount of time is changable in the Animation Editor menu)
 bird.x+=1; // moves its X and Y positions over by one
 bird.y+=1;
}

Then if you set that animation as a map's overlay, it will have little birds flying over the player's character.


When I go beta with the editors, I hope to take user submissions of artwork and original music that I can bundle with the program or offer for download on the official website. But of course, if you don't like what I offer with the program, you can always create your own art. I don't want to limit anyone to my decisions in making their own games.

[Destructionator XV]

Would there be a way of having tiles for, say, a road? It'd be similar to the river for the canoe, but you'd only be able to get off at towns, perhaps.

Yes, there would be 3 ways to do that:

1. Make it be a tile with a xdec value of 0. That means you could walk on it normally, but with no battles.
2. Use the canoe flags, but swap out artwork of the canoe with art of a car or whatever. (Remember just because I called it a canoe doesn't mean you are forced to keep with my ideas of things)
3. I could add more flags. Perhaps allow the creator to create any number of vehicles he wants, providing a generic interface for him to use. This is actually very simple, and I think doing it this way would be a good idea: the creators could go nuts, and in the code, I could simply use arrays.

Either that or the road could be accessable anywhere, but without encounters. It'd be a fast way to travel before getting something flying.

Like in Final Fantasy 8. Pity they didn't use that idea throughout the whole game instead of just on Balamb.

Yeah, that is definitaly a good idea, and I will certainly implement that.

Could there be any healing tiles or saving tiles?

Healing tiles could either be done with a HP + flag, like Ace suggested, or with the script member (the script can do whatever you want it to do, hence providing near infinite flexability). I like the idea of a HP + flag though, since that is easier for people to use (scripts are not going to be the easiest thing for newbies to learn how to use),

Save tiles are part of the event system, which is a layer on top of maps. By putting them on this layer, it allows transparency of the graphics (remember how the save points looked like in Chrono Trigger: the twinkling stars ontop of whatever dungeon tile they were on) and abstraction of the save idea (meaning you could do more with it than just save, like use tents or have dialog in the middle of the night).

Again, that will make more sense when I explain the event system in more detail, which I think I will be doing soon (though I will not be coding it for a while down the line still, so what I say in my initial explaination will be subject to change.)


And a quick teaser about characters: I want to support a Final Fantasy 5 style job system. Details when I get to the character explainations. That will be an important fact for the artists to remember.

[Ra]

Kewl! I'm not exactly a skilled sprite drawer (Dak says he is, though), but I'll do my best and draw a few people, birds, or animals, if you wish.

[Destructionator XV]

Sweet. Once I get some more of the code going, I'll draw upon your skills. (Don't want to get too much art drawn right now since in a few days, I might (though unlikly) radically change my mind on the requirements again, hence making what was done before that useless)

I would also like to point out some music and sound effects will be required down the line too (though FAR down the line, coding the sound system is not going to be easy at all, and will probably be the last thing I actually do). If there is anyone who would like to write some in-game songs that would be awesome.

[Ace Pace]

Quick technical question: Is the graphics drawing still in a Layers format with bottom being background, then a ground terrain tile, then static objects, dynamic objects? Or did you change that?

<-- is clearly far too much a graphics whore.

[Destructionator XV]

Quick technical question: Is the graphics drawing still in a Layers format with bottom being background, then a ground terrain tile, then static objects, dynamic objects?

Yup. It goes:

animated background (wallpaper if you will)
animated tiles (the dungeon terrain itself)
events (save points, stairs, etc)
characters (NPC first, then player)
tiles with the above character flag set (things like the forest I mentioned earlier) [this is an addition from when we talked about this last]
overlays. [clouds, birds, etc]


I will be using OpenGL to draw the main game scene, and for the first versions, brute forcing my way through the layers (meaning if the background changes, the whole thing; all layers, are redrawn). As the code matures, I intend to start doing redrawing efficently, only redrawing what is actually needed.

[Ace Pace]

Events is a confusing name if it basicly covers everything dynamic thats not characters.

Overlays are always Alpha channel(transperency) images yes?

Is there support for particles?

By particles I mean stuff like spell effects, stuff that could be easily just given some parameters and let to happen randomly, which would be easier then drawing spell effects frame by frame.

[Destructionator XV]

Events is a confusing name if it basicly covers everything dynamic thats not characters.

I am using the name Event since that is what Altus's RPGMaker for the playstation called them, and it is what I called them in M2.

And actually, an NPC is an event too; a mobile event.

An event is almost everything in the game. The bulk of a user created game will be a massive event script.

I could change the name later, or at least write up a more formal definition of it.

Overlays are always Alpha channel(transperency) images yes?

Everything in the program are always alpha images.

Is there support for particles?

Not right now. I'm not sure how I would code that framework on a 2d user-defined surface.

Will have to think about it, and when I determine how I want to do it, I'll add it to the animation script API.

[Ace Pace]

Events is a confusing name if it basicly covers everything dynamic thats not characters.

I am using the name Event since that is what Altus's RPGMaker for the playstation called them, and it is what I called them in M2.

And actually, an NPC is an event too; a mobile event.

An event is almost everything in the game. The bulk of a user created game will be a massive event script.

I could change the name later, or at least write up a more formal definition of it.

Thats a horrible name then, Actor, character, object, anything is better then Event.

Everything in the program are always alpha images.

So the obvious question is lighting support, will all images be static or can they be 'shaded' in differant ways?

Not right now. I'm not sure how I would code that framework on a 2d user-defined surface.

Will have to think about it, and when I determine how I want to do it, I'll add it to the animation script API.

You could just make it mathamaticly generated stuff based on a single image.

[Destructionator XV]

Thats a horrible name then, Actor, character, object, anything is better then Event.

But an event need not be an object. It might be a dungeon initalisation script, it might be an invisible warp tile or a set location battle.

So the obvious question is lighting support, will all images be static or can they be 'shaded' in differant ways?

Haven't decided for sure, but I am leaning towards no. It would add too much complexity to the animation system and make it much harder to use.

Lighting is needed in 3d, but in 2d I think I can get away without it. The closest I will get is the day / night system.

You could just make it mathamaticly generated stuff based on a single image.

Yeah, that will probably work. Perhaps do 3d math internally, with a base line (the bottom of the sprite) as the ground, then draw the result on the 2d plane.

Will see how complex it is when I get to coding it (probably weeks away still). If it is too hard for either me to code or the end user to understand, I'll leave it out. After all, frames can always be auto generated before hand in things like GIMP or Photoshop, etc.