EDIT:

Per Onewing's request, here are some of the important links for this thread:

Monday^[1][2] can be found on SVN at http://svn.miquelfire.com/monday/ (thanks, MiquelFire^[1][2][3] for the repo!).

Two project pages used to keep track of Monday's progress and design ideas are:

• Allegro Wiki: wiki.allegro.cc

• Mark Oates' page^[1]: www.zeoxdesign.com

Monday will use the Lua^[1] scripting language (current version: 5.1.4).

[center]=== ROLES AND ASSIGNMENTS ===[/center]

Matt Smith is our Evil Producer.
23yrold3yrold is our Team Leader.
Thomas Fjellstrom is the official Cat Herder.
Trezker is our Lead Programmer.
bamccaig has started to work on a developer console that may be incorporated into the Monday project to allow in-game edits.
alethiophile is Programmer #12.
Thomas Harte has offered support for "drawing TrueType fonts with OpenGL geometry".
decepto has offered support for sound design.
Pedro Avelar Gontijo has offered support for music (is this different from decepto's sound?).
relpatseht has offered even more manpower.
Paul Pridham has offered some sort of speech support. Cool.

To discuss this in an IRC channel, CGamesPlay has suggested using mibbit.com if you don't have a dedicated IRC program. Join us on the Freenode server in the #allegro channel. The #allegro-monday channel is often used as well for intense Monday-related discussions so as to not derail #allegro too badly.

Oh, and 23yrold3yrold says we haven't yet beaten the longest-running thread record yet...

...there may be more... I keep losing internet connection and want to get this posted.

That sounds interesting, actually. I think there are enough people around here these days who have enough programming and game design experience to do that.

It's just a matter of how many people you can get involved. Well count me in.

Alright. First thing to do is determine the game type.

I've ALWAYS been a fan of RPGs, but I'm flexible.

Ideas anyone for this game? Moreover, GAME NAME ideas anyone?

I'm in.
Should try to make it more than your random TINS entry (though some were quite impressive!), since we have a week or however long to do it in, and more people. And it's hard to come up with a game name if we haven't decided on a genre/setting yet. I propose, however, that it be set in space.

Surely if it's a competition or event, there is no single game name?

I'd be willing to take part, schedule allowing. Obviously team arranging on forums such as this is usually folly, but if it's explicitly a one week competition-type thing then I reckon it could work out.

Would we have a magic computer match us up into teams? If so, presumably it would do so through application of a matching algorithm based on our preferred development libraries and possibly environments?

I would help with a group thing. I've learned that nothing of real note gets done solo, at least IMO. As long as I know the rest of the team is on the job; I think KQ has mostly hit the rocks.

Nice idea. As long as it's not gonna be in the next month or so, count me in! (And as long as we won't run into problems like "no one to do the graphics", which is a project-killer. Unless the project doesn't have graphics of course )

It's never going to work. And it's Monday.

Most probably, but it doesn't hurt to try

First of all, how do we set up coordinating our efforts? Say we have 4 programmers. Do we have someone here who knows how to set up a part-time, short-term repository that we can check in/out our changes? Or do we need to start PM'ing and emailing all ideas to "the head programmer" and let that person integrate everything?

Setup an SVN repo on some server? That makes the most sense, I think.

The fun question is, who's being sarcastic, and will the people who aren't figure it out?

Believe in hope Matthew! Believe in hope!

So I've got these takers so far:

OnlineCop (me),
Mark Oates,
alethiophile,
Thomas Harte,
23yrold3yrold,
CursedTyrant

I have absolutely no idea how to set up any sort of SVN or CVS repo at all. Does someone here know how, and where we can host it for the next week (maybe a week-and-a-half for a long estimate)?

I don't really care if all of this code is 100% original, or if it's only 80% original (like reusing old and very efficient timer routines that's out on the wiki already, or whatever), so we can get started as soon as we come up with a depot for all of our code and graphics. Once the repo is setup, we can hammer out game ideas.

People reading this forum are welcome to submit suggestions! (Or would it be better to come up with the "this is the type of game we're making... NOW who's interested in being part of the group?" approach and choose candidates from people interested in the game?)

I know how to do an SVN repo, and AFAIK that's better than CVS. (I don't have any experience with CVS, just SVN.) As for where to host it, Tuxfamily (Google it) provides free hosting for projects under OSS licenses, but it's uncertain whether they would accept something like a game licensed OSS--there's some wording about "relating to the free software philosophy". I'm unsure about other services providing SVN hosting--I know there are others, but they all cost money. If it's only for a week, then it's barely possible that we could host it on one person's PC that isn't ever turned off. That's a problem, though, because most users' ISP contracts forbid them from running servers on their machines.

Everyone who's interested in this project, rank your top 3 game genre preferences.

Mine are:

1) RPGs
2) Puzzle (like Zep's Dreamland)
3) Action-Adventure (like Zelda, Chrono Trigger, Secret of Mana)

With this, we'll narrow down what we'll work on as a group and get started (with or without a repository, if necessary for a few days).

See I'm thinking that we have several teams.

I think that instead of the group deciding what to make. Spin the Speedhack rule-o-matic.

RPG is a likely-to-fail, Puzzle is too easy. Make it a platformer or adventure game or something.

That's for each individual team to decide.

This should be for each team to decide.

"Each" team? It's Monday; one team is optimistic. Let's not get silly here; start small.

We did a team competition once with four teams. It was moderately successful, so it is possible.

Well I'm really only interested in a proper event, and therefore in planning for an event. I have no faith whatsoever in the idea of us all just deciding we're going to be a team for a week and then actually doing it.

I'm aware that the event may not happen, but I thought that was the nature of the thing we are discussing.

Re: teams in general, the only time I've ever really been part of a "successful" team (i.e. one that completed a project) was doing the Allegro Skater demo game. I did the main game code alone for a concentrated period, the menuing system and script for creating the level with Blender were done by others; I just followed instructions to use the menuing system and provided a documentation of the ASCII-based level file format. So I guess the key, during the event, will be properly defining the boundaries between roles and how the different parts should slot together.

If anyone ends up on my team, I'm going to push for adoption of my event-based game framework*, which sits on SDL, SDL_mixer, SDL_image, FreeType and OpenGL (but obviously I won't go home and cry if it's rejected); can we have ChristmasHack-style rules that don't stipulate Allegro?

• as used, in various states, in everything I've done since 2005.

It's already failing!

The only group decision should be to elect a team leader. Don't you see that any detail left to a group will never get decided? Letting the group pick the genre means five angry kids deciding to do their own thing since the group went against their desires to build a 3D Japanese cartoon porn puzzle soccer game.

The reason group projects work in the real world is because everybody is getting paid to listen to his or her employer.

I think we have a genre!

Well, if this gets off the ground (Key word, if), I can provide SVN repository for whatever. If it's only meant to be for a short time. For long terms projects, use SF or any SF clones (like the one OpenLayer is hosted on)

Exactly why there needs to be a team leader.

Who here would be interested in being a Team Leader?

I'm in.

I figure that if the team leader calls all the shots, the entire "this game is fun (or not)" rests on that person's shoulders. In the gaming industry, some games just plain suck, and I blame the project manager for that. Although the game publisher checks in often and suggests areas of improvement, it's the manager that calls the shots, makes the final decisions, cuts some aspects and emphasizes others.

So if the project is doomed to fail, at least the next time there's a group competition, you know who you DON'T want for your team leader...

Yup, but too bad electing a team leader is a group decision, which can only end in failure.

Team leaders work in the real world because they are paid to be the leaders and you are paid to be the monkey. Out here, in the Internet, we all think our ideas are the best and will argue non-stop in circles until we get our way the thread is closed.

For a group project to be successful on the Internet, somebody needs to step forward and write a bunch of code and get it all working to build up interest. Now he is the leader because he has proven to have what it takes to get stuff done. He doesn't have cash to offer like in the real world, but he does have a substantial code base to build upon. People like to be part of something successful.

All that said, I do think that a team competition like amarillion mentioned can work if it is a very small project with a short deadline. But of course, such projects don't really need multiple people...

What do you mean group projects work in the real world? The failure rate is extremely high, even in the corporate world. The main reason for this, however, is poor planning and lack of organization. Somebody needs to nail down the ideas before a code repository is even on the drawing board. Figure out what you're making first. Then pull ideas in to work out the details. The code, graphics, and sound come last. And don't set a deadline until you know what you're developing. That's a recipe for failure.

I'd be interested in participating, but I'm not sure what help I would be. Especially without knowing what exactly will be developed.

I view myself in a position where I would be of no help, other than setting up a SVN repo or two as that's a few minutes out of my day, unlike the hours (most likely as it's a game project) other work would need.

I nominate 23 as our team leader.

I'll second 23.

23 gets my vote, or my support, however we decide this. Also, this may seem obvious, but I've seen group projects that died because they didn't get this: Team leader is arbitrator and final decider, not sole input to the decision.

I'm down with that.

I think everyone here knows that.

[nvmd]

I'm in, and I'll also throw in my support for 23 as team leader.

No doubt, but I wish you had some screenshots there so we could see at a glance if there were any similarities in theme of gameplay. See what a group finds easier than an individual. Maybe they're all "endless" games, like Tetris.

Flattered by the "nomination". Okay, let's pretend I'm leading this; I'll throw out a "vision" and we'll see what the comments are. I'm partial to the quarter view adventure style game (think Link to the Past). I don't feel like doing a platformer since I'm still working on The Mighty Stoopid and I'd just be recycling code. Keeping within a realistic goal, there should be, say, three dungeons and then a final dungeon. Lots to do in between; like most adventure games, some mini-quests to actually get to the dungeons. Short game but we can try to pack a fair amount of interaction and an intriguing plot in there. So what do we need:

- setting
- plot and characters
- rough map
- ideas for flow of game/quests
- dungeon design
- enemy design
- player interaction, weapons, items, etc.
- graphics and sound (low priority for now)

I don't know how teams usually delegate code duties, but we need the usual; tilemap engine, collision detection, NPCs to converse with, objects to interact with, a way to track quest points, handling death/zoning/saving/options, in-game cut scene, all that jazz. Plus name some stuff I missed. Anyone want to grab one of those and start brainstorming?

Top-down sounds awesome.

I like the idea, though I think it needs to be scaled back a bit. For example, 3 dungeons, an overworld, and final dungeon would be enough to work on and manage, so how about we scrap the side quests and keep NPCs to a bare minimum, like a 1 window popup when you walk within radius?

Basically just simplify for the sake of "get 'er done".

The next question in my mind is the map format?:

1. equally spaced tiles
Or
2. A list of objects arbitrarily placed with rectangular bboxes.
Or
3. A mix of the two, background graphics are tile-based but physical objects, blocks, stones, are arbitrarily placed.
Or
4. Something else

I vote for #3.

3 would be wise. Maybe. Normally I would just make everything tile based though. Maybe some things will need to be separate objects by design, but that will be dictated by gameplay requirements. Clearly tilemap-everything would be easiest, so we'll do it if we can. That's a page 8 topic though.

Once a system is implements to handle NPCs and quest chains, implementing new quests is trivial (kill this monster, find this herb, talk to that guy, bring me materials to make this thing, find key for door, etc.) so there's nothing keeping us from making a relatively interactive world. I'm all for "get 'er done" but let's not be lazy.

Ok. I've never done NPCs, quest chains, and scripting so that all sounds like the complicated stuff to me. Everything else looks very doable on my end, but those three in particular intimidate me.

Here's mah plot proposal, I'll just throw this out here:

Title: Z-Strand
Premise: The overworld is a space station (think ds9 but more federation) where there are shops, people, places to go, etc. Your mission is to go to some teleport rooms on the station, each room ultimately takes you to the dungeons, where you have to do the level and locate... a strand of bacteria... once you locate all three (the three bars of the "Z", I guess N-Strand would work to, that would be in your map/item screen... anyway) then you open the super whatever and it takes you to the last level. Each dungeon can be completely different... maybe the teleports take you to different time periods for example.

The reason I like a space station is because it'll take us out of the days of yore which is typical for an adventure game, and I think that would be refreshing. Plus we could do cool effects like teleports and lasers and stuff like that.

Yeah, I was thinking futuristic setting too. No time travel though; there's lots of time to jump a shark later.

Okay, space station/colony for main setting. We could have a main colony and an overworld with smaller colonies. Dungeons could be satellites, caverns, power plants, hidden bad guy base on an asteroid, alien craft/ruins, etc. Lots of variety. Travel can be on foot or with a shuttle, maybe a teleporter can be opened up end game. Any one of these locations can be in space, on a planet, on a moon, or it can all stay "local". We could have a military man investigating some mutiny in secret (colonies don't get disrupted too much by that), we could have some lower officer who ends up saving (most of) the colony from an alien invasion, we could have something more personal to the main character.

This is going to give us a lot of freedom as far as weapons, obstacles, enemies, etc. go too.

Anyone want to have at a general plot outline? Should we make it a bit "cartoony" (like Link to the past was) or go for something more serious in tone and graphics?

I like that.

I'm thinking cartoony but serious, like color and tone from Titan A.E. (some attached screenshots) but rounder and more bubbly characters like windwaker - Of course the variety would saturate the color palette here and there.

I think everybody else is asleep

Yeah, I'm putting this to bed until tomorrow. Kinda defeats the "team effort" idea if it's just you and me.

What? Two people is not a team?

I think everyone else is so much in awe of your excellent ideas that they feel ashamed to post their own crappy ideas.

The main thing is not feeling ashamed of crappy idea, it's feeling ashamed because you are not able to translate them to working code.

Motivate people, join them !

PS:

I would have joined with pleasure, but some few week ago I decided to continue my abandoned project, so I set up a new project and I am cannibalizing my old old code, creating a to-do list, ect...

Well, I won't be throwing any ideas at you today, since I have to study for tomorrow's exam, but so far everything seems fine.

As for the tilemap, I'd go with #3.

I'm liking it so far. One question I'd like to throw out there:

Turn-based combat(Final Fantasy style) or real-time(Zelda style)?

I vote for real time, because it's more fun.

I'm in. I would have posted earlier, but my internet's been up and down all day yesterday.

I vote for real-time so you can see the enemies and choose to avoid them (if possible).

I'm trying to make some preliminary engine code that we can start and build up on. It's not done yet, but if someone else has an engine, or some code, that they're writing for this, we can let 23 decide on which to use.

Yes, real-time. That's why I drew parallels to Zelda and not Final Fantasy. Just now you'll be using a gun and not a sword.

I'm not too worried about code just yet; we're still in design phase. I would like to use C++ for it personally, but if the people most willing to contribute code prefer C, we're probably stuck with that.

First thing I'd like to be hearing is story ideas. We need something that follows the game flow through 3 dungeons to a final dungeon, and gives you some objectives in between out in the overworld. Is it just 3 arbitrary levels before the final level? Do we go the Zelda route of "collect three things from these dungeons to open the final dungeon" right from the outset? That would make for one simple story. After that we should hammer some details like what items or upgrades you get along the way, and then start mapping this out to various locales and get an idea how all the quest points link up. Once we know what we need to do all that, we'll have both the direction and hopefully the motivation to get the code flowing.

Dungeon #1: Ruins of a civilization that's gone on some planet. Find the first piece of the puzzle, maybe along with some documents telling you what this thing that's now in three pieces is for. Ruins would be a good setting for low level opponents, scavengers, animals etc... You could also put in some areas with high level opponents so you can return here later, but that's bonus stuff.

Dungeon #2: ?

Dungeon #3: Infiltrate enemy base. Make up some story on how you get into the base and provide an extraction point. But you'll have all the time in the world to sneak around in the base and find the final piece.

Dungeon #4: Profit...

I put the ? in the wrong place now...

I'm iffy on the infiltration idea. On the one hand, it can be really fun to sneak around an enemy base right under their noses. But on the other hand, it can detract from a game if you spend half of it blasting your way through every obstacle and suddenly you have to sneak around and move slow. I think it would work best if being caught didn't throw you back to the beginning of the area, but instead the guard tries to set off an alarm and you have to try to stop him before he does or else you have to fight off a large group of enemies.

So then are we spaceships, little men INSIDE of space ships, aliens/astronauts with space-packs?

Are we going to be in an inside setting, or outside? Like, will it be a Halo-style indoor setting as we run around our own (or others') ships, killing baddies with all the effects of gravity, or something like Asteroids and Arcanoid where monsters come to ram our "hurdling aimlessly" persons into black holes?

Heh, I wonder if it would be a good idea to make ruins outdoors on planet, infiltration indoors and third "dungeon" in asteroid field flying around in a scout ship.

If one where to make such diverse environments you can't make a level grind I think since you require completely different skills in each place. "You've leveled up your stamina a lot in the ruins so we're gonna give you a faster spaceship"

As for the sneak vs fight on infiltration I imagine a GTA approach would be nice. You start a fight, guards chase you, fight more means more and more guards. Reset to anonymous by entering a repaint shop... Well, you get a new disguise.

Sounds interesting, define top-down, are we talking zelda, crimesonland or isometric style?

In anyway, I'm definitly in if there are any positions open.

I keep seeing Zelda perspective in my mind...

Opinions on some questions that have been asked: I prefer C to C++, and a Zelda-type, square-grid, top-down view sounds good (easier to move around in than a platformer). Also, if there is an "infiltration"-type level, than an alarm going off shouldn't just automatically lose you the level, but should bring more guards to the area--like it's handled in Lugaru, if anyone's played that game.

So are we all agreeing on the gametype/gameplay? Do we know who's in the group(s) yet?

If not, here's just another game idea to throw into the ether:

You have a grid of colored blocks on a playing field:
http://www.allegro.cc/files/attachment/596282

The Tetris shapes on the right are the ones you can play with. You are shown their shape as well as the "after I have placed this on the grid" spin direction.

You must align 3 of the same color in a straight line, or 4 of the same color in a 2x2 grid, in order to clear the pieces. When they clear, they leave a hole that the pieces on top of them fall into. New random pieces fill up at the top.

After you drop the Tetris piece onto the grid (within the lighter-gray 4x7 grid), all the blocks under that piece are rotated in the specified direction. The reason for the outer dark-gray grid is so you can see what colors would be circulated into the play field if you drop the Tetris piece near the edge.

It's probably not as fun or exciting as the idea everyone's coming up with right now, but if there comes to be two groups instead of one, someone could always use this idea...

no no no... we're doing the zelda thing, that's pretty much decided. Lets keep focused

Think Metroid from a Zelda playstyle and perspective and you won't be far off.

Seriously, we need to get on the story. I'll write one myself given a few days, but again, it defeats the "team" idea. Half these dungeon ideas may end up so much fodder if they don't fit with the plot we come up with so let's do that first ....

Not really. You need to start somewhere. if the entire team is in on it from the start, you'll never get anywhere.

If you plan to do everything together you are all better off splitting up into 3 teams of 2 or 2 teams of 3, better chance of agreeing on things, and thus actually starting. Or just agree on a general outline, then let the leader go off and put things together in a format you can all then work on together.

Yeah, I'll probably end up writing the story in the end, but my point stands that half the stuff being suggested at this point would be scrapped if it doesn't fit the plot. Either brainstorm on that or leave it to me and I'll use it to start a new thread ...

Puzzle games isn't teamwork projects :/.

Anyway, I really hope something takes off, I was to sick to program during tins and now I really need to program.

Question: Is this vision somewhat right:
Zelda style game in futuristic space, where the player shoots stuff (probably aliens).

If this is right, Might i suggest multiplayer? sound like a typical coop-fun kind of game. I might be thinking larger than I should but I think at least hotseat should be included.

I think what we need answers to right now is, how does the game end and how does it start? Just so we know where the box is.

Why do you think 23 is trying to get the plot (at the very least, the outline) done first?

Stab at an incomplete intro story:
A year ago one of our allies abandoned their home planet. For reasons unknown to us they suddenly made a huge effort to evacuate their whole world. We don't even know where they went. They were very aggressive against any attempt to track them.

None of their colonies or even their second home planet followed in this exodus. Whatever happened was local. Our investigations have not produced any answers to his mystery. However, with the permission of the new government they organized, we were given access to the home world to search for clues. In this search we found one machine which purpose we could not find, all documents about it was very cryptic.

Over the last year we have made some progress in figuring out how the machine operates but we do not have the means to make it run. It is missing three components.[insert stuff here]

So, who can come up with the answer to the mystery and what exactly those three components are?

The only backstories I can think of for a game like this are either the character is trying to do something heroic (ie rescue the princess, prevent the bad guy from taking over the world, etc.) or because he/she is taking revenge for something in the past.

I had an idea not too long ago: Its an RTS and not a RPG or Platformer though (fairly obvious)

Your world has just suffered through a self inflicted Global Warming cycle, and are now on your way to a severe ice age. livable areas were already limited, now the previously cooler (though much warmer than normal) north and south regions are cooling down FAST. There is currently not enough room on your world for all the souls living on it, let alone after the livable area shrinks even further. Your mission is to get as many people off your world as possible before they start a global war for limited space, and even further limited resources!

You have several options, Rockets, Space elevator, reusable spaceships.

You have limited destinations available, orbit, the moon, mars, or generational space ship. What order do you build things? Where do you send people, and how many to which place? Do they all die? Its up to YOU.

I vote for Trezker's story. its... erie...

as an addendum (for the sake of clarity):

Our investigation team is stationed on a large, nearby public space station (now I'm thinking more like the fifth element cruise ship interiors) retrofitted with advanced research equipment and a transport shuttle.

so... each dungeon would then be on the surface, transport there and back by shuttle, and since the world is so large we could plan levels in different environments... even areas that had been inhabited before, so that could give us step quest things like find keycard, open door, defeat monster, flip switch, etc.

I'll go with Trezker and Mark. It's a decent story and better than anything I can come up with. Also, if everyone tries to push their own ideas nothing will ever get done.

Mah proposal for the three dungeons:

1. some basic world surface (grassland, mars-rock, swamp, jungle, ?)
2. underground cave (with some technology lab type stuff)
3. city ruins (Looks like the cruise ship except it also extends outside and is much more dirty, lots of broken sparking type tech stuff.)

for the most part I'm seeing the dungeons as being somewhat disorganized and cluttered (as opposed to the clean decor of the space station)

Aw come'on. There's gotta be at least one hulking space wreck, drifting through the void leaking atmosphere.

dude! idea!

after you find all three of the <whatevers> our protagonist(s) go back to the space station... and... ALARMS! ALARMS! >>BOOM!<<

a hulking space wreck, drifting through the void leaking atmosphere has crashed directly into the space station... why? how?... is it a malicous attempt to prevent our team from discovering the truth about the <whatevers>?!

Station Captain: "We couldn't avoid it. It came right at us like a magnet, no matter what maneuvers we tried."
Lieutenant: "It's a hunk of space wreck. It doesn't have any propulsion systems, no navigational sensors, nothing. Something sucked it right into our ship."

someone will have to go aboard to investigate, and who is more qualified than the investigators brought aboard for the research mission!

Begin level 4.

Me likey! It adds a nice twist. Suddenly the safe and secure base is the most dangerous level seen yet!

Here's an idea about how the wreck crashes into the station and actually causes the game to switch from having the player focus on a spot on the planet to being on the station for the last level, what you're finding are generators and you have to activate/destroy them.

If it's to activate them, maybe because you need power to a central city of sorts to get in, it causes a beam to appear that results in it causing the wreck to hit the station. Why that happened could be figured out while you're trying to save the station from crashing into the planet or blowing up, basically causing you to be stuck on the planet otherwise with no way to get home (along with the survivors of the station)

If it was to destroy them, maybe to remove some force fields, then the last one causes the area you targeted for the whole game to be a launch pad of sorts, and the last shield actually prevented its contents from be shot out into space, maybe causing other planet to require evacuation if it's not stopped. It was lucky (maybe) that it hit the space station and basically put itself in a position to be unable to get to other planets, but if not dealt with, may allow the station to be used as a way to other planets.

Seemed much better in my head... I need to work on that. Oh well, this is just brainstorming right.

I like the story and addenda that have been proposed by Trezker, Mark Oates and Neil Black. Maybe also, there could be a level/area in which you are being attacked by robots (either left there to guard something, or malfunctioning), and you have to reach a computer from which you can reprogram them?

That sounds interesting. Maybe the wrecked spaceship could damage the space station's internal defenses and you have to get to the core processor and reboot it.

Need I bring up the huge team we had formed for Retro Remakes several years back? We ended up with a team leader (possibly it was even 23 back then too), the project went on for a short while, then just kinda dropped dead out of nowhere.

Let's not think about failure, it's fun while it lasts.

Wait; what?

Keep brainstorming, sometime in the next few days I'll try to grab a cohesive plan out of it all and post it. More ideas == better ...

Well, we now have the general game idea and genre down. We have several people willing to work on the game. We have someone with access to a temporary repository.

What we DON'T want for a game is a committee. All of the programmers who will be in this team will have to acknowledge that they may give some game ideas that are flat out rejected by the project leader, and some that are only partially accepted or implemented.

All the game fleshing-out, storyline details, environments, animations, battles, and so on should only be the project group's decisions. Forum input is always welcome, but quickly gets out of hand.

Is there anything else we need to actually start programming now? The whole idea is to get a simple idea "just working enough" to showcase it here on the forums in a short amount of time. It doesn't HAVE to be a blockbuster. Heck, it doesn't even need to be FUN, nor 100% bug-free. Just get something working and "out there" and let others take a look at the group effort, give feedback, etc.

I wanted to do something fun without it becoming tedious.

So let's program!

I know very little about game programming for larger games, but from what I can tell we'll need some engine code that won't change regardless of storyline, especially if we've agreed on the basic game type (top-down shooter). Maybe we should work on that.

I suggest setting up trac. Its wiki and task management is easy to work with and it can be extended with more features if needed.

And no, I don't think we're ready to start coding yet. You can start on your own stuff if the fingers are itching, but we haven't even passed the concept stage yet.

Who will setup the trac server? It requires root access. Well, if it doesn't, then I don't feel like looking too hard right now. (That, and the system I would run on only has Python 2.3... Bleh)

Scripts for dialoque scenes would be useful, but the story can often follow after the map. Instead of a story declaring "He walked a long way" it's a case of "Map #3 looks nice but takes a long time to walk across, so let's explain that in the story".

Major characters need fleshing out first, so they can be drawn, animated and used to devise storylines. This would need to be a fairly detailed biography. Professional authors do it for themselves, and it would be utterly essential in a group project, or else the characters will be children of a single mind. If it's your primary duty Chris, then you'll either have to carry through the "visionary" thing or let go at the start and make sure the character's motivations and emotions are public property.
EDIT: Another plan would be to get volunteers for the voice acting, and let them motivate their own characters. Is there something like skype which lets you multitrack record a conference call?

Somebody needs to specify exactly what the tile size and perspective is, unless you are waiting for an artist to come along and read your mind.

I'd say 16x16 or 32x32 would be a good tile size. 16x16 would be good because the tiles require less time, but 32x32 looks nicer (when done well). As for the perspective, I assumed it would be in the 3/4 top-down style like the early Zeldas.

EDIT:

Another question, would this load room-by-room like the early Zeldas, or be more free-roaming like FF, but with Zelda-like combat?

It would be safe to assume it will load map-by-map. Whether that involves scrolling is not important at this stage, and is platform dependent anyway.

How the combat is done is constrained by the available graphics. If your artist can do 20 frame sword sweep animations in an hour, then do that everywhere. If you are forced to work with scanned concept art then you need a separate combat 'pop up'.

Doing everything as 3d models saves making pixel-size decisions, and needn't take any longer to do. Pixelling can be VERY tedious, after all. You could shave this burden off the total prohect workload if you used Reiner's Tilesets for everything.

Reiner's Tilesets?

http://reinerstileset.4players.de/englisch.html !

He uses an odd 4:3 iso with 64x48 tiles. There's a lot more interesting characters now. The original ones from his RTS would have left you with a main character who mines gold, and in his spare time hunts and chops trees.

Best of all, they are all totally free to use in any game you like.

EDIT: I've just found his Sound Effects That's another 100 man hours saved. http://reinerstileset.4players.de/soundfxE.html

16*16 is too small. I'd much rather see 32*32 tiles.

I've been thinking a little bit about this space station/ship thing. I'm thinking a science vessel carrying a couple hundred people designed for travel around the galaxy. So something along the lines of the Enterprise from Star Trek in size and equipment. Though I suggest making original design, weaponry and propulsion if someone has good starship imagination.

Of course, huge parts of the ship will never be visited in the game, but it's good to get an outside view in the cutscenes and on the box cover.

Another thing. What kind of inhabitants do we want on the ship and in this alliance of planets? (It's been sounding like some people like my intro story) Is it all humans that has spread through the galaxy, splintered into warring factions with different home worlds? Is it lots of different species radically different physiologically? Or should one go the Star Trek way, different races with minor facial features?

Whatever kind the artist gives you. Draw Your Captain!!!

I vote for 32x32. 16x16 is cool, but hey, this is 2008

For perspective, Lets go with zelda, but taller characters. Think Chrono Trigger... actually, yea, Chrono Trigger at 32x32.

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

I like this one. It gives some creative fun to the art department, and can make the game style more visually dynamic.

I'm thinking Chris is more of the bottom line decision-maker. Its our job to spit out a bunch of crap, push around each others ideas, and then Chris sifts through it to make the final decisions.

Strangely enough, thats what a good leader does.

Tile size, I vote for 32x32. For the plot, I think it makes sense if it's humans who spread around the galaxy.

I like the idea of aliens, especially really funky-looking aliens that would have interesting sprites.

I generally prefer the humans spreading around space idea... The aliens humans come up with are generally poorly thought out and irrational, especially when placed in a world designed for human physiology. I find quite often the alien species can detract from a game, TV show, or movie. Of course, this game probably isn't intended to be very realistic so aliens could work just as well here.

Comprimise: Illegal aliens! Now you have humans AND you have aliens!::)

It works for me. Actually I just don't want to make a big issue out of something that is, in the end, not very important.

Who wants to add a Hooloovoo somewhere in the game?
(A Hooloovoo is a superintelligent shade of the colour blue)

Can it be the final boss?

"How the f*** do we kill a superintelligent shade of the color blue?"
"Mix it with a shade of the color orange?"

Here's some backstory I'll suggest to the mix. Also, I vote for a mostly human race the player controls.

Lastly, my additions are to the proposed stories of Trezker and Mark. (note: I tend to go very epic in my storylines)

I'm going to make them alien, let's call them alien race X for now.

I'm going to say the three components are the "brain," "heart" and "network." The in-game names would be something like, respectively, the "Prospect Judgment Processor" (or PJP), "Xeon V Core Drive" (catchy, eh?) and the "Central Datalink Module."

The machine itself I'm calling the "Robot Prophet" (catchier name needed), a combination not too common. Essentially, this is a machine that takes huge amounts of data (which it connects to with the Central Datalink Module) and calculate a predictable future. So you can ask it, what will happen or where something might be.

Good ole alien race X did just that, asking it where something was. Upon receiving their answer, they dismantled the robot and left in hurry, because the Robot Prophet had been hacked and sinister alien race Y was coming to obtain the super toy. Not having much time, they scattered the main parts (not destroying it for some reason) and left, not giving any clues to their allies so they could obtain [whatever] before them (not the friendliest of allies, cue a sequel to the game).

Anyway, it's some thought fodder for inspiration.

At last, a clear sprite request for the Art Dept.

596295

That's pretty good Onewing.

More input, this time per gameplay.

Perhaps we could say that teams are going to pick up the three components. Your team happens to be part of the "cool" team that's just awesome. The other teams meet uncertain disaster upon their missions. So, in the beginning, you get to pick which order you retrieve the three components (as the other teams attempt to go to the other locations). This breaks it up making it less linear. We just need to figure out how to make the six different paths work (e.g. properly balancing monsters, plot, etc.)

I have one question about the additions to my story.

This doesn't quite seem enough of a reason for the whole population of the homeworld to leave... Do we explain this, or do we change it to government, military and scientists left the world?

I think the story becomes quite a bit less erie when they have a rational reason for leaving. Of course, it's ok if the answer to the mystery isn't erie, but the game should be erie until you find it.

Perhaps the population are infected with some virus to hide the fact that everyone important left. Then we could have zombies and immune people scared shitless on the planet. (enemies and NPC's) Zombies feels a bit old though and robots aren't scary. Maybe replicators, like in Stargate.

I feel my attempt to change the story failed miserably.

No zombies. We've already got a space shooter/rpg/mystery, we don't need to add zombie killing into the genres.

"Robot Prophet"?

It has to be "Deep Thought".

Gotta have a dash of geek pop culture in there.

Deep Thought. Yes. It must happen.

It's hard to say. I like the idea of the entire race leaving the planet, but in that case, the machine's prophecy must've been something huuge (that's with two u's). It also adds to the erie factor. However, we still need life on the planet for the player to interact with.

I'm with Neil on not wanting zombies in this game on top of everything else.

Agreed. To the player, I think we should portray an erie overtone. However, to us, the developers, as soon as we decide what the mystery is, it won't seem as erie.

Heh, I can imagine playing the game, putting on the final component of the machine only to have it say, "you're all doomed!" calculating the inevitable armageddon.

Quick comments:

Because of the size and scope of this game, I'm thinking we're going to keep the setting a little lower than "planet" scale. The player will operate out of a central hub, around which will be a basic overworld with the four dungeons, plus a few caves and crashed vessels to explore should the plot require it. The "collect three things and go" plot is a bit unsatisfying to me; firstly, there's not a tremendous amount of logic to the dungeons and bosses that surround these objectives unless we put a little backstory into them, and secondly, it pretty much negates the in-between plot stuff I was thinking of. Bluntly, it's kind of dull and we can do better.

Here's where I was starting out, and maybe we can build on this. I can supply a map in a day's time if this turns out to be agreeable:

The main character will assume the role of a forensic investigator/engineer, or whatever the appropriate title is. This is a young colony he's arriving on, and there have been some mechanical malfunctions he's been called upon to investigate. The game opens with some minor footwork as he moves the backstory forward talking to NPC's, reporting here and there to pick up his weaponry (light personal protection, mainly). I was thinking of a firing range where you have to hit moving targets with limited ammo; no reward for winning, just a simple minigame you can play anytime, get used to new weapons. Eventually he turns in for the night. Nothing you haven't seen in Chrono Trigger or a million other RPG's.

Cut to darkness as he steals out of the colony and heads for dungeon 1 in a deliberately shady manner. Once the dungeon is completed the backstory is fleshed out: he's a military internal affairs investigator and they are suspecting a member of local command of sabotage for some not-yet discovered motive, and he's investigating covertly, James-Bond style. Between dungeons 2 and 3 there's some questioning, and something useful left for the main character by an informant who's identity will be disclosed later. It's an NPC the player's already had interaction with, naturally. We need to keep some plausible mystery, and enough clues to keep the player wondering.

The investigation ultimately leads to Dungeon 2. The plot heats up a bit, perhaps the guilty party is now aware someone's on to him. Whether that party has been revealed to the player, the main character as the prime suspect, both, neither, whatever, depends on the rest of the plot and how we want to play it. Maybe the main player has a near miss with an "accident". Also keep in mind that this whoel time, the main character can gleefully arm himself with whatever he finds and can take without being caught. That inventory is slowly filling, Zelda style ...

Dungeon 3 pretty much ends any real mystery as all the pieces fall into place. Then it's just setup for the final dungeon, protagonist vs. antagonist, as the good guy has the bad guy on the run and backed into a corner. We can tease the half-destruction of the colony or something to explain why the main character runs in alone instead of with military backup, or whatever else the plot can sensibly allow. Throw a supporting cast in there (like the informant), cool weapons and items, flesh out everyone's motivations and personality, figure out the dungeon settings to follow along the plot, and I think we might have a winner.

I don't mean to step on the previous ideas; just throwing out my own brainstorm. I'm open to being outvoted on this, but like I said I have a few reservations about the previous ideas, unless someone has some really good ideas to make them more workable ...

Ah, cool. Some tangible scene-setting. A male human engineer in a young space colony. The young space colony is a neat idea, as it allows you to mix hi-tech and rustic gfx.

There's always the possibility that there was a huge volcanic blast the hurdled these nearly-indestructible high-tech pieces into outer space. They had just enough juice in them before they crash-landed on various planets (or portions of the same planet if you want) to send out a homing beacon so someone knew that they were at least "out there somewhere" and a general location (on the western jungle continent, and on the far end of one of the northern moon craters, etc.)

That would explain why there was no one left, and why it appeared that they all left in a hurry without actually gathering this technology with them for their flight.

Then you could build your story around that premise, and that you need to

and do all the recovery stuff...

Never mind all that. All that matters is that all these graphics from "Failed Project 2000" can be used. Game first, backstory second. IOW, Quit jawin' and start drawin'

/me brandishes Whip Of The Evil Producer

I nominate Matt Smith as the Evil Producer.

The gameplay elements have been done before many times. To truly make it enjoyable there has to be a story for the player to get interested in. Figure out the story first and then design a game around it second. IMHO.

I'd say the "core programmers" should figure out what type of game they want (in this case, it's a tile-based, top-down RPG) and start on the engine code.

1) Figure out how maps will be stored, saved, and loaded.
2) Figure out how the characters (player and NPCs) need to be represented on the map
3) Figure out how to draw the entire map, including background tiles, characters, shadows/shading, etc.
4) Figure out how movement and bounds-checking will be implemented, including for battles. Will characters be constrained to tiles or be able to roam freely?

