Varis's "shuper shecret project"

Yep.
So I’m gonna start coding a game engine. And an editor. And I’m pretty much going to use this topic to organize my thoughts and get feedback as things move along. It’s not really going to be a “fan” game, of course, but it’s the only section that makes sense =3

If you really don’t give a shit about any of this, there’s a tl;dr at the bottom of the post. Sorry for wall of text. It’s for me, not for you.

My “shuper shecret project” doesn’t really have a name yet, but I eventually want it to be two games. First, there will be a single player game, and maybe a co-op mode, maybe with LAN support. Second, there will be more of an arena type game with a focus on 2 v 2 and 4 v 4 gameplay. I plan to have online support for this game… Although I’m not sure what the best approach is yet. But I’ll get into the gameplay a bit before I go into that.

Gameplay: The games are going to have either a 2D or 2.5D side-scrolling view point. I haven’t decided yet because I’m terrible at both spriting and texturing. ^^
But the gameplay will be something like… Smash Bros mixed with Megaman Zero. It’ll be a bit floaty compared to MMZ (slower up and down speed), and a bit faster than SB. (faster left-right speed… Maybe not inherently faster, but the incorporation of a dash button will make it a bit faster paced.) I’m modeling the controls to assume a D-pad for movement, four buttons on the right hand side (jump, dash, fast attack, power attack), and four “shoulder” buttons to be used as modifiers. Holding a shoulder button changes the fast/power attack buttons to other “special” attacks, some inherent to the character, some chosen by the player. The jump and dash buttons will not change when a modifier is held down.
(This is subject to change, just like everything, I suppose. I may convert two of the shoulder buttons to block and grapple, or maybe just one to block. I currently plan to activate block when the player holds the fast and power attack buttons.)

It will be possible to play with a keyboard, but probably more inconvenient than it would be with a game pad. Co-op or any other gameplay on the same screen will be almost impossible with just the keyboard, which is why I might include LAN support.

I plan on making a level editor that I’ll include with the game… and probably build most of the game with. I’ve got no idea what kind of support/features/capabilities will be going into it, but I’ll be gearing the single player one towards custom “campaigns,” with a more open focus on the multiplayer one, allowing for multiplayer campaigns, arenas, odd mini-games, boss hunts, custom game types, etc. I THINK I’m going to try to incorporate custom models and skins, but I’ve got no f$%&ing clue how to do any of it yet, so we’ll see when I get there, yeah?

But this is where I start asking for advice: For the level editor, my original thought was to make it generate a list of coordinates for the top-left points of both graphics objects and collision rules. Buuut… Is there a more efficient way than a list? Should I combine graphics and collision rules into one list object? Does it really matter?

Aaand network play… more advice. The one area I tend to shy away from when I’m thinking about this stuff. There are a couple possibilities: peer-to-peer, private game servers owned by me (lulz), and public game servers owned by people in the community. Since I’m just a lil guy with no funding and no way to pay for a game server, and since I’m not planning on having enough of a following to warrant community servers, peer-to-peer is the most likely choice. But I feel like this is going to hurt gameplay. To reduce input lag, (like the horrible lag in SSBB) I plan on including lag interpolation… To the most effective degree possible, since I’d like the game to be viewed as a competitive game. Unless I’m way off, this would be easier (and better) to do with a client-server relationship, not a peer-to-peer relationship.

I suppose it might be possible to have peer-to-peer support, of sorts, and choose one player to “host” the game… Then still have support for dedicated servers. But again, give me your feedback, and I’ll cross the bridge when I come to it. Core gameplay first, networking later. The level editor, in my eyes, is much more of an important issue.

Random fact: Likely going to use DX10 libraries, unless DX9 suddenly looks more appealing for some reason.

The random questions that have been asked either in a rhetorical manner or by some curious fellows who took interest in this project:

1.) Varis! Why two games? Why not just package the multi-player and single-player components together?!

A: Lots of reasons. First, I want to get this s#&$ done, and it’s going to take me much longer to figure out the multiplayer portion of the game. (first-point-five) I’d rather release the story-based game first, get the game spread around, get people playing and interested, and then have an audience ready and waiting for the multiplayer portion. This also means that I’d get more feedback for the multiplayer game, which I’m hoping will help make the game as awesome as possible.
Second, I don’t necessarily want the engines to have the exact same physics. I want to be able to tweak the multiplayer engine for balance/competitive gameplay reasons without changing how the singleplayer game feels. Also, there will be different things going into both editors, and I feel like having the two games/editors separate will make things easier for people and remove some excess features that are only meant for the singleplayer or multiplayer game.

tl;dr:
I’m going to be making a game, here’s a bunch of random information on the core of the game and no information on the story, give me advice and feedback. Also, I need programmers/sounders/drawlers/modelers to make the game for me. lol j/k.

Double post so I can put story crap here without making the first post any longer =3
I’ll do this at a later date. Like, tomorrow at school or something.

An editor’s internal organization should be able to produce what the game engine itself wants. So in my mind, a good rule of thumb would be to make them match. :stuck_out_tongue:

For example, if the game engine is designed to handle collision boundaries as one thing and foreground/background graphics as another, the editor should keep them separate internally or at least be able to separate them when finalizing the level file. Likewise with lists. If the game engine stores collision boundaries as a grid of tiles, the editor would preferably do the same internally, or at least be able to convert its list of shapes into a grid of tiles when finalizing the level file.

From the outside the user may think the editor is doing something else entirely, but internally the editor should be at some point converting their input into the format that the game engine wants. Don’t worry at all about the editor’s algorithmic efficiency. Worry about keeping the code organized and producing what the game engine wants. Laggy editors are not a problem. :stuck_out_tongue:

Aye, that makes a lot of sense. Thanks =D