Metagame Reboot - YOUR PARTICIPATION IS REQUIRED!

[Ignate]

While me and matt work on the engine, I'd like some of the design to be taken off my shoulders, Ignate, would you be alright with heading that up? I really love what you've been doing, I'd love some of that feel to be put into this.

AHAHA no way for srs? That'd be awesome. I'd love to.

Question though. Do the enemies (soldiers) have to be 32x32 pixels, or just the player? What colour scheme will be used for Bin Hero, and what are the dimensions for tiles? 40x40 or 76x76 pixels? I need some size and colour specs to work on the sprite concepts.

EDIT: Also wtf you guys are brainstorming during the times I'm not at the PC

[mattk210]

australian/new zealand timezones is why. (And I'm up far too late).

I wouldn't say it would matter what size stuff is - we'd want both big and small stuff and (i'm not aware of) any specific limitations technically. Just make sure everything is on the right scale next to each other. I believe right now our tiles are 32x32 but it's set up with chunky pixels so that's design space of 16x16. We could change that in basically any way in about five seconds.

Geti can probably tell you more about colours/styles. But if you're heading it up, i'm pretty sure the choice is yours. just make it look good :)

we totally need to not name our main character so we can have people using awesome names like Mr. T and bin hero, haha

[Ignate]

Sprite update.

I like how the new limes came out, but now they look a bit out of place compared to binbot. :P I'll play around with his colour scheme I guess.

Oh, and here's an idea I had for a HUD display.

The gadget icons can be simplified of course, but I guess that's for later. The map can be viewed bigger by acessing the pause screen or something. Oh and I used N sprites a bit because I don't have sprites for keys and enemies yet. :P

I have two problems with this. First, the text is a bit hard to read, but that can be fixed easily. But I find that it's a bit crowded on the left side, especially the tally and switch zone indicator space. I may have to revise the layout later.

The idea I had for the HUD is that it's sleek, offset against the roughness of the game, as geti said. It shouldn't be too glaring, and it's neatness allows the player to read it fast. I was going for something like in the Ratchet and Clank games, see below. Any thoughts?

[Universezero]

That HUD looks really awesome man. It just seems a little too... in your face for gameplay. Maybe a duller colour, and a bit more simplified? Also, I think that you should make is transparent, like in R&C. But still a really good concept. ;)

[Geti]

AHAHA no way for srs? That'd be awesome. I'd love to.
Question though. Do the enemies (soldiers) have to be 32x32 pixels, or just the player? What colour scheme will be used for Bin Hero, and what are the dimensions for tiles? 40x40 or 76x76 pixels? I need some size and colour specs to work on the sprite concepts.