While they're doing this, everyone else can hammer out "what should the game BE ABOUT". After all, that's a DESIGNER's job. It's also their job to create or provide the tilemaps once they agree on setting, which should just "snap in" into the code that the "core programmers" had established.

Plots, subplots, etc. are all superfluous at the early stage of the game, IMO.

Unrelated EDIT:

Næssén, in this thread posted a link to a project on code.google.com. Maybe that would be a good place to setup a temporary repository?

No noé!. You are clearly underestimating the gameplay part! , the gameplay must be tweaked into near perfection where every element is taken into consideration when planing the other elements.

Just beacuse you've made the player able to jump dosen't mean the jump is good. I don't like it when people simply skip the gameplay tweaking beacuse "it's done". Gameplay is what makes a game, if this where an adventure game then maybe story would have played a bigger role, but I don't think this kind of game can get away with crappy gameplay.

Hear me roar!

I agree totally. But no one is saying "just throw together some crap and call it finished." In my experience, you start out with that just to get the functionality working. Then you tweak, improve, adjust, and otherwise fine-tune it and hone it to perfection after everything is coming together.

That's the difference between the role of a "programmer" and a "developer". The programmer just needs to make it work; the developer needs to make it work well.

Games don't have to have a rigid form of creation. Having a general concept of the story is like having a physical art concept drawn where everybody can go "oh, I see now!" It's fine if the story is only at madlib level, the actual scene by scene description of the story can easily be "overdoing it." This is why I suggested some story and some gameplay concepts for discussion.

23's post above presents a pretty good understanding of the flow of the game, with room for the designers to fill in the specifics.

I do think that what we have now, gameplay-wise, is enough to start work on code. The finer details of story aren't important to the code, or shouldn't be--it's just a matter of writing the right cutscenes.

The point is you can't develop until you design. If you rush the coding you'll end up with people not knowing what they're doing and just making it up as they go.

We have enough to go on to start coding, and I think we should. Actual progress will help keep up our motivation to work on this project.

Speaking of working on the project, maybe we should begin deciding who will do what. I'm willing to do anything needed as long as it's within my abilities.

I'll do anything I know how, as long as we're making progress.

Wow, this is not something I want to be left out of.

Too late to join?

You're welcome to participate, either in design or development.

Cool!

Is it going to be multi-player? (hot-seat, LAN, Online?)

I know it can add all sorts of complexity for it to be a LAN-online game, but from previous comments on these threads, I've heard that implementing "player 1" and "player 2" is time-consuming up-front, although it really makes everything easier down the road. It'd be nice to have, and the code I've been working on so far kind of take this approach. But it's far too fragmented yet to be used in the current project unless I can get some serious programming time in.

Doubtful. I think that's outside of the scope of what we're wanting to do.

Well, as getting to coding goes, i think we should start with the engine, as alethiophile suggested. First of all, though, we need to be able to have a central access point where all the files are saved to. Does anybody have a server that they'd be willing to give everybody a limited ssh account on? I may be able to supply that, but not an SVN.

We don't need a server that people log in to, we just need an SVN repository. Google Code could provide that, or there are paid services.

Why start the code from scratch? Surely it would make more sense to take an existing unfinished RPG project (KQ Lives Again anyone?) and we could all pile in and tidy up the source for that.

You really want me to be the Evil Producer? In the commercial world, the Project Lead and the Producer are two different roles. The Leader leads, the Producer threatens. Without the power to withhold your salary, there is nothing a Producer can do except attempts at public humiliation.

Reusing old RPG code might work, but it might be more work than it's worth to integrate what we need (firing guns, etc.) into that. It depends on the state of the starting code.

Wouldn't hurt.

Let the games begin!

Haha, so very true. From my minimal experience, the producer was the one who made all the schedules and kept a careful eye on each person to make sure they were where they needed to be. He was also senior designer (note: not lead) on the project. He also watched over the lead designer to make sure he wasn't slacking (and vice versa).

I think it works pretty well to have a system like that. Of course, we'd have to be willing to subject ourselves to humiliation if we fell behind.

Heh, I can be the HR guy who listens to people's problems and drama about team mates, writing it down and putting it in a "won't resolve" box.

I have svn up at svn.tomasu.org if you guys want a repo I'll be happy to create one for you. Warning, its about as stable as the wiki

That's the problem I can herd cats with electrodes. not without

Well KQ builds and runs from CVS, using nothing except what's on the stable debian mirror (amd64 etch). This would be a fine start indeed. It's a nearly finished, working game. It has a map format, it has LUA embedded already. It plays modfile tunes.

I think it would be a splendid team building exercise if we all built KQ and see if we can agree how it could be improved, and maybe we could even finish it.

What is this KQ?

"it" being KQ or this new project?

See their wiki page.

I thought we were starting a new project, not trying to finish an old one that half of us have never even heard of...

If the KQ engine does what we need it to it could save a lot of time in developing the engine... We could just refactor a little bit or something. IF.

Oh, ok.

I love the idea of using a pre-written engine, if it has a good API.

What is KQ? What functionality does it have?

You missed the wiki link?

KQ has a map format specified already.
- 3 layers
- shadows
- an obstacle layer
- markers, which are kind of a "set this coordinate as a target location"
- parallax

It has support for either the DUMB or JGMOD music library formats that you can compile with.

It has scripted movement support.

There were even a few spin-offs based off of their engine before (I think it was KQ Lost Lanarion, or something), so others have at least done some stuff with it.

I built KQ last night and took a peek at the code. I did not like it, the organization seems weird. I didn't try very hard to understand it though.

I looked at the KQ code, and my eyes started bleeding. I'd stay away from that stuff if I were you guys .

Yeah I wasn't too thrilled with the code when I looked, but I'll get it in an IDE before I pass judgement (or cast my vote). It's reasonably clean and in C, praise de lord.

My opinion of the game is that it is a little bit too retro for my taste. I would up the resolution. I personally can't abide turn-based combat, especially when the correct response (Run Away) is not present in the menu. It should be easier to avoid rerunning the intro so many times.

An updating of the code could separate the rendering from the gameplay, so that a pseudo 3d version could be grafted on, but for a quick and dirty job just upping the res to 640x320 and the tile size to 32xN would suffice.

I have not built KQ yet, but I think that reusing it could be more trouble than it's worth.

Sorry about the delay; I got tied up this weekend. I'm technically running a bit late for work here, but concept art you were promised and concept art (such as it is) you shall have.

To answer a few questions; no, we should not recycle KQ. The differences in control and gameplay are non-trivial, and what we would end up borrowing (tilemapping? and, um ...) are minor enough that we can write it from scratch faster. This game will not be complex enough that hunting for and trying to apply some other engine or API is warranted. Also, someone asked how the maps would work; all dungeons and the colony will be very Zelda-like, in that they are sectioned off parts of map (not necessarily square in the case of the colony) you see as you move through doors. The overworld will simply be continuous. The player will object if you move too far out into the open, away from the actual game area.

Map attached. Few notes:

The big structure in the upper right is a small city/large colony (for fun, let's say the population was roughly 3000) that was here previously and met with disaster. Part of the current small colony's job is salvage and investigation (population, around 30-ish). The main player is arriving under the pretense of helping to bolster that effort.

First dungeon will probably be a covert mission into the city itself. On the near side of the base will be something relevant to that disaster and the current plot. My thought is that someone in the city was doing something they shouldn't have which caused the city's ultimate demise. The people that sent you have cause to believe that this individual's agenda is continuing or starting fresh through the new, smaller colony somehow.

The vehicle on the left blocking the way through the mountains will be fixed by the player through the course of the game, unlocking the way to dungeon 2 or 3. It can take a few runs and puzzles in the colony to gather the materials and do the repairs necessary to finish this. Colony 3 will probably be some sort of cave, possibly a mine the original city was using.

The new colony is some prefab thing running off solar panels. Someone more space-minded may want to take a crack at its aesthetics; the overall shape and layout will probably be influenced by the final plot and quest points.

I'm thinking the third dungeon will be some sort of alien ruins, but I haven't figured out how to factor that into the story yet. Final dungeon will either be on a space station or in a larger part of the city ruins. The final boss will either be someone in the chain of command at the small colony or someone still alive in the city, I believe ...

I could hug you.

And to the rest, sounds good, I'm in.

Will the main character wear a uniform? Will it look like this or sth less imperial? What's his name? Rank? Serial Number?

Two more stock characters. The Mad Scientist and his Beautiful Daughter

Should the main character be an ordinary soldier, or a special ops type guy? I'm thinking a special ops guy, because that allows you to use cooler weapons with more realism to the story (ie, people in specops tend to have fancy tech-heavy weapons).

Reliable Grunt #1 and Captain Cockup

http://www.allegro.cc/files/attachment/596325http://www.allegro.cc/files/attachment/596326

If I get the idea of the game right, then these drawings will be useful mainly for cutscenes, if that. Why not someone make 32x32 tiles of them?

Nobody should start pixelling until the characters are sorted. These concept pics are easy to churn out. Here's 2 more. Kawaii Servobot and Scary Lady Doctor.

Is the 1930s clothing style to everyone's liking?

And here's The Surviving Eyewitness

That makes eight characters in search of a story. It's a posse!! Let's quest!!!!!

No more for now. Battery in tablet worn out.

The character will be a special-ops type. James Bond, basically. I'm picturing the player running into doors he can't open during the opening scenes with the NPCs, only to start the covert op to the first dungeon by pulling a key card out of his pack which opens all the low level doors and leaves no trace in security. The parallels with Bond are mostly in the personality though; very cold and professional, but good at acting warm and "part of the team" around the other staff at the colony. No lasers in pens or shoe-phones, please.

As far as the look of the characters, we can go two ways. I was actually drawing up the main character at work today (still twiddling my thumbs over a male or female character). I'm thinking of uniforms for almost everyone; with a small cast, we can keep enough physical differences that characters remain distinct while looking largely alike (think the Bleach shinigami; they all wear basically the same thing, just different faces, builds, and minor personal effects). On the other hand, we could decide not to play it straight and instead go the route Matt's taking with his characters. I want to hear some votes on that. We don't even have to make them human.

The surviving eyewitness is an interesting idea, depending on if the plot needs him.

Here's a few motivations I'll throw out there for the main bad guy:

1. The main bad guy himself is part of a team within the government developing weapons systems. During a minor war many years ago with an alien race, an alien ship crashed on this planet. Scans showed no survivors. Funding a salvage mission to examine alien warship technology simply could not be justified when ends could barely be met developing technology for colonizing (Earth is kinda getting crowded in the future). So this secret weapons development team pulled political strings to make that planet, years after the crash, a candidate for colonization, as a cover for researching the ship. Someone touched something they shouldn't have and weaponry went boom, which is what destroyed the colony. A member of this black ops research team now heads the smaller colony, and a small crew who are still researching on a much lower scale now, to make sure things go better. This crew, along with the small colony who are pretty much oblivious, are now there under the pretext of investigating the disaster. Player objective: discover the bad guy's motivation and report the true cause of the disaster.

(btw, for some role-reversal fun, if we were to make the player race non-human, the ship in question could be one of ours before they kicked our asses. Yeah, shouldn't have tried to open that photon torpedo with a hammer, noob.)

2. For this one I was a bit inspired by The Martian Chronicles by Ray Bradbury, specifically the "Mars is Heaven" chapter with Captain John Black. Not that what I came up with is actually anything like it. >_> But anyway. This time the original colony (and the smaller, second one) start legit. But there are actually aliens on this planet, undetectable by technology of the time. These aliens are largely psionic by nature, and while they aren't terribly mean, they're invisible, defensive, and they use their psychic nature to talk ... and influence. They "attack" the colony over the course of years by making colony members who have access to dangerous buttons turn traitor, and one night simply make a few strategic individuals take out the whole installation (themselves included). Now the smaller colony is investigating, and a few of the weirder happenings near the end of the colony's life (like coincidental equipment failures) are happening again, much sooner. Someone in this colony is slowly falling under alien control too ... Player objective: discover the source of this "madness" and save the innocent salvage team.

3. The nut in the city plot. I'm sure we can think of lots of ways to do that, hopefully not too cliche. Why would someone deliberately blow up the city? Did he have a self-serving motive? Did space life drive him mad? Was it an accident and now he's scared witless of being caught? Player objective: find the truth and catch Dr. Wily there.

Just throwing out more ideas. If you can't come up with anything on your own at least vote for what you like, or build on what others have come up with.

I like one and two, but not three. It's a toss up between the first two, one is cooler but two is creeper, so it really depends on the atmosphere we want to create with this.

Seconded.

For the second plot, although I don't fully understand it in depth, it sounds reminiscent of the Final Fantasy: Spirits Within movie. Maybe the reason for monsters to attack you would be these spirits or "energy-fields" that morph and warp.

Better yet, maybe even some of the "monsters" aren't sentient at all: they are simply "blobs" of energized plasma ooze that you run into (or that are drawn to your team's energy packs). You get into "battles" with them and need to neutralize them before they drain your pack (which is what pumps air into your space suits).

So the planet would have very little breathable atmosphere, and only some of the "tattered buildings" left remaining have pockets of air that hasn't escaped yet, where you can replenish your air supplies.

Are you suggesting James Bond isn't camp? Star Trek, not camp? All sci-fi becomes camp when you take it off the written page, and fantasy usually starts in the camp of Camp. cough*Legolas*cough

Yawn, so how much more are you guys gonna plan before some action gets going?

Don't tell me you're all talk and no show..

I know I expressed my interest in participating in this but I realize that I have no idea what kind of game you guys have imagined in your heads.. If I was ever considered a part of the team I'd like to be on stand-by untill I know exacly what you guys have planned, what approaches will be taken, game mechanics used, libraries, etc.. anyway, either way I'm playing it so make it a fun game..

I agree, we need to get something done besides just talking and planning. So what should we start doing? I guess we'll have to wait for our team leader to decide, but we can at least throw out some ideas. A few graphics would be good, and some of the basic code.

well we're getting close to having a doc ready. Phase one is nearing completion.

Yeah we haven't even asked the fundamental questions.

• Allegro 4 or Allegro 5?

• Hi-res or Lo-res?

• C or C++?

• Tilemap engine & map format?

• Scripting Language?

Seriously, the backstory, plot and gameplay are all things that can wait until the scripting language is chosen. Do you all really think the authors of FF1 thought deeper thoughts than "Wow, I've got him moving in 4 directions" or "Wow, that sprite looks good. Let's give him a name and keep him"?

How about a wiki page or two?

My thoughts:
Allegro 4.
Medium-res. (Honestly, here I just don't care.)
C.
I need more info about this. The only tile-based game I've made is a platformer, so I don't know how it would work with a top-down game.
The only scripting language I've heard of for embedding is Lua. If anyone has any better ideas, I have no trouble.

Here's my contribution so far:

I also would like to join this 'little' community project. If there is still room, of course!

But...

Woah woah woah. You can't just contribute code like that! First of all, yes, we DO need a good storyline BEFORE anything else. Whats the point in having the code if the story sucks? And even when we got the story, we still need to distribute tasks, agree on how the code will be structured, etc. etc. etc.

So, lets get the story out of the way before doing anything else. Lets not rush it.

Regarding the story:
I also like the 1) and 2) story from 23. I like the 1) one better though.

