I've started to code the Mechaius game I talked about a while back for that open source project. While I'm not going to build the website just yet, I would be very interested if anyone with some C++ experience would be willing to work with me on it.

Right now, there's nothing more than a Windows/DirectX shell, as I'm trying to flesh out the architecture a bit more before I get too deep into the code.

Here are some random details that may or may not change as time goes on:

• Side-scroller/platformer genre
  
• 2D (tile-based) graphics, but will utilize 3D hardware for special effects such as real-time scaling, rotation, and morphing of levels
  
• Multiple tilesets for a single level
  
• Ability to change background music in a level via scripting
  
• Unlimited tile and sprite/event layers
  
• Scriptable events/AI
  
• Advanced action/control customization (you can define custom actions/moves and assign them to any key sequence)
  
• Upgradable units/weapons
  

I'll post more if anyone is interested. Please reply if you're experienced with design, architecture, or coding.

Note: This is an open source, not-for-profit project.

-Nag

YaYaYaYaY!!!!!!!!!!

I'm more of a VB guy, but will be learning C++ soonly, and would love to help in any way possible.

Oh, and don't ask me to do the website. I stink at HTML.

`N0

Uh... I could make 3d models and render them as 2d sprites... or I could be your cheerleader!

I could help with design I guess.

Radium, rendered 3D models is probably the way we're going to go with it anyway, so that's good.

The characters will be mechs (similar to those in MechWarrior). Just do an images.google.com search for 'mech' if you need inspiration.

Anyway, I wouldn't bother too much with sprites right now, as there's still much work to be done before they can even be used.

Infinite Spaz, design help would be wonderful. I'll post later with the design details I've been working on.

NOBODY, this will be a good project for you to learn C++ on. All source will be publicly available once it is a bit more complete (i.e. clean =).

-Nag

Meh. How about no "rip off mechs". We could take the same idea, but a different approach. Something that won't make people go "he looks familiar".

And you need someone to do concept sketches. No, not me.

Are we going to need a stat system?

By stat system I assume you mean a huge database to track online game stats? Yes, we'll need that. Ideally, it will use SOAP or something to allow other sites to access the info via scripting. This should make things like JDC and clan stuff much easier to set up.

Graphics really aren't my concern right now, but yes, we'll be taking the concept in a slightly new direction.

Okay, here's an old game treatment I wrote. For those who don't know, a treatment is basically an optimistic view of the general game concept. Many features will change as the project goes along, but the general idea should be persistant. Anyway, here it is.

---

Abstract
Mechaius is a side-scrolling platformer set on planet Mechaius in the same galaxy of the Jazz Jackrabbit series. It will focus greatly on storyline and character development, while still providing great gameplay and fast-paced action. The game is meant to cater to Jazz Jackrabbit fans, incorporating many of the non-copyrighted ideas. Mechaius should appeal to all ages.

Background
Organic brains housed in mechanical suits. Probably more details needed.

Gameplay
Players will control a constantly changing team of machines throughout the game. Each machine will have unique abilities and weapons, and each can be upgraded in various ways. Levels will be very large maps, full of power-ups and opponents. Players will choose the path the game takes, as their actions in one level will affect the storyline and even the details of future levels.

Characters
Every character, whether good or bad, can be controlled either by a player or by AI scripts. This will make for much more interesting multiplayer games, and greater flexibility in custom levels than is available when only a few characters are playable. Each character will have a detailed background history as well as predefined personality traits. In addition to the dozens of included characters, players will be able to define their own using one of several included machine models. Players will be able to define attacks, weapons, and other information about each new character.

Enemies
Both baddies and bosses will be controlled by scripted AI. Enemies will be highly intelligent, making decisions based on their current position, condition, and situation. They will also be able to navigate levels more affectively, allowing them to chase after players or take cover when in trouble.

Environment
Mechaius is a large planet, allowing a broad range of rich environments. While most tilesets will depict buildings and the industrial side of Mechaius, it will also include several outdoor settings.

Internet Play
There will be three types of internet servers: public, private, and closed. Public servers will allow any player to join at any time. A private server prevents uninvited players from joining. A closed server is one where all players join prior to the start of the game. Once all players have joined and settings have been selected, the host begins the game and no new players may join.

Bots
Multiplayer games will support scripted bots. The AI will follow general predefined behaviors coupled with scripted strategies to simulate formidable opponents. Bots will learn as they play, making them even more affective against human players. For example, the first time a bot plays a specific level, it will not know where any power-ups are located. As it plays the level, it will remember what areas to avoid and where goodies are located. Players will also be able to define common routes through levels that bots can use.

Level Editor
Players will be able to create their own levels with the included editor. Virtually every aspect of the game will be customizable via scripting. The editor will include features for creating any type of level as well as palettes, tilesets, music libraries, ambient sounds, custom events, etc.

---

And for more fun, this should give you an idea of how the engine is organized and what classes do what. Feedback is welcome.

DXEngine - Handles all dirty DirectX code. Initialization, cleanup, etc.

TileEngine - Derrives from DXEngine. Handles sprites, tiles, and the drawing of every frame and some other engine-related stuff.

Tileset - Represents a tileset. Probably represented as a Direct3D surface?

Tile - Represents a single tile from a tileset. Probably represented as a Direct3D texture?

Layer - Represents a plane on which tiles and sprites can reside. Maybe seperate tile layers and sprite layers?

Sprite - Represents a non-tile graphic. Typically owned by an object.

Object - Base class that nearly everything else derrives from. Characters, weapons, items, powerups, etc.

---

And here are some interfaces.

IDrawable - Inherrited by any object that owns one or more sprites (anything that you can see).

IHasMass - Inherrited by any object that is affected by gravity, wind, etc.

IScriptable - Inherrited by any object that can have a script attached to it.

---

-Nag

It needs a plot. Badly. Most Mech games have a destroied plant theme or an arena theme. How about something much better? You say it's for all ages, so that may be a tad restircting on the plot. I have a few unused ideas for a plot, but I'll prolly just make one up. But I need information as to who this game will appeal to and what level of complexity, violence, romance etc. should be included.

No romance, the brains are all genetically engineered, so there are no family structures.

Everything is mechanical, so violence isn't really an issue.

I'm thinking 10-12 and up for a target market.

The tentative idea was that the planet is very old and the inhabitants were very advanced, but constantly warring with each other. As they advanced in technology, they began creating mechanical implants and body suits to make better soldiers. Eventually, their entire bodies were mechanical and only their brains/concious/whatever was organic. With a non-organic body, they reached immortality, and boom. Distinct leaders rose up and started the different clans/factions that will be depicted in the game.

Most mechs are pawns, engineered to fight the leaders' battles. Those that show promise are promoted in rank and are 'used' for more delicate missions. These will be the playable mechs.

As you play the game, you will gain allies and build a small team of mechs, all of which play on each level. You will only be able to control one mech (the leader), but the others will be controlled by intelligent scripts (bots) and will follow orders. The other team members may betray you, abandon you, or whatever else they feel like, depending on the situation.

I've focused more on the gameplay than the story, because that's what I do. Feel free to play around with it or trash it and start over.

-Nag

I see. I wasn't planning on any romance what so ever. After all it is a 2-d action game. I just listed it as an example. I'll sleep on the idea and come up with something during the week.

I think there should also be a group of "Old school" mechs, who are not completely organic, but more like cyborgs. That would add a little more variety to the game. Oh, and I think there could be a few different tileset types, as in a city, (Almost everything metal) a cyborg city, (Plants that are part metal, fruit with metal brains, etc) and an organic city (Almost everything organic).

Oh, and this should most certainly help my C++ skills.

`N0

