Current Project: RPG Toolkit, codename "M3"

[Ace Pace]

Fine by me, aslong as it's easy to define I don't care how weird the UI is.

[Destructionator XV]

Weird UI.... I just had a brilliant idea.

To remap keys you must carefully move the mouse cursor through a maze on screen and pick up control icons, and carefully drag them back through the maze to the picture of the controller and drop the icons on it.

But here is the catch: if your mouse cursor touches one of the walls of the maze, it will start to delete random files on your harddrive until you complete a game of Minesweeper at which point it will let you continue.

And more, there will be a circling Windows Logo around the program that works to suck in your mouse pointer like a black hole of doom. Stop moving the mouse and the logo will suck it in. If the cursor touches the Windows Logo, it will reformat your harddrive forcing a clean install.

Tread carefully, brave mouse pointer! Make it through the maze and thou shall remap thy keys. Touch the walls and your family dies. Touch the circling Black Hole Logo and thou shalt most certainly die and we all are doomed.



Sound like the best user interface EVER?

[Ra]

Very excellent that this is progressing along, Adam. But before I go much further with my sprite drawing, I was wondering about a game mechanic again.

I was curious. As you probably saw in my "M3 Game Fluff" article, it says that the PC can tell vampires from humans due to a red aura that flashes around the bloodsucker. How hard would such a thing actually be to script?

[Ace Pace]

Very excellent that this is progressing along, Adam. But before I go much further with my sprite drawing, I was wondering about a game mechanic again.

I was curious. As you probably saw in my "M3 Game Fluff" article, it says that the PC can tell vampires from humans due to a red aura that flashes around the bloodsucker. How hard would such a thing actually be to script?

I can guess Adams response. Basicly this sounds like a script. Or perhaps inside the animation.

If inside the animation, implementation is up to artist.
If it's a script, I imagine it'll go like this:
1) Every few random moments of time do:
2)Activate effect Aura(color code here)

Aura being something that takes a sprite and adds in some [color] in the edges.

I suppose both ways are possible if I understand Adams scripting correctly.

[Destructionator XV]

Ace is right. I'd do it in the animation. Just put in a semi-transparent aura surrounding him that fades in and out as time passes. That should be doable with the normal frame based system.

[Ra]

Excellent.

I was wondering something else as well before I get back to doing my artwork; what are the acceptable sizes for character portraits? I recall asking before, but looking through the thread I never could find any other mention of sizes. Personally, I think something like 80 x 80 might be good for at least status screen portraits.

[Ace Pace]

What screen resolution are we asumming? 640x480?

[Destructionator XV]

What screen resolution are we asumming? 640x480?

Right.

For the portrait size, you can have 5 guys on a team at once, and they should all stack in my current envisionment of the status screen (same layout as FF7; might change it, probably won't).

Anyway, 80x80 sounds good. It will fit horizontally and vertically on the screen with some room to spare (good; we need to fit text in there too) and that is big enough to have the faces.

So 80x80 it is.

[Ace Pace]

Just to be clear, Portraits, any kind of display, can be an anim as well as a static image yes?

[Destructionator XV]

Right. Image and animation mean the same thing with relation to the engine.

[Ace Pace]

Okay, hmn, me and Dest have two differant mockups of the character selection screen, why not put them up. Dest it seems basicly copied what has been used, I tried moving elements around. Dest first, ace second.

[Ra]

Thanks, guys. Just for a status update I've got down (facing) and up (back turned) images done for twelve sprites sofar, and I just completed an 80 x 80 portrait (I was already working on it when I asked about size). I'll soon be working on the side views, and possibly a few tiles as well.

[Ace Pace]

Okay Ra, heres another character screen, you can all now debate.



If the added on text isn't clear, Visual studio decided not to show the tab names, which are meant to be character names.

[Destructionator XV]

Since Ace has got me going, eye candy time!

Here are basic mockups of what I envision the main menu and text boxes looking like in-game. This was done by hand with my shaky hands, so it is not pixel perfect, where as, of course, when the program does it, it will be. And obviously, Magus' castle won't be the backdrop in the real thing, but it is a nice shot because it shows layered transparancy; the clouds and partially translucent boxes are all in my design goals, so making a shot like this should be reasonably possible. Also the real thing will have 3d looking borders around the text box, like FF does.

(Linked because I don't want to break the formatting) EDIT: fuck it, inline it is. if it breaks the formatting for you, say so and I will edit it back

[Ace Pace]

Of course, I forgot to add the top tabs for say Items, characters, config, etc. but you can either invision the tabs on top of what I already posted, or imagine that you press some button and that menu superimposes itself on the game.

Of course, tabs work either with buttons that 'Go up a level of the menu' such as the cancel button or with a mouse.

[Ra]

Awesome work! I have to say I like Ace's character selection screen more over the more classic version, since it's clean but unique. And definitely love the individual character screen and the transparency. This is really looking good.

[Destructionator XV]

I prefer the classic style because it gives me a quick overview at a glance, and can also be easily used to reorder the party. I also like the FF1, PS and DW styles for the former reason; it gives a fast at a glance overview of everyone's life. The tab interface gives many details, but not the overview.

This leaves me with a number of options:

1) Have both interfaces, user configurable. A little more code, but if I go with a clean design, it can work.

2) Have a overview popup with a button giving all the HP, MP, and Ace's interface when you explicitly call the menu.

