Some of us have never heard of GameMaker

Hey, since there are more people now who are able to compile Monday on Windows due to Trent's allegro5.org site, let's have the Leaders start deciding what needs to be done.

Some suggestions:

1) We need maps. If all you can do is run a precompiled "monday" binary, that's all you need since the maps are all text files for now (just edit the level, and re-run the game to see your results).

2) We need (more) tiles for the background for the new maps.

3) We need more Entities. The "gryphon" placeholder is a good start, and if we could get more Entities to use in the various maps, we can know when we're attacking an NPC or a monster

There's still a lot left to do in the source code, of course, but these suggestions can be implemented all data-side and not even require someone to have a compiler on their system to help out... they just need to be able to run the binary.

What is the format for documenting code again?

/**
 * This function will do something, and this comment will be auto-parsed...
 *
 * @param a The first input in the function
 * @param b The second input in the function
 *
 * @return true if the return value is non-0, false if it's 0.
 */
bool function1(int a, char b)
{
  return 3;
}

Or is there a different one? Having in-line comments would help with some of the documentation...

Ooooh!

Now, by "stuff we could use"... does that mean that these are more placeholder images/backgrounds that we can use as they are owned by some company that'll get pissed if they ever catch wind that we ripped out their sprite sheets and used them in our own creation, or does it mean that they are freely available for "anyone who wants to use them" (like on the terms that, if the game is not going to be sold, we're free to use them)?

Otherwise, I'd be worried about ripping something off and forgetting that we had them until somewhere down the road when the project gets canned because of an upset copyright holder.

Changing the <entity> tags to have "tile_x" and "tile_y" support (in addition to absolute "x" and "y" coordinates), I've set one trigger at tile_[xy] = 6 and the other at tile_[xy] = 7.

http://www.allegro.cc/files/attachment/597245

These two "entities" are actually the triggers in the bottom-right corner of the map.

As you can see, "x,y" or "tile_x,tile_y" set the center of the entities at the coordinates specified, not their top-left corner.

Should tile_x and tile_y compensate for this 'centering' effect and actually try to align it more closely to the top-left of the tiles instead?

I got most of them from charas-project, so you may have to look at each one to tell...I am no lawyer and all, so I am not sure about these really. Most come from RPG maker...I don't know if you can use them in whatever...but I imagine you could, since you can make a game and distribute it anyways.

Allegro doesn't block stdin or stdout, just make sure the game is compiled with the console enabled (-mconsole/-Wl,-subsystem,console/Console Project in msvc), and things'll work out.

I'm taking a look at some other, older code that we may be able to use to keep track of screens.

bamccaig's developer console (as well as in-game menus, dialog boxes, etc.) will probably require that inputs be captured and not passed up to background processes.

Therefore, a Commander needs to keep track of which window is on top and has focus, and whether or not it's modal (meaning that it doesn't pass inputs up to its parents, nor do parents respond if one of their children have isModal defined).

I'll probably be working slowly on this, since I don't want to break anything, and since I haven't fully wrapped my head around how it works myself (it's my old company's code that I'm looking through that does this).

...unless there's something else our Leaders would like me to be doing...

Actually, just getting ready to post that I just pushed up a few more SVN updates.

Leaders, if we are to start working with collisions and picking up items, etc., we're going to need several maps drawn.

1) We need about 2-3 maps that move "room to room". Will transitions occur when you simply "get to the edge of the map" or will it only occur when you click "activate" on a door?

2) If we have some maps that hold "friendly" NPCs, and others that hold "enemy" NPCs, we could start working on implementing conversations (with friendlies) and fighting (with non-friendlies).

We need more, but we need at least these so we can make sure everything code- and data-wise is set up correctly to handle what we need.

Also, for those keeping track of the SVN, Don has uploaded some tilemaps to start using. Personally, I found some that I like (if nothing else, they can be temp placeholders until we draw our own):

If someone wants to start on a few maps, those are available under the "./rawdata/Free" directory. Many of these are for animations, but the ones for walls and things can be useful as tilesheets.

Leaders! Read the ./docsrc/*_todo.txt files and let us know what needs to be done next, and who should do them!

Do we wish to implement this as a trigger that activates when you walk onto it, or an event that is fired when you reach the "edge of the map"?

This was discussed in a post by 23; I think the conclusion was you wouldn't scroll, but I don't remember why.

A thousand apologies; stuff's been happening at work and with job hunting and other things that are cropping up. Suffice to say, I'm in a bad mood.

Basically. And yes, no scrolling, just because it complicates things. I want to be able to adjust room sizes as I see fit and there's no reason it has to adhere to the same grid-pattern Zelda does; as far as I'm concerned, the only reason Zelda even still does it is because it's part of the "style" of the Zelda series, going all the way back to the original. We're just doing a fade-out/fade-in, like your typical Final Fantasy game.

I haven't had a chance to armwrestle with Allegro 5.0 in a few days; what are the chances of a binary with some simple map-switching, since that seems to be the current topic? I'd like to see if I can start editing those maps ....

23yrold3yrold: If you can use the files from allegro5.org, you can use the "makefile.new" that's found in the trunk. It creates a binary as "bin/run_me.exe". Run that from the base directory (and optionally turn on debugging with a "-d" switch).

You should see the screens I posted earlier.

Right now, my next objective is to get some triggers that activate when you step on them, though I need to know how we're going to handle the collision detection with them: Since we're not bound to 32x32 pixel tiles in our movement (it's more free-flowing), at what point do you activate the triggers?

• Is it when your sprite barely grazes the outside border of the trigger?

• Is it when at least 50% of your character overlaps the trigger?

• Is it when you're between 75% and 100% on top of the center of the trigger?

50% may work fine, but developers may notice that things start activating a little prematurely if the character "kinda" bumps into a trigger-activated spot when they're actually just walking "around" the tile. I'm more apt to go with the 75%-100% because you know that you're intentionally standing on the tile/trigger.

Ideas? Feedback?