Although I've got pleanty of my own code I need to be working on, I could probably help with the archetecture. By naming those interface classes it looks like you're planning on using some kind of COM archetecture. In the games that I've worked on, we've always just used a well structured object hierarchy, so I might need to read up a bit on COM, or see how you're coding things together.

I don't suppose you have any more detail documents than what you have posted here. I can imagine how things could work starting from how JJ2 works, but I'd rather not assume anything. You really need to specify where exactly the 3D functionality will be used. Just putting a bunch images on quads and using them like sprites isn't necessarily the best way to use the system. Also, be aware if you want to start animating these sprites using the traditional multiple images as frames, that can take up a lot of memory. You don't want to be half way into the project and realize that all your animations take up over a gig of video memory. (This actually happened in one of our projects. Thankfully it was already in 2D.)

So if you could fill me in on details and ask what you want from me, I'll be glad to help whenever I have the time.

I can design arty stuffs...perhaps. And I'm extremely good at coming up with ideas for these violent, sci-fi things.

I'm your man if you need concept sketches of characters, enemies or anything like that.
My fantasy is bursting from ideas.

Just tell me what to sketch, and it's done.
It's just that I'm rather busy lately.. well, very busy even. But there's always time for sketching.

For the record, I have no experience with Direct3D, so if these ideas don't sound like they would work well, let me know. =)