3) Rework Ace's interface to add an overview.

4) Ace's interface can be the status screen while my classic interface is the menu screen providing the overview. If this, his interface will need to add room for the detailed stats.


Of those, I like 1. A little more work, but a cleaner code base that will be more extensible and customizable. I also kinda like sticking in #2, and will probably do so since that is a separate feature.


As an aside, I love how I make these feature decisions.. I like them both so both it will be! Due to the obvious fact that doing both is more work it also takes longer, so some of the promised options will probably not be present in the first few releases. Don't be alarmed though, that is common in software development and once the base is out updates will come fast (one a week or even more is my goal schedule once the base is done, each one adding bug fixes and features).

[Destructionator XV]

And I just hit something I should address right now in a TECHNICAL SPECIFICATION.

How the fuck am I going to handle all the files? There are many files with ugly interdependancies and while the absolute paths might work on my box, it won't so well on your guy's Windows machines.

There are tons of files that can basicly be broken down into this:

Base level (.png files)

Animation level (.m3a files, a list of .png files and some metadata to create an animation)

Tile level (.m3t files, has a list of .m3a files and some metadata to create what is needed)

Map level (.m3m files, has a list of .m3t files)

And so on. See the problem here? To load a map, it needs to know where tiles are and where animations and where frames are. There are a few problems here.

Since the point of the engine is to run multiple games from various people, it needs some way to

1) Share files
2) Resolve naming conflicts
3) Redistribute files easily
4) Merge files from another user's graphics library to yourown

The current system (knowing the filenames as they rest on your harddrive) fails in requirement 2 and 3, and arguably 4.

My plan to solve these is to leverage a forced relative directory system. This also has the following requirements:

1) Must work the same on all platforms we support (Windows XP, Windows 98, and Linux).
2) Must work under a limited user account.
3) Must fail gracefully.
4) Must resolve naming conflicts of folders
5) Must be relocatable on the filesystem.
6) Must have support for common files.

This leads to the following directory structure:

/ = M3 user directory ( /home/user/arsd/m3 on Linux, %systemdrive%\Documents and Settings\Application Data\arsd\m3 on Windows XP). Can be overridden in the config file, located in $HOME/arsd/m3.conf.

The binary may be installed in Program Files, /usr/local/bin, or really anywhere as long as its libraries and exes are together. Install and running need not have admin privs.

The rest is relative to that. First the level 1:

/arsd = AS APPLICATION RESOURCE: The files I provide; guaranteed to exist in unmodified form. These don't actually exist as regular folders' they should be packaged into .dll files or something like that.


/images = shared collections of images
/tiles = shared tiles
/maps = shared maps
/events = shared scripts
/sfx = shared sound effects
/bgm = shared background music
/games = game definition files and specific data (/games/scripts will probably be the only one)
(more to come)

Each one is broken down into this:

/creator = each creator may have his own files in his own folder. Creator name conflicts will have to be solved by runtime asking of the user. A bitch, but it is best I can think of right now (and a low priority since it will be just us using this program for a while, and we all have our own screennames)


If a creator name is not specified, it assumes built in as the default. Creator name will be automatically filled in by the editor tools to match what you use.


NOTHING outside this directory structure can be loaded into the game. When the editors allow you to browse for a file, it must copy it into the correct place before letting it be used.

To distribute a game, I'll have to write a recursive scanner and unpacker to get the right files and package them for transport. OR the user can simply copy and paste his data files IF the directory remains intact.

Moreover, the user has only THREE options in game to load:
1) Files provided by me
2) Files in your shared folder
3) Files in your game folder

You can NOT load files from another user's folder.

If there is a naming conflict between a file and the path is not specified, the preferred file goes in ascending order in the list above.

Also, static images can be loaded dynamically based on their filename; they need not have a m3a layer iff (not a typo: if and only if, symbol borrowed from math) static.

This requires a slight rewrite of some code that already exists, but nothing too bad.

The user interface of the editors will be the standard file->open interface with a sensible default opening location, and if the directory chosen is invalid, it will be transparantly copied. If this causes a naming conflict, the user will be asked to disambiguate.

In the future, I might use a custom widget for this, but not an immediate priority.



There we go, that seems sensible. Now to make it happen.

[Destructionator XV]

talking to myself here....

