Metagame Reboot - YOUR PARTICIPATION IS REQUIRED!

[noops]

Wow. I really like these ideas. Especially the flies. I think a good idea would be letting you use the trash lid as a sort of shield, maybe. And you could, possibly, find useful scraps of trash and use them to your advantage. For instance, you could pick up an especially sharp looking piece of plastic and use it to your advantage, perhaps. Or you could even re-purpose your enemies weapons and use them against them! Shoving metal and plastic and rocks into some sort of shotgun, for example, Just ideas,

Good luck, guys. I really want this to continue.

[Geti]

I was thinking last night as I dozed off that maybe the lime's juices are an essential component of your battery, and the only one that you can't synthesise in your internal atomic synthesis system (It'd go with the high/low tech contrast that I like (autonomous robot constructed of rubbish, matter synthesis being used to help maintain acid-metal cells, etc)

btw are we still thinking of having the penistower as some form of easter egg? I'll draft up a 3d zoning thing at some point today, just 4x4x4 for now (64 screens) rather than the epic 10x10x10 mega-map :P

Wow, the progress on this thing is amazing. One thing I would like to point out is that... If you fall down the ledge, you can't jump back up; all the ledges are too high. It'll probably be rectified soon, so I'm just noting it for posterity and because I'm slightly OCD about such things.
Anyway, I would love to help out any way I can, beta testing, and all that.
The only drawback I can foresee is the fact that, due to the restrictions I have on my computer, I can only use it for 2 hours a day, and my router only allows me to use it between 7AM and 10PM, EST. So yeah. Other than that, though, I'd be willing to help in any way I can.
<3's for all of you.

Cheers spoon, glad to have some form of external beta-tester. The jumping will be more viable once you can wall-jump, I'll tweak it again once we've got all the basic actions in. Also if that's cause windows 7 RC is expired, you can just start it up again after the two hours.

Now:

--------------------------------------------------------------------------------------------------
PROPOSITION FOR MILESTONE ONE:
We get the player object and tile rendering system to "near-final" form
--------------------------------------------------------------------------------------------------
all basic movement for the robot down.
-running
-jumping
-wall jumping
-some form of crouch
any other player related stuff, health, power, whatever.
tile rendering (proper edge recognition)
--------------------------------------------------------------------------------------------------

some debates we could have about this would be weather to have background rendering (not of the level in the background, just background decor), various zones rendered, weather getting power in there means we should also get limes in there. Personally I think it'd be fine to have at least a basic NPC class (and be able to give them a variety of behaviours: ally, enemy, neutral) down fairly soon, but I think that could be part of Milestone Two. Having different zones of tiles rendering now is probably a kickass idea and will save some time later.
Discuss.

[Geti]

how the basic map would be laid out

We'd need a simple way of displaying it, maybe as slices? Not sure about that.
What I am sure of though is that I'd want there to be doors and for those doors to be able to be opened in a variety of ways. FOR EXAMPLE you could find the key (complete a puzzle or 3), blow it up (using up a powerful weapon and disadvantaging yourself against whatever boss there is, or there might be a really tricky way to bypass it with a complex jumping puzzle or something (be a pro).
In any case, I think having a few worlds for the player to complete could be a good thing. It might be interesting to do what bomberman 64 did and have all 4 "miniboss" worlds available at all times (to give some variety if you get stuck etc) and the final "boss" world available only after you'd completed the 4 miniboss worlds. Could be an interesting take on columns I suppose, eg the 10 smaller worlds (00-09) (dimensions on any axis below 5, so the largest would be 5x5x5, smallest would be 1x1x1, smallest in game would probably be 1x1x5 (penistower lololol!1!one11) and then world 10 would be a mammoth 10x10x10 effort.
You could save positions on any of the worlds independently, and there could also be a "wipe world progress" option for if you want to take a different approach. Once you've beaten it, your time taken, % keys, % enemies defeated, %limes kept alive, final score in points etc would be saved so you could try to highscore it.
In any case, you start each world with no add-ons, to make userlevels make sense and be fair for everyone.

[ℎalifax]

Geti explained it better than I ever could.

However, the levels/pages seem, at present, more like blocks than like seperate pages. Remember, within each page, there has to still be a decent amount of platforming happening. It's not going to be one tile per page as implied by the above picture. By doing a faux-3D effect, we're not going to get the same effect as if we'd actually made a 3D game - that's just not going to happen. But we do want some foregound/background interaction happening. Maybe focus a little less on the up/down aspect, so we can focus on moving on two dimensions on the ground. Similar to Knytt, the screens/pages above the 'floor level' could be mainly reserved for secrets/easter eggs/etc.

This game is a platformer at heart. We need to keep that in mind when imagining how each world should look.

[Geti]

http://www.swfcabin.com/open/1276401776
Current build with new jumping, no source because it's hardly changed at all. I'll hopefully get "inert" particles happening tonight, and maybe player damage. We're kind of undecided as a team about how damage should be handled. I personally think that if limes are used as HP they should give you a non-instant ~10% health back, like, 2% per second, to have it make sense in the game world (you could be synthesising repair parts and applying them from the lime juice) rather than "Oh, if I squash limes I instantly get health. If that was the case, we could use any form of pickup and call it a day, I'd rather have it make contextual sense.

Also combat is almost definitely a yes, as everyone wants it.

[ℎalifax]

http://www.swfcabin.com/open/1276401776
Current build with new jumping, no source because it's hardly changed at all. I'll hopefully get "inert" particles happening tonight, and maybe player damage.

Excellent work as usual. Finetuning is needed, however; jumping still feels a little too 'slidy' and unnatural, and the animations will need some cleanup. Suggestions include an idle animation of some kind, such as a slight bob and flies circling around the bin.

We're kind of undecided as a team about how damage should be handled. I personally think that if limes are used as HP they should give you a non-instant ~10% health back, like, 2% per second, to have it make sense in the game world (you could be synthesising repair parts and applying them from the lime juice) rather than "Oh, if I squash limes I instantly get health. If that was the case, we could use any form of pickup and call it a day, I'd rather have it make contextual sense.

This is a good idea, gameplay- and context-wise. There should be something on the order of 50 (or 100, to fit the percent) limes per world/level/stage/whatever. Leaving them alive gets you a better score at the end, whereas squashing them returns you some health: something like 5% health per lime, given over 10 seconds, would work well. It would provide a nice source of extra health out of combat without allowing the player to become invincible simply by hanging around a lime cave. The health they give would have to be tweaked and tested repeatedly to determine what is best; too little, and there would be no point in killing them. Too much, and the game becomes too easy. Perhaps for higher difficulty settings, the amount of limes could be halved, or something like that.

Other ideas about health:
1. Discrete health levels (visual only).
2. Health bar in form of battery (HUD notification only).
3. Both of the above (visual damage corresponds to amount of health left in bar).
4. One hit dead.

Input from the community would be welcome here: which of these options do you think would be more fun for this type of game? Feel free to suggest a new option if you like. We're currently leaning towards option number 3.

Also combat is almost definitely a yes, as everyone wants it.

Indeed.

On another note, we discussed time limits. Community input would be appreciated here, again: what do you think will be more fun in a puzzle-platformer: a time limit, which would be in the form of a battery of sorts, that could be replenished by collecting limes/other powerups in the vein of N's gold; or no time limit. Personally, I think no limit would work better for a multi-screen world full of puzzles. You don't particularly want to feel pressed for time if you want to go underground to explore a cave, or spend some time thinking about how to get this felled tree out of your path.


EDIT: Some other stuff about controls. We were thinking the scheme should be something like this:

Left = move left.
Right = move right.
Z = jump.
X = duck.
Up = move through door into 'background'.
Down = move through door into 'foreground'.

To give a basic idea of how this would work, consider this image:



The door circled in red would be the door to the background. Pressing up in front of this door would make the player move to the screen behind the current one. This door would be solid, brown, and made of wood.
The door circled in green would be the door to the foreground. Presing down in front of this door would make the player move to the screen in front of the current one. This door would be semi-transparent and larger, to indicate its 'forwardness', and to ensure the game world is still visible behind it.

I hope that made sense.

[mattk210]

cool, the demo seems quite robust. I'll have a fairly long break after my uni exams finish next week so I figure I'll put some of my time into this game, even though I originally planned to wait and see how it was shaping up before I got into it (haha too tempting, it's been forever since i worked on a game). anyway I have some random input.

programmy stuff (don't have flashdevelop on this computer so i'm just looking at the source):

• The variable called "drag", what is it? it looks like a thrust variable. If so, why is it called drag (that means "friction/resistance"), and why is it 5 times the maximum run speed?
• Should we have some way to modify individual files instead of having to reupload the whole set to a file hosting service each time a change is made?
• If FlxSprite.update and FlxG.elapsed work like I think they do, you have no deterministic logic loop - if a frame lags or takes a long time to render, it will cause jump physics to be different. I think the update/tick function should only measure time in logic ticks, and it may be wise to have it run independently of frame rendering (realtime-based) depending on the quantity of onscreen objects and effects we plan on having. I'm not sure how feasible this would be in flixel.

ideas stuff:

• I would like to suggest giving the character's motion some nuance, especially if level geometry will be all simple and tiled and axis-aligned. (something to reconsider?) Something like the different kinds of motion in super mario 64 might be good, where you can move by diving, long jumps, wall kicks, double jumps etc. You seem to have already thought of wall kicks. what about being able to roll once you've picked up some speed, or being able to bounce off surfaces with your "head"? Just some suggestions...
• are we deadset on having our player have melee attacks? It's a preference thing but I'm more partial to systems where you'd destroy an enemy by jumping on them or rolling into them or something. I've always found melee attacks in 2d games to be quite underwhelming and clumsy because the player is so small on the screen. I have no problem with projectile/bullet attacks though, so long as they're not abusable. There is also merit in having enemies you have to avoid rather than destroy, like N.
• I don't understand the "3D" thing. In knytt, you move to the edge of the screen to scroll to the next one. How can you move to the "front" of the screen?(edit: ok whoops I just saw your explanation with the doors) I do like the idea of background switching to foreground and your goal always being in the distance, though.
• I love the "pretend to be a real bin" idea. Reminds me of the box in metal gear solid! Why not just have that be crouch?
• I also like the story, simple but cute. Maybe I'd ditch the "start on a plastic heap" thing though, you'd probably have to actually explain what it is.
• The page I read about flixel said it worked with non-pixelart graphics as well. May i suggest this might be preferable because it takes a lot of effort to produce a polished, fluid sprite but something vector-graphical and parts-based (ideal for a robotic/mechanical player!) could be animated smoothly, like the ninja in N, with comparatively little effort.
• I'd like health to NOT be instant kill, that's too frustrating for me. Maybe 3 hits to death is a good number?
• I also dislike things that can be "used up". You mentioned that maybe you'd be able to use up a good weapon as an optional route choice, which I would suggest is a bad idea unless that weapon has replenishing ammo. Closing off an available option for the unforeseeable long-term on the basis of a short-term decision is bad design to me.

[ℎalifax]

Just some images to clarify the 3D thing.

What our test level will eventually look like:


An example of exploring an underground cave:


Tried to represent the 3D movement utilising the concept level I drew before:


Sorry if any of this is confusing. We plan to have some sort of 3D 'map' the player can use to orient themselves.

[ℎalifax]

via Geti:

Very glad you're interested matt :D I'm keen to code alongside someone for once.

programmy stuff (don't have flashdevelop on this computer so i'm just looking at the source):

• The variable called "drag", what is it? it looks like a thrust variable. If so, why is it called drag (that means "friction/resistance"), and why is it 5 times the maximum run speed?
• Should we have some way to modify individual files instead of having to reupload the whole set to a file hosting service each time a change is made?
• If FlxSprite.update and FlxG.elapsed work like I think they do, you have no deterministic logic loop - if a frame lags or takes a long time to render, it will cause jump physics to be different. I think the update/tick function should only measure time in logic ticks, and it may be wise to have it run independently of frame rendering (realtime-based) depending on the quantity of onscreen objects and effects we plan on having. I'm not sure how feasible this would be in flixel.

1. "drag" is an internal flixel variable for FlxSprite objects, but I'm using it as a thrust variable here as I'm not planning on using drag for it's actual purpose and it saved variable space :P feel free to rename it if you want. RunSpeed is the maximum speed on the x axis, so it takes .2 seconds to accelerate to that from a standstill, or .4 seconds when running the other way.
2. Yes we should. Should we set this up on github or something?
3. FlxG.elapsed gives the total time to render the frame. I want to switch to logic states (~30sps if possible) ASAP, I'd appreciate help with that.

Also, as a sidenote, I'm just building this with mxmlc, grab flex and you're done.

ideas stuff:

• I would like to suggest giving the character's motion some nuance, especially if level geometry will be all simple and tiled and axis-aligned. (something to reconsider?) Something like the different kinds of motion in super mario 64 might be good, where you can move by diving, long jumps, wall kicks, double jumps etc. You seem to have already thought of wall kicks. what about being able to roll once you've picked up some speed, or being able to bounce off surfaces with your "head"? Just some suggestions...
• are we deadset on having our player have melee attacks? It's a preference thing but I'm more partial to systems where you'd destroy an enemy by jumping on them or rolling into them or something. I've always found melee attacks in 2d games to be quite underwhelming and clumsy because the player is so small on the screen. I have no problem with projectile/bullet attacks though, so long as they're not abusable. There is also merit in having enemies you have to avoid rather than destroy, like N.
• I don't understand the "3D" thing. In knytt, you move to the edge of the screen to scroll to the next one. How can you move to the "front" of the screen?(edit: ok whoops I just saw your explanation with the doors) I do like the idea of background switching to foreground and your goal always being in the distance, though.
• I love the "pretend to be a real bin" idea. Reminds me of the box in metal gear solid! Why not just have that be crouch?
• I also like the story, simple but cute. Maybe I'd ditch the "start on a plastic heap" thing though, you'd probably have to actually explain what it is.
• The page I read about flixel said it worked with non-pixelart graphics as well. May i suggest this might be preferable because it takes a lot of effort to produce a polished, fluid sprite but something vector-graphical and parts-based (ideal for a robotic/mechanical player!) could be animated smoothly, like the ninja in N, with comparatively little effort.
• I'd like health to NOT be instant kill, that's too frustrating for me. Maybe 3 hits to death is a good number?
• I also dislike things that can be "used up". You mentioned that maybe you'd be able to use up a good weapon as an optional route choice, which I would suggest is a bad idea unless that weapon has replenishing ammo. Closing off an available option for the unforeseeable long-term on the basis of a short-term decision is bad design to me.

1. I'm keen for this, but other members are less-so. I think walljumping and the like would make this a lot more interesting, though I don't think it should be like in N where you can climb up an infinite sheer cliff (or overhang :P), especially since the character has no arms!
2. I'm not deadset on melee, but a lot of people seem to want it. It's up for debate. Projectiles will probably be taken from enemies, see below.
4. I like no time limit on hiding as a bin as well, but I only think it should work on organic enemies (anything seeing with a scanner will know you're a robot regardless, the soldiers and crabs about won't though).
5. starting on a plastic heap can be ditched easily. I think you just start in a small collection of junk/rubbish on each of the islands.
6. but I like raster graphics :P I'm not fussed either way really, but I prefer raster to work with and it'll be easier to get the scrappy feel I'm going for here.
7. Yeah, me too, but those 3 hits could come in quick succession with a machine gun, and an explosive could count as all 3. I think it'd be better to do it as a % so we can have all manner of damage (especially important for fall damage)
8. By "used-up" I mean found, and then used up. You start with nothing, only the ability to jump and run (and maybe some acrobatics depending on how that gets decided). You might be able to pick up enemy grenades or rocket launchers or machine guns or whatever after you get an upgrade that lets you mount weapons, but ammunition would be very limited for all of them to keep heavy combat to a minimum.

[crescor]

Here is some music:
http://drop.io/MetagameMusic1

This is far from completed, but it's a start:

Metagame1 is something long, and it gets too complicated at the end. I still like it though, but not really fitting.
Metagametheme1 is more something of a boss-battle tune, said romaniac, and I fully agree
Metagametheme2 is something that I really like, but I must admit that I got the chords for the organ from this: http://www.youtube.com/watch?v=FHWer4AnYGY
Metagame1loop is a loop that orange finds very fitting for the mech theme, and I agree.
Metagame1loop2 is something else I tried with the first loop, not much difference, just some little things.

Also, matt:
<~geti> sorry, quickly, can someone tell matt to not start on any level processing stuff and work on objects if he wants to do something now, I'm halfway done with it.


and geti, can you put the link on the main post?

[Universezero]

This is going to have a background, right? If so, I would like something like the backgrounds in Braid. Go to here and watch the video at the top of the page... notice the backgrounds, especially from 0:10 to 0:12; the foreground platform moves faster than the far background does. I think that makes an amazing effect, as far as looks of the game go.

Also, geti, I'd like to reiterate what an amazing job you're doing so far. These plans look fan-fucking-tastic.

[ℎalifax]

This is going to have a background, right? If so, I would like something like the backgrounds in Braid. Go to here and watch the video at the top of the page... notice the backgrounds, especially from 0:10 to 0:12; the foreground platform moves faster than the far background does. I think that makes an amazing effect, as far as looks of the game go.

That's called parallax, and we did discuss it, briefly. The problem is that since the game won't be side-scrolling, the camera won't actually be moving within a screen. There will be noticable background change between screens, though. Unfortunately, nothing like what you see in Braid.

Also:

[mattk210]

I don't want to actually start coding yet because I'll inevitably lose track of time and i have exams to worry about right now.

if people aren't fans of some of the suggestions we can make branching prototypes and experiment with them i guess. My concern is that people see the interesting platforming in N with very simple movement and controls and assume the same is possible here, but with only axis-aligned surfaces it might not be.

RunSpeed is the maximum speed on the x axis, so it takes .2 seconds to accelerate to that from a standstill, or .4 seconds when running the other way.

FlxG.elapsed gives the total time to render the frame. I want to switch to logic states (~30sps if possible) ASAP, I'd appreciate help with that.

OK, I think I understand - i was assuming acceleration was in pixels per update, not per second. So Flixel is built around delta-time for integration...
If we switch to logic states (which I'd like to, for determinism), I assume we'd have to rewrite the integrator, and perhaps some other functions that are also realtime-based or rely on the integrator (collision resolution?)

[OneSevenNine]

Just wanted to pop in and say it's awesome that you guys are rebooting this, and I hope you can get something done--

My skills lack in terms of coding/design, but if you guys need yet another musician I'd completely love to submit as many tracks as you'd need. I know I'd be able to find the time because composing is pretty much all I have (or plan) to do this summer, and I don't plan to stop anytime soon.

And here's an example of some of the things I do.

[Geti]

OneSevenNine I'll have a look as soon as I'm home.

if people aren't fans of some of the suggestions we can make branching prototypes and experiment with them i guess. My concern is that people see the interesting platforming in N with very simple movement and controls and assume the same is possible here, but with only axis-aligned surfaces it might not be.
OK, I think I understand - i was assuming acceleration was in pixels per update, not per second. So Flixel is built around delta-time for integration...
If we switch to logic states (which I'd like to, for determinism), I assume we'd have to rewrite the integrator, and perhaps some other functions that are also realtime-based or rely on the integrator (collision resolution?)

1. Yeah, that's kind of why I like the idea of at least having walljumping in it. We'll see how it works out though.
3. Yeah, not too much will need rewriting, there's very little collision logic native to Flixel (basically it just prevents stuff from moving through the object, you write what you want it to do upon collision). I might let you handle that though, I'm working on getting a solid level format down.

Orange, you're still forgetting that the protagonist has eyes :P
UniverseZero: Glad you're liking what we're moving towards here.

I'd like to reiterate: everyone get on #metagame and discuss this, that way it'll get a lot more thoroughly mulled over and we're less likely to run into contextual problems later on.

[Geti]

OneSevenNine: That was damn cool, loving it. Definitely drop into #metagame at some point and we can sort something out, I'm usually on ~8PM-930PM GMT+12, Maybe later or earlier but likely not during the week, but sure, I'd love to have your music in game (props if it sounds just as good after some clever downsampling, we want to keep filesizes down on this thing ;) ), maybe give crescor a bell and do a few collabs too. I definitely want there to be a motif or two in the game's music to make it identifiable, but there's no real limit on genre as long as you can make it work.

[mattk210]

OK i browsed the flixel source to see how to remove the delta-time stuff. I can see three potential approaches:

1. permanently set flxG.elapsed to 1 so logic and rendering both happen deterministically on a per-frame basis. This is what (I think) N uses, it means if a frame takes a long time to load for whatever reason the logic will slow down with it. There will also be slight inefficiencies because code that has been built around variable timestep is redundant, but they shouldn't be noticeable.
2. selectively rewrite/override instances of flxG.elapsed that affect game logic (just FlxObject.updateMotion as far as I can see), leave those that affect UI/rendering crap. This will keep non-game stuff like fadeins running smoothly in realtime but the logic will be frame-locked and deterministic. Some things may act a little strange such as effects not syncing properly with the game.
3. separate the rendering and logic and run logic on a realtime basis (such as iterating the logic multiple times per frame depending on framerate).

1 and 2 are fairly trivial, but I can't see 2 having much benefit if any. Flixel already has reasonable separation between logic and rendering so it shouldn't be too difficult to do 3. What do you think, Geti? Actually it should be fairly simple to change between these timing methods even late in the development process so long as don't do anything too strange.

also I had to change the font embedding line to

Code: Select all

[Embed(source="../../../data/04B03.TTF", fontName="F04B", embedAsCFF="false", mimeType="application/x-font-truetype")]

in MenuState.as to make it work on my computer in Flex 4.

The first thing (apart from the timing) I'm probably going to do is to test out a whole bunch of movement options, wall jumps etc. to see what works. But I don't know how much time ill have in the immediate future.

[ℎalifax]

I've been thinking about the whole '3D world, move between dimensions with doors' concept. I've come to the conclusion that it's inherently flawed. I've never liked games where the key feature is restricted to certain areas/times, and I think that's what we're essentially doing with these doors. The current idea also makes maps a lot more complex to view, make and even locate oneself within the 3D world. Furthermore, it slows down the action if we're going to have a pause every time you go through a dimensional door. Instead, I propose a different system.

Time travel.

The basic mechanic would work similarly to the 3D thing currently intended. However, the protagonist now has the ability to press up or down at any time, whereupon very different things would happen.

Pressing up would transport the player to a version of the screen they are currently on, same tiles and zone, but at some point in the past.
Likewise, pressing down would transport the player to the same screen, but in the future.

In this way, it will essentially be a 2D game, but with three 'time levels' for each screen. This, I feel, will make for some very creative puzzle design. For example, a large tree blocks your way in the present. To progress, either travel to the past, to a point where the tree is merely a sapling, and jump over it with ease. Alternatively, go to the future, and the tree has withered and died/been cut down, and you can bypass it. Once past this obstacle, the player can return to the present, with the massive tree now safely behind them.

To clarify (with images) each screen would have three 'versions' of itself: past, present and future. The player moves between these 'time levels' at any time with the up and down arrow keys. Like so:



Again, hope that wasn't too confusing.

[mattk210]

It seems like you'd just cycle through all the timeworlds every time you got stuck so it seems like extra keypresses for nothing. With limited access (through doors) it can work, as seen in metroid prime 2 and zelda, but in those games the alternate versions have quite a different feel and are basically new levels.

With the original idea there's no need for a pause. You could move as the POV is changing even.

[ℎalifax]

Well, the tree example was a very simple one. There would be harder puzzles that involved you actually doing something in each timeworld, as opposed to just scrolling through to see which one allows you to win. For example, to get across a huge expanse in the present you might have to fill it with water. So you go to the past and turn on the tap. Then you go back to the present and hey presto, the expanse is full of water and you can traverse it.

I just feel the design would be too difficult and the rewards too insignificant to warrant the faux-3D system.

[Geti]

The first thing (apart from the timing) I'm probably going to do is to test out a whole bunch of movement options, wall jumps etc. to see what works. But I don't know how much time ill have in the immediate future.

I think locking it to a fixed frames per second with FlxG.elapsed = 1 could be best in the short term, though it could be better to do further abstraction later (like having 30 input states/cycles per second, but unlimited logic and rendering states to make demodata possible but retain the highest possible integrity of the simulation), so eventually, I suppose option 3 will be best. But, for now, I think just locking it to a fixed deltatime and limiting the framerate could be an excellent idea and let us get prototyping various functions quickly.
The font embedding meta needing changing is odd O_o again, I'm just compiling Metagame.as with mxmlc, so maybe doing it with FD requires different metas.

Also Orange, if enough people are keen to do time travel then that'd be fine, but I really like what we're doing with the 3D so I'm working towards that with the level structure and eventually the demo level.

[mattk210]

I like the 3d because we have an extra degree of freedom to link levels together, and I like the idea of being able to see your eventual goal in the background. Indeed there are complications though. We're definitely not yet at the stage where we actually implement the 3d system, so there's still plenty of time for discussion.

Geti: do you have the font installed on your system? Which version of flex are you using? (I'm on 4) I'm using mxmlc as well for the time being. Does my fix break fonts on your end?

it could be better to do further abstraction later (like having 30 input states/cycles per second, but unlimited logic and rendering states to make demodata possible but retain the highest possible integrity of the simulation)

unlimited logic states? I'm not sure I follow why that would allow demodata. But whatever, option 1 is working fine for me, I just needed to tweak the speed variables.

[Geti]

Geti: do you have the font installed on your system? Which version of flex are you using? (I'm on 4) I'm using mxmlc as well for the time being. Does my fix break fonts on your end?

it could be better to do further abstraction later (like having 30 input states/cycles per second, but unlimited logic and rendering states to make demodata possible but retain the highest possible integrity of the simulation)

unlimited logic states? I'm not sure I follow why that would allow demodata. But whatever, option 1 is working fine for me, I just needed to tweak the speed variables.

No, I just have it in the /data folder. I'm using flex 4 and compiling with a simple "mxmlc Metagame.as" so I can't imagine what the problem is.. Your fix doesn't break anything for me though so good that it got picked up I suppose :)
The unlimited logic states would be like it is now, with velocity additions etc modified by deltatime, but the input states would fall on set times. It might work, it might not. Glad you're getting fixed time working, in any case :P

[mattk210]

The unlimited logic states would be like it is now, with velocity additions etc modified by deltatime, but the input states would fall on set times. It might work, it might not. Glad you're getting fixed time working, in any case :P

That would break demo data for accelerating motion, for collision and a whole host of other things that are triggered on logic states. Euler integration has different results with a different timestep, for one.

[Geti]

True. Scrap that idea then :)
http://drop.io/st4cey1 the latest source, I'll try to get a github or something up tomorrow, but for now, there it is. has level and screen objects in it, still unfinished and thus do nothing but it'll give you an idea of what I've been doing. as it does nothing interesting for those not looking at the source, no swf for now.