Metagame Reboot - YOUR PARTICIPATION IS REQUIRED!

[Geti]

Oh, sweet, I'll do that split() business now, and maybe draft the DynamicObject stuff.
oh, also, for naming extensions of our own classes, not flixel's, it'd be handy to use the acronym of the derivative classes, for example Actor (as an extension of DynamicObject) would become DOActor, and Player (as an extension of DOActor) would become DOAPlayer. It could help when remembering supers, and i'm used to it from cortex command, could be something to think about..

EDIT: done the string stuff, made another mess of the Network with all the merges, but it's in. Might do some DynamicObject stuff tonight, might not, depends how much time I have after doing coursework..
I think we should get rolling into the player movements too, rather than sliding around as the crouchbin. I think crouch should only be crouch in the context of no movement, otherwise it should be a roll that lets you bounce off walls and get under stuff and the like.

THE LATEST BUILD FOR ALL YOU PEEPS OUT THERE

[mattk210]

i think we misunderstood each other when it comes to naming. I was ok with underscores for private/protected variables, indeed that's normal convention. Anyway for consistency I removed underscores from player.as

level.as looks heaps better now, that's great geti.

I might get started on rolling next. Some stuff to consider:

• should we programmatically rotate a sprite or have a handmade rolling animation
• flixel only works with square bounding boxes. Should I write some new collision code for collision with circles? (would come into effect when hitting a corner...) Alternatively, we could design rolling in such a way that it always goes at a high enough speed for that not to be noticeable.
• how would you begin a roll? just press crouch while running?

also is it just me or does that antenna look a bit strange? it's so pixellated i think it would be better to just remove it.

[Geti]

Oh, I see what you meant with the underscores. I'm not fussed either way, if you'd prefer them for privates then that's fine too. Glad you're liking the new Level setup.
I think a handmade rolling animation could be good, as the robot is currently at a 3/4 viewpoint
Circles could be useful in other places too, I'm not sure if we should do that just yet though (Though dynamic switching of collision bodies is definitely a good thing to have). Rolling would be triggered by hitting X while running, yes.
Also on the sprites, I think we should likely leave them until we have level sprites etc so we can see if they work, but they could use some touching up (especially wherever that grey-brown is used)
I'll try to get screen-screen transitions working today, or by the weekend. I should be able to get transitions on the x and z axis (assuming z is vertical and x and y are the horizontal plane), but forwards and backwards will take time unless I let the player travel whenever (no zoning yet). We might want to use masking to do zones by using FlxU.overlap and just not rendering the mask..

[mattk210]

i was thinking crouch could be like the cardboard box in metal gear where you can move, but restrictedly.

Not sure what you mean by masking, but if you can get it working, great.

[Geti]

i was thinking crouch could be like the cardboard box in metal gear where you can move, but restrictedly.

I like this. I don't think we can steal the camo index system and get away with it though :P But yeah, same idea in any case. Rolling would just happen when you were moving when you hit crouch. Context sensitive actions, hooray!

[Geti]

I'll just drop this here

It's buggy, but it gets the 2d movement semi-done. Bugs need to be fixed, but I thought you'd like to see progress. We need more discussion in here too.

Matt, what do you think about moving the changelog to the wiki? I'm thinking the readme will get really cramped really quickly if we stick to the current method :P

[Donfuy]

Character (Bin) should be much smaller, in my opinion.
The fall accelerates too fast.

[Universezero]

Character (Bin) should be much smaller, in my opinion.
The fall accelerates too fast.

He does look a little big... but if we make the levels big in comparison, then it should look fine.

[Geti]

a WIP mockup, scaled w/ 2x pixels like the game currently is.

I think we could make the painterly style work. I changed the perspective from the one I was imagining to a purely side on view of the landscape. We could probably still make the 3/4 view of the actors work though, suspension of disbelief and all.
I'm thinking of stealing an idea from Arne, where sediment and flora are destructible (forming gibs and particles which do physics and whatnot) to give the levels a feel of destructible interactivity, without doing it for the tiles (allowing for a more "planned" approach to level design). Still need to do a background, HUD, and actors, as well as some touching up on this WIP.

I'll do a writeup on the more technical/thought out aspects of the mockup in a while, I've got to go out now.

[noops]