SON OF A FUCKING BITCH. I have spent so much time on the editors that I have been neglicting the engine itself. SDL doesn't do input or timer handling unless I initialize video. And SDL and Qt can't play together on the same window, so if I want input handling through SDL (which I do: that gives me joystick support and my established interface I did over the weekend), I must do graphics through SDL.

Which means adding and debugging my own alpha blending algorithms or learning 2D stuff through OpenGL (harder than it sounds). And I dunno if it will be fast enough; I might be forced to learn OpenGL. This also hurts code reuse.

...unless I port the QPaintDevice class to SDL, but that has its own issues and will take a damn long time... a better idea might be to wrap Qt's classes inside my Screen interface, yes, that might work. Not the most elegant, but it might work. It looks like I'll have to fork my wrapper library though (ugh)... nah, maybe not, I can preprocessor it. Not the prettiest thing but it should work.

edit: spoke too soon with the scripter I think I can make it work

[Destructionator XV]

Yeah on the scripting system, due to a series of complications, I am going to lean away from the object oriented approach to the world and bring it to a procedural approach.

Any scriptable object, most often events now, will be able to modify itself and its variables and can access the rest of the game world through a series of function calls. This is a little limiting and ...different, than the object oriented approach (I am not sure whether to call it better or worse, really. It has its ups and downs.)

One of the ups is it will be easier to put it all in menus for you GUI people; the list will indeed be a list. That makes it a little easier to document too.

It will feel like using C instead of the Javascript approach I was going for at first. There are a number of reasons for this change, related to the problem in the above post. I should be able to give about the same power to you through potentially an easier to use system (depends on how you look at it, I guess).

Sharing data between events must be done through a call to the system to keep it for you. Easier than it sounds.

Anyway, I am going to be respecing the whole thing soon, but what I am seeing now is code like this:

Code: Select all

       messageBox("Hello, want to take my money?"); // if this was a NPC, it would now talk

     if(interface.yesOrNo()){   // asks the player for an answer yes or no. If yes, it will do this, otherwise, it will do the else block below

       interface.addMoney(500);    // gives 500 money to the party
       interface.messageBox("You gain 500 g."); // tells the player with a generic box. This is different than the first message box
// because it is not a message from the NPC, but just a generic box
}else
       interface.gameOver(); // oops, game over. silly player, you should have taken the money.

I'm not super excited about it, but it is either a design like this or a delay while I work things out. I'd rather have something to play with than more delays.

[Destructionator XV]

Simple question: for the game when it is running, do you prefer full screen or a window?

Do any of you have an objection to it being forced to run full screen or forced to run in a window?

[Ace Pace]

Windowed, anything at 640x480 is going to be shitty quality upscaled to any kind of LCD.

[Mayabird]

Upon discussion with Ace, I've agreed that we need to create a test RPG first before going crazy with our own wild schemes to make sure the stuff works.

GENERIC COMEDY RPG

Featuring: The Mysterious Adventurer (gender, appearance, and name can be chosen, but people just call him/her Adventurer) who exists only to save the entire world by coincidentally showing up exactly when needed

The Townsfolk, who all have problems ranging from inconsequential to world-shaking, though none of them have any inclination to actually fix their problems themselves.
*Ex: Old lady/Granny: "Oh dear, that mean old troll Manslayer of the Bloody Axe just kidnapped Mittens, my favorite cat. Could you do me a favor and save him?"

The Helpful Additional Party Members, who for some barely believable reason decide to join the Mysterious Adventurer and save the world.

The Totally Useless Party Member, which is probably a bard or thief that can't steal anything in the game or someone equally wimpy.

The Bad Guy, who wants to destroy the world for no real reason except that he's evil.

"Adventurer, use this Ancient Sacred Sword to defeat the Bad Guy once and for all. Even though it didn't work a thousand years ago when used by people who actually knew what the heck they were doing, I'm certain it'll do the trick this time!"

Dungeons! Items pouring out of dead monsters! Double entendres! Cliches!

How's that sound?

[Destructionator XV]

Certainly. I will be doing little test games too before you even see the engine, and the more you do, the more you can get a feel for what it is like and what you hate, so we can change things before committing to a project. Test games will be a good thing.

I wish I had a private office so I could work faster, but meh. Anyway, I have decided to start giving out one part at a time. I am redoing the animation editor as stand along then doing more, one piece at a time and will post it for download. I have a pretty good idea that this will be ok.

And I have to get up to college and have damn boring homework too so probably not much more done today or tomorrow until night. Task switching is an expensive operation. I can't wait for the semester to be over or vacation times so I can focus.

[Ace Pace]

Possible ideas for something we should make as early as possible, is modular dungeon peices.

My idea is, to save on developer time, we create modules of Dungeons, such as entrances, that can easily be copy pasted around and change some things like names and textures. Asumming that the script block for a Dungeon is something larger then a trivial 3 liner.