That's all fine and good, but this "I want a week-long project" has now been running for over a week.

You know, most of the time, game PROGRAMMERS and game DESIGNERS are sitting in different rooms during the game-creation process. The programmers have to start getting the preliminaries ready (map editor, structure for the tiles [rectangular, hex, diamond] to render correctly onto the screen) while the designers are actually coming up with "okay, so it's going to be a space-aged RPG with live battles; what should it be ABOUT?"

So we have enough NOW to actually start on the basics: get the allegro timing right, get the main loop set up and working (logic, inputs, drawing to screen).

If we know there will be NPCs, then we can always get those in the works just so they're ready to be used (and altered, naturally) when the game is hammered down more.

This group on a.cc isn't comprised of ONLY programmers. There are some creative thinkers and everything, so let's start designating jobs: "You, grunt #1! You make the game fun. You, grunt #2! You make the game playable. You, grunt #3! Set up a Paypal donations page so we can get some moneys for caffeine."

Seconded.

The point is there are many ways to do all this stuff. It's not good enough for somebody to write it their way and hand it over to us. We need to decide upon how its going to get done. Programmers don't make decisions. Programmers are told what to do. The design is about more than just the story; it's also the art, engineering, etc. And we're all designers at this point. We can be programmers and artists when we're told what to program, draw, and record. If you don't know what modules you've been assigned to write then you're launching your IDE or editor too soon, IMO.

I agree that haphazard code contribution won't get us anywhere, but we also need to get going or else this project will stagnate. Do we have an SVN repo? Candidates for that were Google Code or the thing Thomas Fjellstrom set up. If not, let's get it. If so, then 23 should tell some people what to write.

OnlineCop. I have stucture almost exactly like that for the units in my 3d RTS project. That's because at this level of API, these game types are very similar.

I think whatever code we write should be as flexible as possible, and not tied down to a specific game.

I think different maps should have their own perspective rules and scale etc. Completely different renderers if necessary. e.g. You could go down a dungeon on the outside map, and find yourself in a 2d platform-game level.

From the start, the game should have a sophisticated menu system that loads add-on games, without requiring rebuilding of the binary.

I strongly suggest using an existing map format and rendering library if possible. Either rip one out of an old game (maybe not KQ, it's GPL anyway) or use Mappy. Mappy has the editor of course, and I don't see anyone volunteering to be the Tools Programmer.

I prefer C myself, but as for Allegro 4 I think this would be a more interesting exercise in Allegro 5. It would help the A5 effort if we were all testing it, for a start. Another advantage is that 3d rendering can be played with without "aw, I can't get Allegro GL to work".

We could develop a reusable framework with no content, which does nothing but maintain its own config file, joystick calibrations, window size & position etc. etc. etc. This is something I want to do anyway for all types of game, but I've never made the effort by myself (with no Mac etc).

Anybody who just wants to play this game, should sign up for the QA Dept.

Edit: UML diagrams would be better than raw code at this point, or a good description of the API divisions between framework, gameplay and renderer.

I think using A5 is an awesome idea. What better time than now to try it out? It would help the effort, be hardware accelerated, would encourage all of us to begin learning it, and add a little spark of excitement to the project!

Ok.. to everyone who states that programmers are mindless zombies, F*** YOU.

I hate so called game designers, they're useless. They're meant to be specialists in "game design" but all they do is f*** up, they're always the bossy ones and the most employed type, they're always the one most common ones in game-dev-schools. They're the ones that are too lazy, dumb or uncreative to become programmers or graphicans, and they're always the ones to ask what the payment is.

Sorry, of course not all game designers are like this.. I just really really don't like the game design position.

I did not become a programmer so I have to listen to some stupid guy with boring ideas and no motivation, I program so that I can realize my dreams and make something from my ideas. Everyone's a game designer, do people seriosly need game designers?

I decided to look up the credits of some old games of mine.

I only went through a few games but some exampels of games that does not have anyone dedicated to gamedesign are worms 2 and theme hospital! And those are really fun games, oh, theme hospital does have a game designer, lets see who it is.... "bullfrog entertainment", makes me wanna cry.

Althought most old games has dedicated game designers they're very very few, Total annihilation had only 3 of them, and Diablo 2 only has one. And what is the game designers job? Isn't it to design the game? Then how come newer games can't compare with older games even thought they have millions of game designers?

Another thing I hate is how some designers actuallt put their F*CKING NAME ON THE GAME, like THEY made it, I feel like ripping their heads off and shit down their necks.

I should go to bed..

Agreed.

[nvmd]

You can't really compare games of yesteryear with games of today like that. Back then the development team was very small, sometimes consisting of only two people (the programmer and artist). A lot of times though some/all of the designers are programmers as well.

Unless you're making a game that's just a re-hash of some other game, it's going to be a bigger project, and the bigger the project, the more people that need to be on the team.

Newer games are actually a lot more complex, and in some ways, infinitely better than older games, which is only possible due to very well game design. Any commercial game nowadays (and I bet a lot of the indie games that actually get finished) go through an extensive design process. Hell, even the 1991 game, Leisure Suit Larry 5, had an 86 page design document. Now, Al Lowe already had an engine from the first 3 games, so I wouldn't doubt it if he wrote the entire doc before coding the game's content, since this doc makes it extremely straightforward exactly what needs to be done.

Oh, and if you guys post Windows binaries every once in a while, I may be able to find some time to squeeze in some QA.

We would need more backstory to explain it that way. Aliens simply defending their territory in an alien way is nice and clean. Also, if you ever insinuate that I use The Spirits Within as inspiration for anything ever again, I will murder you with spoons.

I am speaking relatively, of course. Surely you can agree there's a difference in style.

You've never played A Link to the Past. Wow.

Okay, let's try for some specifics here. If you want to write code, how do we decide who writes what, anyway? As far as what we need, here goes:

I guess we're stuck with C instead of C++ grumble grumble. We'll need a simple tilemap structure, flexible enough to handle arbitrary tile and map sizes, but for this game let's shoot for 320x240 resolution, 16x16 sprites. I would honestly like to make it 320x240, 32x32 but I don't want the graphics to be a burden to progress. I'm open to being outvoted there. The game should also be able to handle infinite layers of tilemaps, though for the moment I only see us really needing 2; the main ground layer and an upper layer for objects the player can move behind. If the tilemap code is written right, then adding extra layers with extra detail, shadowing, fringe tiles, etc. will be trivial anyway.

There will be 6 settings for certain; 4 dungeons, the overworld, and the colony. Only the overworld really needs the ability to scroll; the dungeons will be compartmentalized rooms like in Zelda. Depending on final design, we may need rooms that are a couple of screens wide/high, so there may be limited scrolling there (again, much like the ALttP dungeons). That's pretty much it for tilemap requirements. I don't see why collision detection should be anything but binary, either. Either a tile is impassable or it isn't. Nice a touch as it might be, pixel perfect angles would not add much gameplay-wise.

Design-wise, I'm thinking each cave will have a three-key system for opening doors. Some doors will be "puzzle-trapped" but mostly the doors will be numbered 1-3 somehow, and once you have all three keys the dungeon is pretty much wide open. In the colony, this could be represented by pass cards. In a mine, maybe you have to find 3 dropped rock-crushing energy guns that disintergrate different types of minerals (which conveniently enough block off rooms). In alien ruin, maybe the keys are some sort of crystal. On a ship, they might be scaps of paper with passwords written on them you need to find. This is something like the heart/diamond/etc keys in Resident Evil. The door to the final boss takes all three keys to open. Each dungeon should also have some sort of thematic weapon/item needed to progress. The final dungeon should be exempt from the key system IMO; it will be more straight forward to set it apart.

The player will need to be able to interact with NPC's and some objects (locker doors, switches, etc). Simple enough. The engine also needs a way to switch from map to map when the player walks through a door, and also needs to be able to manage scripted cutscenes. There won't be many, but how hard is that to implement anyway?

The game also needs saving and loading screens, inventory, the usual adventure game trappings of a GUI.

So, does anyone want to take a stab at some psuedocode for the necessary game structures? Again, how do we decide who codes what?

Hey man, I'm ALL for C++.

C is... well... more work.

To answer your question, it might be a good idea to keep me out of the coding, unless there is something pretty basic that I could do... like make a random number function or something

How about we write down what needs to be done, then?

Once all (or enough) of these are filled in, some can start working on them. Having a tangible goal like this helps me know that progress is being made.

2D or 3D?

Tile dimensions: 16x16, 16x32 (or 32x16), 32x32, 32x48 (or 48x32), other?

8-bit (with a single transparency value of 0xFF00FF)?
- 16-bit
- 24-bit (at least one of these has alpha transparency; I don't remember which all do)
- 32-bit

What controllers will be used? Keyboard, Mouse, Joystick?

Will keys be remappable or fixed/set?

Will the entire screen be dedicated to the world map(s), or will there be a portion of it covered by a HUD, such as player health/stats?

Will interaction with others be: proximity (hit a button to start talking, then as long as you don't walk too far away, you still talk with them) or absolute (you can't leave until they've stopped talking)?

What kinds of screens should be displayed?
- Menu (Play Game, Configure, Load Game(?), Exit)
- The actual Game
- Menus during gameplay (like Inventory, Stats, Spells, etc.)

Will health bars be displayed on the HUD at all time, or only during battles?

Knowing just a few of these, even before we decide anything else, can have at least a few of us start some skeleton work. It will all need to be adjusted and polished when things start getting more hammered out, but having 200 lines of code with about 50-70 lines that need to be tweaked is faster than having 0 lines of code, all of which needs to be written from scratch.

EDIT:

Sorry, 23. I hadn't seen your post before I submitted mine. I'm glad you're getting us organized!

Why do we have to use C? I'll admit I'm not exactly sure what the difference between C and C++ is when I look at the code, but I'm willing to figure it out. I'm taking this whole project as a learning experience anyway, so I don't mind one more thing that I need to learn as it is.

I'm 99% in favor of C++, personally. Some die-hard fans who really like C can actually implement a lot of our code without a hitch if we wrap it correctly. (Like using the #ifdef __cplusplus ... extern "C" ... #endif symbols).

But C++ will give us all sorts of access to good OO features (such as std::string, std::list, etc. if we really wanted).

That's false actually. Without proper design, all those 200 lines may have to be scrapped. In other cases the tweaking might go on for ages. The chance of putting together 200 lines even close to right before knowing what you're supposed to do is very small.

I think we should start with a higher-level model of the software and then drill down into modules... Somebody that's written similar games should already have enough of an idea of the overall design to draw up a model. Everybody can review it, challenge it, revise it, etc. until we're happy with it.

I think it should become clear to each team member what him or herself is capable of doing as the overall design becomes clear. From there, I say everybody puts in their two cents for what they think they can handle and then we'll allocate everybody as best we can, with 23 having the final say. We obviously can't assign tasks until we know what people are capable of. As long as we stay in communication on progress/problems it shouldn't be a problem to reallocate our resources as work gets done and snags reveal themselves.

Agreed. Odds are the code would have an effect on the design when in reality it should be the other way around. The design dictates the code.

Another small note. What we need is interfaces, not pseudocode.

I like that idea.

I think I should be kept out of the coding/implementation side of things. I'm good in the art/sound/creative department, and I have some professional graphic design programs.

I also have some useful and C++ classes that I've built which could shave off some coding time.

Also, not to detract from the design process, etc., but perhaps before we get too deep into the project we should agree on contribution terms. For example, perhaps any contributions to the project should be automatically and implicitly considered the project's intellectual property (which sounds messy in itself unless we agree on unchanging licensing terms for the project's IP). The point is not to take away the rights of the contributors (we'll try to credit the contributors as best we can and won't take any rights away as far as using the work), but to preserve the state of the project just in case a contributor becomes sore about the project's decisions in the future (it would suck to get really far and then have to spend the time to remove 30% of the code that's already tightly woven into the remaining code). I'm not saying we should have any problems in this community, but just to be on the safe side it wouldn't hurt to at least attempt to come to an agreement beforehand...

I don't care if you don't...

The project is free to use any contributions I make should I decide at some point to quit for any reason.

Instead of requiring everybody to explicitly agree, I think an implicit agreement/disclaimer is a better, more maintainable approach (though I wouldn't discourage willing individuals from being explicit unnecessarily as well).

For example: perhaps to contribute to this project you must agree to surrender your exclusive rights to the contributed work; in other words, if you contribute, the project (and everyone, really) is free to use your contributions in any way they see fit and you're unable to dictate how (aside from leaving credits untouched).

Perhaps Thomas Harte can work on a legally binding disclaimer.

I agree, with the addition of a guarantee that you'll be given credit for contributing even if you quit before the project is finished.

I'm down for this. I've been watching this thread, and I think it's an interesting idea (the whole "lets make a game" thing). I'm most interested in seeing if it will happen. So, count me in. I can do programming, C or C++, whatever language is decided. I have limited experience with embedding Lua, as well.

I think A5 is the way to go. I prefer C++... but C would be great, too. Hardly matters to me.

2nded c++

I'll 3rd it then. All in favor say aye!

my game has concept code and clases that can be used.

Piccolo in his great game also have some parts that can be used as a recycle bin. Mostly.

_

Any plans with the SVN yet? Remember, I have a way of hosting it, and it may be more reliable than Thomas' offer. (Basically, on my site.)

This should be in the framework part, so that remappable keys, joystick calibrations etc. are easily accesible from any game written for the framework.

My plan is simply to split the source into 2 main sections. The first, the framework, does all the tedious stuff that you find in every game. This part will be written in a maintainable high quality style. The second section would be all the game specific code which can be as hacky as necessary.

The game specific code can be further split into a map loading/rendering lib, an NPC AI/scripting lib, and the actual game specific code (custom graphic FX etc, plus any gameplay that cannot be reduced to scripts calling framework or lib funcs)

I'me easy about C++, but the major interfaces should not be only accessable through a C++ to C++ interface. C++ libs should either offer a dual interface, or should use COM or similar which plays nice with both.

proposed Code Outline

Framework   -   main.c  window position & size, screen modes, K J & M remapping,  Mii creation :)
=Game     - gameplay etc.  
==GUI      -  menus/HUD, pop-ups, speech bubbles/subtitles 
==Maps      -   loading, saving & rendering (l/s/r)  or glue code to Mappy etc.
==NPC & objects   -   gfx l/s/r  scripts,  triggers 
==Scripting       - Glue code to LUA
==Triggers
==Objectives  (do these exist in RPG, or or they just fancy triggers?)

proposed Directory structure (user) incomplete

~/flamework.cfg
Framework/launcher.exe
MondayGame/MondayGame.exe
MondayGame/MondayGame.cfg   or ~/MondayGame.cfg
MondayGame/maps     
MondayGame/gfx     
MondayGame/scripts

And if you add a nice built-in map editor, you've made RPGMaker.
Conclusion:

• If you want to make a RPG game, use RPGmaker.

• If you want to code an RPG game, write RPGmaker.

This is actually something we can start on now, even if some of the contributers wanted to make it in pure C (until which language is finalized).

For the speech bubbles, I would suggest that the size of the "bubble" be specified elsewhere (preferably in data, but at the very least, something NOT hard-coded into the bubble class/struct). The bubble's text should allow wordwrap, as well as page wrap (when the text is too large to all fit in the window at once).

I've seen some of the games on the depot implement this with the actual font size being part of the determining factors when considering where to break the sentence for wrapping.

This one needs more information before it can be started. We need to determine tile shape, unless we go with C++ and decide to overload all of the tile shapes in case we change our mind and decide to go with a hexagonal tile instead of a rectangular one.

I would suggest that the Map class/struct contains dynamic number of layers. It's not very hard to do that, nor to iterate through all of them while doing the redraw functions.

Layers themselves are probably the simplest of the data structures:

Then the map simply tracks the number of Layers needed, and assigns them as the map structure dictates.

We can at least start working on this stuff, while the rest of it is being discussed...

The last two posts are the parts where I'm out of my element; coordinating the coding team. I know what COM is basically but hell if I've ever touched it.

I'll keep designing the game as far as maps, characters, settings, items, game flow, etc. go and let everyone know what the code needs to be able to accomplish, but who wants to be the guy who actually organizes that code into sections like that and delegates the programming? Matt seems knowledgeable there ...

I guess I better finish my C# port of Mapslapper, huh?

This is exactly what we'll need for this project. Maybe a working Wiki, as some people will need to define the "general/overall concept", then others will take that and flesh it out, and down the line you'll have the actual "this is how we need to implement it."

So we have our Matt Smith as Evil Producer, 23yrold3yrold as team leader.

Nominations are up for Lead Programmer. Takers?

Trezker for Lead Programmer.

Oh shi...

Trezker, if you don't want the mantle, nominate someone else

or not

I don't want to bug you guys you could say I should be the last one to say this, as I really admire the way you're cooperating, but what are you doing? None of the ideas you have, seem original ("just like that other game"). If you don't have a goal it's really hard to decide how to get to that goal. The only goals you've set so far are:
-Make a space adventure. But I bet everybody has a different idea as what this is: communicate and share those ideas.
-Make a good game: I.e. good story, easy maintainability, etc. (But what else? Perhaps you should even name and prioritize these things.)
As for calling it unoriginal: it's not that it's bad, it just seems to lack inspiration, but that is a problem with most products today IMHO.
Please don't be disturbed by my rant: take it to heart, ignore it, hate my guts; whatever keeps you going!

Ssshhhh, I'm having fun watching.

This is why we're starting to assign responsibilities! Once we determine who will do what, the decision-making for the smaller aspects of the game rely heavily on their "final say".

weapon_S, what part of this do YOU want to be in charge of? You might as well get an official title so they know what to call you in the credits

As for me, my title is the "I'm ready to start programming as soon as you guys start finalizing stuff!"-guy (I think we actually have a few of those here...)

We need to define what there is to do and who is capable of doing what before we can assign tasks... IMO, we're still in the early conceptualizing stage. We have an idea for how the game will be presented and played and a general idea of the story, but we haven't really nailed anything down yet. The people in such a hurry to code should have no problem modeling the application; after all, they're ready to write it. Let's see a model.

Here's something to consider: Do we want to have an overland travel mode, to get to different places across the continent, or will the game's storyline and settings be to directed to make that worth it?

I didn't think there would be that much map to cover... It would probably be good to draw up a smaller, to-scale, version of the map so we have a general idea how the game is going to play out and the artists have some idea of what they're doing.

I'm "Programmer #12".

Not really. But I think that one task that is absolutely uncontroversial and needs doing before anything else is getting an SVN repo going. MiquelFire's offer for SVN hosting seems reasonable. Does anyone have any serious problem with that, or with SVN in general, or something else related to the repository? If so, say so. If not, then MiquelFire should set up a repository.

I've never used, or heard of, SVN. Hopefully it's straightforward enough to jump right into.

Have you heard of SubVersioN?

No.

Wow. Ok, well its a Revion Control System, its somewhat like CVS, but much better.

Most used commands:
svn checkout/co http://site/repo/branch dir/to/put/checkout svn update/up svn -m "commit message here" ci

Revion Control System? CVS?

Why do I suddenly feel like such a noob?

I'm guessing "-m" means "message", but what does the "ci" mean?

I have heard of SVN for years now, but I've never personally had a need to use one.

Sorry, its the short form for "checkin".

So how do I use this stuff?

Well, duhh. It's your duty to remind us that you've already done a working map editor. Is it better than Mappy already?

My current unfinished projects consist of 2 or 3 games, and about a dozen (that's 13, codebakers) game-making tools, some of which would be very helpful in this project if they were in a usable state, but they are not.

As this was supposed to a week long hack project, the idea was probably to manage without tools, and type the maps into hex editor. This could be managed if we were all in one place sharing the same adrenaline rush, but we don't have this luxury.

I've said the job of Evil Producer is undoable over the Internet. A Producer needs to threaten starvation and physical torture to force people to do the boring bits they've been assigned. We've all heard the stories about EA, and we've all seen their games at the top of the charts. The only possible stick (to balance the carrot of a glorious finished game) is to close the source to outsiders, and then slackers can risk being sent outside. This discourages casual assitance so would probably be counter productive.

The plot, gfx & gameplay could and probably should be done in a closed design group. This will prevent spoilers as much as anything else. I see no reason why the design group need to open-source any of the game, and it would be their Intellectual Property to licence how they see fit. It will be their game.

Most of the code can be written outside of the game, and this is where we need public discussion, or we'll end up with code uglier than KQ Lives. If I am to assume the title of Chief Software Architect, we'd be working on our own version of RPG Maker, which would not be limited to classic RPG, but of course we'd give priority to whatever formats the Game Design Team want.

My own personal favourite modded game is Age Of Mythology by Ensemble Studios. This was published as a historical fantasy RTS with a strong storyline, lots of in-game cutscenes, some heavily scripted maps. The modding community AoM Heaven have taken this game with its excellent ingame editor and lots of helpful scripting docs from
ES, and made all sorts of campaigns, RPG and movies with the supplied characters and gameplay mechanism. This is my idea of code built to last.

Anyway, back to the actualities, here is a further breakdown of the framework

That's plenty of GUI work to be getting on with, and none of it is even RPG specific yet. Any volunteers for this? I'll do it with Allegro GUI if nobody beats me to it with somthing better. Any GUI lib is acceptable, and it might even be nice to have versions for several GUIs.

You're including a multiplayer option in the menu? I had no idea we were even doing multiplayer.

It's a starting point which is likely to evolve in the design. Besides, what do you expect from a forum-thread game? If it's finished and playable I'll be dancing; "good" is just gravy. As for the rest of your post, I don't think you're even reading the thread.

Define "better". It's simpler, and well suited to this type of game. I also wrote a Win32 version of KQ's tilemap editor, so I'm pretty good at this so far. I'll tell you what; we'll decide how the game will handle maps as far as code and data go, and I'll just put myself in charge of designing layouts (not necessarily graphics) and make sure my editor spits out the files right. If we want to ultimately end up with some sort of "engine" and use my editor for it, I'm sure I can customize it and there's lots of time for that later. Just for the sake of finishing the game, I'll be the only guy who needs it. The C++/Win32 version was a bit unpolished and I had to do certain things certain ways to keep it from crashing; the C# version will probably be better ... once I finish it ...

As the guy most involved in design, I'm probably going to end up with tilemap duty anyway, and I'm fine with that. I like making tilemaps; I did the last dungeon for KQ too. I was going to throw together some pics with ripped graphics just so people could get an idea of how moving around the game would be. Will probably be the next picture I post.

No. This will be very localized. The map I posted is basically the overworld in its entirety.

Again, I'm not even touching the SVN and CVS, though I want to see how you guys handle things. And why multiplayer? O_o

PS: I'm toying with the idea of using the keyboard to walk and the mouse to aim/shoot. Comments?

Google will tell you.

There are GUI-based SVN tools for Windows though, that are very easy to use.

I've always wanted to make a game with that type of play control. I think it would be relatively easy to manage and would make the aim/shoot thing work, since the gameplay isn't going to be sword swiping. easier than 90 degree angles (watch AVGN's review of Star Trek). I think it's worth trying.

Why not? This is the twenty-noughties!

OK OK, leave that out for now. This is a one player RPG after all.

MiquelFire : Sure open a SVN repository. Call it Monday. Start it off by checking in the code on http://wiki.allegro.cc/index.php?title=Let%27s_make_a_game as a file called src/main.c

We can then blame the entire list of existing contributors for the finished article

Is Monday acceptable as a working title? That could be the name of the planet or something.

EDIT:

I've already got that in my 'RTS' (screenshot: http://www.allegro.cc/files/attachment/596339). It makes me wonder exactly what kind of game I'm making A world with NPCs walking around a map is a powerful resource for many many different styles of game. It could be GTA or C&C or Oblivion. It might be all three, at different stages of the game.

O.
M.
G.

The name of the colony/city/player/villain/game/something has got to be Monday.

I had that thought too when this thing started rolling!

How about "Final Monday", sounds more cryptic

concept aht
http://www.allegro.cc/files/attachment/596340

And there has to be at least 13 of them with several offshoots for different platforms, and a couple different genres.

Final Monday? Are you having a laugh? Why not Final Fantasy on a Monday with Zelda and Link?

I see something more in the Golden Age Of Pulp

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

Nothing cryptic about THAT

that reminds me of the Captian Proton episodes on Voyager.

because nobody will ever make the connection.

Yeah, pulp science fiction is the definition of "camp". Actually I think its the camp of "camp".

How bout, like, Super Monday, or Monday 64?

Personally, I don't mind just plain old "Monday". Or name the character Monday. Its an old school detective's name.

that's cool.

I approve... in all my approval authority.

My thinking as well. Monday should be the main character's last name.

Matt: We're going for a subtle mystery plot here, I thought. "Monday" will be a fine project name, but let's not try to go too over the top.

I played around a little with UML.

I haven't figured out how to bind stuff so script can do stuff. I don't have much experience with scripting.

Yes, I know. There's not much explained. It's just a throw up of the stuff we need to implement and a few relations between them.

{"name":"596342","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/6\/f\/6f7a30e4441f38df7ac1b477283a176b.png","w":492,"h":334,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/6\/f\/6f7a30e4441f38df7ac1b477283a176b"}

OK, well my ego is far too big to be on a creative team, so I'll try and stick to my CSA role. You and Mark have the art & music skills to set the atmosphere. I'll stick to organising the code and maybe doing a bit of it.

Later on when you've got the sprite style and everything down, I can help with the million animations.

Helping people to get on the same page, I stole some Final Fantasy tiles:

.http://www.allegro.cc/files/attachment/596345 http://www.allegro.cc/files/attachment/596346

So that's the basic idea of how the ship will look as far as the pure dimensions of rooms go. Pretending that will be the screen size and keeping those proportions, I think I'd want the player at least the 16 pixels he is now, maybe 18. I was picturing him Link-sized, with the ALttP style of too-big heads, but if we keep normal dimensions for the player like in the mockup that can work too. Not pictured: life meter, current weapon equipped, etc. The colony, which this is kinda supposed to be, is going to look fairly white and sterile, but be cluttered as hell with various gear and equipment.

Upon reflection, I think all the screens will scroll (not 100% sure yet). Being forced to make all the level designs adhere to compartmentalized room is going to bite me in the long run; I can tell now. All dungeons and the colony will be as you see above; black enclosed rooms that may or may not have to scroll. Perhaps they should all more-or-less stay centered on the player? The overworld will still just be one big tilemap, and if you want to challenge yourselves you could make it load a screen at a time from file so it only has an area 3 screens tall by 3 screens wide loaded around the player at any time. The idea of moving with arrow keys and shooting with the mouse appeals to me, and I should probably start thinking of ways to design rooms/enemies/puzzles around that philosophy ....

PS: Tilemap engine needs parallax scrolling; don't forget that detail.

I started writing an iso tile engine that worked like that. I eventually realized it was more trouble than it was worth. After calculating the memory it would take for say, a 1000x1000 tile map, it wasn't really worth it, and making sure thing that are off the loaded map keep state was more of a pain than just keeping stuff loaded, and using a few extra MB of ram.

I did actually get the code working though. Supported 9 layers as well or something like that.

I actually had been thinking of making a little demo of that (which is why I brought it up) and I think we had very different designs, but that's another thread ...

For my first tile engine, the code is rather pathetic but it let you load NxM "blocks" of tiles, where normally you'd just let it pick the best number of blocks for the resolution you're using (larger mode has more visible blocks on screen). And as I mentioned, that style of dynamic map loading didn't mesh well with the features I wanted to support.

I like the player proportions in that shot (needs bigger doors to match, though), and I would prefer that to anything else. Where did you get that player sprite?

Okay, I should be able to have everything setup by tomorrow night. Just need a method to control the users, and once that's done, I'll let you have it. Next week, I'll see about allowing other people to control user access as well. For this weekend, just allowing a way to allow people to change their password will be enough for me.

URL is http://svn.miquelfire.com/monday/

Subversion clients can be installed from numerous sources. Official binaries appear to come from here. That's mostly useful for Windows users. *nix users will probably either have Subversion installed already or will be able to easily find it in their distribution's software repositories. Or you can get the source and build it yourself (there are probably also binaries for most common distros). For Windows, it's definitely easier to just use pre-compiled binaries though. And for those not comfortable with the command line, there are a few GUI front-ends that do the job. ToroiseSVN is a pretty good one for Windows, I guess.

The command line client works a little different from most *nix tools in that it doesn't have a --help option (nor a /? switch for the Windows users). This used to catch me quite often. Instead, it just has a "subcommand" as the second argument (examples of these given by Thomas Fjellstrom are checkout AKA co, update AKA up, commit AKA ci).

svn [subcommand]

The one you'll probably use most often when first starting out is help, which lists the various subcommands available or, if supplied a subcommand, lists the help for a particular subcommand.

svn help [subcommand]

You can either view the Subversion Documentation online or download it and view it locally (Reads pretty much like a tutorial; I recommend you at least attempt to read through the first few sections so that you know how to use Subversion and get a general idea of DOs and DONTs):

• v1.5*: Download (.tar.gz / ~350KB) | Online (~1.1MB)

• v1.4*: Download (.tar.gz / ~364KB) | Online (~1.2MB)

_{* Not sure which version MiquelFire is running on the server. I'm not sure if the client/server have to match so to be safe I'll say they should (though they very well might not have to).}

I find it much easier to set the SVN_EDITOR environment variable (i.e. In Windows, I have it set to notepad because it's so light weight that it takes no time to launch). Then, when you don't pass the -m variable, the Subversion client will launch the editor set in SVN_EDITOR and let you take your time to write a detailed log message (Which also allows you to write multi-line log messages; which might be possible, though not pretty, on the *nix command lines, but not in Windows). When you're finished, just save (to the temporary file that was created by the Subversion client) and exit the editor. The client will examine the temporary file and react accordingly (either committing with said log message, or if you didn't modify the file, asking you what to do).

Fixed.

My server (if you clicked on the link) is 1.4

Though I think a higher version client should work with a lower version server. After all, if they weren't backwards compatible, how would you explain how they handle the SVN repository for SVN itself? Yea, to check out 1.5, you need SVN 1.5... chicken/egg... wait, what?

Maybe Monday's evil twin could be Yadnom?

I know this is blasphemous, but I stumbled across the ClanLIB library (competitor to allegro), but they have some really good ideas that we could "borrow" from if anyone needs to know how to do GUIs, use networking, use their style of maps (or map editors), etc.

I like the OO approach (almost entirely C++), though that may grate on some people here.

If I look at just one more 'CL_' I think I'll barf. Their naming conventions are awful. Haven't they ever heard of a namespace? The abstraction levels for image formats seem pretty low and their class names are rather lengthy. There are some interesting things there though, like their Sprite class with animation support.

Regarding the group project :
Keep at it people, I'd like to see everything come together. I may make myself available for proof reading once code starts materializing.

Play Game:  
    Centered buttons:  New Game, Load Saved Game, Exit

I don't see any value in having a Play Game sub-menu. Putting the New Game and Load options on the main menu (and perhaps a Save option while in-game) is more efficient from a user's point of view. Speaking of which, it may be a little early, but how do we intend to save the game? Are we going to store the exact player position, health, or perhaps just the inventory and progress?

Maybe we should start recording all of this stuff in a single place so we can find it later (either a Wiki or the OP?).

How did we define player vs. enemy fights? Zelda-like, where they attack each other on the world map, or will it do the FF thing where you're all in your line, they're all in their line, and you have very limited animations ("sword attack! Hi-ya!")?

I'm just thinking of the number of frames that need to be drawn in either case. For FF-style, you have "stand and wait for your turn" animations (a few "ho-hum" ones), but for Zelda-like, it's more like:

"walk left", "run left", "attack left", "defend left", etc.

Thus, we would know what kinds of animations they'll need. For just these four "left" movements, you may need to have 2-3 of each (so 8-12 different animations each).

With that new Spore game's monster-creation lab, we may be able to quickly create hideous monsters through that interface and just take a highly-pixelated snapshot of a few of its different movements (and then rotate in the different directions you'll need to use for 2D animations and do it again).

But that's obvious plagiarism...

EDIT:

From what I learned, many people prefer tend to prefer fewer "distractions" in a screen than having to click through a few more screens to get to where they want to go.

You COULD put the screen-configuration settings on the same page too, but then you immediately see how that could become more cluttered quickly.

There may want to be a design spec that says that we should limit the number of on-screen elements (buttons, information panes, etc.) to a certain number (as a standard, not a hard-fixed rule, of course). That would help us know when "too much" is too much...

I think we agreed on real-time, which likely means "world map" battles. And it's seemingly going to be a shooter. For the record, FFXII and FFXIII have world map battle systems though.

Like I said, we should record the details in a single place so we can look these things up easily as time goes on. What should it be? A post, wiki, static Web page managed by an elected member, or something else entirely?

It really depends on just how clean the title screen is. Keeping the background of the actual menu uncluttered will make the menu easier to see. I think that's key. So long as the menu items fit nicely on a single screen there should be no problem. I've played games that did either well and either badly. It's really just a matter of making the title screen UI first and art second. It shouldn't be too difficult to experiment with each though.

The best and most concise references right now are 23's posts (the long ones). I reviewed them last night before I went to bed and found some things I had missed. I recommend that other people do that as well.

Trezker, did you use Dia for that UML? Can we have the file to play with please?

This was to provide an opportunity to put more games (or expansions) in the same exe . The first main menu would be the framework's, and could have [PLAY GAME1], [PLAY GAME2] [WEB UPDATES(clickthrough;D)] buttons. It would have its own style (flames for Flamework (earlier typo) is what I'm thinking, done in a slick, corporate style, so if you a) don't read it b) don't press a key and c) only have 1 game in the exe, then after a few seconds it would jump straight to the game's main menu, and you would think you'd just seen a publisher's logo. It's like lilo in a launcher

The Game's main menu would be the individual game's main title screen, with its own graphics etc.

Hmmm, as some of you know I've recently become interested in Unicode programming. And it just occurred to me that it might be a nice thing if we use Unicode internally. Assuming the story will be told 100% through text, we could even conceivably store said text in locale-specific XML files, which would allow for easily translating the game to other languages. And with Unicode, it would conceivably enable the game to be translated to any language.

Obviously, the font we chose would have to support it as well. We'd need to make sure the "speech bubbles" and any other text controls were dynamic too. They'd need to be able to calculate the required horizontal and vertical space and split the text appropriately across lines and screens... There might be issues with incorrectly formatting some languages, though members fluent in those languages could advise us on those quirks...

It would probably add a considerable about of work so it should be put on the list of extra features or whatever. If it's not a big deal to any of our multilingual members then it's probably not worth risking the project on another optional feature. Just a thought for consideration.

Allegro has full support for UTF-8 built in. Fonts are the only concern.

I made a full Unicode Allegro font from a free one but it's rather plain. I think we should suck it up and let the user select the best font on their system, rather than try and supply a good, complete one with a compatible licence (which would be a huge file anyway) This removes stylistic control from the design team, unfortunately.

On the subject of internationalisation, I've got an evil plan for the Japanese version. Let's do to them what they did to us with Zero Wing. Nobody with any degree of fluency shall be allowed to assist. Otakus + Google Translate = Mirthful Joy Feeling \:)/