Here is how I'm planning on representing different things in D3D terms.

Front Buffer - ID3DSurface9
Back Buffer(s) - ID3DSurface9(s)
Tiles - MipMapped ID3DTexture9s (64x64, 32x32, and 16x16)
Sprites - ID3DTexture9s
Layers - Arrays of pointers to tiles (textures)

I'm thinking maybe load an entire tileset into an ID3DSurface9 and generate a series of release the surface once the ID3DTexture9s have been created. I'm not sure how efficient this is. Monolith, I'd appreciate your thoughts on how Direct3D should be used, as it seems like you've had some experience.

A kind of 'quad-map' would be used to write tiles (textures) to the back buffer. While the quad-map would generally contain all square quads, it would occasionally morph (under water, around large explosions, etc.) to make for easy warping of scenery. I hope that made sense.

I'm not planning on using COM architecture, just interfaces. For those that aren't sure, here's how interfaces work using seudo-C++.

/*

 * Base item class

 * i.e. defines basic properties and methods of all items

 */

class ItemBase

{

     float weight;

     string name;

     virtual void Use() = 0;

};





/*

 * Inherrited by all container objects

 * i.e. objects that can hold other objects

 */

class IContainer

{

     virtual Item GetNextItem() = 0;

     virtual void AddItem(Item) = 0;

};





/*

 * Sample item that implements the container interface

 * i.e. inherrits from IContainer

 */

class BackPack : public ItemBase, public IContainer

{

     // From ItemBase class

     void Use() { ... };



     // From IContainer interface

     Item GetNextItem() { ... };

     void AddItem(Item i) { ... };

};

The idea is, an interface doesn't actually contain any code on 'how' an object should perform a specific task. It mearly defines what tasks an object must perform. If you're unfamiliar with the 'virtual' or '= 0' bit I've added to the functions, that's just the way to define a function that 'must' be overridden in all derrived classes.

The benefit of using interfaces instead of full-blown base classes is that your derrived objects can be much more specialized in how they perform tasks. More examples:

An IDrawable interface might declare (but not define) functions for coloring, transforming, and rendering.

An ICharacter interface might declare (but not define) functions for walking, jumping, and dying.

An IHasMass interface might declare (but not define) functions for applying forces such as gravity, wind, friction, or magnetism.

Shall I suggest a plot?

The only way I would be able to contribute currently would be web site design (just formats and graphics, none of the special php or anything). If that is needed and I suffice, just tell and I'm there.

Wow. This sounds really cool.

As for helping out, I have nil experiance with C++, but I can help out with tilesets. (I'm currently working on a factory-ish tileset, and I can send it to you if you're interested in seeing the quality of my tilesets.) I might also be able to make a few low-quality 2D sprites for the game, if you want.

Originally Posted by Piccolo

Shall I suggest a plot?

No keep your suggestions to yourself, please.

Ahhahaha...

Yes. Please share.

Pmed the plot I had in mind, and now I'll go do concept sketches...maybe...