So.... Is it too late for the time-travel? I hope it's not too late for the time travel.

[Spawn of Yanni]

After only a quick glimpse at that swf you just put up, geti, I'd agree with a smaller bin guy.

[Geti]

After only a quick glimpse at that swf you just put up, geti, I'd agree with a smaller bin guy.

Yeah, this seems universal, but I think it could be related to everyone being very used to a small ninja. However, it's definitely something to consider. If we stop scaling the res we could probably rescale the levels and keep everyone happy, he's really only 1x2 tiles big at the moment.

So.... Is it too late for the time-travel? I hope it's not too late for the time travel.

It's never too late, but you'll have to convince me and matt why it'd be worth all the extra work. for time travel, we have to:

• Implement cross screen movement (the main roadblock to the 3d screens idea, which isn't a big deal.
• Implement a way for the time layers to interact with each other (not easy unless we scrap the next point)
• Find a way to make this all easily editable with an in-game editor (it's one thing to edit tiles and place objects and decor, but another to work in with "time" as one of the factors affecting all of those things)

That list is, in a nutshell, why I'm unkeen to work towards time travel at this point. If we get a simple scripting system working (read: one that allows manipulation of level data, likely based on regular expressions that's still workable in-editor (for example, you could link a script to a key's activation, or to an area of tiles)) then the time travel aspect can be done manually. I'm not keen to sign up for a core game mechanic and a lot more work when I myself don't really want it that much though :P If I see a lot of community support for it, I'd consider it. I'm unsure of Matt's stance on it.

What do you guys think of the style of that WIP? I'll likely redo the grass in it, and I'm going to add some trees/clouds etc in the background, but I think I'm actually quite happy with the grid size. If we don't use an upscaled resolution we could have a larger grid I suppose, but I think the fidelity of the levels will be an overall thing, and one screen won't be too much of a big deal until later in the game, where the jumps are harder and the ways of dying are more plentiful.

example path through the screen.

I just drew the path in an threw an unsharp mask over it to get some more contrast into the background. I suppose if we're going to go whole hog on graphics we may as well have automatic lighting (we could manually "light" the edge collision tiles with highlights, but if the background tiles are all one colour and the decor is what makes up the texture (which I'm very happy with) then we could likely just render a darkening gradient at the collision boundaries of tiles that have bg tiles on them (more checks, oh well).

On that design, why things are currently the way they are:

• The texture in the ground tiles, and the uneven-ness of the lies: I found myself unable to draw the sediments etc onto flat tiles. I hand drew the lines (we'll have to organise how to do this with smaller tiles) and then added the stones (which improve the texture a lot, and could also just be part of the tiles), and this prevented the sediment and plants from looking unnatural (which you'd hope for, since they're intended to, you know, represent nature).
• The horizontal lines in the terrain: These perform a variety of functions. Firstly, they make the ground seem more natural, and break up the would-be flatness of large areas of tile. They'd be manually placed, as FGDecor, along with any larger rocks (currently not pictured). Secondly, in the darker area of background, they help make up the "bricks" of the wall, which could hint that the cave has been constructed by something, which indicates history of the area. Even if we don't ever reveal it to the player, we should have some idea (or perhaps many "theories" or ways of explaining) the environment. Why is the terrain so square?
• The plants: There are only 4 plants present, and they've been "evolved" from 3 ancestors-
  • The green slime with occasional orange "flowers" - from mould.
  • The bulbous green tubers with/without orange stripes - from mould. (NB: the "grass" is made up of these in a dormant juvenile state.)
  • The blue-cap cylindrical mushrooms - from mushrooms.
  • The leafy plants with/without blue outlining on the leaves - from a fern. (NB: the blue outlining indicates sexually active plants. The "palms" will also be from ferns, and have leaf similarities)

None of this is final, of course, but it's always a good idea to think designs through in any case. I really love the sediment idea (stolen from"inspired by" Arne's exile project) and the rocky terrain, I think it'll make our world feel alive, no matter what the context. I think more development is a good idea, I'm not certain "a scrap heap" is a great final or short term goal, I was thinking maybe an AI interface could possibly be the goal, or a beacon.

TO BE CLEAR: The point of the 3D is not so you can see the goal getting closer. That would be neat, but is certainly not a reason. The reason is that making a true 3D game is beyond our scope, but making an in depth platformer isn't. The 3D-ness provides a way for us to write a portable, string based format for levels that are very complex while sticking to discrete screens.
I actually might be alright with having extended screen sizes that you can follow the player around in with the camera, but I'd like to implement that later down the track (that would be very good for boss levels, or any areas with a lot of combat really. The problem is that you're bending space if you make them take up the same area as a normal screen, but I wouldn't want to make the map change size based on how big a screen is. The Zelda games on gameboy did that well by mostly sticking to same-sized screens, I think.

A note on level data sizes before I depart (yet again :P) I'm not sure how much space the screens will take up in memory, but that's fairly trivial if we can store them again. What I understood recently was that the level strings are going to be massive. Like, stupidly big, for a string. Even for a 3x3x3 level (fairly small, when you think about it, that's the same as a 3x3 with past-present-future) if you have your tiles, background tiles, zone mask tiles, and even the tiny limit of 100 characters each for objects, FGDecor, and BGDecor per screen (on average, there could be empty screens), that's still 3*3*3*((25*17*3)+300)/1024 = about 41.5 kB, or 42525B assuming a character roughly = 1B. This is good news in the sense that if holding all the screens as screens becomes a memory hog, we can just store the strings in an array (updating them when ever screens are traveled between, meaning we'll need a screen.revertToString() function) and keep our memory usage very low in that regard, but bad in the way that it means even a small level with a low amount of objects in it will dwarf N levels in size. "Manual editing" will not be viable for very long, which means we'll need an editor pretty much quicksmart. Some good news: if we have empty screens (we will), we should be able to feed "////|" (empty fields) to the screen function with no issues.

Sorry for the wall of text.

[mattk210]

Yeah sure let's move the changelog to the wiki.

I like the level art, it looks very professional.

Time: I'm not convinced it's a clever mechanic. It seems like a lot of trial-and-error could be involved for timeshift-based puzzles, and it could also feel like doing the same level several times. If someone could more fully explain the implementation and some interesting puzzle ideas that could be helpful.

level/player size: I do think it would be a good idea to scale up levels, maybe have scrolling in them. It strikes me that in that sample level art you have, there's really not room for anything except a few enemies - an elaborate puzzle/boss/platforming segment wouldn't really fit. But everything is relative, so i guess scaling down the player would have the same effect.

seemingly falling very fast: that's a result of there being no vertical air resistance, which I did because it made variable-height jumping cleaner. I'll try and figure out a way to put it back or maybe just have a speed cap.

as an intermediary between manual string editing and a full blown editor (which will be a biiig job), maybe we should cannibalize something else. Maybe we could convert Ned data?

[Geti]

As a quick note before I coma out for the next while,

level/player size: I do think it would be a good idea to scale up levels, maybe have scrolling in them. It strikes me that in that sample level art you have, there's really not room for anything except a few enemies - an elaborate puzzle/boss/platforming segment wouldn't really fit. But everything is relative, so i guess scaling down the player would have the same effect.
as an intermediary between manual string editing and a full blown editor (which will be a biiig job), maybe we should cannibalize something else. Maybe we could convert Ned data?

Re: levels - I was figuring that the more complex puzzles, platforming etc would occur across multiple screens, which was a large part of why the 3D thing happened. I fully agree about bosses/combat though :/ I suppose if we don't upscale the graphics and keep the same pixel resolutions on the sprites we could have 4x size screens, but then levels would be even huger in the string-size department. People's userlevels.txt (or at least their .sols if we incorporate saving levels that way) are going to get larger a lot faster than with N, but I suppose it'll still be in the low MB range anyway.
Re: ned data - I don't really see why not, we'd just need a way of stripping away the useless tiles (they aren't the same grid resolution).

[Ignate]

The new build looks pretty good, but MY WORD that walk cycle looks gippy. I'll look into that later I guess. Also, as said, Binny looks a bit big, but I think it's sort of relative, given the actual screen size and details may solve that, but we'll see.

Anyway, new HUD concept.

HUD concept 2.

The gadget ideas are of course, not final, just to fill up the space and to give ideas. However I think the magnet might be a pretty cool idea. I dunno, maybe you can use it to latch onto metal surfaces, like ceilings, which may come in useful on the later metally levels.

In fact, you could also use the magnet to deflect metal projectiles if you're good with your timing (not bullets though, too fast, and it's sort of cheating deflecting them seeing the amount of soldiers, or in fact anything fast like railguns or fast rockets, I assume it only works on slower stuff like slow rockets or grenades). This is usually for enemies maybe, but especially for stronger enemies or bosses where they can be damaged by their own shots, and if you want to conserve your ammo, since the magnet only really uses metal from your surroundings.

The magnet could work both ways, attracting good metal and repelling projectiles. Some amount of puzzle-solving could be possible as well, like pushing metal boxes or deflecting something at an angle to hit something far away. Heck, you can probably even FLY a bit by repelling yourself off a metal surface. Plus there's metal ziplines, tagging on a robot boss' back, using a piece of metal as a shield, etc etc etc. The magnet could actually be a pretty awesome idea. Thoughts?

Also I just realised that the image's about 9 pixels short of 800x600. Oh well.

[Geti]

Also I just realised that the image's about 9 pixels short of 800x600. Oh well.

Hahah, My fault. I just drew it up and when I scaled it down it wasn't quite the right size but I DIDNT CARE BECAUSE ITS JUST A MOCKUP :)
loving that hud's colours, but I'll still post my iteration of it later. I think the player should be limited to 3 or 4 inventory slots, too, but there should also be "upgrades" which don't take slots but give you NEW AND POWERFUL POWERS like wall-jumping or jet-packing (with limited fuel that only recharges on the ground or eats your battery) or a bigger battery or some form of weak melee or whatever else.
sorry for all the rediculo-caps, its the morning and I haven't had my coffee.
Loving the magnet idea.

[Geti]

updated annotated WIP mockup. hit me up if you cant read any of it.

The BG trees are a bit drab, but whatever, it's not asset quality anyway. The battery is ugly as hell, too.
I changed the map format. I figure you're more likely to be doing platforming rather than lots of backwards and forwards movement on the x-z plane (assuming y is still up), so the vertical indicator is now a depth indicator, and the other stuff is now a side view map. I added an "artefacts" counter below enemies because it'd be awesome to have collectables that serve little more function than to provide some history for the area, and give the player a few more %
MOAR DISCUSSION PLZ rantrant, we need more community input on what's good, what's not good, "I can do sprites", "Max your art is lazy look at how ugly the plant you pointed out is pick a better specimen", "why do the trees have dangly things" etc. I didn't get any coding done this weekend :( I think I'm going to have to do the masking thing before I do anything else on the levels. Maybe I'll get the DynamicObject class happening at some point soon.

Matt, are you off exams?

[mattk210]

yes. My internet is currently capped though. I'll be out today but I should be able to do some stuff tomorrow. ill fix vertical drag, make some mockup rolling sprites and get roll working. I should probably leave level stuff to you because you seem to have crystallized ideas about how it's going to work, so that basically finishes off milestone 1? maybe ill work on wall jumping and such although it would be weird without sprites.

Also I noticed you've listed me under "heavy activity roles". I'm not sure how reliably i'll be able to contribute, I'm just planning on doing this when i have free time.

[Ignate]

The clouds look awesome. I can imagine just staring at those for a good while. The new gadget slots look good too, with the ammo notice on the side. I'd like more info on the level totals part, and the "artifacts". Are they some form of Easter eggs that boost your overall percentage or something?

Anyway, I'd also like to ask how would the control scheme work? Here's my rough idea of what I think is going on:
left and right: walk
z or up: jump
x or down: crouch
x/walk or down/walk: roll
up or z: background swap
down or x: foreground swap
???: melee
???: use gadget

I'm assuming that up and down are for scenery swaps, seeing I think most people that play N are used to using a different button for jumping, instead of up, but using up and down for jump and crouch is neater, in my opinion, since now the arrows are the movement scheme while the scene swaps use a separate group of keys. Also, with combat and possibly another button for melee, the control scheme may need some revising.

ALSO ALSO, I was wondering what everyone has in mind for the general feel and gameplay in this game in the context of other games or media? I was sort of associating this with Cortex Command (thank you geti :P), Iji and Cave Story. Iji has too much RPG elements for this, but I liked some weapon concepts and the control scheme, it also has a storyline that's affected by your kill count and who you kill. Cave Story also has a lot of outcomes and exploring based on what you pick up, and it has like 3 endings. I like that sort of freedom in a game, IMO.

[mattk210]

ok i implemented rolling. We didn't really have a fleshed out plan so i just went with what "feels right". The way I've coded it, it can be changed quite easily. The way it works is that when you press crouch at nearly max natural running speed, you go into roll mode where you have much less friction, bounce, much less control and no jump. I rotated the crouch sprite because I don't have a real sprite yet (I'm not good at working with pixel art)

One thing I found as I was building this is that it feels more fun to not have bounce (something metanet discovered with N). It sort of loses its impact as a kinetic "charge" though without the bounce.

[Geti]

I've rolled the version number to v0.1.0 in light of all the changes. Rolling about is fun, it needs some tweaking but I think the community should have a very direct say in that :P it really does make the game live a little more even without more graphics.
ALSO: I changed the velocity cap on the player drastically. I'm going to be lazy and just link github rather than host it on swfcabin.
Also moved the changelog to the wiki. A+ stuff Matt. I'll see if I can get masking happening before my girfriend gets here on friday.. Do we want to implement inert particles along the way before we tick off milestone one? It'd give us a concrete reason to iron out DynamicObjects and likely make movement etc feel more kinetic (every other game I've done that kind of thing in, I've been happy with the result).

[mattk210]

Your change to maxVelocity had no effect. Because of friction, the player has a max speed of 3.333 naturally (sum of an infinite geometric series because drag feeds back on itself.) This is incidentally why that constraint relating drag and thrust is necessary, for natural max airspeed to be the same as natural max groundspeed (it's why I reverted your earlier changes). I'm using maxVelocity as a defensive catch in case somehow the player's speed exceeds its natural max (like the BLJ glitch in Super Mario 64). Actually the max speed should probably be higher, it should be the maximum speed possible without going so fast it glitches through walls.

I can't reproduce your bug "rolling over seams". Can you elaborate?

[Geti]

Your change to maxVelocity had no effect. Because of friction, the player has a max speed of 3.333

Well, it seemed to fix the gravity superspeed issues, I didn't think we had air drag. I was just changing the x cap to have an even limit, but doing it with drag is definitely the logical way to go about it.

Also, the seam bug occurs mostly for me on the lowest level of the cave, if I roll slowly over that seam while moving to the right I get rebounded back every time.

[mattk210]

oh I see what you mean bleugh sorry. I forgot to fix gravity-related air resistance, ill do that.

the bounce back thing is probably something to do with the way room transitions work? ill take a look. edit: ok the reason is because you're not switching rooms until the player has already fallen off the stage. You need a tile of "buffer" (it could be automatically generated) around the whole room so when the player passes the screen edge it won't fall into the void.

edit again: ok I changed jumping and gravity. As is, I didn't think falling was fast enough so I tweaked airDrag. It could be put back if people think it's too fast. Also I found an accidental feature: if you roll just after a jump you cannonball straight up into the air (because of the drag difference). I could have easily fixed it but it's really fun so I'm considering leaving it in! (you can flick the roll on and off to change the dynamic of the jump mid-flight)

[el_devo.]

This is a great idea. I support it completely. The progress so far as I see it has been pretty good, and I would like to offer some feedback/ recommendations. I hope I don't come off as rude or harsh, just trying to provide constructive criticism. :D

First: The sprite needs to be smaller, or the levels need to be designed in a way that makes the rubbish can feel smaller. It almost seems like the sprite takes up a quarter of the screen while playing, and it just looks to dang big. (Also this is less important and will probably be changed anyway, but the sprite could be updated a bit to be better-looking)

Second: Slow down the movement of the character while running (and just in general) and increase friction and drag. This is a garbage can robot, not a ninja, and it is way too agile. It can jump a little too high and far, and needs to be toned down. I know we are used to freedom of movement and all with N, but you don't want to end up with a game that just feels like a rehash of the same ideas.

Third: You have to do something about the tiles. I assume they are all just squares because it is such an early build, but this kind of tileset is very obviously a result of our N addiction. The gameplay so far is really limited by the tiles. Rolling is kinda useless without slopes.

Fourth If I came off as rude, I apologize. Please let me know if I can help in any way. :D