Current Project: RPG Toolkit, codename "M3"

[Destructionator XV]

First things I would say do are tiles. All dungeons, towns, and maps are built out of tiles.

I will provide a few, of course, and they really aren't too bad (I did some rather good ones IMO for M2. Pity the files were lost with about half of M2 on my old hard drive, but I can make them again.)

Naturally, tiles need animations and animations need frames.

Dungeons, I'm not sure how modular you can get. You can reuse tiles and some generic scripts (which I will also provide), but not too sure about other things. One thing I can think of is the entrance to caves, like PS4 did:



Going though the cave hole moves you to the cave itself. But for the interior of dungeons, not sure how much can really be copied and pasted (and that reminds me, I should try to support copy and paste in the editors) without making lame dungeons.

Dungeon wallpapers and overlays could be reused easily though. Really, any graphic can be (which is why I am putting so much effort into sharing their memory too). So can sounds and music. The rest, not so sure.

And the scripts for most dungeons should be trivial. 3 lines per script (and a couple scripts per page, remember treasure boxes and stairs and exits are scripts too, albeit very very simple scripts) is actually pretty realistic. The hard part will be making the mazes and balancing the enemies.



Since I am posting, a quick note. For the animation editor, what it does is lets you write and test animation scripts OR put animation frames together from a series of .png files. It doesn't let you change the images themselves. Now, if you think that would be useful, I can add it. The reason I didn't though is there are existing programs that can make and edit graphics (such as Paint, the Gimp, or Photoshop) much better than a little thing I would whip up. But if you want something for minor touchups of convenient little stuff, I could make something pretty quickly and add it in.

Something else: I have decided to make my editors all separate programs. A little less convienent, but so much easier for me to do and update. The big thing here is if you are editing a map and decide you want a new tile, you will have to file up the tile editor and save the file, then reopen it in map editor to see the changes. Hopefully, that won't happen enough to be a hassle. If it does, I can make it automatically load the editor and watch it for when it changes the file and reload automatically. That is just a wee bit more complexity I am looking to avoid right now for scheduling reasons.

[Ra]

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.

I had already been planning on making a "test quest" before doing work on the actual game quests, so I definitely concur with this.

It was going to be something really wacky and mainly designed to test out each aspect of the game system. The character would start out at a maxed-out level, just to allow me to test out all spells, all moves, etc, and would have one party member that would be joinable (to test NPC interaction and party stuff) and one enemy to kill, to test the combat system. Nothing special there.

Another thing I realized is that even when we are working on our ultimate projects, we will likely need to go through the game from beginning to end, double-checking in order to locate bugs, glitches, and improperly done events that could lead to crashes. I hate to sound like I'm adding more programming hurtles to this project (hell, I'm dying for the release ), but this may require a debugging mode.

[Destructionator XV]

I hate to sound like I'm adding more programming hurtles to this project (hell, I'm dying for the release ), but this may require a debugging mode.

I didn't even think about that. Shouldn't be too hard to add though, especially since most scripts will be very small (if you break one hundred lines with a single script, that will be amazing, and probably means you or I did something wrong). If a single action takes more than say 10 lines to script, it is probably worth adding to the C++ code as a library function. Doing long story dialog and automatic moving stuff will be the longest scripts, and a bunch of lines of
display dialog stuff is nothing too hard.

Yeah, debugging is something I'll have to keep in mind, but probably will not have in the first few releases.

And speaking of debugging, I assure you my code will not be bug free either. You all can be my beta testers! If something causes a crash of the program, that is always going to be my bug, not yours, since scripts shouldn't have that kind of free access anyway. So any crashes or bizarre activity is almost certainly my fault, and should be reported so I can roll out bug fix releases.


