O.
M.
G.

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

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

that reminds me of the Captian Proton episodes on Voyager.

because nobody will ever make the connection.

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

that's cool.

I approve... in all my approval authority.

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"}

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 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 ...

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?

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.

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.

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?).

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.