Metagame Reboot - YOUR PARTICIPATION IS REQUIRED!

[Geti]

Could be interesting to put sleek overlays as huds and menus over the rougher appearance of the game (with fancy antialiased text with patterns like in that title concept) to get some contrast, but it could clash.. maybe something to try out in photoshop rather than flash.
I'll try to fix the bugs asap so I don't have to fix a million conflicts xD

[Izzy]

Testing out a homescreen or something. Still haven't found a good, not overly grungy font to use.



Went with a slight sepia-ing to help convey the "trashiness" of the game.

btw, what is the font you used for the pause menu and the start screen? (Closest I got was uni_05_53 (didn't bother to download any other fonts))

[Geti]

I'm kinda "meh" about that font :P I think it'd be good to use desaturated, warm colours overall, but not go straight sepia. I'd like this to feel more lively than that

btw, what is the font you used for the pause menu and the start screen? (Closest I got was uni_05_53 (didn't bother to download any other fonts))

It's in the /data directory of the game's source, it's called F_04_B, from http://www.dsg4.com/04/extra/bitmap/
I was considering using terminus, the best console font ever, but figured it could be better to go with something fresh.

[Geti]

Right, well I've broken everything :P I've raised an issue about it HERE, It'd be awesome for someone else (most likely just you, matt, noone else seems to be coding :P) to have a look at it, the arrays are doing my head in (I've probably defined them incorrectly, I'm not native to AS3.0 so they're confusing).. The line number that it's breaking at is in the issue, but it could be anywhere before then involving arrays in Level.as, or anywhere in Screen.as (Screens are used). As I said, I'm not actually sure what I'm doing wrong here, they seemed to be working for dimensions but the 3D one full of screens is absolutely refusing to do as I think I'm telling it :P
Both the level and screen objects need a bit of refactoring, but the data format works for the time being, I just need to get movement between screens sorted.

QUICK QUESTION GUYS! do we use doors between the screens as our mode of travel backwards and forwards, or zones of tiles. Zones lets us do fields, large cave entrances and whatnot prettily, and means we have a zoning system set up that we can use for other neat things like water physics or whatever, while doors is piss-easy (comparatively). I'd much prefer zoning, it'll make it more up to decor and background tiles to shot the user what they're walking into (and a hud item saying "YOU CAN WALK BACKWARDS/FORWARDS HERE" for clarity).

[mattk210]

I discovered yesterday you can kill the last commit even after pushing it with

Code: Select all

git reset --hard HEAD^
git push origin +master

people seem to recommend not to do it but I don't see that it will matter if it's only for fixes relatively shortly after the fact, because there's only 2 of us

I'll try and have a look and fix it but I'm kind of busy over the next few days and I'm not totally certain what the code is meant to be doing. One thing that does strike me is that you haven't used split() and join() which would be perfect for manipulating the string data. Also you shouldn't use arrays for coordinates (maybe make a flxpoint3 class) and otherwise you should use "vectors" (typed arrays) almost always.

edit: just browsed through it.

• why does a level have a unique author? Wouldn't it make more sense for different people to design individual screens and put them together? In any case wouldn't many people be tweaking a given screen?
• are you adding every screen to the playstate at once, complete with update() functions? Shouldn't you be somehow freezing and invisibling every screen except the current one? Or not even interpreting their data at all until they are reached?

Otherwise, it shouldn't be too hard to fix stuff. I might refactor your code quite a lot though.

also I think both doors and "zones" would both be pretty easy to implement but doors seem more natural?

edit: also i noticed you commented out the crouch jump multiplier in player.as. You don't like it?

[Spawn of Yanni]

Haven't been reading through the thread, so excuse me if I'm off-target with my assumptions.

What's our art like? The way I see it, we've got a pretty detailed setup coming up, with themed levels, parallax backgrounds, coloured and not-straight-edge (in terms of the art) tiles (judging by something I saw by geti as I was scrolling through); what are we doing about userlevel creation (assuming we're implementing that, which I'm reluctant not to do)? I figure, to make it work, we'd have the user make a tileset not unlike how they would in N and then ask them to specify one of the (four?) themes we have in the story mode, which would result in a relevant, preset art overlay?

[squibbles]

I wish a little bit more talk had happened around the concept of the game. I had me a brilliant idea just the other night, but it's a bit late now, since we appear to have commited somewhat to Rubbish (which is a fantastic name, by the way). :/

[mattk210]

All we really have right now is a small amount of concept art and a very rudimentary platforming engine. The game could basically go in any direction, so share your idea! I think there was some eagerness to get started because we all wanted to avoid the stagnant pool of ideas without any progress that the last metagame ended up as.

@Yanni: geti's vision for level creation I believe is that the player just creates a grid of filled or unfilled cells and sets out the object (for game logic) and then chooses tiles to overlay on that. The level designer will also need to create a background layer from tiles and can add decorations to the background and foreground (like trees).

[Ignate]

How. Did. I. Miss. THIS? Geti, you are at a level of awesome so high it could only be surpassed by having a fitting username, like "Geti-ng more awesome." I'm sorry I don't know what I'm talking about

I was really psyched by the first Metagame, and it'd be awesome to make some art for this one. I'll be working on some sprite concepts (not that I'm inclined towards raster graphics for the game, just that pixel art is a bit more up my alley). I made some sketches however, including a HUD concept, following Geti's suggestion on a sleek HUD compared to the game.

EDIT: You know once you think about it this is sort of like Robotology: Fan Spec Edition HOLY YES FAUXGASM
EDIT2: Some early sprite concepts. I prefer peeking, it seems less flat.

[squibbles]

Oh, alright. I kind of doesn't work with /any/ of the concept art. I just kind of assumed a direction had already been chosen, since all the concept art seemed to be very...thematic.

Well, to explain my idea, I think that a descrription of a scenario would work best.

So picture this. You open the game, and it loads. you are face with a menu of some kind (I think similar to the fancy-pants menu interface could work well here). You select some kind of play option, and are sent to a new screen, where your character walks on from the left of the screen. The character is dressed mostly, if not entirely in dark clothes, and is weilding what appears to be some kind of gun (unable to be shot initially), probably also black, providing stark contrast to his surroundings. The entire stage, bar the protagonist is white (but not white, it's hideous. Perhaps #f4e2b0?). On the top of the of the screen the directions "Go right" flash. You take 5ish steps to the right, and then hit some kind of seemingly invisible object. The directions to walk by now have disappeared, and are replaced with a simple "left click", and as you press shift the paintball gun that you're weilding fires a single pellet, which flies straight into this hidden object, splattering it with paint, and revealing it. From this point on, a hud would become visible showing the remaining bullets, as well as the location of the crosshair, bullets following a straight lime from the character to the crosshair (and continuing past it, should the projectile have not reached a solid surface.

In reality, the background is white, as are all obstacles on the terrain, and the only way to see them is to reveal them by firing a paintball at it (oh my god, colours randomly chosen from an array, please), giving a coating of colour along the object. This is where it gets interesting.

I think that for this game, it should definately be approached as a puzzle. Like, totally a puzzle. I think enemies should be very few, if any, and that the main challenge of the game should be conserving a limited about of paintballs, which are assigned tou you at the begining of each level.this would also allow us to fairly easily control the difficulty, as by both increasing the complexity of the puzzles (switches to open doors, moving platforms, really strangely shaped objects), and lessening the nuimber of shots given each level we could very effectively increase the pressure, to create a cohesive and fluent experiance with a reasonable and consistant difficulty curve.

[Spawn of Yanni]

@Yanni: geti's vision for level creation I believe is that the player just creates a grid of filled or unfilled cells and sets out the object (for game logic) and then chooses tiles to overlay on that. The level designer will also need to create a background layer from tiles and can add decorations to the background and foreground (like trees).

I don't think it should be left to the designer to create their own background and such. In the interest of quick and easy level creation, I'd say that just placing the tiles and then letting the program fill in the renderings by itself (at least by default) would be a more ideal situation.

[Izzy]

A menu screen like squibbles' doesn't sound like a bad idea.

Perhaps something like this: http://imgur.com/jfkEd.png

Once the player chooses to start or whatever, the Title fades away and he can move. Then, you would be able to enter the levels.

I don't know if a level screen like N or something like FancyPants or Mario might be better. Eh, you guys decide.

[Donfuy]

I thought it would be fun to have Sir.T. /very/ large, doing funky moves (dancing) to a funky song in the background. The menu would be him. The options would be his members/parts. Once you clicked a part, that part stopped dancing and the rest would continue.


Just because I find all the other options too generic :x

[mattk210]

@squibbles: I like that a lot! You're right in that it really doesn't work with everybody else's stuff though.

New idea: in each of our "worlds", which were originally going to be generically forest/beach/swamp/mech, why not instead be like braid and give each one a unique mechanic? We could even have each one be themed on a different kind of garbage (plastic, chemical, paper, metal or whatever) and have the "paper" one be squibbles' idea.

edit: ok elaborating on this idea:

• construction/demolition waste: mostly barren so platforming-based to learn the game. special feature: destructible terrain. items found here: ability to roll in the trashcan, ability to wall jump.
• biodegradable waste/compost: lots of little weak enemies, kind of jungle-like
• chemical waste: features brightly coloured chemical pools, strong individual mutant-like enemies. special feature: swimming. items found here: chemical gun at the end.
• paper recycling: use chemical gun to paint with squibbles' idea. items found here: paper aeroplane or something that lets you fly
• glass recycling: special feature: tread carefully because things shatter easily. items found here: some kind of weak gun?
• radioactive waste: special feature: you take radiation damage so move fast. items found here: a big powerful gun that drains your health when you use it?
• technological/electronic waste: maybe have this part a little stealth-based?

@yanni: well without choosing the tile style for each part of the level it would probably be quite boring-looking. I suppose we could start by procedurally generating some tiles/decorations which the designer could tweak

[Geti]

New idea: in each of our "worlds", which were originally going to be generically forest/beach/swamp/mech, why not instead be like braid and give each one a unique mechanic? We could even have each one be themed on a different kind of garbage (plastic, chemical, paper, metal or whatever) and have the "paper" one be squibbles' idea.

Problem I see with this: userlevels. I wouldn't like to give us the ability to do all of these neato things and then have to manifest them in an editor or otherwise disadvantage the aspiring mapper when compared with us.

@yanni: well without choosing the tile style for each part of the level it would probably be quite boring-looking. I suppose we could start by procedurally generating some tiles/decorations which the designer could tweak

That'd be easy enough. I just want the designer to have as much control as we can give them without murdering ourselves with a million hours of work in the process.

@squibbles: I like that idea, perhaps we can work it in somehow like matt says.. I'm not sure it'd make a good basis for an entire game though, so perhaps we can have a decalling system for the weapons (for bullet holes, scorches etc) and have a paint gun item available. I agree that we should've probably spent more time getting an idea down but last time that's just about all we did. If we'd had more interest initially it probably would've stayed in the discussion stage for a bit longer, but it was easier to push ahead. Sorry :\

IGNATE I LOVE THOSE IMAGES <3 <3 FUCKING A+! HOLY SHIT I'M GOING TO DO SOME DRAWING TONIGHT TO DEVELOP SOME OF THAT A LITTLE MORE, GODDAMN YOU'RE AWESOME ETC ETC.
Having X slots to put gadgets in is also an awesome idea. overall, I just love what you've done with it.

JUST TO BE CLEAR: I think the best way to approach items is to have the player with an empty inventory at the start of each level/world (They're called levels in the code and are what's going to be editable) similar to what knytt does. This way, the designer controls what the player has access to at various points, which is much more fun from a design perspective (where's the fun of having a huge imposing cliff if the player comes at it the first time with the ability to jet-pack up it?). Think of it as each world is a separate adventure, self contained. It makes userlevels a lot nicer too (if the mapper wants to give early access to wall-jumping leg-pistons or a huge laser or whatever they're free to do so, but if they want to save that for later they're also free to go for it).
FURTHER CLARITY!:

I figure, to make it work, we'd have the user make a tileset not unlike how they would in N and then ask them to specify one of the (four?) themes we have in the story mode, which would result in a relevant, preset art overlay?

I figure that because we only have axis aligned tiles (filled or not filled ie square) we can afford to do what Ned does with tile groups but with zoning. If we were going to go hole hog on the art we could have 9 zones using WERTYUIOP and the three keys below to select the zone and what "type" of tile to place, and QAZ for selecting how seaming was handled (Q being the default (filled tiles prevent hard edges from being drawn), A being filled tiles of the same type prevent edges from being drawn (for seams between different types of rock or between metal and rock or whatever) and Z being all edges are always drawn (for placing a stack of metal "cubes" for example)). Other keys could be used for switching layers. We'd probably need something more gui-oriented though for placing decor though, if we implement that.

edit: just browsed through it.

• why does a level have a unique author? Wouldn't it make more sense for different people to design individual screens and put them together? In any case wouldn't many people be tweaking a given screen?
• are you adding every screen to the playstate at once, complete with update() functions? Shouldn't you be somehow freezing and invisibling every screen except the current one? Or not even interpreting their data at all until they are reached?

Otherwise, it shouldn't be too hard to fix stuff. I might refactor your code quite a lot though.
also I think both doors and "zones" would both be pretty easy to implement but doors seem more natural?
edit: also i noticed you commented out the crouch jump multiplier in player.as. You don't like it?

I didn't think I touched the crouch multiplier, sorry! It was fine, don't mind me.
I think zones would be better just cause it lets us do things like fields and the like without having to put a door in the middle and make the player walk through that. You could have a "door" decor item for inside, or just make a "door" silhouette with background tiles.
The levels author could be any string, it'd probably be shown at the start of the level underneath it's title, which could fade away. It's more of a userlevels-oriented thing though, we could just sign off as "The Metagame Team" or whatever.
I'm adding the level to the playstate complete with update, but we could only update the current screen very easily by overriding update. I'd like all the screens at least loaded during play though so we don't have to do data processing once the level has loaded, but I suppose we might have to later on if we're eating ram or something. Screen objects shouldn't be too complex though, in any case, it'll be the object's updates that'll eat CPU-time. As I said though, we can switch that off, the only thing that's added to the Playstate is the Level object itself. I'd love some help with debugging it though, I'm stumped. It processes the data fine (I've made it print each of the strings, I'm using slice and two indexes rather than split and join) afaik, the only one it might be doing wrong is the string it feeds to the FlxTilemap (I'm not sure if you can do += with strings, can you?) which I haven't printed, so I think it's just the arrays causing hassle, as I said, It halts on line 88..

Sorry to anyone I've missed, going out now..

[mattk210]

Problem I see with this: userlevels. I wouldn't like to give us the ability to do all of these neato things and then have to manifest them in an editor or otherwise disadvantage the aspiring mapper when compared with us.

As I imagine it, all the unique mechanics would be available to the level designer for custom levels as well, it's just that each world would emphasize a certain one. Like destructible terrain would be usable in any level, that would just be the focus of the first one.

JUST TO BE CLEAR: I think the best way to approach items is to have the player with an empty inventory at the start of each level/world (They're called levels in the code and are what's going to be editable) similar to what knytt does. This way, the designer controls what the player has access to at various points, which is much more fun from a design perspective (where's the fun of having a huge imposing cliff if the player comes at it the first time with the ability to jet-pack up it?). Think of it as each world is a separate adventure, self contained. It makes userlevels a lot nicer too (if the mapper wants to give early access to wall-jumping leg-pistons or a huge laser or whatever they're free to do so, but if they want to save that for later they're also free to go for it).

As for having each world be a self-contained start-with-zero adventure, wasn't the whole idea that you gradually worked your way towards the final world while being able to see it in the distance? wasn't that the main motivator of the 3D thing? Why not have the whole thing be a master adventure that contains multiple worlds, and userlevels would typically be much smaller (but not limited as such!) This is closer to how knytt does things, I think.

I'm adding the level to the playstate complete with update, but we could only update the current screen very easily by overriding update. I'd like all the screens at least loaded during play though so we don't have to do data processing once the level has loaded, but I suppose we might have to later on if we're eating ram or something. Screen objects shouldn't be too complex though, in any case, it'll be the object's updates that'll eat CPU-time. As I said though, we can switch that off, the only thing that's added to the Playstate is the Level object itself. I'd love some help with debugging it though, I'm stumped. It processes the data fine (I've made it print each of the strings, I'm using slice and two indexes rather than split and join) afaik, the only one it might be doing wrong is the string it feeds to the FlxTilemap (I'm not sure if you can do += with strings, can you?) which I haven't printed, so I think it's just the arrays causing hassle, as I said, It halts on line 88..

honestly I foresee that loading a screen will take a tiny fraction of a second. I suppose it doesn't matter but if we want the whole game to be a really huge master level might cause problems. I intend to fix your code, but as I said I'm in the middle of an exam block so I'd prefer to prioritize that.

[Geti]

As I imagine it, all the unique mechanics would be available to the level designer for custom levels as well, it's just that each world would emphasize a certain one. Like destructible terrain would be usable in any level, that would just be the focus of the first one.

Well, true.. I was actually thinking a light scripting system in-editor could be interesting if we could get it working, likely just an input (ie step into an area of tiles) -> output (ie spawn enemies in the next screen, show a text box with something indicating an enemy drop) system if anything, but it could give some real power to the editor.. Regardless, yeah, I want our toolset to be the same as the end user's, I was just suggesting that it could be annoying to integrate all the advanced stuff
Also! I think destructible terrain could be good, but (borrowing a concept from Arne that I really want to test out) what if for the most part we just have destructible vegetation (focus) and sediments (possibly, though with square tiles it could clash) that are considered objects rather than full on destructible terrain (for the most part). Destructible tiles would be cool too though, but because it's all on a grid it could seem, well, odd. I'd like to test both of them, and in any case destructible plants etc would make the world feel a lot more.. interactive. I'm really just musing at the moment though.

As for having each world be a self-contained start-with-zero adventure, wasn't the whole idea that you gradually worked your way towards the final world while being able to see it in the distance? wasn't that the main motivator of the 3D thing? Why not have the whole thing be a master adventure that contains multiple worlds, and userlevels would typically be much smaller (but not limited as such!) This is closer to how knytt does things, I think.

The scrap mountain was more of a side-motivation for me, I was more concerned with having a solid mechanic that sets our game apart from the masses of sidescrolling platformers. Obviously we still have to test weather it is a solid mechanic, but it seems like it'd be a very good way of abstracting 3d space in this context.
The loss of stuff could very easily be explained by you losing your upgrades in the swim/launch to the next island, or I suppose being able to set player inventory at the start would be good.
If it was a launch from a scrap-heap mass driver, and you lost your parts that way, you could regain them in the first few screens as though they actually just disconnected from you. If you have limited inventory slots, this will become less important as the player will probably choose to use the higher level equipment available in the later levels than the stuff they had at the start. We could of course also just write exceptions

honestly I foresee that loading a screen will take a tiny fraction of a second. I suppose it doesn't matter but if we want the whole game to be a really huge master level might cause problems. I intend to fix your code, but as I said I'm in the middle of an exam block so I'd prefer to prioritize that.

I fully agree about the tiny load screen, but that's kind of my point. If we can load all the screens at load-time, why not? We don't have to update them (but we could perhaps update all the adjacent screens), just keep them around so we aren't loading and unloading resources all the time.
Also sweet as about the exams, sorry for putting any pressure on; Good luck.

[Geti]

some thumb development.

I liked ignates stuff so much that I had to do one of those binbots. Need to play with it more, I can't get the same awesome feel, but yeah, <3
For the soldiers, all I really require is that they have a backpack, are abstracted humanoids (I'd prefer a slight homage to kris' cyanide and happiness style, but that's personal) and can use lots of weapons. I'd like them to be a very versatile enemy, not found everywhere, but able to seem like part of a military, not just a single enemy.
I kind of prefer the limes being more literal limes. I'll do some work on landscape feel, and possibly weapons and faction ideas etc now.

Oh yeah, for smoke, I'd prefer it to be particle based rather than sprited as part of the player actor, so you can leave trails of smoke behind.

[mattk210]

all this art is amazing. It seems such a shame to resize it down to a tiny pixelated sprite. I like Geti's new lime a lot. Maybe we should have the sprites take up more of the screen and not have blown up pixels?

If we can load all the screens at load-time, why not?

it could conceivably cause memory problems. also it would be more difficult to reset objects(enemy positions, states etc) when you leave and reenter a screen, which I think is important so you can retry something afresh and stuff isn't one-shot-only. I think a better question is, if we can avoid loading all the screens at once, why do it?

[Geti]

it could conceivably cause memory problems. also it would be more difficult to reset objects(enemy positions, states etc) when you leave and reenter a screen, which I think is important so you can retry something afresh and stuff isn't one-shot-only. I think a better question is, if we can avoid loading all the screens at once, why do it?

I think there should be some way of making a screen "beaten" which would make it save it's state, to prevent screens with lots of enemies from blocking an area if you run out of stolen ammo or whatever, which would still let you have multiple tries of a puzzle, but also give you a sense of progression. to prevent it from becoming an empty map, there could be some screens (non-puzzle centric ones) that would reset their objects whenever you got x screens away from them, but I think the tiles, decals etc should be preserved (at least within a 3x3x3 block around whatever screen you're in), and especially if there's destructible tiles etc. I suppose we'd have to have some way of saving all that anyway, so i suppose we could just save a screen before unloading it, but unless we run into issues I don't see a big issue with just keeping them all in memory.. anyway:

HUGE IMAGE EXPLAINING POSSIBLE ISLANDS AND HOW I THINK WE SHOULD APPROACH FLORA AND FAUNA CREATION.

I'm not saying those levels are anywhere close to final, but I think it could be interesting to have some sort of layout like that. Even if you can play the levels in any order (which would be preferable to me, I like having something else to do if I get stuck) a geographical layout would be a good thing to have concrete, and lets us do things like the "coalition" pathing (not final name, just wanted a name for the military faction). I figured they'd beeline for the big island with the scrap heap to try and salvage any free technology (whoever built all the tech buildings was pretty advanced), but also drop off recon troops on any islands they passed, which could scout the other islands and move on that way. Having different presences of them in different levels would provide a more interesting variety (rather than oh god more soldiers you could be fighting/avoiding the insects in that image once in a while, wooo). Also, characters should have reasons to be where they are, so there's some backstory for the coalition guys.
I've added a scrub zone because I think it'd be important to have a bridge between forest and the rock or dirt zones. It made Proto-rts a lot more visually interesting as well.

Ignate, I love what you did with that other protagonist concept, I think it should be a high level tech type enemy.

On the bigger sprites... It's possible, but it's a bit of a pain to have to animate things at a larger size.. perhaps we could double the dimensions and drop the chunky pixels, but I do love that look.. It's not purely my call though.
I think if we do go bigger, limiting ourselves to at largest a 64 colour palette would be a good idea to maintain some retro-ness, and I'd prefer unantialiased sprites (simply because they're easier to edit and it loans a scrappier feel), but again that's just me being an idiot with my preferences.

ON ENEMY DESIGN: the "coalition" should share a colour scheme between their units, as should any related species. I usually prefer the heavy/medium/light or at least heavy/light approach to design, as it means more situation combinations are possible. We can probably afford to have at most 8 different coalition unit types, and maybe 15 other assorted enemies. Flora is different, as it really only has to be drawn once or twice, but regardless we can boil down/combine ideas if we have too many, or specialise/evolve ideas if we have too few. 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.

[mattk210]

I've kind of had Metroid in the back of my head so it seems more natural for destructible tiles and junk to not stay destroyed except special cases (bosses should stay dead, probably). Nothing fundamentally wrong with preserving the state of everything though I guess, just preference. Anyway even if we do keep everything in memory we'd still have to save it when the player saves the game, so I can't see keeping everything loaded having an advantage. It's not going to be hard to change though so I guess we can do it your way until we run into problems. Still haven't looked into your array problem, was meaning to do it today but I didn't get around to it.

Also I'm not sure about having such a diverse ecosystem of plants and animals,and this "coalition" thing, seems like a lot of work, especially in graphics and animation. Why don't we get a basic game first, and keep ideas like this shelved away for later.

I guess do whatever kind of graphics you and ignate are more comfortable with.

[Geti]

All good about the arrays, I didn't get to touching the code today, Was having too much fun scribbling :P I'll try to get onto it soon, though I'm not sure how much luck I'll have..

Also I'm not sure about having such a diverse ecosystem of plants and animals,and this "coalition" thing, seems like a lot of work, especially in graphics and animation. Why don't we get a basic game first, and keep ideas like this shelved away for later.

Of course, but it wouldn't hurt to have some solid designs to pick from.

Sorry if it sounded like I was being annoying-project-leader before btw, reading over it it seems like it could be taken as me being a douche.

[mattk210]

OK, i think I just found the source of your problem (straight away!). Your position is (1,1,1), but that element doesn't exist in the array. What you should have is (0,0,0), start from zero, remember? You should probably have some sort of verification so you get told when you try and position in a nonexistent cell. I haven't compiled or anything though so there may be other problems. In particular you need to make player.collideVsTiles() outside player.as (either in playstate, level or screen) because collision needs to happen between integration and rendering and for that, player needs to know the tile data so it can run collision internally. Basically just copy what I had in my last commit.

The level loading code should also probably be totally refactored. There's really no reason to not use as3 vectors, and split() would greatly improve clarity. Also we should make a 3D vector class so we don't have to resort to opaque syntax like position[2].

edit: also, what are you using for debugging? I had to resort to trace() statements because I don't know how to set breakpoints, track variables etc. outside of the flash authoring tool.

[Geti]

... start from zero, remember? ...
edit: also, what are you using for debugging? I had to resort to trace() statements because I don't know how to set breakpoints, track variables etc. outside of the flash authoring tool.

Oh ffs, I knew all that lua was going to come back to bite me :P thank you. Also I'm confused as to why you're telling me I need to do collision comparison outside of player.as, I figured that was a given? Or have I done something stupid while inanely tired?
I'm using FlxG.log(output) for debugging, it prints stuff to the flixel console (hit ~).
Also yeah, a n-D vector class would be good, though I can't imagine any uses I'd have for >3D vectors at this point. I'm just about off to sleep, its 1210AM here, so I'll pull from the repo in the morning and hopefully not make any more silly 0-based blunders <_< thanks again.

[mattk210]

hmm I would like to be able to track all the variables in a tree structure and step through code one line at a time. I'll look around for a debug tool.

You need to do collision comparison inside player.as, but you need to construct the function outside it. This is because FlxSprite.update() contains both integration and rendering code so collision needs to be inserted in player.as, but player.as does not have access to the tilemap so it needs the function defined outside. (there are other solutions but they seem worse to me). It seems like you've removed that definition so collision will fail unless you put it back in.

yeah i was being stupid with n-d vectors, edited that out when I realized it, but you ninja'd me haha