And I am on schedule. Release in two weeks or less. I am currently redoing the animation editor, making it way better (my first development version didn't have keyboard shortcuts or help text!), and it is moving along quickly, very quickly thanks to the fact that I now know how to use the GUI design tools that came with the Qt toolkit. Also redoing the animation class to fit into my new design, and it is way cleaner. I like it a lot more. Once it is near done, I can put it up for immediate download (well, next day, since I'll have to compile it for Windows unless you want to switch to Linux, which I doubt and would not recommend).

Same with tile editor then map editor and character editors. Then comes the engine, where I am having a few problems right now (as in one frame a second speed (and my computer is reasonably fast), desperately needs work there. Maybe shifting the transparancy work to the GPU will solve it, or a more efficient algorithm at the very least). But once that gets nailed down, I have lots of work to do, but if you want to see it in steps as it is developed, I can do bidaily Windows builds or something.

My engine plan is: first, map walking around will be coded. Then main menus. Then event (NPC scripts) systems. Then shops, etc. Then one of the battle engines. Then more detailed monster systems (AI, etc). Then more event systems including save / load games, title screen,s etc. Then alternate battle systems. Then little things and finally major testing and bug fixing time. At any point in there, it will be runnable. Some of those will take mere hours or at most a day to code, others (like the battle systems) will take days. But since it is all finally designed and the foundations all finally laid down, a week is pretty realistic time to get it ready, excluding nonsense (like homework, which I think I just won't do for a while. It will wait, my excitement and lack of laziness here will not).

EDIT: And test games: again, I will be making one myself and all the graphics, etc, to support it. This will be made available for download as a guide to help you guys to make your tests.

[Destructionator XV]

An important user interface thing just came up and I think I have made a decision on it.

When opening a file, you may open it from anywhere on your computer. Be aware that it won't just be opened: it will be copied into your 'data directory', unless it is already there or coming from my provided shared directories (this is most relevant for animation frames. Since it makes a copy, you might have multiple copies laying around and if you edit the old one, the changes will not show up if you reopen the animation!)

EDIT: I know how I can help that multiple copy thing. I'll pop up a dialog box warning you if it feels that is the case. If it sees the file already exists in the proper folder and you are opening from elsewhere, it will ask if you want to 1) use the version in the proper folder instead 2) overwrite the version in the proper folder with the one from outside or 3) cancel. Simple and should work. /EDIT

The obvious way to deal with this is to create all your image files in the right folder and edit them there. I should probably provide a shortcut option or two to open these folders for you.

When saving a file, it only lets you save it in the proper folders (your 'data directory'). This means you won't see the same user interface you might be used to for picking a save file name. It should not be too complex; a list of folders and a list of files and you punch in the name, but something to be aware of.

The rational for this limitation is described on one of my posts last page. The engine will need to know where stuff is to reliably load it when relocated to someone else's computers, and this is the simplest way to do it I can think of that still allows sharing of data between games. (The other way I thought of is every game gets its own folder of data. This is easy to do, makes some sense, and extremely easy to redistribute, but not so easy to share items between games, so I am going a little more complex than that with my scheme).

[Destructionator XV]

I have completed support for my new file saving and opening scheme in the revised Animation Editor, and it seems to work pretty well. While I was at it, I redid the file formats to be able to catch more errors and differenciate versions of the program saving and loading it, meaning things are less likely to break in the future if I decide to change up the format. The code is far more organized too, so less chances of bugs and more easy to change in the future if needed.

Moreover, I moved the core stuff to a shared library while the editors remain exes. This way, it will be more disk space (and download bandwidth) efficient and easier to update.

I like it a lot. Just flesh out a little more stuff here to make it feel finished and write the manual, and the animation editor will be put up for download. I estimate this done some time tomorrow, though not up for download for another two or three days, unless you want the Linux version (I don't have the tools set up to build Windows binaries yet).

[Destructionator XV]

The animation editor is ready, so I have moved on and got the tile editor basically working.

But I hate it.

Take a look at this shot from M2's tile editor:



Remembering how it works is hard, since it is all obscure key presses, but look at what you can see.

In the upper left, there is a zoomed in current frame, allowing you to edit the pixels individually. Under that is the color palette, allowing you to pick any colors you want to use.

Up top, there are the 6 yellow boxes which symbolize your current palette selection, and the white one is the one you are actually editing and viewing. You change that box to signify if it was day or night in the game and what you want the colors to look like.

On the far right, you have the four frames of the tile, and could select them and edit them independantly. At the bottom right, there are the eight frame order indicators; you have only four frames, but you can make them animate in any order.

Above that is the animated frame, on the left, it stands along, on the right it is tiled so you can see what it would actually look like on a map, instantly.

Under the palette, you see what the current frame would look like on a map; the difference between that and below it is the above is not animated.



What you have there is not pretty and requires explanation, but it is easily functional, gets the job done, and gives you instant feedback about what it will actually look like.

Compare that to the M3 tile editor.



What you see here is the tab that controls what the above program did. Ugly as hell. Though now, you can point and click to do stuff rather than have to remember the obscure keyboard commands and there are Whats This? hints for everything if you right click on it, but it doesn't give the instant feedback the above gives you.

Here you can set six animations, similar to the palette swaps in M2, but I hate it. You need to make those animations ahead of time; you can't make them on the fly. You need to do the palette swaps in separate programs and save them as new names then recreate the animations. I really hate it.

So, you ask, why am I so far going forward with it if I hate it? Pretty much because the old M2 interface won't work with the M3 graphics requirements. It isn't just 16 color graphics and 4 frames anymore. In M2, tiles and characters were all that were animated (characters actually were tiles with stats!). In M3, everything can be animated.

In M2, the tile basically did what the animation does in M3, but in a far more limited fashion. (And tile components in M3 were actually part of the map in M2, and scripts in M2 covered much of what the map in M3 can do, built in. I really like the new map over the old one.)

I really like the new system over the old, but this interface, which is basically required by it, I think sucks. (Lucikly, the map editor is turning out awesome and will kick the old one's ass, and map editing / script writing is what takes the vast majority of time).


Since the tile editor should be rarely used and it does get the job done, I can probably get away with this, but I still think it sucks. I am thinking the alternative is to try and go back to the old system, incorporating a little paint program into the animation editor, and incorproating aniedit into tileedit, but bleh, that will suck too.

Meh, I'm open to ideas, but am going forward anyway since finishing the map editor is next, and it will actually kick ass, then I can make my first test game.



EDIT: One thing I will be doing is providing a set of tiles and animations / graphics for your test games and as examples on how to do things. I will clone a dungeon from FF1 and one of the Dragon Warriors, stealing graphics from them to do it. Obviously that is no good for original creations, since stealing graphics is wrong, but for example's sake, I'll do a few.

[Destructionator XV]

Well, I hate the new tile editor, but it is done and it works. The map editor has been designed, though I am doing a few revisions to it and am going to make a thing called a 'complex tile', which is nothing except descriptions on how tiles work together, e.g., shorelines that can be automatically drawn when you place a water tile.

Once these design revisions are done, it is implementation time, which should go quickly (software design is always a bitch, but implementation is generally straight forward, although sometimes boring). Release is finally in sight.

[Destructionator XV]

I think I might take part of tomorrow off (14 hour days staring at my computer kill, and I probably should do at least some of my backed up homework anyway), but here is the schedule.

Task : Time required (generous)
Compound tile creator : 4 hours
NPC creator : 3 hours
Character editor : 6 hours
Monster editor : 6 hours
Vehicle editor : 4 hours
Map editor : 15 hours
script editor : 8 hours
game variable editor: 5 hours
fill in the help menus : 2 hours (code), 20 hours+ (actual documentation)
main engine : 30 hours

Total: 83 hours + documentation write time

Estimated productive hours this week (conservative):
Sunday : 3
Monday: 4
Tuesday : 1 (my birthday; will probably be eating or sleeping all day, but aside from a test at the college, I'm not doing anything except eating, so will probably get way more than that done in reality)
Wednesday: 7
Thursday: 2 (thanksgiving, probably going to be interrupted often, and a single interrupt can kill an hour)
Friday: 4
Saturday: 6

Total: 27

Following week:
Sunday: 0
Monday: 0 (another fucking english essay)
Tuesday: 5
Wednesday: 4
Thursday: 5
Friday: 6
Saturday: 8

Total: 28

Following week:
0 (allocated to English final paper, fucking waste of time, I should just drop out again)

Anyway, 55 / 83 toward 1.0 can be done in the next two weeks, of that, I feel certain, and some of these are going faster than I thought; today was very productive, so maybe even sooner. That is not enough time to wrap things up before the end of the month, but it is enough to go into alpha and maybe beta stages. As it sits now, the file formats are pretty much designed and there is enough functionality already done to get started in using the tools; I will begin creating the first example set of tiles tomorrow at some point. (These will be used in testing of the map editor)


(the only reason I am actually posting this is to see if my estimates are going to be accurate. Blame Joel Spolsky and Ace Pace (indirectly) for making me do this)

[Destructionator XV]

I've been kinda struggling with the map editor user interface design; what I posted a while ago I decided to discard.

I am going with a new setup partially based on the layout of the Starcraft map editor, but of course, altered to fit this job.

The two most important things about the map editor are the tile placement and the enemy domain system. (And also scripts, NPCs, and events, but they are a separate, and simpler matter).

Tile placement is pretty straight forward: load a tile you created previously in Tile Editor (which I am probably going to merge into map editor on some level), then select it from the list, and click on the map to place it.

More complex is the enemy domain system. This is how the engine determines what and how many monsters you fight in a random battle.

I have decided to create a system so you place domains and tiles at the same time. This makes some sense, since, for example, if you are placing water tiles, you probably also want them to have water enemies. This can be overridden simply by selecting NO CHANGE for either one of the fields and still working with the other field.

I am taking the basic idea from a system I used with some success in M2 to make this work, and the main purpose of this post is to explain how it basically works. I have touched upon this in a previous post; consider this a more detailed revision of those same ideas.

As I have said before, you can be walking or have 6 vehicles to use. You can encounter battles in vehicles if you want, and those battles can be different than what you would encounter walking.

Any map must have zero (if a town with no fights) or more domains (at least 7 for a full world map: one default domain for walking, and one default domain for each of the vehicles. If you want these to be the same, you can simply tell the program you want them to be the same, and it will set the domain to look up from the one you specified. (If you want car fights to be the same as walking, simply set the car fight default domain to "no change"))

You may also add any number of additional domains (well, actually a limit of 256 total, but realistically, you should never need to use that many; even a big game like FF8's world map had no more than about 20 different domain areas, and DW3, which is even bigger than 8 monster wise, had fewer than 80) for your use.

Each domain lists the monsters possible in that area, how many of each monster is possible, and the probability of each quantity, including, if you want, specific combinations. Here is an example:

1 Slime: 20% of fights
2 Slimes: 20% of fights
1 Slime, one Black Raven: 20% of fights
Two slimes, one black Raven: 20%
Two black ravens: 20%

In the example, every fight has equal odds of being any one of those five combinations.

If you don't want to list specific combinations, you can set the probability of each slot and quantity total, and allow the computer to do it for you. Here is an example:

1 monster: 50%
2 monsters: 30%
3 monsters: 20%
Slime: 70%
Black Raven: 30%

Now, when a fight happens, the computer randomly, based on your percents, determines how many monsters there will be. Then, it fills in each slot independantly with the monsters listed, based on their percents. So, if it determined there would be 2 monsters, it would do first slot first, 70% of the time picking Slime, the rest of the time picking Black Raven, then do the same for the second slot.

You can also combine these methods. Example:

Two slimes, one black Raven: 25%
2 monsters (computer chosen): 50%
3 monsters (computer chosen): 25%
(when computer chosen) Slime: 70%
(when computer chosen) Black Raven: 30%

Here, the computer picks a number randomly, and 25% of the time, it makes a battle with the 2 slimes and 1 black raven. The rest of the time, it does what I explained in the last example.

(Actually, the way the program does it, it always figures you are doing a combination, just the chances of computer generated or specific combinations can be set to 0%. Same effect.)


In any domain, you may also override the default for any vehicle, but it is not required.


Once you have created a domain, you give it a name so you can remember what it is, and place it on the map along with the tiles.

[Destructionator XV]

M3 Production Update!

Well, despite getting lots done early last week, I slacked off again for most the rest of the time of the week and into this one (spending much more time blabbing about government on forums and my new blog...). I actually accurately predicted yesterday and sunday would be unproductive though, yay prediction, but I fell short of many the other days.

So I am sorry to say I must push back the time again. I should be able to work tomorrow and friday and saturday quite a bit though, hopefully getting the big important piece done at last: the map editor. What I have so far I like, which is at least good.

The wait will be worth it, just stay with me.

[Mayabird]

Take your time. I have finals coming up soon, and I'm guessing that you have a buttload of stupid English paper and term papers to write as well.

[Ra]

Since we're all busy with various things (though I am getting a few sprites tweaked and editing my plot in my spare time, however), I was wondering if anyone else in the board would be interested in helping the project with artwork?

My own drawing isn't up to snuff, and attempts to draw character portraits on MSPaint have ended up abyssmal failures. In initial releases and in the test mini-game I detailed above, I may run with portraits disabled, or all characters will have be given a "filler" image that is some class icon or whatnot.

That said, sprites are looking great. No problems there.

[Destructionator XV]

Production update! I have gotton nothing at all done this month for various reasons. I am right now caught up in the High Frontier (click the pic in my sig) and work on my original sci-fi universe, including lots of writing, math, and simulations (I've done more physics in the last few days than I think I did my entire year as a physics major at uni). Once I get this worked out a little more, I am going to get back to work, since the break between semesters is now in session and aside from this work, which I want to do while it is still on my brain, I don't have anything to do for the next three weeks (and hopefully won't be pulled away too often by IRL people).

But yay to one thing: screenie of map editor skeleton. That is what I will be working on once I get back into it, and my hours estimates from before should still apply, again, once I get back into it which won't be long.

The time sure flies though.

[Ra]

*casts greater thread resurrection*

I hate to be a bother, but I just feel I need to ask; is M3 still in development, or has it been canceled? I sure hope that isn't the case...

[Destructionator XV]

It is in development, but I keep getting distracted by other things. (January it was reading about hard sci fi, feburary it was blog and OZ,
march it is boobies). Not abandoned though.

[Destructionator XV]

ACTUAL IN GAME SCREENSHOTS

The opening sequence from FF1, cloned in the engine:



This is the skeleton of one of the menus I am working on, atop the main map from Final Fantasy 1, which I converted to an M3 map, with an automatic NES screenshot -> map tool I made for fun:



And this is what I am playing with for night time over the FF1 overworld:



Not sure if I'm actually happy with that yet; what I did was just shaded blue above the regular map, but it was quick and easy, and seems to work. I'm open to better ideas, though.


It is also playing midis of the FF1 songs, which you obviously can't see in the screenies, but it is there.


We have progress, finally! All this also runs at excellent speed on my computer, though it requires a 3d capable (don't ask; it is a hassle I wanted to avoid, but alas) graphics card to make that good speed.


I still have pretty far to go, and there is no knowing how busy I'll be, but this is awesome to me. I'll be there before a year late.

[Ace Pace]

Update!

Okay, I'll let adam fill in the technical data, but two updates.
1, we have a website.
2, basic work on the Tileformat is on, well, this is mostly my side.
We have a semi final Tile data format. Instead of just copy pasting the definition, which I doubt will mean anything to anyone, I'll explain it.

A tile is an image, or a series of images which can cycle, with several properties. Some properties are obvious, such as, can the actor walk on it, can he drive a vehicle, park a vehicle. Other properties include damage stepping on tile causes, the chance of battle while on the tile, the battle background that would result, whether to overdraw the tile on top of the character(say in case of clouds), is it always animated? Is it still animated after the player steps on it? Thats not set in stone, if you can think of anything that needs to be related to a single TILE, comment.



Quick explanation: Left side is frame Control, this is where you add the frames that make up a tile, such as a rotating animation of something. This is done by stacking up .png files. If anyone has issues with creating images in .png, now is the time to speak up.
Each frame has properties, being the minimum 'time' between frames, and maximum. Note the note, thats about game time compared to read time.

Right side includes 3 portions.
Generic flags, such as Walkable, overdraw, animated, animated after step.

That animation after step is kinda weird to explain. If that is set, stepping on the tile resets its animation counter and it runs exactly once. If the animation flag is also set, it then returns to normal.
The use of that would be like if the player runs through grass - the animation would be the grass being pushed aside and returning to its original position.

Vehicle flags, can the differant TYPES of vehicles(not specific vehicles) drive or park over the surface.
Battle data, how much damage is taken, whats the chance of combat, whats the combat background, etc.

Damage right now is defined as:
The damage on step is damage you take on every step.

Missing right now:
Everything except the display.
Loading and Saving full tiles, this is actully written, but not plugged in.

Alot of technical stuff behind the scenes still needs to be done, alot of stuff I have to learn how to do.


Open question
A tile is currently defined as an image thats 16x16 pixels.
What would be easier, creating a single large tile, say, that contains all the tiles of a specific set, such as water, deep water, shores from differant sides, and telling the program where to take the image from, or creating differant tiles?
For adam, it's a trivial change, for me, some more...interesting work I guess. Voice your opinions.

[Ra]

It's alive!

[Ace Pace]

Yes, nice, it's alive. Now can you help me? I'd prefer not working harder on the current design if it's going to get thrown out in 5 seconds due to being hard to work with.

[Ra]

... I don't have any issues with it sofar. I've been making all my tile and sprite images in PNG, so I hardly have an issue with that. Again, I don't have any issue with how it is sofar. Good job, guys.

[Destructionator XV]

On the file formats: it isn't a big deal. If you do png, bmp, or pretty much anything Paint can make, I can probably convert it easily enough.

We are moving forward again, and I'll be offering downloads as soon as it is at a point where it doesn't take my knowledge to use it. Will probably be another month at least. But it really is so exciting.

[Destructionator XV]

How exciting. The to-do list for the scripting engine is down to two major entries, both of which I am certain I can finish by tomorrow night.

The script system has undergone a complete rewrite since I last talked about it. Previously it was based on the same standard Javascript is based on. Now, it is based on the programming language Lisp. Radically different - the syntax is a complete change, as are the paradigms I am focusing on. The good is it should still be easy to use if you stick to the basics, and for the advanced stuff, I'll hold your hand for a while, and after you get the hang of it, it isn't so bad, and incredibly powerful once you get to be good with it.

If you have never heard of lisp, the syntax is like so:

(function-name function argument 1 function argument 2 ...)

That is, parenthesis with a series of things separated by spaces. You can have other parenthesis inside yours as much as you want. For example:

(set 'a (+ 4 2))

Sets the variable a (more on the ' in a moment) to the result of the function + with the arguments 4 and 2, which means 4+2 which of course equals 6.

Math with this prefix notation may seem weird at first, but you get used to it pretty quickly. There is no hidden order of operations - it just goes from left to right, with parenthesis first.

(+ 1 2 3 4 5 6)

returns 1+2+3+4+5+6 which equals 21.

(- 3 2 1)

Means 3-2-1, which = 0.

(- 3 (* 2 1))
Means 3 - (2 * 1) which is 1.

Nothing too bad there, and everything is based on the same ideas.

Something you might see when making a game script is

(message-box "Welcome to some random town.")

Which does just what you would expect - prints a message box with the quoted message. What if you want your message to have " symbols in it? You do what we call escaping: write \" instead of ". Like this:

(message-box "Bob said, \"Welcome to our random town.\"")

I'll probably also provide the syntax:

(message-box `Bob said, "Welcome to our random town."`)
as well. Notice the ` instead of " enclosing the string. This is not finally decided though; there still might be a complication with this that I haven't forseen yet, but it will most likely be there.

How about that ' I used above? To understand why that is there, you should understand what is going on when a function is called. The first thing that happens is all the arguments are evaluated, left to right, then the result is passed on to the function. This is of course why

(+ 1 (* 3 1))

Works - first, the arguments are evaluated:
First arg: 1 => 1 (numbers evaluate to themselves (so do strings in double quotes)
Second arg: (* 3 1), which is another function, so the rules happen again, 3 evals to 3, and 1 evals to 1, the multiplication is done, and the answer is returned: 3. So, (* 3 1) evaluates to 3.

Then both those are passed to +, which adds them, and in turn it itself evaluates to 4.

Things change a little when you add a ' before something: it forces it to always evaluate to itself. Let's do the above again, but this time, quote the second arg:

(+ 1 '(* 3 1))

First arg is 1, which being a number, evaluates to itself => 1.
The second arg, since it is quoted, also evaluates to itself, so what + sees is exactly what you wrote: it thinks its second argument is actually (* 3 1), which isn't a number at all (this is actually a list), so it can't add it. In this situation, + would barf; it doesn't know how to add things that aren't numbers.



In the case of set used above, which sets a variable, it also follows the same rules. Normally, a symbol (that is, something that is not a number or a string (or a list) - just letters and dashes, etc) evaluates to its contents. Let's see an example.

(set a 10)

This evaluates the arguments from left to right:
a => ? (remember, a is a variable, so it would evaluate to its contents. However, its contents haven't been set yet, so this would barf on it).
10 => 10 (since it is a number)

So set is asked to set an undefined variable to 10, which of course it can't do. So you would quote the a:

(set 'a 10)
'a => a (quoted, so it evaluates to itself)
10 => 10 (again, number)

And now it sets the variable a to 10, which succeeds. Now, you can pass a anywhere where you would pass a number, like to addition:

(+ a 1)
a => 10 (set above)
1 => 1
Returns 10 + 1 = 11.

Note that variables are only changed by two things: set and let (let is like set, but set sets it forever, let only sets it for a short time. I'll explain at some other time). So after calling (+ a 1), a is still 10. If you wanted to update a, you would have to (set 'a (+ a 1)).




And that is the basics to scripting with M3. There is much more to know, but you can probably get away with just this for most tasks. More important than knowing this stuff will be knowing the functions I define for you to interface with the M3 world, things like message-box and the sort. I'll provide a list of these with explanations before or with the release of the engine.

[LadyTevar]

Just let me know when it's ready to play :)

[Ace Pace]

Tile editor 0.5



Right now me and Adam are working on hunting down final bugs in the code, and I'll soon start writing a help system.

Right now, as of this post time, it's still not fully functioning but it's getting there.

Missing:
Some key bugs are still inside.
Help system.
Advance image manipulation, the box does nothing.

[Ace Pace]

Version 0.5 of the M3 Tile Editor



Download Link.

Introduction:
A quick overview of what maps are before I focus on the tile editor. All maps in the m3 engine are built out of Tiles. Each tile, as is quite obvious, is a small rectangle that contains data. The visible data to players is quite simple, the frame displayed, or frames.
But theres more, tiles in the M3 engine have the following feature:
Support for multiple frames per tile, up to 255.
Configurable minimum and maximum delay between frame animations.
-Note: Frames can now use different parts of the same image, I.E you can have a large image from which you can make several frames, each taking a different part of the image.
Support for different tile sizes.
-Note: currently fixed to 16x16 but this is trivial to change if there is request for this.
-Support for multiple tile settings, such as:
Is the tile walkable?
Is it drawn on top of characters or not?
Is the tile animated?
Does the tile start animation after the character steps on it?
Note: As of now, it's not automatically setting it self to animated if there is more then one tile.

-Support for vehicles types, such as whether they can drive or park on top of the tile.
Note: There are currently 8 vehicle types: Cars,Boats,Ships,two types of Airships(Airship1,Airship2) and three custom(Custom1 to Custom3) vehicle types.
-Support for damage if stepping on the tile.
-Support for different frequencies of battle on this tile.
-Notation whats the preferred background for battles occurring on this tile.

Now, several technical notes:
Currently, a frame can only be a .PNG, while you can select other types of images, please stick to .PNG.

Advance image manipulation, such as taking the frame images from a spot that is NOT the upper left, is not supported, it's visible(nice button saying 'Advance') but not working yet.

This version is not complete and not completely bug free, before saving, please make sure everything you set is correct, and currently, write that data down somewhere, because there still might be some issues in loading Tiles.

Currently, a tile is set to .tile, in expectation that later on, we can tie this to Windows so that whenever you double click a .tile file it will load the program. However, this is not working yet. Please do not save tiles in any other formats.

Important note: This version is beta, try it, play around with it, but stuff might change. Hopefully only for the better, but for all we know, the entire setup is currently not useful and we'll have to rewrite this.

Important note 2: If the program crashes, please pretty please tell me what you were doing, as much as you can remember, and send me an email at AcePace@Libriumarcana.com

Missing features:
Right now, since this is a 0.5, theres quite a bit of stuff missing.

1.Advance image support, this is coming, might even come in a few hours of this release.

2.Help system.

3.Built in help system so you don't have to use stupid help programs/files.

4.Serious error checking. The editor currently checks that you don't input letters where there should not be letters, but it doesn't really tell you. Also it doesn't check if you input stuff thats way out of bounds.

Technical data: (Non programmers need not apply)

If anyone wants to extend this program, please do so, or create their own.
Currently, the file format is as follows:

-4 bytes giving us a magic number, which is currently 'M' '3' 'T' 1. This is for versioning.
-A byte giving the number of frames.
-After this, each frames follows in the following format:
1.A string containing the filename/file path of the frame image.
2.An Int16 containing the minimum wait between frame animations.
3.An Int16 containing the maximum wait between frame animations.
4.An Int16 containing the starting X coordinate of the frame inside the image.
5.An Int16 containing the starting Y coordinate of the frame inside the image.
6.A byte containing the width of the frame inside the image.
7.A byte containing the height of the frame inside the image.
-A byte containing bit flags regarding what vehicle types can drive on this tile.
-A byte containing bit flags regarding what vehicle types can park on this tile.
Note: The order of the vehicles in the bit flags is according to data provided in the start of these notes.
-A byte containing bit flags regarding tile properties in the following format:
First bit: Can walk on the tile.
Second bit: Overdraw
Third bit: Animated
Fourth bit: Animated after being stepped on.
-An Int16 containing the damage that occurs if the player steps on the tile.
-A byte containing the battle frequency on this tile.
Note: Battle frequency is calculated thus:
A Battle counter is randomly created. Each step decrease the battle frequency number from that counter. when it is <=0, a battle occurs.
Or in code:
start_over:
battleCounter = random(0, 255);
on each step:
battleCounter -= tile.battleFrequency;
if(battleCounter <= 0){
fight();
goto start_over;
}
goto on_each_step:
-A string containing the filename/File Path for the background to be used in event of battle.

The source code for this release is available here.