I'll have to look into the D3D stuff since I haven't actually been the one to do that part of the code. One thing I do remember right now is that the optimal texture size is 256x256, so probably what you want to do is put multiple tiles on a texture of this size, and then just set uv coordinates on the quads to show a single tile. Same idea should go for sprites as well.

Hmm.. let me think a little bit on how big all of this might be. A 256x256x32bbp texture takes 256 KB of vram. Let's assume we want to make everything be able to fit on a 32 MB video card. Since we don't really have all that many vertices to worry about, we can say that there's about 25 MB available for textures. (The front and back buffers at 800 x 600 would take 3-4 MB.) This leaves us with room for 100 of those texture blocks. I'm not sure how big you're thinking of making the tiles or tilesets, but for this I'll say we want 4096 32x32 tiles. We can fit 64 tiles onto a texture block, so this would take up 64 texture blocks. This leaves us with 36 texture blocks for sprites, hud graphics, particles, and whatever else needs to be on the screen. I sort of doubt that that's enough room left for sprites and their animations.

I donno, that's just some initial thinking.

I don't really see any need to make code empty interface classes since you can always overload inherited virtual functions. Sometimes it's nice to have a default behavior anyway. I see no problems in doing it this way either, so whatever you prefer. The thing I am a little concerned about is the multiple inheritance. This has been I've been told not to do many times, however I'm not exactly sure why..

Multiple inheritance is generally a bad thing, yes. Interfaces are the exception (according to Andre LaMothe). In fact, one of the main benefits of using interfaces is that you can have multiple inheritance without much trouble, which allows for cleaner class heirarchies. For example:

Below is a generic class heirarchy.

Object
   Character
      Enemy
      Player
   Item
      Shield
      Weapon
      Ammo
      Health

Problem: Some items can be held in an inventory, others are simply collected.

Solution: Make a seperate class for inventory items

Object
   Character
      Enemy
      Player
   NormalItem
      Shield
      Food
   InventoryItem
      Weapon
      Ammo
      Gem

Problem: Some inventory items can be used at will, others are just there to collect or are automatically used when needed

Solution: Make a seperate class for usable inventory items

Object
   Character
      Enemy
      Player
   NormalItem
      Shield
      Food
   InventoryItem
      Weapon
   UsableInventoryItem
      Ammo
      Gem

This leaves us with an increasingly complex structure. Eventually, you're going to have an item that belongs in more than one group (needs methods or data from more than one base class).

Here's the same heirarchy using interfaces.

IInventoryItem
IUsableItem

Object
   Character
      Enemy
      Player
   Item
      Shield : IUsableItem
      Food
      Weapon : IUsableItem, IInventoryItem
      Ammo : IInventoryItem
      Gem

Maybe not the best example. I'll try to use something from my actual code (when I get that far).

Originally Posted by Onag

No keep your suggestions to yourself, please.

Ahhahaha...

Yes. Please share.

Eh...heheh... *cough*

Well...

The planet of Mechaius used to be a totally normal, though alive planet (this "alive planet" thing should sound familiar to FF fans. )
That was the situation until a virus destroyed its inner core, practically its heart.
There were already humans (or whatever. Just intelligent creatures. ) already inhabited the planet, and they used technology in order to keep the planet "working".
As their technology kept getting more and more advanced, they began to turn themselves into cyborgs, to gain immortality, as Onag already said.
This continued to a point at that a part of the population only consisted of the most important part of their brains inside heavy metal suits.
These began acting like the Borgs, warring those who still had parts of their own bodies to gain power over the planet.

This could also be caused by the virus.. that could give an extra quest, or several even.

My plots better. Nyahnyah.

Silly Faw, this is a Gundam rip off, not a Final Fantasy rip off! Theoretically the best plot would be written by someone who never watches movies or TV and never plays video games. We get the most originality that way. Heck, maybe I'll try to write a plot too...

Gl Hf Dd Ka

And once again, everybody ignores me. ¬_¬

My plot idea:

It is not the past, present or future. Nor does it matter, after the discovery of time travel. Unfortunately, time travel is available to all of mechkind. Dislike your enemies? Destroy whoever created them. Abuse of the grandfather paradox is common. The only authority in existance is the Protectors, a collective mind with the soul purpouse of keeping the planet Mechaius, home and source of all mechs, in existence.
As space and time crumble, a new robot appears. Nobody knows where, when, or who he came from, even himself. His alliances are badly chosen at the start, though he secretly seeks the answers to his past. As the truth is learned, his purpouse becomes apparent: There is only one way order can be returned to this crumbling universe. One way this shattered continuum can be repaired. Mechaius must be destroyed.

Essentially, you'd play as a mech who starts with a rather blank personality. You'd start out sided with the Protectors (creative name, no?) for lack of knowing anything else to do, but slowly notice the importance in restoring order to the space-time continuum. Your goal would be to destroy Mechaius in it's early stages, which would solve the problem but "delete" yourself from history in the process. Can you say "multiple endings"?

Originally Posted by Radium

My plot idea: ...

I think we have a winner.

-Nag

Wow, Rad came up with an adventure game's plot, Faw came up with an Rpg, and I came up with a RTS plot. Strange. Well, seeing as how everyone is posting their plots for all to see...

You are working under a protectorate. You are developing fast and growing strong and expanding well. One day you come under attack by some efil force, and you turn towards your protectorate for help. You see them eradicate their forces, and you rebuild your empire. Eventually, you strike back at the force that originally attacked you. You spend a while decking them, and you get attacked from once allied forces of your protectorate.

I guess it could be mostly linear up to this point but branchy off when you get to chose your allies, or it could use the predetermined plot I sent to Onag. *mumbles*I liked that plot*mubles*

After reading this thread, the general idea of this game that I have gotten is an action Pokemon game with a sci-fi plot and robot pokemon with online play and a level editor. Disagree with me, please.

Originally Posted by KRSplat

After reading this thread, the general idea of this game that I have gotten is an action Pokemon game with a sci-fi plot and robot pokemon with online play and a level editor. Disagree with me, please.

I disagree with you, please.

Personally, I think Radium's idea is the best. Plus, going in past would allow for some really interesting environments, and you'd get to see the whole planet change. The problem is that you'd have future technologies in the past, so you'd think they would be able to achieve destruction quite easily just after going in back a while. I think.

You could do that by giving "powers" via pickups, and they would simply not exist in the past, or not work there, or whatever. You should watch out though, it might become like in JJ2: once you got 99 seekers you are practically invincible. I'm not sure how to implent pickups ins omething else than a platform game, though

Originally Posted by Spaztic

The problem is that you'd have future technologies in the past, so you'd think they would be able to achieve destruction quite easily just after going in back a while. I think.

Keep in mind that Protectors from every point in the future are coming back in time to stop you.

Yay, I had a good idea!

*mutters curses*

Originally Posted by Radium

Yay, I had a good idea!

I'm really liking this. Instead of a linear set of levels, we could have a predefined set of "areas". These areas would be locations on Mechaius (and maybe a few on other planets?) of specific importance. Each area would have pre-defined important times that you could visit at any time.

It would be kind of like MegaMan's level selection, in that you could choose which area you want to go to at any time. But, you would have the additional time aspect, plus you'd be able to (in fact, have to) return to some areas/times several times throughout the game.

Everything you do would affect things in different areas/times.

On a side note, I also like the idea of the planet being mechanical to an extent. It would make sense that people who have mechanized themselves would also mechanize their environment to a degree.

I ALSO like the idea of having to go against your old allies in the end. I think you should innitialy side with the protectors (or whoever), who secretly know the source of all of the problems is Mechaius. Anyway, when they realized you're finding out too much, they turn on you.

Okay, too much to think about when I'm supposed to be working. More later.

-Nag

Yeah, why don't we just combine the three stories?

Originally Posted by Piccolo

Yeah, why don't we just combine the three stories?

What aspects do you suggest we combine?

The best. Which don't contradict each other.