Scooby Dooby Doo!

I think that internationalization/translations should wait until we maybe have a working game.

It'll actually use the EDITOR variable on linux/unix which is normally set to vi or something similar, though mine is set to "nano", and I just prefer to pass short messages in, instead of messing with the editor when it launches. Basically I only use it when I have long messages to apply.

I used Umbrello to make that UML.
Umbrello doesn't seem to export to many formats so I don't know if I can give you something that loads in other programs, maybe you can load the format it uses...

Yeah, but it's worth considering before hand-drawing a custom multi-coloured font.

Do you guys have any consolidated design documents, including role allocations, for those of us that are dipping in and out of the conversation to use to keep up? It might increase your probability of getting further volunteers.

Did you pick a lead programmer?

EDIT: as ever, I can throw my code for drawing TrueType fonts with OpenGL geometry at anyone who is interested. Though I suspect you're all heading for a CPUy, pixely game?

There are still no code ?

Still on your UML thing ?

Move in team ! Go for the Objectives !

EDIT:

Trezker is IIRC.

The most ambitious thing we should be worrying about, text-wise right now, is word wrap. If we're following good coding principles, upgrading the engine to handle more will be simple.

If anyone is coding anything, it should be a general framework. Whoever is on that should just start writing a simple engine that handles the main menu, player movement, and changing maps. Once the world is more or less established we can add NPC interaction to it, quest points, simple GUIs for player inventory, enemies, items, scene scripts/triggers, and the like.

So if the coding team is looking for "step one", there you go. Write a basic framework that we can plug all the other crap into later. Simple main menu, the player can move around simple tilemaps and switch maps by stepping on "doors", and just have lots of comments what should go where later. Keep the design open enough that we can add in everything else easily. For now the player can be {int x, int y, BITMAP* sprite}. Tilemap can be {int w, int h, int[][] map} and each number in map can be for drawing a rectangle of a solid color. Simple like that. In the making of the framework we'll have figured out how to handle everything. Will you keep separate arrays of each object? Use polymorphism and STL to keep every game object in one big vector<>? Figure it out now!

I've made a second stab at UML. This time I made a god class which is preached against by OOP gurus... But it's simple, and we can split it later.

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

is Game a global base class? So all those objects are all in a "isa" relationship with it? Or does Game just "havea" (contain) bunch of other objects?

Game has a lot of stuff. It's the manager of everything.

I figure Monster, Player and NPC will share a lot of functionality so I made a Unit base class for them. I don't know why I bunched in trigger with them though...

On the subject of word wrap: I have some code from my TINS entry that wouldn't be too terribly difficult to put in.

Sure, but some thinking ahead might make it a lot easier in the long run. It would be nice to be able to just drop a new translation file, pick an option from a dynamic control, and have the game 100% translated. Again, optional, but I think it's worth consideration before starting.

Notice how when KQ was suggested, people started looking into the code, immediately saw that it was overwhelming and ugly (by their standards) and decided they hated it? The same thing can happen to the code written by others if it's not governed by the project. The framework is going to be the foundation of the project and if people don't like it or find it difficult to understand, they probably won't be too excited about the project.

I think we would benefit from coding standards and a thorough design. It might even be a good idea to use an automatic source formatter on the code before going into the repository (i.e. GNU indent). I personally have a compulsion to reformat code that I find difficult to read. This would allow me to hopefully do that without actually changing anything (in theory, GNU indent could put it right back again). It could be used on the client, instead, but then the repository itself would likely end up storing a lot of white-space differences (I think Subversion can ignore white-space, but that just seems like it would grow increasingly messy).

It just seems like some members would rather dig this project an early grave than take it's time and succeed.

The thing is, if we don't get anything done, then it's just a lot of talk and no code. I think we need to do something.

I agree. Something like defining coding standards and modelling the application. It's a major part of writing good code. Designing it first. Think of how easy it would be to write the code if all the modules were documented beforehand!

Doing it right takes time. If you disagree with me then you'll be every manager's dream, every maintainer's nightmare, and every user's enemy.

I AM modeling, not getting much of a discussion going though.

The basic idea is we're trying to keep this from being a "long run". This is a very simple design with very basic mechanics which a single person could probably make easily enough given some time. We have enough of an idea of what we want that we can start putting code down. The last thing I'm worried about is indenting.

It looks like there's still some discussion on how the classes will be organized, and that's fine since it's actually important. But don't sweat too hard over it; agree on a design that works and start implementing it.

Yup, and it's appreciated. My only input is that all the managed objects should derive from a base class but you've got that anyway. If anyone else has a problem with how you're setting it up they can speak now or hold their peace.

Since people are talking about classes, it seems that we'll be using C++. I don't know too much about that, but there's got to be some code we can write that is independent of how we decide to organize the classes.

I've never written a game like this so personally I don't know too much about the overall design/structure. I'll happily try to critique it though...

The model appears to be missing items/weapons. Are we still planning to have upgrades that the player can find? And what about NPC's and Monsters. Are either of them going to be able to have/use items and weapons?

It think it's awkward that the ScriptGlue and Script are not related at all... I think it makes better sense to have Game -> ScriptGlue -> Script and the game itself will still manage everything, but scripts are then able to communicate with the game (i.e. to control Units, for example). My only experience with a game engine and scripting was with Torque during a short 3-day "class" (?) at the local university. I don't remember the how, but C++ classes in the actual engine were bound to scripting classes in that if you called a method on an object in script it would be called in the actual engine, resulting in the desired behavior. That's how I see this going... Anybody done this before? Is this what we're planning?

Does anyone see value in a SpeechBubble class for managing the text, etc.? This way an actual Unit could just say() something and it's SpeechBubble would take care of the actual drawing. We'll likely need some way to tell it to switch pages though (i.e. say_more()) when given user input.

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

Essentially, CGame represents the actual game (:P). So far the game contains a configuration manager (CConfigManager), save game manager (CSaveGameManager), script manager (CScriptManager), tile maps (CTileMap; though perhaps we also want a tile map manager), and units (CUnit).

CGameObject is a base class that everything derives from, directly or indirectly. Obviously all of these classes will need to be wrapped in a namespace.

UML: PNG (XMI)

There is a lot still missing... Critique/revise! For those of you familiar with the kinds of work that will need to be done (collision detection, path determination, etc.), it might be a good idea to start thinking of how to wrap these things into a framework that can later be used...

** EDIT **

Hacked menu system back into it (Umbrello crashed and I forgot the menu system the next time around). I'm not sure why I went with "System"... I guess for the sake of the model, "Manager" and "System" are synonymous. So we can pick whichever we prefer.

_{UML would be so much more attractive if the software was intelligent enough to automatically arrange entities and relationships so they were readable and didn't overlap... :-/ Trying to do this manually, as demonstrated in the above class diagram, is a bitch. :P}

First, I don't see the point in putting a C in front of every class name. I find it very distracting.
Second, I prefer Speech_bubble over SpeechBubble.

I see how a universal base class might be useful, especially for saving and loading games. We should discuss how saving should work.

As for items and weapons. I don't think they will cause much trouble. Your model for that looks good.

In my model Script wraps a script specific to the instance that uses it. A certain NPC for instance needs to be bound to its specific script.

Scriptglue is there to make various functions available to all scripts. So the connection between Script and Scriptglue is made in Lua or whatever we use, not within the engine.

Personal preference, I guess. I like it because it frees up ClassName as a module-scope identifier, which frees up class_name for limited-scope identifiers. For example...

Which is exactly why we should nail down our coding standards. Odds are a lot of us will be disappointed that the project won't be using our standards, but it's a little bit easier to deal with when it's the "project's" standards as opposed to "his" or "her" standards. And as I said, formatting can hopefully be handled mostly with software (i.e. GNU indent). The naming conventions will need to be nailed down, but that's also why it makes sense to document the entire project model... It won't be individual programmers coming up with names for things. It will be them implementing an already detailed, named, project idea.

I think we're the same here...

I haven't actually used scripting in a game engine before so I'm a little confused as to how it works exactly... I think having to write a separate script for every single action or NPC would become lengthy. It seems like being able to write a single script for a "scene", for example, would be nice and clean. How to do this, I don't know. Perhaps the script will need a concept of a "timer" and "frame" as well so it can time it's actions appropriately (although "triggers" will help with this, they probably won't be able to handle everything).

The low level stuff, although I can't think of what isn't in Allegro already, except the tile renderer, and that has to wait for the game spec.

I think you can have a library of functions in one script, which can be called by name from the NPC_update() func in the binary. You might need a flag to distinguish scripted from hard-coded actions or at worst a vtable. Or, you could have scripted funcs that wrap the hard-coded ones, so all NPC actions are scripted.

Are we agreed that LUA is the scripting language? The only alternatives I can think of are Python (making an interface API is verbose) or Ch which may have licence problems with the free version. I can't tell from reading it if it's allowed to distribute binaries with Ch embedded.

Lua seems to be the language to use. I haven't personally used it before, but I guess I can take the opportunity now to give it a try. Mmmmz, Linux.

READ THIS: I'm going to keep the summary of our progress and game concepts on this page: http://www.zeoxdesign.com/monday recommendations and suggestions are not only welcome, they're necessary! ;)

Feel free to use the wiki as well.

I think we should go with plot #1, btw.

Sorry, i've been out for a while, so somebody might have already said this...

Not to be the enemy of all freelance coders here (myself included), i think that to avoid the problem of having code that some members of the project consider "evil", i think we should set up some style guidlines, everything from newlined curly braces to what should be a global variable, to should we use gotos (just kidding. )

To save time on deciding style rules, the group could use the Allegro Hacker's Guide.

agreed

I didn't even know that existed!

For the coding standards, that's fine. I'm uncertain about how the indentation will work. The way I do it is two spaces for each new level of indentation, replacing any eight spaces in a row with a tab. I'm not sure if you can set Emacs to do anything else.

Two seconds of googling says you can.

alright, that's 3 for the allegro hacker's standard... none opposed

Fourthed. Although it doesn't explain all things, like naming conventions of:

1) Classes (class CClassName, class ClassName, class class_name, class _class_name, .. ?)
2) enums (enum PLAYER_DIRECTION { ... }, enum Player_Direction { ... }, enum player_direction { ... }, enum _player_direction { ... }, etc.)

There may be others, but these first few would be important for me.

Then we all have to read the Allegro Hacker's Guide! Actually, it was looking good for a minute,...

/* foobar:
 *  Description of what it does.
 */
void foobar(int foo, int bar)
{
    /* do some stuff */
}

...but I personally prefer to line up braces at the start of the indentation level (i.e. Nothing on a line before the braces, but single-line blocks can follow...). It makes it a lot easier to find missing braces and also makes the program structure clear.

if(foo)
{
    /* stuff */
}
else
{
    /* stuff */
}

Fixed.

do
{
    /* stuff */
}while(foo);

Fixed.

switch(foo)
{
case bar:
    /* stuff */
    break;
default:
    /* stuff */
    break;
}

Fixed.

I'm not really trying to start a flame war, so if the majority agree on the Allegro Hacker's Guide I won't fight it, but I think my recommendation is valid. The newlines add clarity. The spaces between a condition statement keyword and its condition generally don't, IMO (though spaces should be used inside the condition to make it readable and parenthesis should be used to make it clear).

if((condition1 && condition2) || (condition3))
{
    /* stuff */
}

// -- OR if conditions are long --

while((condition1 && condition2)
        || (condtion3))
{
    /* stuff */
}

Mark, put a <title> tag in that document.

Anyway, got some time, will start coding up the interface to handle users for the SVN now. Won't be too long now.

And also, we would probably benefit from using a documentation system (i.e. Doxygen) standard in the comments.

okie-dokie!

Allegro hackers guide looks good. I'll set my IDE up for that.

What classes are we going to have? Maybe it's just a personal preference, but i prefer to have a complete object API before we begin coding, even if none of the structs are actually coded. I was thinking:

{
NPC

Map

grid-square

Main character
}

at least.

It's a work in-progress.

http://www.allegro.cc/forums/thread/597566/769552#target
http://www.allegro.cc/forums/thread/597566/769787#target
http://www.allegro.cc/forums/thread/597566/769906#target

Far from complete.

** EDIT **

Thinking a little more deeply, are speech bubbles going to be dynamically positioned/sized or perhaps there will only be one at a time (in which case, each unit will not really need it's own and the say() method could communicate with the game's single speech bubble instead).

Okay, SVN is up and running. All I need to do now is add users basically.

The repository url is: http://svn.miquelfire.com/monday/
The url to change your password is: http://svn.miquelfire.com/svnadmin/?project=monday

For now, only Chris and Matt (as they're leaders of this project) can send me usernames to add (VIA PM), so bug them about getting access. Later (next weekend I hope), I'll allow them to just add and remove names themselves without having to wait for me.

Oh yea, they need to contact me for the usernames they want. And Chris, if their anyone else you want to allow to add/remove user access to SVN, just let me know.

MiquelFire, what version of SVN do we need to have?

- Source

Much appreciated!

I feel like I've gotten out of my league. The last page or two... so confused! Is there some non-programming position available, I still want to help, you guys are just way beyond my technical skill.

• Design graphics

• Develop storyline

• Get some sort of simplistic framework ready

Even if you only write code in C, it won't be too difficult to have some of these C++ programmers to convert it, if they need to (though, since C can be compiled FINE without much/any changes, I don't see this being a big issue, or at least a time-consuming one).

I nominate myself to work on the storyline! Any objections?

hahaha.

anyway, yea, these last few pages of programming specifics aren't quite in my relm either, but that's why I'm glad I'm not doing them! I think once those experts iron that stuff out there will be some good mid-level stuff to do, even for programming. They're pretty much working out how it'll all be structured in the grand scheme so that the little guys will know what to do.

I think you should wait and see if there is anything in the overall design that you have experience with (or even think you can handle). And regardless of your coding contributions, there is always documentation and testing.

Fine, I'll wait. The storyline will just have to do without my pure literary genius.

I've started a few files to get an idea of what needs to be done, and it should be flexible enough that even with radical changes, it won't be hurt too badly.

I need some concrete specs for the maps.

It would look something like:

void the_game(...)
{
   Map map;
   map.set_tilew(16);
   map.set_tileh(16);
   map.set_dimensions(200, 240); // width, height
   map.set_num_layers(3);

   // ...
}

What else does it need? I think that the "layer" tile values should be public, so you don't have to call expensive getters/setters: just access the array directly.

This is something at least that we can start on. More features can be easily added as needed.

I'm not saying you can't work on the storyline. I think the storyline should be worked on collaboratively though, as a team.

the team being Mark Oates and his team of brain cells...

just kidding

Is that akin to brain children, but just with more neurons?

Hey OnlineCop I think your map proposal would work nicely. I approve

with vector and all

except I think the tilemap should be a seperate class

The storyline should be collaborative, bet we really need one or two people to do the actual writing. Division of labor is a wonderful thing for getting team projects done.

Opinion #1

Isn't this in direct conflict with Thw Whole Bloody Point™ of C++? I don't think performance is an issue here if we are aiming for SNES age gaming tech. The renderer might need direct access but that can be done as friend class.