Glad you're happy to.
Tiles are actually smaller than the player, 16x16, as matt said. If you think in the actual resolution (the resolution before scaling) it could be easier for you design wise. The game is 400x300 pixels scaled 2x, but yeah, as matt's said we can change that if you need. It could be a good idea to keep enemy size down (not restricted as such, you can still have fairly epic bosses and large tanks, just maybe keep to a soft limit of 2x the player's size) because unless we want to go for a full rewrite, flixel only has simple bounding-box collision, which will make larger enemies behave strangely unless they're made up of components (more work <_<).
Very much liking what you've done with the limes, hahah! I think the reason they clash with the bin is the different outlining techniques. On the bin's colour scheme, I very much like it being grey and having lots of contrast in all but the tech-zone areas, but also having some rust/mould on him too. for the pixel art, maybe try using the palette I developed here for sandbagging, and make edits where you want more colours?
On the map, we should probably make it only display the nearby screens, as some of the worlds will require a lot of screen space to display that way. It'd also be nice to have some indication of whether you can walk sideways off the screen or not, too.
How are we going to do vertical mapping? Loving the switch zone indicator, though maybe we should have some sort of in-game indicator as well? (maybe some lights on the player's actor?)

One big note I'd like to make about the HUD is maybe it should be on the bottom of the screen instead of on the top? there's already some free space down there.

we totally need to not name our main character so we can have people using awesome names like Mr. T and bin hero, haha

Yes, this.

[Ignate]

ARGAFLAF FINALLY I've finished binbot's walk cycle. Hopefully it's satisfactory.

Any suggestions for the army colour scheme geti? I'm sort of stuck there.

[squibbles]

Ok, whoa, guys, slow down. Seriously.

Right now, we're just flying directionless. We haven't even decided on what we're doing, supposedly, and out of nowhere all these designs are flying everywhere. This is going to ultimately constrict the potential of the game, because we'll be conforming to what has already been unofficially stated.

Stop
Start over.
Talk.
Write a brief statement of intent. In this include what we want the game to do, how it should do it, what we will include and how we plan on doing that. Include everything, from the language in which it will be coded to the colour scheme of the background.

Only once this is done, and our goals for the game been established, and clearly stated, should the creative proccess actually begin. We should not be having sprites and huds and opening titles thrown around at this stage.

[Geti]

Hey, squibbles, I don't mean to sound rude or anything but for the most part, momentum like this is actually the best way to get something done (see: previous metagame - we talked for half a year and matt got a few prototypes working, while everyone got frustrated with no progress). It's why prototyping is such a good tool to use in large game production, because you can see in rough terms what you're trying to achieve very quickly, and then refine from there, but I agree that we're going overboard with design. Just don't take everything as final, just about everything could change (though I very much like our little bin).
This is how I make games and get them done, personally.

We can slow up and all get onto the same page, everyone can have a say, but they need to say it quickly if they want it to be part of the initial concept (though the main idea is very likely to evolve over time, so it's not like there's a hard deadline for "get a word in". It just won't be in the early builds.)
In any case, see below for my intent write up.

colour tests.

Statement of intent: Geti
Overall game synopsis:

• A faux-3D platformer with a strong focus on level creation and author freedom (though not data-driven) with a puzzle focus and combat elements. Each level is separated into discrete screens between which the player can travel as though within a 3d grid.

Game Language: Actionscript 3.0 using Flixel as a base - having this in flash will make it more accessible overall, and prevents platform dependency. It'll be a learning experience for me, but it's looking easy enough, and there's a lot of online support for anyone interested in lending a hand who's inexperienced.
Key game goals with elaboration:

• Axis aligned tiles: only solid and non-solid tiles should be available for level design, this will speed both development of a level format and the game overall as flixel already supports tilemaps.
• Complex Player Movement: This will keep platforming interesting and allow emergent gameplay.
  • Jumping, walking, crouching - The basic player actions. Crouching may have stealth aspects.
    Walljumping - Possibly as an unlockable
    Rolling - Allows the player to get under small gaps, but prevents the player from changing direction.
    Possibly a Jetpack unlockable.
• Community/End User Focus: I want the editor to be usable, the level format to be distributable, and everyone to have a say in development. Highscores / demo-data and a hosted map archive site would be a definite plus. Make the game to last, "just like N did".
• Rich environments: I'd like the focus of the vanilla content to be on developing very rich levels, no "boring" screens, with some exploration but not to the same degree as knytt.
• Puzzle Focus: Enemies and interesting platforming will prevent moving from screen to screen from becoming boring, but the focus of the level progression should be in it's puzzles, probably with thematic challenges for each level (mine-jumping areas could be a focus in one area, while a complex key-door puzzle could be the focus of another)
• Non-frustrating gameplay: Rather than use a checkpoint system, the game could be saved whenever you travel between screens, and if you die on one screen you would just load your last save, preventing grinding through an area many times to get to a particularly hard puzzle.
• Combat: The player should be able to approach enemies from many angles, including combat. The player should definitely not be very powerful at any point though (even if you pick up a railgun, you should only have a few shots with it, or it should drain your health).
• Logical Design: Everything should have a purpose, and a logical reason for it to exist in the game world. Case example: The limes have evolved to be mostly inedible to the fauna of the archipelago, so they're common and naive (the initially don't fear you at all). All the mechanics should have a logical grounding behind them.
• Hand-Drawn art feel: The game's art should be produced by hand, resized and then touched up at a pixel level, but should maintain a "scrappy" feel. This will put less stress on the artists to produce "perfect" assets and allow us to explore designs more. For the final production version we can reiterate each asset set and retouch each sprite as needed. I'd personally like to keep this in raster, but that's personal preference. I feel that if we go for a warm, muted palette, the spritework will fit together better, though it'll lead to desaturated blues..
• Musical Motifs: The best example of this that comes to mind is the Pirates of the Caribbean soundtrack, each piece usually incorporates one of two musical motifs, and it helps all of them fit together wonderfully.

Some Implementation Notes:

• Each of these goals should be discussed beforehand to assure all of the developers will be going about solving them in the same way.

Preferred position on the Team: Project Head/Manager, Coding and Art production (I can help with music but I'd prefer a more minor role there)

Some further points.
Milestone System: We should all agree on a milestone and work towards that. In between milestones we can have further conceptual development, but during milestone production time everyone should work towards that goal.
Use of IRC: All active developers should attempt to take part in the IRC discussions at least twice a week, and keep up-to-date with the forum thread.

EDIT: still not done, but I'm going out now. Still needs a lot of refining, synopsis isn't complete either.

I'd like everyone to write up one of these to see if we're all on the same page.
We should also establish leads in each department of development, I'd like to maintain the position of Head here but I'd also like other people in leadership roles. Ignate would be my candidate for artistic lead, and Matt for programming, but I'm not sure who for music; I'm not sure who's on board for it. THAT MAKES THE PREFERRED POSITION PART OF EVERYONE'S STATEMENT VERY IMPORTANT.

template statement:

Code: Select all

[b][u]Statement of intent: <NAME>[/u][/b]
[u]Overall game synopsis:[/u]
[list][i]SYNOPSIS HERE[/i][/list]
[u]Game Language:[/u] [i]ONLY IF YOU'RE CODING[/i]
[u]Key game goals with elaboration:[/u]
[list][*][i]TITLE:[/i] ELABORATION[/list]
[u][b]Preferred position on the Team:[/u][/b] POSITION(s), ELABORATION IF NECESSARY

[squibbles]

I don't mean slow down the progress, but maybe actually do what we need to do first. At this rate, ultimately all we're going to have is a thin, derivitave game, if that. Without planning we won't have anything other than what first jumps to mind, the ideas of which are inherantly generic. I think we should just start at the begining.

Sure, getting on the traintracks is great, but if you do it 10 kilometers out from the station, you're just going to get run over.

[mattk210]

I guess it is a shame that we didn't have a long ideas phase because I really liked squibbles idea and I actually think it could have worked for a whole game. But yeah, we kind of needed to show that we were actually going somewhere because I don't want to waste my time again getting nowhere. Anyway, experimenting with stuff is far more effective than theorywork in making a game fun.

Statement of intent: Matt
Overall game synopsis:

• metroidvania style platformer with a focus on interesting multipurpose mechanics

Game Language: something multiplatform, AS3 works for me
Key game goals with elaboration:

• total avoidance of RPG elements: nothing should be gained by repetition in any circumstance, decisions that aren't super short-term should always be reversible. (so no master ball style design). Avoid luck-based stuff as much as possible.
• short, varied game: we should be constantly introducing new stuff to the player, and if we run out, we make the game end there.
• non-frustrating design: don't particularly care how saving will work but opportunities shouldn't be too sparse, and stuff in between save points should decrease in difficulty so you don't have the situation where you repeatedly die against a hard bit and are forced to repeat an easy bit over and over.
• user content: users should be able to build levels with a comparable amount of options to actual designers
• combat: I'd rather see the game not be all that combat oriented, and most weapons should have an alternate equally useful use, like flying with recoil or something.

Preferred position on the Team: programming and design, maybe a tiny bit of art?
Not a big fan of IRC, I might drop in occasionally but I'd prefer to mainly use github and the forum. If we have general meeting times that would be better though.

[Geti]

I don't mean slow down the progress, but maybe actually do what we need to do first. At this rate, ultimately all we're going to have is a thin, derivitave game, if that. Without planning we won't have anything other than what first jumps to mind, the ideas of which are inherantly generic. I think we should just start at the begining.

I don't think starting over entirely is a good idea. Regardless of what the end concept is, we're very likely going to be working on a platformer, which is really all the current engine is anyway. Instead of theorising about what we should do, let's just do it, hey? More discussion needed? Good, let's get on that.

Avoid luck-based stuff as much as possible.

Heck yes.
It's a shame you don't like IRC, Matt, it's very good for getting more collaborative design going (you can interrupt people ;) it helps sometimes).

The reason I'm less than exited about having each world focus on a different gimmick is that I'm not sure we need all those gimmicks, I think, for example, that N gets away with using the same design aspects the whole way through and we could easily do the same (especially because we have a whole community of people who are used to working with a fairly limited toolset and object library). However, N does have all the extra tile complexity that I'm not sure we should pursue (We don't want to make a clone, just learn from what works and what doesn't), so having greater object complexity and graphical tiles could help bring enough variation to keep gameplay interesting, as well as design interesting.

[mattk210]

the reason i prefer forum is that can just take a break from whatever I'm doing, drop in and add something in my own time whereas for IRC I actually need to stick around and participate in a conversation.

I'm obviously in the minority but I think N is too long, repetitive and frustrating (I only finished a total of like half a column before giving up). I would actually welcome some well-implemented gimmicks.

[Geti]

Re: IRC - fair enough :P
Also really? I always used N as something to sit down and relax with, it took me out of whatever situation was draining me at that point and made me focus on MAKING. THAT. JUMP.

I would actually welcome some well-implemented gimmicks.

Oh, me too, but I don't think using them as a focus for each world is that great an idea. I like constant variation, so if we use the 3d gimmick, I feel it should be used everywhere, if we do destructible tiles I'll likely be using it every world I design, etc. One that I wouldn't use every world would probably be the paint one though, it'd have to have it's own place.

EDIT: added ignate's latest sprites and got levels ACTUALLY WORKING!
awesome, huh? sort of, I still need to fix lots of bugs and update collision boundaries.

EDIT2: updated github, player movement is gimped for some reason (I'll look into it soon) but the level object is working as far as I can see. I'll work on getting transitions happening as soon as I've fixed the player issues (we might want to make a base object class that does all the fun stuff player does in its update and make player an extension of object), so we can see if this 3d thing is going to work.

[Geti]

Proposition for the project's colour space: a 32 index palette that could possibly be extended to 64 colours.
It's fairly muted, meaning lurid colour use will be hard, a plus or minus depending on who you talk to, and lacking good yellows. If we do go for a palette (which would help tie the graphics together, even if we do use colours outside of it (I often find myself using swatches when painting to help everything mesh)) it'll need development throughout the yellow ramp (I warmed the colours too much, by the look of it) and the dark end of all the cool ramps (there is no proper dark cool colour, as you can see from the blue/cyan ramps).

Something to think about, in terms of design.

[Ignate]

Statement of intent: Ignate
Overall game synopsis:

• A platformer playable on most systems with relative player freedom (exploration). One or two interesting game mechanics such as faux 3D and creative use of puzzle aspects.

Key game goals with elaboration:

• Replayability: Different approaches to solving problems or taking paths, and branching levels to prevent getting stuck. Also, user-made content.
• Combat: Possibly flexible combat mechanics, such as aiming at an angle to ricochet a shot at an opponent, as opposed to just shooting straight.
• Defined gameworld: Basic backstories for the protagonists and enemies.
• Varied gameplay: Creative ways to solve problems like unconventional uses of weapons. Certain areas could also emphasize a skill like accurate jumping, but in a way that the player doesn't get stuck if the skill isn't mastered yet.

Preferred position on the Team: Artistic design, conceptual design. That's pretty much it.

I don't really have much goals, as long as it's fun I guess. :P I'll be mostly on this thread, since IRC is a tad inactive when I check in. I should be mostly active on weekends due to school.

Also, are all the tiles just going to be square and non-square (empty), or would they have angles like in N? I'm confused about that.

[Geti]

At this point the plan is to have only filled or empty tiles, to cut down on workload. Doing other slopes would involve rewriting quite a lot of flixel (possibly just incorporating Box2D instead of flixel's native boundingbox collisions), which would eat coding-hours.
What time zone are you in ignate? Me, orange, r[e/o]maniac, and matt are between GMT+8 and +12 I think (depending on where in aus some of them are). I'm unsure about a lot of people though, in fact I'm unsure of how many properly active members we have working on this. Orange seems pretty keen, me, ignate and matt are doing stuff, but everyone else seems to be taking the drop-in drop-out approach, which is fine, but it'd be nice to know where we stand in terms of active developers.

Edit; I've updated the OP quite a lot.

[Universezero]

Oh yeah, this is important. I can help with music for you guys; here's a quick thing I tried: http://www.megaupload.com/?d=Y0HZS4MH

[Donfuy]

I'm GMT.

• to the people who are making songs, if you ever need a real bass in your song, tell me
• the hud: I enjoy Ignate's design, although I agree with Uzi - it's pretty big and too much info. Maybe we could have two huds? Like, a bigger one and a smaller one. You click a button, and the smaller hud slides down a bit to show other stuff, and thus showing the bigger hud. (I hope I'm being understandable
• I like those soldiers' designs, Geti, but those hats make them look too... friendly (maybe it's just me but they look so cute)
• about the soldiers, and this is just an idea, what about having different ones for different weapons, like they are specialized for that only weapon, and they couldn't possibly use another, cause that's how they were set up to. also, we should have some kind of melee soldier

[crescor]

Oh yea, just wanted to say that I'm probably slacking at the moment, but around next week I'll be back and start working on music like never before.

[Geti]

I like those soldiers' designs, Geti, but those hats make them look too... friendly (maybe it's just me but they look so cute)
also, we should have some kind of melee soldier

Hahah, true. I might do some more concepts with them but I'd rather focus on coding for a bit.
I'm not keen on a solely melee soldier (We have other enemies for that), but maybe they could also have a strong melee regardless of their specialisation (if we include that). I was considering using the same object and just giving them an inventory system, but that'd be another facet of the AI we'd have to write..

edit: @crescor: that's fine, music isn't incredibly important at this stage, though it could have influence on the end style if we get something AMAZING that we're certain to use I suppose.

[Universezero]

Got another potential song here: http://www.megaupload.com/?d=P0TRPLKW
Any thoughts on the style? Too soft? Need more action? Any other songs I should make?

Also, just to clarify: what's the goal for the character in this game? Is there a story? Why are there inhuman soldiers walking around the place? Is this game anything like Wall-E?

By the way, does anyone know a website where I can upload songs and then put them in the [mp3] tags?

[mattk210]

er the reason for that collision bug is that you commented out my collision code. Why did you do that? As I said, collision needs to be called inside player.as, it just needs to be defined outside it, for reasons I explained. You were trying to collide before integration. I pushed a quick fix.

Before we try and add any more stuff, I think the code needs to be refactored, some of the it is really messy. We also need to standarize naming conventions and such

on another note, is it just me or has everything gotten much faster since your last commit, geti? binman is basically zipping along the screen.

[Geti]

er the reason for that collision bug is that you commented out my collision code. Why did you do that? As I said, collision needs to be called inside player.as, it just needs to be defined outside it, for reasons I explained. You were trying to collide before integration. I pushed a quick fix.
Before we try and add any more stuff, I think the code needs to be refactored, some of it is really messy. We also need to standarize naming conventions and such
on another note, is it just me or has everything gotten much faster since your last commit, geti? binman is basically zipping along the screen.

Oh jesus, really? I keep commenting out odd things when I'm tired (last time the crouching scalar, this time the collision logic, ffuu-), I should stop touching the code after 12am I think :P Sorry about that..
I think a few things could be best gotten out of the way now, to simplify code later (on top of a lot of refactoring):

• A base DynamicObject class to extend most of the other game objects from (with things like gravity scalars, collision logic etc).
• A base Actor class extended from there to extend Player and enemy objects from, with a controller object (that can be linked to player or AI) as the main extension. Should probably have movement linked to the controller here for us to override if we need to.

Both of them should probably have switches for most of the functions not native to FlxSprite (like movement linking, probably gravity (for keys), it could be a good idea to have bouncing as part of the object code too, for gibs and the like).

The superfast movement could be possibly a double Player update, I've been pretty haphazard lately and that was one of the problems I was having.. If _player is getting updated separately to _curscreen in the Level, that would explain it, I'll look over it tonight and fix any stupid mistakes I've made.
Sorry for all the mess, a refactor is definitely a good idea. Do you have any preferences for naming conventions etc?

UZi, I haven't been able to listen yet, sorry :| You should consider soundcloud or at least drop.io (it has a preview from .mp3s)

[mattk210]

sounds like a good plan to me. I think the most immediate things we should do (before completing milestone 1) are:

• refactor string methods and junk in level.as, refactor bounding box code in player.as, clear out old commented junk that's floating around, maybe other stuff?
• variable naming. Don't really have any preferences, the main thing that bugs me is public variables with leading underscores.
• fix that timing bug.
• fix that superfast movement bug.
• A base DynamicObject class is definitely a good idea, we won't need it for what we're planning in milestone 1 but it's definitely a good idea to set up in readiness.

OK i made a quick fix of the speed bug (update was indeed being called twice. You updated the whole group then you updated player.as as well), and I fixed the timing. Next I'll refactor player.as.

[Geti]

Sweet, I'll work on clearing out the leading underscores if you don't like them (I'm not fussed, just an old habit for publics so you get Player._pos.x or whatever which stands out more), and start refactoring the level code. I'm not sure what you mean with the string methods, but I'm sure I could clean it up a hell of a lot more than it is.

What do we want for the DynamicObject's properties? Just the majority of the new update code, and gravity scalars, or do we want anything else? I'm about to go out, but yeah I'd like to do some coding tonight, I'm sick of writing essays xD