I suggest by-the-book (Stroustrup, zzz) clean, elegant, OOP code. Ideally the classes output by the UML tools will be used verbatim.

Opinion #2
What the hell, yeah go for it. Do whatever works. We've only got one week, after all

This made me smile Why, do you suppose, do writers go and live in a cabin for the duration, with nothing but a manual typewriter and a tube of bear repellent?

Sure, throw ideas at the writers, but don't be offended if they don't stick.

Personally I'm not very fond of the one week limitation. I think it's good to set dates to motivate productivity, but to say the whole project must be done within a week (before even really nailing down the details of the project) sounds dangerous. I'd rather do a good job and take something away from the experience than release another semi-functional embarrassment upon the world, or possibly nothing at all.

It would make better sense for the project/team leader to set goals for individual task completion so the whole thing falls into place nice nice. A week may seem like a lot of time for a project like this for some, especially with so many volunteers, but most of us have day jobs or school. Heck, some of us allegedly have lives. I think it makes sense for a project like this to be flexible with it's schedule.

This way when it's not satisfactorily done in a week, moral doesn't have to drop to the point of giving up. Instead, we revise our plan and continue working until it's done right.

The original idea of a one-week thing was unrealistic for this project. I think it was set so low because problems maintaining interest were expected.

I've pretty much got a basic plot in mind, I'll flesh it out and post in detail down the road. It has no bearing on the engine anyway. We already know what we need to code, and the cutscenes/dialogue won't be anything special. If I feel something fancy might be needed you'll get lots of notice. Scripts really only need to handle dialogue, movement, and the occasional animation change right now.

I hereby put myself in charge of overall plot, and level design. Which are the two hard jobs in my opinion anyway. The basic requirements of the engine are laid out; let's get on that.

Map map;
   map.set_tilew(16);
   map.set_tileh(16);
   map.set_dimensions(200, 240); // width, height
   map.set_num_layers(3);

Down the road, you can replace that with this:

   Map map("dungeon 1.map");

At least it's written. Code format affects the final game not one iota; it barely warrants 5 minutes discussion. We won't be writing the code long enough to care. If we need to get everyone on the same page then there's our page. Code beautification is not a pressing issue for short projects!

Lua works for scripting. It's proven and I'm sure a few of us have experience. And no, this is not going to be just a one-week project. Like I said, I'd really like to have seen an executable by now. Not a very usable one (black screen, please press Enter ftw? ), but one with the internal flow of the game mapped out if nothing else. Extremely basic interfaces and variables to be added to later, zero implementation.

K, I've updated the Monday Game Progress Summary Document Webpage Area.

everybody review it please and make sure it's correct/we're on the same page.

You are missing me.

Are we going for 16x16 or 32x32? Nice page btw, I like the Web 2.0'ness. I agree with bamccaig on the time limitation issue.

I suggest we write out tasks for everyone on Marks page/the Wiki and then everyone can set out to do their jobs.

We've been ordered decided to use 16x16.

Pretty much.

What color depth? I don't like 8bit.

Neither do I. Forgot to say that, yeah. 16 bit plskthx.

For some reason I've always thought that Allegro couldn't do 16+bit with a 320x240 resolution.

not with GFX_VGA etc 320x240x8 does indeed work with (nearly?) any old Allegro 3.x driver, but even djgpp has options for higher depths

IMO, 16x16 are no quicker to do well than 32x32. The only advantage is reduced file size, which is no big problem these days. Kids today are not bashful about getting a 5GB game via torrent, if it's worth it.

If whoever is drawing/compiling the tileset and drawing the characters disagrees with me then that's fine.

A possible motive for increasing the res is font size. It's pretty hard to represent a Chinese char in less than 16x16.

k updated the color depth and Vanneto (sry).

oh? what's web 2.0 about it?

Obligatory Redundant Link to the Monday Game Progress Summary Document Webpage Area or ORLMGPSDWA for short.

We're representing Chinese chars now?

I think we've unofficially decided to indirectly keep internationalization an easy possibility in the future. Something crippling towards that goal would be unfortunate.

We have? Why? I thought the whole point of this project was to get something done. WHEN ARE WE GOING TO GET SOMETHING DONE!?

Fair enough. 16x16 tiles in 320x240 at 8bit is out. We're now running 32x32 tiles in 640x480 at 16bit colour depth.

And I agree with Neil Black. If I wasn't about to start writing up a hard plot outline I'd just code the bloody framework myself. Honest question: what's left that I can't see this by the end of the day in a format that compiles?

You get the idea. Make a .cpp file, put the rough classes in it, get the inheritance and STL containers rocking, and start plotting this thing out. Here, I'll get you started:

     // Initialize standard Allegro stuff
  allegro_init();
  install_keyboard();
  
  set_color_depth(16);
  if(set_gfx_mode(GFX_AUTODETECT_WINDOWED, 640, 480, 0, 0))
  {
    set_color_depth(15);
    if(set_gfx_mode(GFX_AUTODETECT, 640, 480, 0, 0))
    {
      allegro_message("No support for 16bit or 15bit!");
      return 0;
    }
  }

For realz? Link with Lua, get some empty functions for obvious stuff like the initialization and shutting down, make (mostly empty) .h and .cpp files for the major classes ... you don't need much of a design doc for a skeleton this basic. Whoever is in charge of the coding team, get the basic flow going in code and be ready for details. You should have a basic idea what the game will need; we've already seen diagrams. Write it up, upload it, and let's flesh this puppy out. And remember to follow the Allegro Hacker's Guide for formatting!

Once we've got the files organized then we can probably start delegating. We'll decide what we need, everyone will grab a class and start writing. Once we've got them all together we'll edit as needed until the engine pieces all fix (be nice if they did without editing but what are the odds on that?), and by that point we'll long since have the plot done, script requirements finished, and some levels to play with. Graphics and sound will be last concerns, but obviously the engine should be written to take care of all resource loading, playing, managing, and deleting.

Theres no reason to forcefully leave out i18n.

Time? Otherwise you do it.

Its no more work to keep it in mind, than it is to consciously leave support out. Besides, allegro has a function to get translated strings, and natively supports Unicode.

EDIT: edited.

It's in mind. Waaaay in the back, is all.

I have a self-contained module that completely hides whether the input comes from a gamepad, a keyboard or even (in principle) a mouse. It lets you use multiple sources at the same time (so you can switch between gamepad or keyboard by putting aside one and picking up the other) and you can remap physical keys to "logical" keys. You then query whether a logical key, say GAME_KEY_UP or GAME_KEY_USE_ITEM has been pressed.

If there's any kind of demand for this, let me know. I haven't touched the inner working of that code in years though and it might be a bit convoluted. It's also rooted firmly in Allegro 4, so it'd have to be rewritten for Allegro 5. It's also in C rather than C++, but a C++ interface is of course easily written for it.

I have started putting together the Game class. The hub of activity in my design.

Now there is one question I would like an answer to. How do we handle input?
I'm imagining this as an old style console game with only button input, no mouse. I thought we could make an input hierarchy of menu>dialog>player. So if a menu is open it gets all input, then if a dialog is open but no menu it gets all input and if neither dialog or menu is open you can run around with the avatar and blow shit up.

As an improvement over KQ, you should always be able to open an in game menu by pressing esc (or select/start on whatever) and choose to skip dialog or exit to main menu. Pressing esc in any menu should close it.

Anyone have objections?

No objections to that. For cutscenes, there should be an option to press space and skip through.

How do we want the .map file designed? We could do XML, standard UNIX config file, our own proprietary thing, or one of those other things that Cortex Command uses.

whaddayathink?

I'm for our own proprietary map format. It makes us look a lot more l33t!

I agree with Trezker about the input. Simple and easy, thats the way it should be.

So, is the SVN server going to be Miquel's?

Trezker: I need to finalize this as I design the dungeons, but we're currently going with the idea of keyboard movement, mouse aiming/shooting.

I prefer Trezker's suggestion.

I'm the kind of person that watches cutscenes 99% of the time, even when I've seen them before (unless they suck, in which case I'll probably still watch them once). I hate when I twitch or something and hit a button or click the mouse and unintentionally skip the cutscene and have to reload the game from a previous save and work to get back just to rewatch the cutscene (even if I'm right there it still takes time to load). The better solution, demonstrated in games of late, is to bring up a menu offering to skip the cutscene or exit to the main menu. And a confirmation prompt might be a good idea too, at least for the exit to menu option. This way the user is much less likely to trigger it unintentionally.

This seems extremely unintuitive to me. I think a skip button makes a lot more sense, and not just to me, but your average joe. I can't even remember a time where I accidentally skipped a scene.

If you're worried about people skipping them on accident, I think the best idea would be to keep a "journal" of all the scenes, and the player is able to replay scenes that they've encountered.

The journal is a good common sense feature that too many games leave out these days.

But I still think it is reasonable to display a confirmation prompt if they skip the cut-scene early, maybe something that asks if they are sure and tells them that they can always view it again in the journal, and has a tick box to disable prompting in the future. That seems quite sensible.

SquareEnix did it in FFXII and I think it's brilliant. I'm sure they'll do it again for FFXIII. There's nothing unintuitive about it. That's like saying a file deletion confirmation is unintuitive.

This is a good idea, however, it doesn't solve the problem of accidentally skipping the cutscene. Either way, the flow of the game is broken, which is very annoying for users (at least for me).

Agreed. The optional prompt makes it even more user-friendly. Everybody gets what they want and if a user does unintentionally skip a cutscene it's probably his own damn fault for disabling the prompt.

The menu also has the advantage of offering to exit the game faster (rather than waiting for the after-cutscene elements to load and render, he can immediately exit if he so desires).

I must have missed the point. I think a confirmation would be a great idea. But I was thinking something like "Press spacebar to skip..." in the corner and then after you push it, it would ask if you were sure. I got the impression that you were saying that the user pushed the "main menu" button or whatever, and one of the options there was to skip the cutscene.

Anyway, hardly matters. It seems we're on the same page.

I don't think it matters much. I mentioned mouse because for some reason I figured it might cause some kind of problem... But now I've realized I was wrong.

I've written a very simple Menu class that has pointers parent menu and child menu. So you can go further into submenus and escape to parent menus, no mish mash. For now I just send in ALLEGRO_EVENT events to the top menu which sends it on to child if available, to its own handler if no child.

However we implement specific menus, I have no idea.

I'm attaching what I have done so far. I'm too lazy to start using svn for this yet. Also, an attachment is easy for everyone reading the thread to just download and take a look at. See it as a nightly snapshot...

There is not much comments in the code, so you'll have to just look around at your own risk. The Player, Animation, Animator classes is just something I ripped from my allegro 5 test project, I thought it'd be fun for everyone to fly around with Mr. Smiths famous Gryphon sprite.

Oh, maybe I should also mention I build the project with scons.
But it's using the speedhack organisation so you can use a makefile from there.

cool!

I usually keep keyboard input separate from my player classes, just wondering why you decided to include it in Player? just cause?

I like the Animator/Animation classes. I've never done that before.

Yeah, the player class probably shouldn't know where the input comes from. It should just get events called up, down, left, right, shoot...

Having actual code is good. Using the SVN repository that we have now is even better. You should import that.

Also, in case anyone needs help with SVN: http://svnbook.red-bean.com

Okay, as long as we're using the Allegro hacker's guide, and it doesn't contain ALL the coding formats that we may encounter, where will this "new and updated" version be? Maybe as part of Mark Oates's page?

I'd like to do our own proprietary thing. Then you'd be forced to use a map editor to make changes. This means that the map editor itself could do a lot of the error checking and corrections, at the expense of easy readability and flexibility...

it doesn't have to. Just use your best judgement. A 2nd line brace isn't going to cripple the project, but worrying about it will.

For the map format, binary formats are a pain in the @$$. It should be plain-text, editable with any text editor. We can provide a map editor and say "don't edit these unless you're sure you know what you're doing", but taking out the ability of knowledgeable users to fiddle the maps by hand is not a good idea.

EDIT: Also, we should start getting the code we have imported to SVN and giving developers access to it.

I agree with the text-editable map format.

Everybody familiarize yourself with trezker's basic game structure here.

Obligatory Redundant Link to the Monday Game Progress Summary Document Webpage Area or ORLMGPSDWA for short.

I third the text-based map format. Assuming we're going for open source, the whole project should be as open as possible.

And if we're not doing open source, then we need to make it as open as possible so as to avoid annoying users any further.

My system (with the SH2007 makefile) doesn't like Trezker's project:

[bamccaig@rufus ~]$ cd src
[bamccaig@rufus src]$ mkdir -p allegro/4.9 && cd allegro/4.9
[bamccaig@rufus 4.9]$ svn co https://alleg.svn.sourceforge.net/svnroot/alleg/allegro/branches/4.9
snip
[bamccaig@rufus 4.9]$ mkdir tmp && cd tmp
[bamccaig@rufus tmp]$ cmake GRADE_STANDARD=on GRADE_DEBUG=on GRADE_PROFILE=on SHARED=on STATIC=on ..
snip
[bamccaig@rufus tmp]$ make
snip
[bamccaig@rufus tmp]$ su
Password:
[root@rufus tmp]# make install
snip
[root@rufus tmp]# exit
exit
[bamccaig@rufus tmp]$ 

Then...

[bamccaig@rufus tmp]$ cd ../../../Monday
[bamccaig@rufus Monday]$ make
g++ -Iinclude -O3 -s -W -Wall -o obj/Animation.o -c src/Animation.cpp
src/Animation.cpp: In member function ‘bool Animation::Load(std::string)’:
src/Animation.cpp:43: warning: no return statement in function returning non-void
src/Animation.cpp:43: warning: control reaches end of non-void function
g++ -Iinclude -O3 -s -W -Wall -o obj/Animator.o -c src/Animator.cpp
g++ -Iinclude -O3 -s -W -Wall -o obj/Dialog.o -c src/Dialog.cpp
In file included from src/Dialog.cpp:2:
include/Dialog.h:17: error: ‘ALLEGRO_EVENT’ has not been declared
src/Dialog.cpp:13: error: variable or field ‘Event’ declared void
src/Dialog.cpp:13: error: ‘ALLEGRO_EVENT’ was not declared in this scope
make: *** [obj/Dialog.o] Error 1
[bamccaig@rufus Monday]$ 

** EDIT **

Corrected cmake arguments to be identical to what I think I did. Also added the cd tmp, which was missing. I didn't have the original history (ex_opengl crashed X on me) so I had to go by memory.

are you using a5?

Wow. A5 is a LOT different than A4. I'll have to learn it first.:-X

AFAIK (edited the above post). Is there a command to check the installed version?

** EDIT **

[bamccaig@rufus Monday]$ allegro5-config --version
4.9.5
[bamccaig@rufus Monday]$ allegro5-config --libs
-L/usr/local/lib -lalleg-4.9.5
[bamccaig@rufus Monday]$ ls -Al /usr/local/lib | grep alleg
-rwxr-xr-x 1 root root  929520 2008-09-14 21:40 liballeg-4.9.5.so
rw-r--r- 1 root root 1145556 2008-09-14 21:41 liballeg_s-4.9.5.a
[bamccaig@rufus Monday]$ 

Replacing allegro-config with allegro5-config in the makefile has no effect...

Until I get access to the SVN, how about this for just the layers?

It only needs to have a few things:

• type (unsigned char, unsigned short, or unsigned long: 1, 2, or 4 bytes)

• number of tiles (horizontal and vertical)

• z-index (since the map has to keep track of which layer is above/below the others, it makes sense just to store this along with the rest of the structure)

• array (std::vector) of tiles

The other things are functions like different constructors and map-resizing support (to make bigger or smaller).

In my prototype "CMap" class, I've typedef'd the layers with a "unsigned short":
typedef CLayers<unsigned short> Layers;
Then, I've got a std::vector of these Layers (or CLayers<unsigned short>):

  std::vector<Layers> layers;
  // ...or...
  std::vector< CLayers<unsigned short> > layers;

The map is responsible for the size of data type (the "unsigned short") for the map, since we may use less than 256 tiles in one map (then you'd use "unsigned char" to define the tile datatype), or less than 65536 (hence, the "unsigned short").

The layer itself doesn't need to know any other information than that.

Ideas, comments, or suggestions?

• Why not replace the TILETYPE with a CTile pointer (assuming I understand its purpose)... The CTile class can even store most, if not all, of it's properties statically.

• The tiles_x and tiles_y properties should be width and height, IMO.

• I'm not sure why the class name is plural. AFAIK, it represents a single MapLayer.

IMO, we're not ready to be writing code yet.

** EDIT **

[Wrote some pseudo-classes and struck out a statement]

I'm not understanding what a CTile pointer is supposed to do. How can it tell whether we need an unsigned char (for tilemaps with <= 256 tiles in it), or an unsigned short (for <= 65536 tiles in it)? I mean, if it does that, it's fine with me. Implementation isn't really as important to me as just getting something that we can work off of.

And that's fine.

I just haven't figured out good naming conventions yet

Maybe I don't understand what it represents... What is the TILETYPE for? I was assuming it was an identifier to reference the actual tile (i.e. bitmap, whether it's walkable, etc.) in a container or array somewhere else. If so, we could just store a pointer to the actual tile instead. If not, you'll have to tell me what it is.

After writing some psuedo-classes, I realize that I was likely wrong about the static properties though... Unless we want to actually define subclasses for each unique tile. I haven't really thought out the details of the storing and loading of tiles/layers/maps yet.

My bad. I'm just OCD like that. The little things bother me.

** EDIT **

Stupid Umbrello displays the class diagram with most of the classes too small to read... I shouldn't have to rearrange the diagram every time I open the file!

Whoops, forgot that speedhack doesn't use a5 yet...

If you want me to commit the code to svn, I'll need an account I guess.

Umbrello problems... Weird, it works perfectly for me.

Maybe the result of trying to squeeze it all into one screen? My resolution is set to 1024x768.

I just watched the latest video from GyroVorbis. They describe a bit how they use lua, starting 2 minutes into the video.
http://www.youtube.com/watch?v=ik6lCtxYj28

I thought this might be educational to someone, or give ideas for how we should use lua.

Okay, here goes the plot, mostly. Incoming stream of consciousness attached ... I highly suggest anyone seriously involved read it all because it's not all plot related.

I forgot to hit the upload button; yeah, I fail.

looks for attachment
...
fails to see attachment

I've added a makefile to the project and discovered that indeed, you cannot compile because I forgot to include allegro in Dialog.h which confuses me a bit. I wonder in what order I actually did stuff last night...

Now I got that working though and trying to figure out what to do next. The Base class for game objects maybe? Game loading framework?

Game loading can wait. Get a base class going imo.

EDIT: You'll only be able to save at actual save points, btw. Not Zelda's save-anywhere system.

Nice. I like it. Especially (1) the rock crusher which can be 'upgraded' with new rock frequencies, (2) most of the dungeons are underground, eg. rocks and mountain tiles are relatively easy to draw , and (3) the rockin ending.

For controls the big question is should we go two mouse buttons or one?

One mouse button would lead to a combination of quick-keys QERTFCX for items, spacebar for weapons menu, select with mouse.

2 button would mean the same quickkeys but right-click for menu, mousewheel for scrolling through weapons. Space to interact with objects.

2 buttons would probably be best then, even though initially I though 1mouse would be more 'universal'. But that's just silly in 2008.

about lights for Dungeon 1, I think we should consider (very basic) shadow layer for the lights. It would be relatively easy to put into the map (a 'light' tile could have a larger light circle drawn on the light layer at the same coordinates). We could do really erie blinky lights too.

Only Dungeon 2 will have much rock to speak of. Dungeon 1 is the ruins of the original city, fairly technological. Dungeon 3 is underground, but it's still a build city; it's very simple since this race needs few trapping that we'd be accustomed to. It will still be quite shiny.

I'm thinking a 2 button system will be necessary. How will you fly with the rocket pack and shoot at the same time? Or will that ultimately be necessary ...

PS: If you jump/fall down a hole to a lower level, again much like ALttP did, after the upper level fades to black, the new level will fade in as you land with your jetpack, regardless if you had it equipped or not. So I guess I can't put any holes until after the jetpack dungeon if that goes through.

Start asking questions about the plot so I can find holes to fill.

So what it appears we are looking at for art direction (to which graphics will come second) are:

1. Overworld
- contains several types of basic alien-type planetary terrains
- exteriors of the temp colony (how big to scale?)
- interiors of the temp colony
2. Wrecked Human Space Ship (interior and exterior)
3. Dungeon 1: ruins of the original Human city.
4. Dungeon 2: rocks, underground pebble laden world
5. Dungeon 3: underground alien race, simple, minimalist designs and shiny stuff.

... ?

Most importantly, how big is the colony and how big is the space ship?

That struck me as automatic like the ladder in the original legend of zelda.

What wrecked human space ship? I missed that bit ....

Overworld is mostly rock. Sandy ground, rocky mountain "walls", loose rocks here and there, maybe minor plants and moss. The tileset will include the colony exterior and some sort of outer dome/wall on the original city (if I had not made it clear, it was covered). For some reason I'm seeing this in purple. Yeah, purple rocks, you heard me.

The colony will be fairly white and drab as far as walls and floor go, and lots of research equipment that's a bit of a clash in tone. Rememeber, the building is just some general-purpose prefab thing they threw together. It looks like a hospital designed by a science engineer and is somewhat sterile looking. The actual equipment, vehicles, tables and chairs, etc. should look much less clean, gritty, "real".

Dungeon 1 will be a futuristic city. We'll be cribbing heavily from Mega-man style of textures, I imagine. Lots of wreckage though, no shiny. Since we're in a power plant, there will be a lot of computer equipment in various degrees of "working". I'm seeing offwhite and blue in my head.

Dungeon 2 art will be mostly rock, reddish-brown. There will be some tiles on load from Dungeon 3 since they discovered alien ruins; old city I guess. But of course the tiles will be cracked, dusty, rusty, etc. Also, the mine will have all the trappings of a mine, with areas for scanning, equipment, etc.

Dungeon 3 will be lots of shiny. Flat surfaces and techno-stylized lining. I imagine more heavy cribbing from Mega-man, though very unlike Dungeon 1. It looks like it was made from sheets of cut emerald.

The final dungeon ... well, imagine every starship ever. Lots of whites/grays/blacks and blinky lights. Think Death Star.

Scale-wise, everything should be (roughly) as it is on the map I drew. Because of the way the player changes room when he goes through doors, we can lie a bit about the size anyway (see my "screenshots"). The colony won't be terribly big since it won't be serving as first or last dungeon as I thought it might. But all dungeons, command ship included, will be roughly the size they are in Zelda, probably a bit smaller.

Hmmm, so anytime he steps over a hole, he's flying? And if there's floor below, he auto-hovers down? I guess that works, but I'd rather my idea. I was thinking of flying like in Cave Story or Little Nemo, where you can take off and fly for five seconds before you have to touch down again (like the gun, the meter builds up quickly when not in use). I was thinking of a boss or other obstacle where you have to use the pack to avoid some kind of ground attack; that wouldn't work so well if it's a passive ability. I need to finalize the items and gameplay, I'm sure the coders would like that info as quickly as possible.

Oh I meant broken human vehicle.

Ok, your idea for the hover-mechanism is better. I'm assuming it's a button-press trigger that sets it off for 5 seconds, as opposed to holding the button for 5 seconds? I think that would make the gameplay more interesting.

What I meant by scale... I've attached the map with a Link sprite. Which size did you have in mind?

Obligatory Redundant Link to the Monday Game Progress Summary Document Webpage Area or ORLMGPSDWA for short.

Either your "favorite", or a touch smaller. Subject to change based on final colony layout.

Either or. That's just a detail.

It'll be roughly the same graphics style/tiles as the colony equipment. It's not like they only have one vehicle.

ah, ok. gotcha. Like a Magitek suit... but bigger. I wasn't sure if it was like, a small room or something you walk in.

I discovered some flaws in my menu class and decided to fix it before moving on.
I also made a fake main menu and added a ttf font.

As for the base object class. What features should that have? How do you want to use it?

I forgot to mention: assuming the link sprite and everything is upscaled proportionally to 32x32 instead of 16x16, correct?

What kind of berry is he?

You know what, Just PM me if you want SVN access. I'll use the name that you're using when I get your PM (Removing space, and replacing non-ascii character (if any) with their acsii versions). Note, you only need access for writing only!

I have acquired svn rights and committed the stuff.
So now everyone can checkout, check it out and feel good about themselves.

Just so we're clear:

If someone submits code, it is subject to review, modification, removal, or complete overhaul. Since the Leaders need to have final say, no one should feel bad if their contribution(s) get tweaked or obliterated.

The game is going to be evolving, so if there are things that just aren't needed, don't fit, cause crashes, or has bad formatting, I'm in favor of the Leaders to be able to have the Final Say^TM in the matter.

All in favor? All opposed?

Vote for despotism?

The best despots seize power on their own initiative. Objections and rebellions will result in a truckful of soldiers at your house in the middle of the night

While I agree that code submitted is subject to those things, and the leaders should get the final say, I think the best approach is to communicate before committing something to the repository (and preferably before developing something in the first place) so there's no need to throw away somebody's hard work (I'm pretty sure the Subversion documentation recommends this approach as well). There should be no need for people to waste their time here. Let's make it clear who is doing what how so it isn't a matter of two or three dominant members overwriting the project while the others see their efforts gradually filtered out.

Ideally, nothing should be "overhauled" without the project deliberating over it first and preferably coming to an agreement (or if need be, the leaders having the final say). It's normal for a project's design to evolve. It's not normal for a project's team to develop abstract concepts individually without guidance and attempt to mesh them all together in the end.

Have to be careful though. Some people get attached to how they do things, and change things just for the sake of changing them, and will get into a commit war with others...

But otherwise, that is how opensource tends to work.

Oh, I totally agree. However, if the Leaders only want to give vague "it needs to do this..." descriptions, it leaves the programmers free to implement it as they know how to do so best.

But if the implementation is missing features (like having a lot of empty framework stub functions), I feel that the Leaders should be able to go in and tweak the calls: map.get_tilemap(0); may be changed to be map.get_tilemap();

If the "leaders" feel something needs to do something and they don't really need to wait, they can just go change it. I can't see myself doing something like that, but part of the idea is this is a group project anyone can contribute to, right? Surely that includes the lead programmer.

I don't like the idea of my work being thrown out or altered beyond recognition but I suppose that's an inherent danger of coding. I've thrown out my own work plenty of times so it should be no shock. We'll still acknowledge any meaningful contribution.

Just so we're clear; lead programmer is officially Trezker? I just need to know who to poke with a stick should the need arise ...

Yes. And since it's been finally officially pointed out, fix my name.

Well by that logic anybody can just go change it. I think anything that could be seen as an alteration warrants a discussion, or at the very least, some attempt for discussion. If those attempts fail and somebody is confident that their change is valid, I see no reason why they shouldn't press on (it can usually be undone should the need arise), but they should make it clear in the revision log why they made said changes and what their justifications were. This way at least, when I come back and see a void where my hard work once stood I can be reassured that it was done for a good reason and not some political or religious reason. The point is, nobody likes to be neglected or mistreated so do unto others applies, basically.

Well the Subversion repository should keep a history of the codebase at every revision, meaning that unless something happens to the repository, it will be possible to recover your (committed) work if you or somebody else erroneously obliterates it. It's one of the many benefits of using version control software. However, that doesn't mean that recovering it will necessarily be effortless and it does pave the way for other problems (i.e. as Thomas suggested, commit wars, being one of them).

I have a question on "preferred uploading practices":

I would like to propose that, when we check in our code submissions/changes, that they are all done at the same time (in a single commit).

This way, if anyone were to try to do a checkout while someone is committing, they won't get partial code as the other programmers are submitting the files individually (it takes time to write the "what was changed, and why" comments!).

So when I commit 4 different files, the commit comment would look like:

// All these are in a SINGLE entry when all the specified files are checked in at the same time:

Animation.cpp: changed how foo() was implemented.

Animator.cpp/.h: Updated to tie into changes made to Animation.cpp

Menu.cpp: Updated bar() to be able to use changes to Animator class (Animator.cpp/.h).
Added new foo2() function as private member to simply checks for changes to bar2();

Vector.cpp: Changed blah() and barf() to use the new barf() format.

Will this work for everyone else?

Bad idea in general, but I take it you mean that if the addition of one feature requires the modification of more than one file, then those modified files should be committed together. That is a good idea.
It is usually a bad idea to have big commits that change ten different things at the same time and add three new files.

Anyway, if you'll take some advice, discuss (major) changes in the code before you commit them.

Certainly. IMO, code shouldn't be submitted to the repository until it's working or at least has no effect on the compilation or execution of the project. If somebody is working on something large that will take a while to complete and they want to "backup" their code in the repository, I believe that is what branching and merging is for.

Good revision.

Indeed, and I still feel guilty over my last few large commits in branches/4.9-fshook. Specially that last merge. Yeesh. Took for absolute ever for svn to do the merge, then some more "ever" to commit it to the repo.

Yes, make branches if needed.

Though why everything is currently in a folder called monday... that I'm not so sure of. (Plus the svn path for it..., and the directory structure if someone just checks out trunk into a folder called monday.)

Changes (meaning commits that alter the future path of development) should be discussed here or wherever; if you are working on a change and want to save it to the repo, make a branch. Contributions, meaning advancements in the path of development that don't change it except for moving farther along, need not be. Bug fixes especially not.

EDIT: Also, make sure what you commit to the main repository compiles and doesn't make anything else unusable.

Just too lazy to switch to Notepad

OK, who's gonna fix this?

** EDIT **

Assuming trunk/monday is redundant, I have a working copy ready to commit that should fix it, if nobody else has bothered to do this yet... Is that what we want to do or is it there for a reason?

The question becomes, if something happens with the path, should it be renamed (so that any tools can have their own directory?) or just moved to trunk and the extra monday is 'lost'?

What path? What's gonna happen to the path? IMO, we should move the project into trunk and get rid of trunk/monday. Tools can just be nested in subdirectories; or, if you're feeling generous, afforded their own repository.

They are not going to get their own repository!

Anyway, I'm moving the everything to trunk.

IIRC, it's in monday/trunk/monday. We should get rid of one of the Mondays. It's general SVN practice to say trunk/monday, but it's not really important.

Depends on how you setup the repos. Some projects have more than one "part" and they only give them selves a single repo, like kde, so they have trunk/blah, but all of my projects each get a separate repo, so its just project/trunk, instead of project/trunk/part.

OK.

Now it looks like I have to learn Scons. sigh...

Really, I think it's a better idea to use make, because it's more universal and fits in with the autoconf system, which is even more universal.

Ok, I'm a bit lost.

Is this a multiple team competition for the allegro.cc community? Or is this just a single game that the allegro.cc community is collaborating on?

Either way, count me in for sound design.

It's a single game.

>> Neil Black: It's a single game.

Aww. I was kind hoping for a group competition. Maybe next time. Oh well.

Offer still stands. If you lads need help with the audio, just let me know.

You can try to form a group. Maybe some competition will get us moving.

I am arbitrarily defining a group to be at least four people.

Audio is currently filed under "pray for this", so yes, we will.

Too late, I'm stealing him for my own group.

I can do audio but I'd prefer to work on the art direction for this one. decepto, if you want to do audio I'd be thrilled.

No problem.

Are we going to be sumbitting this project to any competition? Or is it just for kicks?

The goal here is simple accomplishment: group projects are a running joke around here and it would be nice to set a precedent that, yes, they can be done. If we can get a finished product in reasonable time, maybe more people will make more honest stabs at this, and we can actually make games faster by splitting up the work. Anything beyond that is gravy, or an afterthought imho.

Reasonable time being the operative word. This was supposed to last a week.

Well cool!

Like I said, anything dealing with audio, and I'm your man. Everything from small special effects all the way up to 15 minute+ music scores. My home is more or less a shrine to Bob Moog, so I have all the equipment needed.

Also, I'm pretty efficient with AI algorithms. If you run into any algorithmic or combinatorial problems, let me know. I also have several dedicated servers in case we want to set up Git or SVN. Just let me know. Here's my email:

nacarlson {{{{a___t}}}} gmail ((((Dooo-dodododod--dot}}}}} com

That'll get teh bots!

edit: Sorry, my ambien kicked in, and I'm not very coherent. Talk to yall in the morning.

I need some communication from the coding team as to what they're waiting for. What needs to be done before you can just start matching people up with hpp/cpp files and tell them what needs doing? Has Lua been linked? Have interfaces been written for Lua so we can move people around and trigger dialogues? Can we display a tilemap? Do we have a game loop running to call logic, do collision detection, etc. even if the functions the loop is calling are mostly empty right now? Tell me what you'll need and I'll get it.

This was never going to get done in a week. People are still talking about how to coordinate the code uploading. But on the upside, if you guys can work out a good agreeable system that works, we'll have a process set up that everyone else can just reference if they want to do this. And then we can cut like a week off future group projects, which is part of the point ...

I tried that email, but it caused a compile-time error. I think it was either the unclosed parenthesis, or the extra closing braces.

Just be happy I didn't write it encoded in brainfuck.

Or White space.

I just googled some lua in C++ and found this little gem.
http://www.bigbucketblog.com/2006/03/02/lua-and-c/

I think it looks very simple and good, maybe thanks to this I can finally learn lua. Does any lua experts have complaints to file against anything on that page?

I've been working on tiles and want to know about translucency. Since we're in the modern age, using a5 hardware accelerated and only running at 640x480, would it be ok to use png tiles that include an alpha channel?

I'd say yes. Alpha is ok. Unless people decide the graphical style should not include it.

I have added lua to the project. I've only bound a method to change the player position to test. It's checked in to svn.

I'll record vocal stuff. Just tell me what sounds are needed and I'll see what I can do.

revision += 4;

A week isn't reasonable time, ffs... No wonder projects here fail.

We should probably identify and document hpp/cpp files... And from there, identify and document modules, inputs, outputs, etc... The whole damn thing should be documented before people can go off and do it. Otherwise, we won't be using everybody as efficiently as we might. We'll just have those people that have done it before hacking it all up and throwing it in the repository...

You're the leader...

Really ?

{"name":"596416","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/1\/8\/18b77e340d176a3a301628dedc98a84a.png","w":802,"h":530,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/1\/8\/18b77e340d176a3a301628dedc98a84a"}
Here's a rough stab at the purlpe-hue Overwolrd. This is just a non-screensize tile taste. I'm just throwing this out there for feedback, but (1) there will be more rocks and (2) the stone stuff will be textured.

The shot shows the basic terrain, color, a few variations in the terrain type, grassie stuff (not frequent in the map) waterie stuff (also not frequent), some alien plant life (my favorite ), a locked door (the kind that goes to one of those random hole-in-the-wall), and two items at the top left, a key and a data chip with drop-shadows.

Don't stare too long, it gets crappier the longer you look at it

That looks nice. Do you have tiles for those? If not, you should make them. I like the alien plant life.

no tiles yet, but they're all lined up to a 32x32 grid and extracting tiles is relatively easy. You're looking at a tile-size accurate render (scaled 2x for beautification), though the screen will be wider and taller.

class Tilemap
  void Load(std::string filename);
  bool Collision( ? );
  void Render();

How precise collision? Fill in that ? with what we need.

If we will have layer(s) below stuff and layer(s) above stuff maybe have two calls to render these separately. I don't suppose we'll be using a zbuffer...

Any other considerations? Let's iron out what features the interface needs.
Then decide who will implement the tilemap.

I'm considering handling items outside the tilemap, so items doesn't have to be aligned with the map grid. Then they'll have their own manager in which we could implement a quadtree if that's necessary.

class Item_manager
  Load(std::string filename);
  Clear(); //Remove all items before loading another map
  Render();
  Item* Pick_up(Vector position); //If an item is found close enough to the player
  void Drop(Vector position);

Anything else for items?

I'd like that. I think it would be easier to do that than trying to work items in with the tile map.

No Z buffer I don't think, just draw each layer back to front.

My thoughts are that we should have an enum for the type of collision-precision we want, then call that one as needed:

typedef enum _collisions
{
   PIXEL_PERFECT,
   BOUNDING_RECTANGLE,
   BOUNDING_CIRCLE,
   // ...
} COLLISIONS;

Then we can write all the collision routines once, and choose later which one to use (we may want to use all of them at some point...).

EDIT:

The ONLY reason I was thinking about this is for use with parallax. If you have a z-buffer set really high (or really low), then when you show that on the screen, it better simulates height (like overlooking cliffs, walking under tree limbs, etc.).

It's not necessary, and can be removed because, like was pointed out, we just need to draw in the order of layers (bottom-to-top).

The only way I've ever handled items in a game, it works by having an obj_map[][] that contains the object map in the grid, that's used to find things, but you can put the objects wherever and obj_map is automatically updated when it moves.

Yes, and? I go to my team leader when I need something all the the time; if something is a hindrance to production I want to know about it.

Actually that's really nice! Original art by you? Good job. The ground texture and the grass are excellent imo, the striped plants are good, I wasn't really picturing any water in this area but it doesn't look bad. The buildings look more like rock than metal and a bit beat up but even as it is it's pretty close or better to what I pictured the overworld as being like. Just need to worry about rocky tiles now, the colony tiles can wait a bit until we figure out how they're going to look, unless you want to take a stab at designing that too.

I didn't even know Allegro 5 was usable yet ...

Tilemap collision will be strictly binary so far; the settings we have in mind imply a lot of right angles and I don't see much need for sloped tiles. If someone wants to implement them I'll use them but not real necessary. And yeah, draw bottom-to-top, no need for a z-buffer.

Um... top-to-bottom or bottom-to-top?

Sorry; more noobness on my part. Wasn't thinking.

I suggest using bounding rectangle collision.

Maybe bool Collision(Rect brect, Vector velocity, Vector &adjust);

Then the function could provide an adjustment vector that would move the brect onto free ground.

You've basically told us to git'r'dun without documenting what 'r is. Where's the leadership? You should be telling people what they're doing, IMO. And you can't do that until you know what needs to be done and what people are capable of. That's my opinion anyway. I'm not just gonna start adding code to the repository unless asked to do something because it probably won't fit into what the others are working on. I suspect there are others among us that feel the same, but maybe I'm wrong.

So are we saying that we're doing more of a free-flowing movement style, or a "I'm on this tile, I want to go down to THAT tile..." approach?

If we did the tile-to-tile movement, we really don't need much in the way of collision detection for player movement. "if (is_occupied(map[...]) {...}"

But if we do more of a free-flowing movement (especially for shooting things with the mouse), it would be more "if (is_in_line_of_fire(object[...]) {...}"

I have been telling people what to do and "git'r'dun". If something is getting in the way of that, the leader needs to know. This is a two-way street here. I agree the programming team doesn't have all the details yet but if they need to know something in particular they need to ask. Right now they have enough to start and if they're waiting on me for something in particular, I need to know it so I can keep them informed.

Free-flowing, like the typical Zelda games. This is an action game; movement is pixel-based, not tile-based.

Hmm, line of fire might be needed too with these high tech weapons and all. Good call there.

Well, I'm imagining characters moving freely and have a bit smaller bounding box than tiles. So when going through a one tile thin alley you can still jiggle a little. And maybe we could have "monsters" that are too big to go pass through some places, or just a fat NPC.

Yes, you'll have to worry about line of fire especially if we're shooting with the mouse. Lots of funny angles to fire at ...

Well who is working on what? And what isn't getting worked on that I'm capable of?

I second that question.

I as lead programmer is being lazy.. But I have done some stuff and is thinking of what to do next and who to delegate stuff to.

Maybe time for some nominations.

OnlineCop for tilemap coding?

bamccaig, are you capable of making an item manager?

That depends on what an item manager is in this context. I'm going to assume I can probably figure it out, but I'm going to need some details to do so.

The item manager manages Items that are on the ground.
A little info was posted here: http://www.allegro.cc/forums/thread/597566/770566#target

Basically you can add items at given locations and pick stuff up.
The Item class itself hasn't been designed clearly yet, but from the managers point of view it just needs a few functions I think.
Item::Render()
Vector Item::Get_position();
Item::Set_position(Vector position);

I don't think it needs to interact with the map, just assume things can be put where it's asked.

Yeah, I should be able to handle that... I don't get off work for another 4 hours though.

Will somebody please think of the children!

Right, the children. Their bounding rect should be so small they can pass by each other in a one tile wide passage.

What all do we need to implement tilemap coding?

Map:

• layers (std::vector to include # of layers and actual pointer TO the layers)

• # of tiles high and wide

• layer identity (0 = normal tiles, 1 = obstacle layer, 2 = shadow layer, etc.)

Does this look right? I don't want to start coding unless I'm on the right track.

People were talking earlier about some line_of_fire() code? I have some vector code that could be useful. All in C, but it's there.

C is fine (it's REALLY easy to import it into a C++ file, so it's not really like there would be that much heartbreak over the code...)

[bamccaig@rufus trunk]$ ./monday
./monday: error while loading shared libraries: liballeg-4.9.5.so: cannot open
shared object file: No such file or directory
[bamccaig@rufus trunk]$ 

** EDIT **

Fixed. I had to add the installation path (/usr/local/lib) to /etc/ld.so.conf and then run /sbin/ldconfig.

I usually spare myself the trouble (even if debian does include /usr/local/lib by default), and just set the install prefix to /usr for allegro.

mkdir build; cd build; cmake -DCMAKE_INSTALL_PREFIX ..

Or some such (I usualy use ccmake .. instead, which lets me set all of the cmake vars).

Anyway, I need more details before I can write said item manager... I'm still not sure what it is. Is it just going to be a container of sorts for inventory items (i.e. weapons, items) located somewhere on the map, detailing where they are so the engine can render them?

Hey bam, essentially, you'll need to create a class which holds a bunch of items on the screen at whatever their coordinates. basic example:

everything ultimately managed by item_manager.update() in the main loop

Items could have a bouncy thing or... ya'know whatever have fun be creative

For bamccaig. Let's keep it basic for starters. All we need right now is the ability to add items at positions, remove items at positions and render all of them.

class Item
{
   void Render(Vector position); // position provided by whatever is holding the item, just draw a circle or smth for now
};

class Item_manager
{
   std::vector< std::pair<Vector, Item*> > items;

   void Add(Item* i, Vector position) // add an item to the list
   void Render() // draws all the items
   Item* Remove(Vector position) //returns an item if one is found near position
};

[EDIT] Scratch bamccaig from the contributtors list, I did it myself
We chatted a bit on irc and agreed that I might as well code this myself, as you can see it wasn't much work really. We were just wasting time arguing over design.
Maybe we can find something for him later, some advanced function maybe pops up in the tilemap department.

Yeah, without a design in place I don't really see a part for me in this project... I don't like the idea of everybody designing as they go and hacking it together later (I'm stuck doing that all day at j0rb and hate it). As many of you know I'm a little OCD sometimes and really don't like hacking things up unnecessarily. As was demonstrated with the item manager, rather than putting me to use I'm being assigned trivial problems and, to add insult to injury, refused a detailed explanation of what those problems are. I can't solve a problem if I don't know what that problem is. It's just going to slow this project down in the long run so I might as well step aside. I'd still like to help out if something comes up that I would be well suited to, but there's no sense in the project making sacrifices to make room for me. It's a waste of my time and yours.

I would like to request permission to use IP from this project on a sister/branch project so that I can still sort of participate without holding this one up. Does anybody object to me using art, sound, story, etc., from this project or have any terms in mind (I would certainly open source anything of mine)? More precisely, does anybody (everybody?) give me permission to use the IP from this project for a sister/branch project?

OnlineCop: As you can see items are handled outside of the map.

So, no "stuff" on the map, just tilemap layers. As for what layers we need there has been mentions of shadows and parralax and stuff.
So make it easy to add new layers, but start off with the old basic ground we walk on and collision.

Sometimes? Seriously, its something you might want to look at improving.

I get a little Obsessive my self, and tend to way over plan/engineer stuff, and its something I've been working hard to fix. I think the current progress everyone is making is a huge improvement over past efforts.

shall I write up the item code then, Trez? Is it ok if I go with my model from the inside? I've never used std::pair but I think a little simple function could get whatever data is necessary.

Obligatory Redundant Link to the Monday Game Progress Summary Document Webpage Area or ORLMGPSDWA for short.

As long as you get the general api right, it doesn't matter how you implement the functionality (so long as it works), that can always be replaced later if needed.

Hey bam don't be discouraged, it's less technically cumbersome than you might think! Put your OCD aside and pretend you're Captain Kirk.

Yeah, I can't think of anything better than just getting in there and doing something.

Just got home, lots of posting. Apologies to those who feel discouraged for lack of design and info, much appreciation to those who "get it" and are making progress. Admittedly, I don't know much about the code delegation and progress since I'd like Trezker to handle that (don't do all the writing yourself, buddy ). When there's something compilable and playable let me know; I want to check it out.

I did some long hard thinking at work today about the items this game will use besides the jetpack and rock crusher. I'm going to write up another detailed text doc and attach it presently. It'll have some details besides just "this weapon does that" so this will be vital info for the coding team moving forward.

Can we get a post devoted to what exactly has been done so far, code-wise? Do all the major classes have at least a declaration? Does someone have a basic idea how game objects will be managed, rendered correctly, etc? Is Lua in the pot?

This is actually probably worth bringing up. Anyone care to propose a license for this thing? People will get individual credit for work done so as long as credit is given to this game (which will have well-documented individual credits) I'm down ...

I believe LUA is in.

For the license I'd say everything's fair game, just don't sell it.

You can has poorly formatted weapons doc! I may have forgotten some things, possibly like the plot doc (I would still like someone to poke holes in that so I can consciously fill them). Ask questions!

Awesome; I missed that. Thanks.

We have lua, can position the player but nothing else yet.
I have coded the item manager, but item itself needs proper rendering and script functions.

I have written a Code_todo and it's in svn.
http://svn.miquelfire.com/monday/trunk/Code_todo.txt

There's quite a bit of question marks in it that 23 needs to take a look at.
Anyone wanting to code should take a look and see what they can do, ask questions that break my illusions etc...

Well right off the bat, there will be no "drop item". There won't be much "move to" in the AI but if someone can do some simple A*, maybe we can give it to the odd abnormally-intelligent enemy. "Use item" will be a straight mouse click. If I click with the gun equipped, I fire in the direction of the cursor. Interacting with level objects like consoles will be a key press (Ctrl or Space or something). No on-screen buttons for that. Info about items will be if you have it highlighted with your cursor on the Inventory screen; there can be some text in a lower window with items in the upper window. Equipping an item from inventory will be just a click; right click to bind to right mouse button, left to bind to left. Graphics should pretty much all be animations, not still bitmaps. Renders ... I'd like to get away with 4 directions for everything, but my gut is telling me it'll end up being 8.

can I get a list of regular items like health, big_health, heart_container, ammo, etc?

how bout for simplicity sake you just walk up to it and it works, if you need a key then "You need the red key" pops up. Can this work?

Ammunition is a non-concern; everything is energy based on purpose. Health will be restored fully when you kill (most) bosses or minibosses. There will be the odd strategically placed med kits which will probably come in small and large varieties. So the challenge will be surviving from save point to save point with the health provided. Dungeon trash enemies will not "drop" anything.

I was thinking of adding a lot of flavour-text to this system (examine stuff, read colony documents, etc), but we can drop that and just go with this system. If the dungeons are designed so the player is unlikely to accidentally trigger a script because he's fighting enemies and brushing the wrong wall 20 times, it could definitely work. I was honestly thinking the extra button might be a bit clumsy with the other controls required, so that would actually solve a design flaw ... I can get behind it.

exactly, that's the reason I mentioned it.

maybe like a floaty blinky aarow that shows "put key here" icon, I dunno.

We could also have a universal "click here" icon over terminals and stuff, so when you click it, the game checks if you're standing in the right spot and facing the right way, and if so runs the appointed script. Or some other telltale sign that tells the player "come here I have candy". I leave that up to popular vote to decide.

No comments on proposed weapons yet?

Ok, I have updated the todo list with the new info given.
I also added some more stuff I thought of.

So you can go through it again.
http://svn.miquelfire.com/monday/trunk/Code_todo.txt

Now I think it would be useful with a diff viewer online. Then it'd be easy to see what I just changed in the todo.

Looks okay from here as I skim it; I'm not sure how much you want to do with scripts as opposed to hardcoding so I guess some depends on that. I'm going to draw up some more crappy screenshots between today and tomorrow.

EDIT: I forgot an idea. One thing I always liked about some games is how they throw you into a "minigame" sometimes to progress the story. Twilight Princess does this on several occasions; flying that giant bird to hunt those light beetles, snowboarding, etc. The old Battletoads game did it every other level. Monday leaves the base to pursue the bad guys to the capital ship to kick off Dungeon 4; can you find room in the engine for a quick shooter level in there? It'll be fairly quick, over in two minutes, and not be terribly unlike the Allegro Demo where you shoot rocks. In fact, that will basically be it. You can steal my code from the third STL tutorial for Pixelate if you want, I don't care. But I feel it will be good for the game to go that extra mile just to keep the player interested. Just a thought.

Jet pack sounds cool and so does the rock crusher. I like their refiningness.

the scanner is a good idea too, does it have two functions?
(1) in a lit room will show a hidden enemy within cursor radius?
(2) in a non-lit room will light up within cursor radius?

and I like the other items, too and their upgrades. I'll design some sprites for them.

This is cool, it looks like there'll be a lot of room for variety in the gameplay, more than I had figured.

could you... uh... hold off on that for a couple days? I'm still working on tiles and they're starting to look pretty sweet. Here's a wip door:
http://www.allegro.cc/files/attachment/596443
(next to an upscaled chrono trigger sprite to see proportions and perspective, which are a little off)

I want to get working on those item sprites first.

And in a non-lit room with hidden switches/enemies it does both (although I guess hidden enemies in an unlit room is kinda redundant). Also, it's the only "weapon" that doesn't require clicking.

My screenshots will only concern screen layout for things like dialogue boxes and inventory. It didn't occur to me there might be confusion there; I need to spell out more for the coders and stop assuming they can read my mind.

Any other concept art I have in mind is for things like weapons and vehicles. You can have full reign on tile art IMO since I like what you've done so far. Though I've got ideas of my own for all the graphics too (graphics guy that I am), I need to learn to let go of some control and delegate.

rock.

please tell or show, we could bounce visual ideas. For the items I was thinking white plated like in portal. Each item would have a different shape and lights or whatever but I think the ipod thing is, like, totally in.

Minigames is noted. Though I think we'll keep that on the wish list until we have the basics done.

So, waiting for programmer volunteers to step forward. I'd like to see some people who can work without too much help from me.

If the host needs help with setting that up I'd be happy to help (or do it). I've setup SVN::Web several times now on my own server. Its real pretty.

Yea, help is needed on that front.

Eventually, I'll set up a mailing list, just need to find out where the e-mail will be coming from and add it to the list, then give out the URL for subscribing to it. (I been too busy to even look at it much more since Sunday)

Sorry for not following the general forum common-sense ethics, but... I didn't read any of the 19 pages.

Is what my eyes tell me true? A Monday project on a.cc is working out? This is just so impressive I'll offer my help as well (well, not because it's impressive, I always like to help).

If someone sums up the whole story behind this thread so far to me, you can count me in for music

Obligatory Redundant Link to the Monday Game Progress Summary Document Webpage Area or ORLMGPSDWA for short.

Let my contribution to the project be this: WASD would be a much better default arrangement.

Thanks a lot! As I said, you can count me in for music.
I'll try to keep track of this thread from now on.

I have been coding on a character class and ran into a lua problem.
I can't figure out how to call lua functions from C++.
It says "attempt to call nil value" so I guess it doesn't find the Test function in the script but I don't understand why.

I load a script that looks like this

function Test ()
  player = Get_player()
  Player_set_position(player, 100, 200)
end

And try to call it.

  lua_State* L = game->Get_lua_state();
  lua_getglobal(L, "Test");
  int errors = lua_pcall(L, 0, 0, 0);

  if (errors)
  {
    std::cout << lua_tostring(L, -1) << std::endl;
  }

I think it adds to the interactivity of the game to make the user do it himself; it feels less like he's watching and more like he's doing. I don't think it's clumsy, though it may require testing to determine each trigger's dimensions. You might also take Square's approach by displaying a (!) icon when the user gets close to an interactive object (and perhaps add some easter eggs that don't display the icon). I generally hate when things like that happen automatically on me. I'm imagining walking by a terminal and suddenly the game mode changes.

To add to the complexity/difficulty you could implement a battery for all of the electronic equipment. This way, when the user wants to use the scanner he does have to click, thereby deciding to use the battery. This adds to the complexity and makes it seem more real (infinite anything is boring) and also makes dark rooms or hidden enemies more overwhelming. Something to consider, at least. There could either be replacement batteries located at strategic places on the map or recharge stations or something.

Seconded. I can't believe I missed ASDF... WTF is that!?

(I haven't had a chance to read the plot or TODOs yet so I'm basing this off of the thread)

Everything in the code you provided looks alright. I'd guess that the error here is that the script doesn't actually load properly for some reason - Lua cannot find the function in the global index.

No the file loaded properly. The problem was that I had execute the script to make the functions global names.

Took me this whole damn day to find that information. I think this is exactly what kept me from learning lua every other time I tried.

Well yeah, the documentation for Lua is not very organised or complete. It's also a rahter annoying language - I always wondered why it was always considered first choice among game developers for scripting.

Still, I don't want to derail this thread, considering that you are making progress regardless of the Allegro Monday curse. I don't have much time nowadays, so I can't really help myself - but I'm cheering from the sidelines. Keep it up .

On the topic of a code license, I would recommend the MIT license, because it is less controversial than the GPL, and also shorter. If people want to modify it to preclude selling the game, then that's also doable.

Now there just two difficulties left in my lua checklist. Matt is doing some menu stuff that may contain more hindrances though...

Now we can do one off script calls. Just call script, it does stuff and that's it, all good.
But for something like NPC movement, the script can't say Character_move_to(x, y) wait until it arrives the do something else. The game needs to keep running. For this I'm thinking to call the script every time Update is called on character in the engine. So the script has to maintain a state for the character.

Then there's the case where the object that triggers a script just starts it but doesn't maintain it. For instance a trigger that starts a series of stuff moving around. Then I'm thinking to register the script function to a list of functions that are updated every frame and removed when they return a completion value (true or false).

If any lua experts read this, please inform me of any fatal flaws in my plan.

Next commit should send an e-mail to a mailing list now. Sign up here.

[edit] Oh yes, I added a webview as well.

Mark, update the site!

K I think everything is up to date.

Obligatory Redundant Link to the Monday Game Progress Summary Document Webpage Area or ORLMGPSDWA for short.

And you crossed out the first two links why? They're still valid.

I guess you didn't need my help then

May I recommend Jottit.com? It's like a wiki in a way, but better. http://jottit.com/gnn3h/

The password is allegro. There's also a history. So if anyone vandalizes it, we can just revert back. Or, we can pick a different password and just email it to everyone.

Btw, please email me on the music requirements.

Their site appears down to me.

I have opened an irc channel, #allegro-monday. In case people feel like some more intense discussion is needed.

I also wrote a Lua_wrapper, so far it basically just inits, deinits and load/run scripts. I don't know if it needs any more, but if it does the base is in place.

The mailing list is pretty cool (first one I've ever joined). It's nice to get a changelog in the mail like that. I only wish it would specify a mono-spaced font. Is that doable, MiquelFire?

Sorry, I don't know if I can make it monospace font or not. I think it's up to the mail client to handle that.

Seconded.

Maybe I can stop posting my progress here whenever I solve a problem, it's gonna be read by the subscribers anyway.

I'm waiting for other programmers to come with contributions, whether they take initiative and code something or suggestions for how I can make it more likely for them to contribute...

Then I would like to hear from OnlineCop again. I'm wondering if he started working on the tilemap or what's going on.

Mattymatt is talking about menu coding and lua debug window and stuff like that. But I don't see any activity from him in svn... He also mentioned something about a camera...

What can i do? Give me a list of stuff that needs to be implamented and ill knock them out.

Group, can we trust piccolo?

Anyway, here's the todo list, not entirely up to date though since I forgot to update it along with my latest progress.
http://svn.miquelfire.com/svnview/wsvn/monday/trunk/Code_todo.txt

There should be no harm letting him contribute. I think it should go without saying that the code (identifiers, comments, etc.) should be in English though, which he might have problems with. If he does any damage you can always undo what he did with Subversion and restrict his write access. I'm kind of curious about what he's capable of, myself.

:-X:-X

piccolo just needs to copy a few lines form his game and he's got Monday right there.

Ooh, ooh ooh, can I say something about those items? I was also thinking about a scanner ! And since the Rockbreaker can scan "frequencies" itself, it should be fed "algorithms" or something. Maybe you would first need a "rock sample" that you scan in your computer (do you have a base?). Or even better with the scanner: because I freaking hate it when a computer character says: "I can't do it" and I'm thinking : "I could do this!". So the dark room would be replaced by a new type of (unbreakable) rock (and it fits in the current scheme). And I'm thinking you're making it too complex with all those "3D" weapons like grenades and jetpack.
I also hate it when I'm prompted to do something I'm forced to do anyway (with the buttons).
And do I see: rockbreaker + jetpack = Jetpac mini-game?(Or was that already mentioned?)
Oh, perhaps you could give some arguments/return values for anyone to make a mini-game?
And do you actually want raving (enthusiastic) loonies in this thread?:-X

Yea... I'm just a little fuzzy on what I need to do for this

As far as tiles for the tilemap, I'm out of my league trying to draw them. However, if you mean the maps, I can start working on that soon (school and homework allowing).

For maps, this is what I imagine we need:

Maps:
	Multiple Layers
		# tiles: Need to know height and width of layer (in tiles)
		DRAW_LAYER flag: Some layers may not need to be drawn (like a collision layer)
	Tilemaps
		BITMAP resource of tileset
		Dimensions of the tiles: As discussed, this SHOULD be 16x16, but I
		   don't want to hard-code those values in unless we really need to
		Tile animation sequences: Need to know which tiles should animate
		   (and the timing)
	Entities
		Current (absolute) position: need to know where they are in x/y coordinates
		From and To tile positions: need to know what tile the Entity is
		   on, and where they are trying to move to

"Entities" will be the base class for the Player, NPCs, enemies, etc. All I really need from them is their on-map coordinates, their current animation frame, and their BITMAP.

Is this all we need so far for the maps?

Deja-vu.

I thought we had agreed on 32x32.

Oops.

Exactly why I wanted to ask

Has anyone successfully compiled the repository code? I finally got Allegro 5 installed, had to include a missing header file in Character_manager.cpp, then when I run the exe it says

./monday: /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.9' not found (required by ./monday)

Anyone have any help? I've Googled, but no solutions suggested there seem applicable.

I hope you mean code there.

Tile graphics are being done by Mark Oates, since he took initiative and is doing a fine job. The maps themselves will be done by me; I'm doing level layouts as part of design anyway so I might as well do both, and I'm already letting Mark know what he'll need to do in general terms on maps. In the time it takes to communicate the general layout of what I'd like to see, I can just draw it anyway. Plus my tilemap editor kicks ass. So leave that to us. We need code laid down for map loading/drawing/scripting/collisions/transitions ... animations?

I'm currently in the process of drawing up sketches of items since Mark wanted to start on those and I had some ideas (Mark, between this and the tiles expect a very large private message from me in the next day ). I'm also hammering out the finer details of the plot; I gave a long writeup but there's still some holes I need to patch up so the programming team has no surprises. The current priority is the delegation of code writing to this person or that and it looks like people are doing it, so what do we need? More design information? More volunteers?

PS: I'd like everyone who's having a major hand in this to keep in mind that, once this is done, I want you all to write up how this went for you and what you did, challenges, what you needed or didn't need, etc. Start journaling now if you want, but our secondary goal, besides a finished game as a group, is leaving a record of "how" for future groups to look at. Next time a group project is seriously undertaken, I'd like people to be able to go back to our notes and see what we did, what we should have done differently in hindsight, what worked and what didn't, how we communicated, etc.

You're making my head hurt here ...

From a code-perspective, these aren't terribly 3D. The game will simply skip checking if you're over a hole or electric floor or something as long as the pack is equipped and firing. Plus you're drawn a few pixels higher. That's hardly 3D. And the grenade is 3D in drawing only; it arcs. That's a call to calc_spline(). No complexity.

I'm becoming more and more of the mind that you shouldn't auto-interact with terminals. One, it can be annoying in theory (much less so with good level layout) and two, if we have some sort of clickable icon to interact then it helps draw attention to the areas the player needs to interact with.

One of the rooms in the final level will be a sort of "minigame" in the sense that you use your unsafetied jetpack to fly across a room with no floor, and shoot down enemies along the way. Taking damage while flying cancels the jetpack, so if you get hit ... player goes down the hoooole. It's not a minigame though, just level design.

The only potential "minigames" are the firing range in the base, and the previously mentioned flight to the fourth dungeon, and both could get cut from the final design. Not much room for minigames besides that ...

Yes, but this is supposed to be a learning process ... that's cheating.

23, could you upload your current tilemap editor to the repository? If anything I'm working on needs to correspond with that, having a framework (even if in early Alpha stage) is useful.

My tilemap editor is currently in transition from C++ to C# and not terribly usable for anyone but me. Since I'm already deep in the code right now, I'll be writing it with an option to spit out maps in Monday format. So basically, get the game engine figured out, decide how to store things in files, and I will get you those files in that format, using Oates' graphics and whatever scripts. When the game is done, I'll make the editor available since it'll be usable then. I was planning on making it available anyway; Mapslapper (the original) was released ages ago. You can go read that Win32 mess if you want a head start that desperately.

Short version: you guys figure out the framework. The editor will conform to the engine. It's not like tilemaps are hard.

On that: we're using Allegro 5 and some alpha channels? I guess my editor will have to compensate for that; it doesn't use alphas yet and I haven't installed A5 yet ...

Layer height and width in tiles is dynamic, first thing you read from the map file.

Dimensions of the tiles should be coded dynamic also so loading a map with 16*16, 32*32 or x*y tileset doesn't matter to the engine. Makes things easier for us when designers start changing their minds...

Tile animation is awesome. Try using my animation/animator... Wait, how would this work within a whole tileset? Put this on low priority, get basic map working first.

As for entities. You've made me start to think more carefully about this. I realized they need to be draw back to front too.
OnlineCop: Don't start coding this yet. Just make the tilemap for now.

Question to 23, are we gonna have any entities on different layers? Or will all items, characters and whatever be on the same layer?

Entity
{
public:
  bool operator<(const Entity& o); //For sorting, using position.Y() is enough?
  virtual void Render()=0;
private:
  Vector position;
};

My tile animation is done by adding the extra animation frames onto the end of the tilemap, and having a seperate tile animation class swap images in and out of the main image array (not the 2D map array) according to keyframes. It's very fast and looks great; the only downside is it's a bit clumsy since my editor doesn't support it directly yet (I do all the animation edits in the game's code) and all the tiles animate in unison. That can look a little boring, but it can be fixed by adding extra animation objects and is actually a plus if I need a lot of animating tiles to line up.

Hmmm. I'm going to give a tentative "all on one layer" for that question. If different layers would honestly impact the gameplay that much and weren't too hard to implement I'd say yes, but considering how we're managing the maps (full screen wipe transitions like Final Fantasy instead of scrolling from one screen to another like Zelda/Metroid) I think we can certainly get away with a single layer system.

I vote all on one layer.

Did you figure this out yet? Sounds to me like you either need to install glibc or need to install v3.4.9 of glibc. Or maybe you just need to register it with the linker?

I would try to locate the installed glibc libraries and look for "3.4.9". I think locate glibc should work. If you do find a 3.4.9 then it's probably just not cached by the linker (see this post). If the version number is not in the filename then I'm not sure how you would check, but I expect it should be. If you can't find that version of glibc then you might need to install it (check your distribution's repositories).

** EDIT **

Does anybody else notice a long delay for the code tags with so many posts?

Not me.

He needs to update his libstdc++ (for me, it's part of GCC; not sure where other distros would have it). It's how the new ABI stuff works, to avoid complete breakages like when happened with GCC 3

Though unfortunately, whichever Gentoo has, it doesn't have the newest version marked stable.. I've run into a few apps that have a similar error, and I have the newest stable GCC (4.1.2).

IMO, the mouse shouldn't be used to click on icons. This isn't a desktop, ffs, it's a game. The user should have to walk up to an interactive item and press a "use" key, preferably while facing it. The mouse should be limited to firing weapons or using certain related items. Icons are useful for drawing attention from the user, but making them click on the icons takes away from the game. Am I trying to rescue a space colony or launching notepad?

I agree with bamccaig about icons; they're a pain in a game. The mouse should be limited to shooting or using equipped items and maybe interacting with menus.

That was the original idea. The issue is: what key? Shall we use WASD for movement and the spacebar to interact with game items? Because it's tough to pick a key and not make the player wish he had more fingers ...

I've had success playing games that use WASD for moving, Q, E, space and shift for other actions, along with the mouse.

Fair enough; to be honest, I keep imagining using the arrow keys to move. I guess I'm just a console noob.

If you use the mouse, you need to use WASD because mouse + arrow keys = user either reaching both hands awkwardly to the right, or even worse, if it's a laptop crossing their hands. If all your controls are kbd, you generally should use arrow keys because you use right hand for arrow keys + two or three other things, and left hand for other keyboard controls.

Well how much controls do we have?

WASD for movement
Space or a key around WASD to activate stuff (as in good old Doom)
Mouse aim and fire, and for menus / dialog

Is there anything else? Doesn't seem so much to me.

Yeah, that's it.

The "activate" key should also be a shortcut to "next dialog" or whatever.

Also, if it's possible (don't worry if it will delay coding at all) is to have two sets of keys, since we're using the mouse/keyboard combo. So that for left handed users, they can use the arrow keys with the mouse.

Or just allow for reprogramming of the keys (someone may want TFGH for reason, though that seems not too bad of a compromise for handling both left and right handed players, even though I just pick a random spot on my keyboard... Though VERY bad for laptop users)

The best approach is configurable controls, but the default should stick to the WASD in use in modern shooters. They are the easiest controls to use with a mouse (for right-handed users at least...).

I think multiple sets of keys is a good idea. Or make it easy to switch between user defined setups.

I've played games in a place where lots of people use the computers and especially Flatout was almost changing settings every damn time it was played. Some people have either really weird preferences or they just wanted to mess with us...

A combination of multiple defined setups and configurable controls is probably the best approach. Preferably, there would be a mechanism for saving the custom setups as well (i.e. control profile or something) so that multiple users can easily use their custom settings.

It might benefit the project if you think smaller. This is already a difficult undertaking (coordinating multiple people with no solid motivation to get it together), so I think you should make an effort to think simple and restrain the programmer's complicator instincts (we all have them ) for the time being.

Have a simple abstraction for now, for example an interface like this:

enum GameKey (GAMEKEY_THIS, GAMEKEY_THAT, ...};
class InputHandler /* interface, really */
{
   virtual bool pressed(GameKey key) = 0;
}

That way you can both: a) quickly implement this interface with a dumb proxy to key[], b) easily build on it when you have a game to use this clever input methods in.

Of course, you are free to disregard everything I said .

Progress report.
Improved script wrapper with some function calling.
Created Entity and Entity_manager which replaces the item and character classes. I realized they had so much in common.

I have also made my own WIP branch, I thought this was a good opportunity, so I can commit some experimental stuff for people to test and halfdone stuff etc. without pooping all over the trunk.

mattymatt is doing some strange things. He wants write access to svn and doesn't seem to get much attention on that matter.

onlinecop has been silent ever since he committed his own todo.

mokkan offered to contribute a resource manager.

Sorry about that. Really wrapped up with school, so I've only been able to work on the map intermittently. I'll see if I can't at least get a prototype of a map structure in the repository this evening.

Question: Does this initial stage need any sort of Draw() functionality, or can I leave that off for now and just focus on getting the map to load all the layers correctly, and do the Draw() functions later?

You can do it in whatever order you prefer.

[edit] Please make your own branch and commit what you have, then I can see what you're working on. Don't wait until the whole thing is done.

I'm still trying to get allegro5 to work (compile, link, etc.) so I can't even test to see if what I'm working on is functioning (or what the other stuff already on the repo works). That's my major hangup on this... it's not fun to make stuff if you can't even compile to see if empty stub functions are correct...

I'm just not a.cc that much during the weekend.

Just remember, if I give you write access to the SVN, you MUST change your password on the password changing page (which is crossed out on the summary page for some odd reason, along with the URL you need for using SVN on your system)

Has the player class been implemented? If we want to set some sort of milestone, I'd like to be able to get the player moving around a loaded map, shooting, and maybe triggering an extremely simple script ("Hi!" "How are you!" "I have hair!") just for the sake of doing it. I'm glad the tilemaps and scripts are going well; how about the player class? Since we've nailed all the usable weapons and the interface at this point, hopefully nobody is waiting on me for more information on that one because handling all those possible weapon controls will take some time.

I sent Mark Oates a ton of pictures, both sketches and tile examples, so he's have some idea where to go with the art. I'm really happy with my design for the rock smasher; it looks sweet. So hopefully the code will be ready to load and display some of it soon. How are you handling scrolling and the "camera"? The scripting engine will probably need to move the screen around a bit too. Are map transitions controlled by scripts too? Is there a class for things the player can affect in game, like switches, or moving walls?

Thanks for the progress report, Trezker. Are there any classes that need someone to write them that have not yet been claimed? OnlineCop is on tilemaps, that's good. Who's on enemy entities? Who's on the player class? Any particle systems? Or is it all stuff that can wait for now (I'm not really losing sleep over the particle engine, if one is even planned ). I guess this weekend was slow, that's cool, but as long as we have people on tasks who will get their share done in reasonable time then I'm still happy.

And no, you don't get to see my art until I see more code. Call it motivation.

If someone feels like making a particle system that's an open position. It's something that doesn't have much to do with anything else in the engine...

I'd like to get a camera in the game. I'm thinking of doing it myself, but Matt mumbled something about making one and I don't know if he made it.

As for enemies, npcs, items, triggers will just use the entity system. Take a look at that code. It lets you set scripts for UPDATE, PICK_UP, ATTACK (maybe should be ATTACKED). So it can handle any kind of object...
Only update is processed now though, I'll get around to the rest soon...

The player class has not been worked on, it's still the same thing I threw in at the start, probably because there hasn't been anything for the player to interact with.

4/8 direction animation has not been worked on either.

I'll have to look at it shortly. I don't know if I need some kind of access, and I guess I need to install Allegro 5.0, but I guess it's getting to the point where I need to keep a closer eye on it. Meanwhile I'm going to keep working on getting the finer details of this plot/dialogue worked out and get some final designs and layouts for bosses and dungeons ASAP. What would you say the big priority is right now, code-wise? As in, if any one thing could be done right now Trezker, what would be your pick?

You're going to have to start on some of the tilemap things without me... I can't get Allegro5 to compile what's in the repo for the life of me.

Not being able to actually test to see if my code is even compatible is getting a little annoying...

I had to add two cmake scripts to the cmake directory (when compiling with cmake) to get allegro-4.9.4 to compile (probably because I used an older version of cmake though). Have you tried adding those (attached).

Does anyone have any pre-compiled libraries I could use? I have done much compiling of other libraries and I get confused with all the cmake files and such.:-[

Yay! I got it to compile! It doesn't exactly WORK, but it shows a window (then SEGFAULTs, but that's easy to fix now that it's compiling).

Here's what I had to do (under WinXP):

1) Install the allegro5 library (I'm using the dev branch 4.9.5).
2) Copy everything from the allegro5 ./lib directory into wherever your compiler's libraries are stored (mine is Mingw/lib).
3) It would have also created a bunch of DLL files under the allegro5's ./lib directory: copy or move these somewhere into a location specified in your PATH (I just dumped them into my MinGW/bin directory since that was already in my PATH).
4) At the end of Monday's (the project Monday, that is) ./src/main.cpp, add the END_OF_MAIN() macro (it was left off and complains if I don't have it there).
5) Compile each of the source files with this:

g++ -c -o obj/Animation.o      -g3 -ggdb3 -W -Wall -Wno-unused -Iinclude src/Animation.cpp
g++ -c -o obj/Animator.o       -g3 -ggdb3 -W -Wall -Wno-unused -Iinclude src/Animator.cpp
g++ -c -o obj/Dialog.o         -g3 -ggdb3 -W -Wall -Wno-unused -Iinclude src/Dialog.cpp
g++ -c -o obj/Entity.o         -g3 -ggdb3 -W -Wall -Wno-unused -Iinclude src/Entity.cpp
g++ -c -o obj/Entity_manager.o -g3 -ggdb3 -W -Wall -Wno-unused -Iinclude src/Entity_manager.cpp
g++ -c -o obj/Game.o           -g3 -ggdb3 -W -Wall -Wno-unused -Iinclude src/Game.cpp
g++ -c -o obj/Lua_wrapper.o    -g3 -ggdb3 -W -Wall -Wno-unused -Iinclude src/Lua_wrapper.cpp
g++ -c -o obj/main.o           -g3 -ggdb3 -W -Wall -Wno-unused -Iinclude src/main.cpp
g++ -c -o obj/Main_menu.o      -g3 -ggdb3 -W -Wall -Wno-unused -Iinclude src/Main_menu.cpp
g++ -c -o obj/Menu.o           -g3 -ggdb3 -W -Wall -Wno-unused -Iinclude src/Menu.cpp
g++ -c -o obj/Player.o         -g3 -ggdb3 -W -Wall -Wno-unused -Iinclude src/Player.cpp
g++ -c -o obj/Vector.o         -g3 -ggdb3 -W -Wall -Wno-unused -Iinclude src/Vector.cpp
g++    -o Monday.exe           -g3 -ggdb3 -W -Wall -Wno-unused -Iinclude obj/*.o -lallegd-4.9.5 -llua -Wl,--subsystem,windows -la5_iiod -la5_font -la5_ttfd

I think that all that I did. The hardest part was probably the actual allegro5 compiling, but that was discussed in other threads and I finally got it going.

This didn't give me any more errors or anything; I just got a Monday.exe binary as my output. Running it through GDB yielded a segfault, but that's probably just due to the fact that the binary is in the wrong directory (or that I'm in one of my branches that may not have all the resources).

Your results may vary (and you probably don't need "-g3" or "-gdb3" as a regular "-g" may be all you need... I like to have the extra debugging stuff there, though, to give me better GDB tracebacks). I'm just posting my results here in hopes that anyone else with similar problems can use them.

EDIT:

Now, this is only off the top of my head after a lot of tinkering, so it may be partially incomplete. But here's what I think I did (again, for WinXP):

1) Install the latest version of CMake. Make sure that its directory (at least its ./bin directory) is in your PATH. Mine was C:\Program Files\CMake\bin
2) Unzip the allegro5 sources into its own directory: C:\allegro (also remember to get all the dependencies, like the DirectX8 [or 9] that it needs)
3) Change to that directory and then create a new directory (mine was ./BuildCMake)
4) Change into that directory.
5) Run the "cmake-gui.exe" program (the latest version that I installed for CMake included this file in the ./bin directory). It comes up with a graphical interface.
6) When it asks for "Where is the source code:" put in the directory where you put the allegro5 sources (C:/allegro -- it changes the backslashes (the '\') to forward slashes automatically.
7) For the "Where to build the binaries:" put in the directory of that new temp directory (C:/allegro/BuildCMake)
8) Click the button in the bottom-left corner (I think it says "Configure" on it) and it will run through a bunch of startup checks.
9) On mine, I got a few warnings, saying something about FLAC, libMagick (probably from the WANT_ICODEC option), Vorbis, and something from the SNDFILE. Anyway, just uncheck anything that gives you these warnings. Re-click the "Configure" button each time and finally, it will stop giving warnings. Click the "Generate" right next to it.
10) If it finishes the "Generate" stage without problems (I didn't have any problems), go back into DOS (you still be back in that new "temp" directory you created: C:\allegro\BuildCMake) and run "make" (I have to explicitly use "mingw32-make").

It installed allegro5, and I was able to run "make install" (actually, "mingw32-make install") and most of the important files were installed into my MinGW's ./lib and ./include directories.

Then I had to copy the files like I explained above, and compile with some of those special flags, and things started working.

See if any of this helps, and let us know if there are any problems (though I'd recommend posting into a new thread so we don't get too off-topic on this "Monday" thread).

Cheers!

I've just had 2 days of 'fun' installing in MSVC myself Only to get the same segfault at game->Get_lua_wrapper().Call(1); in Entity::Update()

I made a wiki page describing how I got 4.9 installed (using precompiled binaries where available): http://wiki.allegro.cc/index.php?title=Installing_4.9_Windows

and then I had to make MSVC projects for lua and Monday. I'll make a wiki page for that process today, or post the precompiled lib somewhere, once I've conformed it isn't causing that segfault.

After all this grief, I've come to the conclusion that VS's debugger isn't worth the pain.

And on top of all this, the al_font_textout API has changed, so now to stay compatible with 4.9 SVN and the upcoming 4.95 release, we've had to break it in 4.9.4, so don't use 4.9.4

I was under the impression Allegro 5.0 was completely separate from the current 4.x branch. So where is Allegro 5.0 at?

I gave an idea for a milestone a few posts ago; I think a sooner one should be just getting a stable binary everyone can compile and use. Go from there. If that's you already then just keep coding.

4.9 is WIP for 5.0, or will be.

4.3 is WIP for 4.4.

Ah, gotcha.

It's all so much easier in Linux. All the dependencies (strictly optional for a5, but Monday uses iio, ttf, font, png and zlib addons already) are just there in the repo, and it all just works.

I only came to Windows to knock out a quick demo exe. I haven't seen my family in 14 months (for real, 72 hrs of pain so far, and I haven't got VORBIS or some of the others yet)

So, Allegro 5 is here, and it's real, and it works GREAT in Linux, and it works in windows too but with PAIN.

I think a nice precompiled bundle of everything (a5+libs) will make life a lot easier. I'll try and arrange that when I've got VORBIS support in (we will want OGG in the game, won't we?)

OBLIGATORY SCREENSHOT!!! Just to prove it works. This is the crappy keyboard configuration screen from my menu demo branch

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

BTW, I was pleased to see C# supports PNG alpha translucency right out of the box. I was playing with how to implement it in my tilemap editor today, and literally all I did was change the .bmp image file I was using to a .png. I was pretty happy about that.

It's Monday! Quick, add some more features to your game!

I think it would be more interesting if the monday project was never worked on on a monday. But I guess that idea is already broken.

Looking over all the posts dated the 22nd, I'm not so sure.

In other news, I'm focusing on my tilemap editor for a few days, and I have the first 3 dungeon bosses all planned. I'd like some minibosses guarding the special items but I don't want to give everyone too much work. By the way, I skimmed the thread and I appear to be blind; where's the link to our code? I know I saw it earlier ...

Redundant link blabla yaddayadda -> http://www.zeoxdesign.com/monday/
SVN repo -> http://svn.miquelfire.com/monday/
Wiki page, has instructions on stuff, could use more info -> http://wiki.allegro.cc/index.php?title=Monday_project

Hey, could someone make an automated nightly build? Mostly for the windows people since I heard it's a pain to build the project with all the allegro 5 and lua problems. Linux people probably wont mind building on their own.

On the redundant link, none of the code related links should be crossed out. I'm not sure why Mark crossed them out in the first place.

Is there something strange with the SVN repository?

I commited a branch with ~/mybranch/trunk# svn import . http://svn.miquelfire.com/monday/branches/mattsmith -m "menu demo"
and when I checked it out with
~/monday/branches/mattsmith# svn co http://svn.miquelfire.com/monday/branches/mattsmith
, it was all mattsmith/blah instead of blah, so I have mattsmith/mattsmith

Thats because if you don't specify a directory to check out to, it uses the last component of the repo path.

go into ~/monday/branches and "svn co http://svn.miquelfire.com/monday/branches/mattsmith".

I thought the new URLs were to replace the old ones. I have them un-crossed them out now.

My name is spelt right. That's all that matters.

I tried to follow the code at work today; at least, the main trunk, I didn't have time to read the branches. The Allegro 5.0 is making my head hurt. I guess there's no main menu yet? At least to the extent that you can navigate and select your options. And dost mine eyes decieve me? No tilemap class yet? Ewww!

The menu options are pretty much set, so how soon before you can actually start the game to a menu and pick selections? Even if Play Game->New Game just takes you to a fullscreen "Hello, World!". It looks like the basic framework is there for the game loop, it's handling time in a way I'm not used to but I guess that's Allegro 5.0 again. Are we basically just waiting for a tilemap class before we can proceed?

Just curious for updates from everyone; how are you all doing? Everyone just still bored and tired coming off Monday blahs? Anyone doing anything today? Keep the group updated!

The menus are in my branch. I've been too busy getting VS set up to handle it to do any coding the last couple of days. And doing gfx for MORE menus

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

I will do the Map and Tilemap classes if nobody else does, but I'm trying to concentrate on the non game-specific parts. Different map types can coexist in the same game, so if anyone wants to code their own minigame-specific Map-derived class then go ahead. The interface that the Game class expects should be fairly apparent by now. Init(), Update() and Render() methods etc. At the moment, you could expect to get raw Allegro events in an Event() method, but this will change soon to a game specific event type so you'll get user-configured key events etc.

I think we are ready for some music now, so we can test A5's ogg handling abilities. Does anyone who has offered want to do (or has suitable placeholders already done for) the following tunes?

• Overture - 30 seconds of rousing full-production. Something to gladden the heart of someone who has just spent an hour installing, and has been muttering "this had better be good" for the last half.

• Menu Ambient - Welcome to the wacky world of Moog beeps. Something to loop while the menus are showing.

• Game Ambient - This should match the tone of The Game, which in my personal fevered dream involves lots of theramin spookiness, because It's A Mysterious Planet.

Let's wait on OnlineCop to speak up. He said he was going to do it, then he couldn't get Allegro 5.0 working, then he did ... maybe he just got a late start and is slaving over the code as we speak. But if you can't do it or don't have the time, OnlineCop, let us know sooner than later, k?

Edit:

Hmmm, no one but Matt since then? And only Trezker just before that? I'm going to keep designing level layouts and writing dialogue and such and hope there's code to meet me when I run out of things to do on this side, but I'm hoping a few more people can try to get active on this. If nothing else, the basic code framework I was asking for seems like it's getting solid. Maybe we should have a Speedhack-like weekend where people grab a source file and start fleshing it out. The members can make time for that, they can make time for this.

Sorry; I was in a big bus wreck yesterday (I was on the bus, not the one hit by the bus) and couldn't commit my current code, etc.

Tilemap is coming, though slowly. I pushed up at least a mini-skeleton for it, but if someone else wants to work on it until I don't have my hands quite so full, that would be great.

OnlineCop is the kind of guy who throw a monday project on rails, and who is just currently dropping it.

Man, eat some powerfull meal, drink some powerad, burner, medics if needed, but GO AND CONTINUE YOUR JOB !

WTF ? You think you can act like you've just without me to bash you ?

Meh, you don't know me enough.

/That_whole_post_is_partly_a_joke

/edited

Have you installed 4.9 + addons yet, GullRaDriel?

Even the critics have to buy a ticket

Ok, Let me play it nice and admit that I tried, but not finished.

Point taken, M. Smith'M'Att-son ;-)

Now look at what you've made, I am in a huge need of finishing that 4.9' install ! Darn you !

PS: I am a good mood today, in a very good mood ! Some madness of the few last day (they were horrible) can still rise up sometimes. You can say 'it's not a reason', please accept my excuses for being a lil' bit too harsh that time, OnlineCop. Next time I will (also) try to help instead of just judging.

OnlineCop, why don't you branch have the other files? Each branch should be treated as if it's a different version. I mean what game have you compiled that had one version just give you a map.cpp file, but no main.cpp file, and yet, every other version is using other files, including the map.cpp (which may not change between versions)

I think what MiquelFire is saying is that each branch of Monday should be a full project, that when stable is compilable and runnable entirely on it's own. IIRC, and if done correctly, the repository doesn't even need to duplicate the data (it will just know that unchanged files copied into your branch are actually files from another branch at a specific revision).

My biggest problem is that some of the other branches are creating things that I need for the Map (or Layer) classes that I'm working on, and so I have to incorporate their work into mine. But then something changes on the trunk, and my code gets outdated very quickly.

I was thinking of JUST changing files on my branch that differ from the (main) trunk, expecting that if you want to compile it, you'd be able to simply drop it into yours without it breaking anything.

I'm still having a lot of problems with the allegro5 library (I had to compile without any of the addon support, so I have to keep going back and adding in one feature at a time and fixing the source files that are breaking it), so that's something else I'm fighting with while doing this.

Are we going to do a simple version of Extreme Programming, where we code only for what's on the current spec without adding any "well, we MAY need this feature in the near future..." features?

AFAIK, it should be possible to keep your branch up to date with changes in trunk by merging trunk into your branch (somebody correct me if I'm wrong). This basically means that even though you're making changes, you can still bring the changes made to trunk into your branch without hurting trunk. In theory, if a conflict arises I assume Subversion will provide you with the same resolution options as with any other conflict. Then, when all is said and done, you would merge your branch back in with trunk (i.e. the other way; again, having to fix any conflicts that may have arisen). This allows everything to stay organized and allows Subversion to version everything properly.

Subversion is very efficient with how it stores this stuff (it only stores change-logs, and only once, AFAIK) so you don't have to worry about the extra space your branch would be consuming. The point is, somebody should be able to just checkout your branch and have everything they need (aside from external dependencies). Having to checkout trunk and then export your files over top is messy, slow, disorganized, and error prone, IMO. I see what you were going for, but I think it's probably just a lack of understanding in version control software (not that I should talk ).

OnlineCop: What is conflicting with your code except maybe the animation classes?

I don't know if you should even use those in the map. I don't know what we could be changing that affects your work...

Anyone able to understand this SEGFAULT backgrace (gdb)?

This is coming off of the code from the main trunk; I'm expecting that all the resources are available to it...

al_draw_bitmap crash from a al_font_textout call?

I just got a bitmap crash, but that was from a failed load.
Does the font load? There's no error checking on that (game.cpp:40)

My crash was because something went wrong with allegro after an svn update. If you've done that too, try a checkout in empty folder instead, new shiny install of allegro fixed my problem.

So we're basically just waiting on people to get Allegro 5.0 going still? Has anyone done any code progress this week?

Why are the html tags in those text boxes showing?

That's copy/pasted text going through a parser intended for writing basic html. I just slipped it in a textbox so it wouldn't take up too much space. It's legible despite those <br />'s

I've done some inside of my branch, but don't like posting things into the trunk unless we can get something there that doesn't crash.

I need some help with the maps (and tilemaps) that I'm working on, if anyone has some time. I'm not sure what all we need, and how to tie everything together properly. Getting some feedback and suggestions would help a lot, since I've got the equivalent of writer's block.

From all of the code currently found in branches/onlinecop, I can compile and get an executable. I drop that .EXE file into the main trunk and run it through GDB. I get a blank window, then immediately a SEGFAULT. So I can't see if my code (and code stubs) are even being hit (through debugging messages, etc.) because of this problem.

We do have a Lua problem on Windows. That may be your problem. I'm not even getting warning signs on Linux so I have no idea what it might be.

MattyMatt said he'd be debugging it, but you could try figuring it out too, if Lua is the crasher.

If you want to know whether a line or function has been executed, set a breakpoint for it in gdb.

gdb>break [filename]:[line_number]

Use the continue command to keep going and 'delete #' where # is the breakpoint number to get rid of a breakpoint. Use 'info breakpoints' to find the breakpoint number if you forget. If you're not already, use 'backtrace' to find the contents of the stack at the time of the crash.

I'm here to throw in my ignorance of the development of this thread again.
How is it going? Much progress?

Remember, people not following closely the progress like me won't do anything unless asked to explicitly. Is there any musical need yet? I'm up for anything music, anytime, but (normally) you need to reach out for me and ask... it's just that this time I felt like coming back and checking on everything.

Yeah, the need is for code right now. I have a short list of what music we need but I'd like to get something remotely playable first so people know what they're making music for, and just in case the list changes. I was actually going to make a new thread just to ask how much anyone knows about what we've done so far; from the look of the Programming Support Group thread maybe some people don't realize what's going on here.

Just so I'm up to speed, the coding team is basically Trezker, Matt Smith, and OnlineCop right now? I get the impression that there's some internal communication between you three in the last few days I don't know about. Is there some progress being made, if only to help OnlineCop get compiled? Has anyone else contacted you offering their help?

I need to spend some time today getting SVN and Allegro 5.0 set up, although I'm still just doing design work and finishing the necessary tilemap editor over here. Mark Oates, done any more graphics?

I, for one, am clueless. I stumble into this thread periodically, but I've no idea what's going on. Not that I could help anyway.

Me and Matt are talking on IRC. OnlineCop is pretty much on his own, he only posts in this thread and leaves some clues by committing to svn...

Then there's Mokkan who said he's gonna convert his resource manager to allegro 5, that's not a critical task though.

I have made a somewhat usable entity system with Lua interface, so you can make items and characters in script.

Matt Smith is working on menus and gui, which will be bound to Lua too.

OnlineCop is working on map code. Don't know how far along that is, unfortunate that this task fell on someone so short on time. This part is the one most people seem to be waiting for. It also seems he's working on Windows, which has that annoying Lua bug...

Sorry for the off-topic post, but according to my calculations, this thread is now the longest by post count at Allegro.cc, having surpassed the Team Chess thread (580 posts) with Trezker's last post. The Team Chess thread is still the longest lived thread by time, lasting almost 11 months.

Carry on.

[append]

Well, 23 demonstrates I'm wrong I'll update my calculations

I already looked into that a while ago. We're not there yet.

The longest thread on a.cc is about sports?
Inconceivable!

What I've got on SVN is basically all I've got.

I don't have an IRC client, which is why I've not been chatting with anyone. So at least on my part, no, there's been no outside communication with the team except through this forum.

I've posted my backtrace report a few times now, but I can't make heads or tails out of it. With the code I've posted in branches/onlinecop, I doubt that there's a way that a NULL-pointer access is happening, since I've got all sorts of "if (blah && blah->foo != bar)"-style guards. So I'm really stumped.

I'm working with LUA 5.1.3, if that helps at all. Don't know if this is the source of the crash, but I'll have to keep digging.

And yea, I don't have as much time now as I did when the thread first started (I had a week until I started classes, so wanted to have a "one-week competition" before my time ran out ). But I'll help out whenever and with whatever I can.

Should I post what I've currently got into the main trunk, or should I leave stuff where it is (branches/onlinecop) so you can check it out and see what's there without it breaking anything?

OnlineCop: Check out this web-based IRC client, Mibbit. Set your server to Freenode, pick a suitable user name, and set the channel to #allegro.

For me at least, I have to mkdir obj in branches/onlinecop. Then I get a bunch of invalid conversion errors in src/Main_menu.cpp between line 26 and 29. So onlinecop, if you're managing to compile your branch then I'm going to say that your branch in the repository is not a full reflection of your working copy (or I'm overlooking something...).

Haha, my last attempts at either C++ or a Monday Project were during that World Cup. I may revive some of the GL code. It has little stick men, on a pitch, with little WoW nametags floating above their heads. Just what we need

I've merged some simple hard coded menus into the trunk.

No luck with the lua bug in Windows yet.

Well for Lua I'm guessing 5.1.x should work but the latest version is 5.1.4 so that's probably the best...

I'll take a closer look on the map code. Maybe put it in trunk if it works here.

[edit] Well I would unless someone already broke the trunk...

[edit2] Trunk reverted to where it works. I also merged my own latest changes.

OnlineCop: what's with all the namechanging and making everything pointers? And why are you using std::nothrow everywhere?

Your branch is a mess, I'm guessing you manually moved files to trunk and committed. If you had a real branch you could just do the following in trunk.

svn merge -r LAST_MERGE:HEAD http://svn.miquelfire.com/monday/branches/onlinecop
Make sure everything works here, resolve conflicts..
svn commit -m "merge"

I'll be taking a look at your code now, see if it works with the trunk code.

First of all I had lots of trouble compiling it. All sorts of strange errors. You also have optimized and inlined stuff, why do that before even rendering a simple tilemap?

I also wonder what the idea is with the TILE_TYPE template? I don't see any use for a template in this. Why not just graphical layers and a special collision map?

edit:nm

Ok, since I was not so satisfied with onlinecops design I tore everything up and made my own... In my own branch of course. Still nothing visible, the loading code isn't in there yet.

Check out my branch if you want to have a look at my Map, Layer and Tileset classes.
http://svn.miquelfire.com/monday/branches/trezker/

Well I'm kinda disappointed in that. I mean, okay, OnlineCop can't finish the tilemap, stuff comes up, fine. But Trezker picks it up? No one else on Allegro.CC has coded a tilemap and has some time to spare? Wow. The guy has enough to do.

I can throw you my current tilemap engine code if you want Trezker; if you haven't done much yet it may give you a head start. I told OnlineCop no when he asked since it kinda defeated the purpose, but I guess the purpose has been TKO'ed at this point and is being dragged out of the ring.

If anyone cares what I'm doing, I'm basically writing up the quest points proper. Talk to this guy, get this item, go here next, back it all up with logical plot, from start of game to end. By the time we can walk around a map, talk to NPC's, and switch maps via doors/stairs I'll probably be done. Hopefully that's not far off?

PS: I just accidentally added "Hopefulyl" to my dictionary. Lawls ...

I would participate, but anything I code belongs to my company However, I am still watching this from time to time (especially because I want to learn the new API).

I have Allegro 4.9 installed and currently a bit too much free time. I could check out OnlineCop's branch tomorrow and either use that or start from scratch--a tilemap engine doesn't seem too much work.

I'll check it out tomorrow.

Meh, I don't have much to do. I threw together some code because I felt like it in just a few hours.

When did we decide this whole thing had to be made from scratch BTW? I think if someone has good ready code that we could just plug in, that'd be great. If it's not a perfect fit we could just tweak it a bit. We would have had map in the engine weeks ago...

Mokkan's resource manager is an old thing he based on X-G's even older thing... I don't have it yet though...

I don't recall anyone deciding anything had to be from scratch. I was basically expecting someone to do exactly that; grab some old code and modify it. You could do 75% of this engine that way. I was just hoping even that little effort could be spread around more. Think of how fast we could have been done ...

I feel a bit bad about coding a new map system when OnlineCop had written so much code. But it was too much enterprise...

Also, I don't think the project can wait for the map much longer, I can't wait for it much longer. There's only so much I can do on entities...

I think I'm only gonna do the basics of the map. Someone else can extend the tileset class with animation, code the collision handling, line of fire, parallax scrolling...

That is unless someone throws a good map system that's done most of that. Then I can drop my code.

Even your personnal work ? Even if you are not at the office ? Man, that contract is soooo restrictive that I am astonished you still have the right to speak on a forum !

I only have an Isometric tilemap system under my hands, and IIRC yours isn't destined to be isometric.
Why not use Tegel ?

Well, if I'm doing it I'm continuing my own work, I kinda like how it turned out. But if someone else really likes to do tilemap coding and wants to do it another way...

While you all are thinking about that, I've completed basic loading and rendering of map.

Map file format, pretty simple. First a line saying "layer" followed by which tileset to use, then dimensions of the layer (in tiles), the the tiles in logical order. It's loaded with std::ifstream>>(int).

The tileset file just points to an image followed by the dimensions of a tile.

media/tileset_placeholder.png
32 32

So, if this works like I think it does, you can have layers with different tilesizes, the tileset determines that.

Then we could make a collision layer with it's own tilesize too, if anyone would be so crazy as to think that's a good idea. But it's almost simpler for me to implement collision of dynamic granularity than fixed so why not do that?

Even in your spare time?

My collision detection usually consists of an array of tiles. That's not just image data; the tile structure also contains an index into a collision array. I use an array of bitmasks for most of my tilemaps. In the case of Monday, it can be strictly a binary value.

Depending on how far you want to go, we can also give each tile a speed and direction (for conveyor belts that affect player movement), a number that corresponds to the script it triggers, animation info, the walkable/throwable/shootable properties I mentioned some time ago, whether it's a hole since we already know there will be holes you can fall in, etc ...

Either way, get the tilemap class implemented and working with all the features we want off a few hardcoded maps before worrying about the file format too much. I don't want us to be loading off maps and then realize we need to change the file format to accommodate something we forgot, and end up scrapping all our map files.

PS: 600 post get

Why aren't you using a binary file format?

Text has been recommended for this for some odd reason. AFAIAC, if you can put data in it and pull data out of it, it's all good. It's not like memory will be a huge concern on this project.

I don't think its very logical, considering you have a tilemap editor, but oh well.

Yea, but only he has the editor. How else will the others be able to edit the maps without the editor?

I just used text because I don't have an editor and didn't feel like writing dummy code to create test data.

For the tileset I think it's quite alright to use text. But when you're making big maps with multiple layers binary is preferable.

How well does std::ifstream work when you switch from text to binary. I feel it should work quite well... But I've had problems fetching values after eachother before... It's like file<<int1<<int2; doesn't put that space between the values so when you do file>>int1>>int2; it doesn't handle it right. But I suck at this...

Yeah, you can't use the "formatted output" operators on binary files. They write textual strings. The only difference between a binary file and a text file (to an fstream) is the line endings.

You need to use put, which writes one byte. You need to break up longer types yourself. Food for thought.

Well, I'm still willing to do something if you ever need more manpower.

If you want to code, report to Trezker. He'll find you work. Feel free to just comment on the design of any given aspect of the project as well. Right now the tilemap format seems like a bit of a hot topic. If you see a not-yet-implemented function but don't want to commit to more than a few minutes, feel free to fill it out and mail Trezker the code so he can review and add it. Anything is helpful; input in general, code, or even just questions.

I have NO problems with you redoing the map system. In fact, I liked 23yrold3yrold's suggestions and ideas for all the structures that the map can use.

Having a good OO design will help if/when we decide to change things like map structure and format, loading/saving, etc.

I like the structure you have already, Trezker. I have been completely out of the loop for a while because of intense classes, so go right ahead...

...which is why I'm actually happy that others are working on this. (Who put me in charge of maps, anyway? I don't remember ever volunteering for it... )

I can ask my sister if she wants to work on the map editor herself; she's pretty versed in things like that (although with 2.3 kids, I don't know if she even comes on a.cc anymore...).

Lastly, my branch is pretty hack-and-slash. I'm writing everything with a focus on Windows, and I know a lot of you don't use it. What ARE all of you using, anyway? Should I whip out my Mac and start programming on that for a while, or stay on this OS and keep using the editors I'm familiar with?

Trezker: what should I start working on now (hopefully, something not too "we're all waiting and depending on you, OC!")?

RAWR!!!

Sister? RAWR!!!?

Hey, who knows? She may have some experience with this kind of thing. I know I sure don't... At least, not compared to the others here who have single-handedly created entire games. You all are like, Chuck Norris cool compared to me.

The point has been missed. One of my three current projects is re-writing my tilemap editor in C#, and it's pretty far along. Obviously it will be able to spit out Monday files.

I thought I had been pretty clear about that ....

EDIT: Mapslapper has pretty much everything vital but the animation editing at this point. And the saving, but I need a format for that.

You mean animation of tiles right? Well you could make that yourself in the tileset class. You could add a timer variable in Tile, which currently resides in the same header, or use the same timer for the whole tileset. Then you'd need to get an Update call in there to update that timer.

OnlineCop... Ok, I see communication has been very poor between us.
Perhaps you could play around with making a particle system, I don't think that's something people will be waiting eagerly for.

Anyone disagree? Is particles urgent?

What else is there? Entities, menus, and maps are covered.. Any specifics will be going into scripting...

I know how to animate the tiles; The Mighty Stoopid had that implemented like 3 years ago. I just mean figuring out a good way to handle editing the animations. Time to check out how C# handles drag and drop ... and no, particles is far from urgent.

"And the saving, but I need a format for that. "

FMP, otherwise it's your call.

If we devise a new complex format with loading & rendering, it would be easy enough to make an in-game editor from there. All we would need would be the saving func, and some GUI work.

Speaking of GUI, we may have MASkinG working on A5 by the weekend, so I'm not going to implement a new GUI from scratch. One of the MASkinG examples is exactly the kind of generic game menu front ends that I've been making, so I'm gonna learn the MASKinG API, and reimplement the menus I've done.

I tried to look into FMP; it doesn't seem to have much documentation beyond "here's an open source program that loads it, look in there or something, I dunno". I'll probably look again later. And yes, in-game editors are win, but I was going to make this program anyway.

EDIT: I found a straight-C Mappy demo which seems to have the loading files in it pretty plainly. It's not formatted very well and there's no comments, but I'm in the process of documenting it and cleaning it up for my own purposes. I'll probably post it later; I can't be the only one who could use that ...

How do I get involved? What is left to be assigned?::)

Edit:
Noticed this (don't know if it has been fixed yet)

lua_State* Lua_wrapper::Prepare(std::string function, void* caller)
{
  if(function == "")
    return NULL;

  lua_getglobal(state, function.c_str());
  lua_pushlightuserdata(state, caller);
}

This function is returning without returning a value...I changed it to:

lua_State* Lua_wrapper::Prepare(std::string function, void* caller)
{
  if(function == "")
    return NULL;

  lua_getglobal(state, function.c_str());
  lua_pushlightuserdata(state, caller);
  return state;
}

Holy shi! How the hell did we miss that!

Thank you. I very much suspect this is what's been bugging us on windows.

My compiler on Linux must be something spectacular, it includes headers for standard functions on its own and maybe even returned that state for me...

It's pretty troublesome since other compilers don't do this so when I forget to include say stdlib, the windows guys can't compile, and get bugs like these.

Always always always always have warnings turned on when you compile. Assume a warning means an error until you've confirmed it to be otherwise.

It probably returns the return value through a register. If you're lucky, the contents you want is already there and not returning a value doesn't break the program.
Still in that case, an unrelated code change somewhere can suddenly break it.

I've never used LUA before. I am trying a test program, using the Lua_wrapper functions...I get this error: "attempt to call a string value" whenever I call

lua_setglobal(state, "game");