Project: Metagame - Join and contribute!

[Atilla]

So maybe planets that are at maximum 150 pixels in diameter and as an average about 100 but no smaller than 50 pixels will work just fine for both platformer and planetoids styles. This also adds quite a bit of variety, which as I see it, is a good thing. For one, a variety of sizes gives us an option of making different game-play environments, allowing us to sort of satisfy both sides (i.e. LV and matt).

Pixel dimensions aren't all that useful unless you've already decided on a fixed resolution for display, which we haven't. Anyway, assuming we're going for the standard 800x600 or thereabouts, I think an average diameter of 100 pixels is far too small. As a comparison, Knytt Stories uses 24x24 sprites, and those have an absolute minimum of detail. So you're basically saying that if we use the smallest feasible character size, the average planet will only be a couple of times wider than the character, as depicted in the attached image (attached). In particular, note that there is very little room for features on the planetoid - if we used this size, every planet would have to be a near-perfect circle, with maybe a couple of small lumps, and the game would consist entirely of jumping between similar-looking tiny planets because there's no room to do much on a given planet. And God forbid if anyone wants a larger character.

I'd recommend that a large planet be about as wide as the screen is tall, so that we can see roughly half the planet at a time, and the smallest planet be approximately one-fifth or one-sixth that. This should leave room for three or so planets on the screen at a given time, allow us to make individual planets more interesting, and allow a larger and more detailed character if people are so inclined. It also decreases the probability of motion sickness.

[Condog]

I'd recommend that a large planet be about as wide as the screen is tall, so that we can see roughly half the planet at a time, and the smallest planet be approximately one-fifth or one-sixth that. This should leave room for three or so planets on the screen at a given time, allow us to make individual planets more interesting, and allow a larger and more detailed character if people are so inclined. It also decreases the probability of motion sickness.

Are we planning on including a zoom function, like in N+? That way, if we use vectors for planets/character/etc if you zoom in they still retain some level of detail.

Those sizes sound pretty reasonable. And I don't think we need the character to be any larger than the ninja relative to the screen at full view. If we did use the zoom fuction, the character would be much larger when zoomed in (duh!), and that could satisfy any people who want a larger player.

[Geti]

i like this idea. zoom would be handy, and would just mean we'd need to go into a little more detail. id like it if planet's were made of 2 .svgs, for the things you walk on and a background layer (for the back of tunnels etc), and there was foreground and background scenery that was definable. if we set this out in a moddable way, loading .svg images etc and reading level info from what is essentially .ini (not even like userlevels.txt, more like editable code). that way we can make content easily, and before we get an editor done people can still mod it. and the editor would just remove the need to "handmake" levels for the level designers after it was programmed.

i kinda think there should even maybe be some reeeeeeallly big planets, like maybe even twice the size of the screen, so the curve was still present but not much visibly. for large battle scenes.

on the bullet hell option, as noted in the development document and about to be added by me:
using weak enemies here and there would let level creators construct bullet hell anyway. if the majority of enemies are weak and crushable and really just there to keep the players attention with some strong, fearable enemies around (either powerful melee (zap, blades etc), missile, lazer or high rate of fire enemies) that could easily be made into bullet hell (or "hard difficulty) by multiplying the enemies a little :P especially the weak ones. ill draw up some concepts of enemies, to gimp!

[mattk210]

Atilla has good general guidelines for planetary size, but in no way should we limit ourselves to an exact max/min. I can foresee really tiny asteroids that have such a weak gravitational field that they can't really be walked on, and really, really big planets that have traditional platforming on them.

Personally, I would prefer the majority of the focus of the game to be on gravity physics and not fighting enemies, rather they just be the occasional obstacle to work around, or as a dedicated boss (which is pretty much a puzzle on its own). That's just my taste though, I prefer minimalistic N levels.

I'm all for dynamically loading images for stuff but I would think some of it would be generated on the fly. Moddable is definitely good for the long term appeal of the game.

Zooming would be great, and give a really dynamic feel. I was thinking kind of like smash bros, where the screen automatically scrolls/resizes to catch all the action. When it gets really flippy, zooming in a lot would reduce disorientation as well.

Also, small points:
* I'm pretty sure planetoids have no active core, once they do we call them planets
* let's not get ahead of ourselves with particle physics. Do we really need them?
* When I update the wiki, I usually make many small changes. Can I collapse my edits? (I have like 5 in a row) never mind, figured it out

[Animator]

LV and I have been discussing some stuff and we feel that this could be more easily discussed in #metagame in the IRC server, WayPastEleven. We could prepare everything there, and then post the news in the messages section at the Metanet Assembla page. Thank you for your time.

-Mechanica.

[Geti]

Atilla has good general guidelines for planetary size, but in no way should we limit ourselves to an exact max/min. I can foresee really tiny asteroids that have such a weak gravitational field that they can't really be walked on, and really, really big planets that have traditional platforming on them.
...
I'm all for dynamically loading images for stuff but I would think some of it would be generated on the fly. Moddable is definitely good for the long term appeal of the game.

yes, especially on the asteroids. i think "fall" damage should be done by speed and orientation, so if you dash through an asteroid blet flipping around landing on your feet on each one, then jumping to the next, you get out without a scratch, but if you clonk about on your head and dont land smoothly, you will come out battered, if at all. i also thing that the jump-man should not get hurt from fall damage if he lands spring-ery side down, the run-man should take less, but the floater (what was his name?) would take a lot if he actually collided with something with much force.
also, with dynamically loaded images the planet size thing isnt an issue, as they can just be scaled and made in more detail for large things, but i agree about the procedural stuff, especially for asteroids. who wants to place asteroids one by one? :P

also whoever put the dead planet thing in, THANK YOU. im glad my idea for them stayed alive somehow, even if not in a dynamic way.

Personally, I would prefer the majority of the focus of the game to be on gravity physics and not fighting enemies, rather they just be the occasional obstacle to work around, or as a dedicated boss (which is pretty much a puzzle on its own). That's just my taste though, I prefer minimalistic N levels.

i like minimalism too, but if its level designer based, and moddable then it can go either way, across any number of levels. some could be ambient and calm, others could be hectic! yay! everyone's happy. there could even be levels were your only enemy is gravity and planet cores.

Zooming would be great, and give a really dynamic feel. I was thinking kind of like smash bros, where the screen automatically scrolls/resizes to catch all the action. When it gets really flippy, zooming in a lot would reduce disorientation as well.

id like it better if it were manual, as then if its flippy you can zoom in, if theres lot happening you can zoom out etc. if it was going to be automatic then it would probably have to be predefined, instead of procedural..

*I'm pretty sure planetoids have no active core, once they do we call them planets

interesting...

i should get on the irc.

[mattk210]

i don't really know how to use IRC, I connected somehow but nothing is happening. Never mind. I was thinking about orbit physics, and as much as I'd like to, I don't think it's feasible to have orbits using real physics.

http://psychonova.110mb.com/test.swf

that's a demo of a planet orbiting a planet orbiting a planet, and the only way it can work is if there is a large distance between each one and the mass difference is very dramatic (like in real life, the moon, sun and earth are very differently sized). We will either need to make some sort of fake physics that allows this, or fake orbits like Geti suggested.

(btw, don't try to drag planets - it's broken)

PS. It was me who put dead planets, but only because you decided to add some stuff about a core, and I wanted the option of a completely neutral 'rock' in space.

[Zora_S_Kenneth]

*I should have clarified my statements that they'd be about 100 pixels zoomed all the way out with a view of 1024x768, which would be full screen for an XGA screen. And now that I look at it, maybe 200 is a better average, and 50 and 1000 as limits*

But a zoom option is a very good idea, as is scrolling. Those are some of the things that made N+ so good.

And it is a good idea to focus on the physics more than on the combat system. Not that we'd neglect making the combat system realistic.

@matt: Particle physics? Need them? Of course we need them! It give the game a whole new level of cool! Besides, it's only a few more lines of code for each emitter. Five lines will define the following: the emitter position/image, the direction, the birth rate, and the image. Add a few more lines for the dynamics and there. At least this holds in C++, I'll need to check in Python.
(I get the feeling it's fewer, since Python is routinely used in low-scale game programming. I mean, come on, Autodesk Maya comes with options to program a game in Python directly).

@Atilla: We don't necessarily need a vector image. If there is a limit as to how far you can zoom in, then we just need a large bitmap that we can shrink as we zoom out, which may help for greater detail levels since you'll need a lot more data with vectors to deal with detail generated by, say, Fractal noise. Although vector images are smaller when we have sprites about as complex as the ones in N+... never mind, I'm not going to make any decisions about this.

@matt again: You'll need an IRC client. Most browsers (yours too apparently) don't have an IRC client built into them. Try mIRC, or ChatZilla (I use the latter, and recommend it highly).

[Animator]

i don't really know how to use IRC, I connected somehow but nothing is happening. Never mind. I was thinking about orbit physics, and as much as I'd like to, I don't think it's feasible to have orbits using real physics.

It's incredibly easy, just download an IRC client and we'll help you from there.

[Atilla]

I was thinking about orbit physics, and as much as I'd like to, I don't think it's feasible to have orbits using real physics.

Oh, no. I meant to point that out earlier. It's not feasible to have true orbital physics for the planets due to the n-body problem. Instead, we could fake the orbit/motion of all objects which have gravity, and have real (well, real-ish in the circumstances) physics for objects which do not exert their own gravity (in other words, the player character, enemies, shots, etc.)

[Geti]

faked orbits unless smashed please *goes to check design document*

[mattk210]

Do you think it would be possible to have orbit physics using heavily modified real-world physics? I think it would be pretty lame if the planets just moved in perfect circles around each other, there should be a way to, say, shift a moon from one planet to another by pushing it towards another at just the right speed. My demo shows that it's possible to simulate this, but because of the nature of gravity, the body being orbited needs to be orders of magnitude more massive than the bodies orbiting it. If we have, say, a mass for its own grav field, and a separate mass to calculate its attraction towards other bodies, we could fake orbits while still having them dynamic and fun to play with. I'll think/program about it some more.

@particle physics: N sort of fakes particles with just a pre-made animation of dust/blood coming off (i think). Real particle physics take a large chunk of the CPU for an effect that is (usually) purely graphical. In any case, I think decorations like that should be made after the big, gameplay-affecting things so that we can just use the leftover CPU rather than limit ourselves for everything else. But I agree, they look cool.

@vector: scaling bitmaps always leaves an imperfect image because the pixels aren't 1:1. Antialiasing/filtering can be used to prevent this, but it'll always look a bit worse than vectors. Really, it comes down to the art style we want. We won't need fractal noise if we have a block, cartoon style.

@irc: thanks guys, I had chatzilla but I didn't know how to use it. If I'm doing strange things on IRC, please be understanding!

[Atilla]

Do you think it would be possible to have orbit physics using heavily modified real-world physics? I think it would be pretty lame if the planets just moved in perfect circles around each other, there should be a way to, say, shift a moon from one planet to another by pushing it towards another at just the right speed.

Fake orbits don't have to be perfect circles - there's no technical reason why the path couldn't be any shape you wanted. Moving, creating or destroying planets in response to player actions could also be handled through scripted events.

Also, trying to shift a moon from one planet to another with anything even close to real-world physics will result in the moon either flying off into space or smashing into the planet after a small number of orbits in most cases. Or flailing around in some crazy elliptical orbit. In any event, it wouldn't really work as a game mechanic.

[Geti]

you do realise i mean particles like, projectiles, and the things that could be used in explosions to cause damage right? can also be used for blood/wound effects etc and gibs (if things do gib into pieces). i dont mean particles that give off light or anything (except maybe some precoded glow that is actually just an additive layer), just extra bodies that move and collide with things. bullets would be an example of particle effects.

even if we use a more detailed style, you can achieve it with vectors. the filesize is usually way smaller aswell. vectors are looking like the way to go. even if we work in pixel for some things, people can convert the sprites to vectors as we work, it doesnt take too long..

the orbits would not have to be perfectly circular at all.. maybe the initial orbits are calculated due to gravity, then set in stone until something knocks them out of orbit? if you can find another way of doing this, that would be cool too. we do also need some slow orbits happening, as the ones in your demos are really fast :P
im not fussed, just thinking of ways to semi-fake things.
----------thank you atilla for the better written example.

also would it be possible for someone to log the IRC happenings and paste anything meaningful in the wiki? for those of us that arent always at the computer :P

[mattk210]

i think there's 2 kinds of 'particles'. There's the practical kind like bullets that are usually discrete objects, and there's the cool yet a bit useless particles like simulated liquid and dust. Explosions kind of blur the line between this, but I don't see it being a problem just to have a circular blast radius that affects stuff, we don't need to simulate shrapnel being blocked by and ricocheting off stuff (unless I'm oversimplifying things and we really do want to make a highly complex game)

@orbits: you may be right, but I want to at least try and have some dynamic system of orbits. Maybe we could have a system that detects when orbits are 'close enough' to orbiting, then lock them in a real orbit until something disturbs them.

@orbit speed: easily modifiable, but if they go slowly, you will have to wait a long time for the ideal orbit position. Generally, any advantage that can be gained by waiting is bad game design. Maybe have a timer to balance this? (also they go fast in my demos so I can easily see the effects without waiting)

[Atilla]

the orbits would not have to be perfectly circular at all.. maybe the initial orbits are calculated due to gravity, then set in stone until something knocks them out of orbit? if you can find another way of doing this, that would be cool too.

It'd be much easier to just set the orbits manually, especially for level designers.

@orbits: you may be right, but I want to at least try and have some dynamic system of orbits. Maybe we could have a system that detects when orbits are 'close enough' to orbiting, then lock them in a real orbit until something disturbs them.

That's basically a convoluted way of having fake orbits with a script which checks if they've been whacked hard enough to be knocked out of orbit.

[mattk210]

OK, i suck, you win. I can't seem to make any sort of orbit that is dynamic and practical in our game. I guess, unless someone else can do it, we'll have to use scripted orbits. Plus, I considered possible puzzles and I can't actually think of a use for dynamic orbits like that. (sorry I was so stubborn)

But there should still be objects that float around that can get into orbit at least temporarily by moving at the right speed - like if an asteroid passes a planet (with a scripted orbit), it could be affected by that planet's gravity in such a way that it orbits once or twice before colliding or escaping orbit. Is this an OK compromise?

I'm going to make some changes to the wiki about this.

[Geti]

thats definitely ok, as the asteroids can be the line between moving object (eg enemy, bullet, player, that is affected by gravity) and planetoid. or really, just a dead planet that is affected by gravity. woot.

and pff, if we have a particle system like the one i explained, everything is easy to script so the explosions are either tiny boring circles or huge masses of debris and fire. if weapons and enemies are moddable aswell, thats even better. good use of a good particle system can make average games great. if we make a great game with a great particle system, so much the better.

[mattk210]

also, another problem with particle explosions is that they're unpredictable. Something explodes and stuff dies/gets pushed around in a manner that can't be reliably predicted. If we want competitive highscoring, an element of unpredictability like this could be highly annoying.

If on the other hand the particles are relatively few and slow and regular, it could be a great mechanic. I think particles could be great when implemented right, but definitely not high on our list of priorities. Something to think about later either way -- we haven't even fully fleshed out the kind of levels/puzzles we'll be having.

[Geti]

if we have the seed recorded at the start of a demo i see no reason why random chance should affect demo-ing at all. you wouldnt want to try to get though an explosion by sheer chance generally anyway, people usually go around :P

oh, just had a new idea, i thought id put it here before making a misc. ideas section in the wiki page:
what if we have a focus meter? it would go up whenever you damaged an enemy or had a near miss with a bullet, or changed from one field of gravity to another, and maybe from chaining jumps, rolls etc., and go down from losing health (from falling, core damage or enemies), and standing still for too long. if anyone can thing of something ive missed, go for it. i can see it being a +/- meter, like

Code: Select all

-               +
|-------|---+---|

if you can see what i mean.. no?
anyway, high focus would make you take less damage, jump further, run faster and generally respond better, and low focus would make you take more damage, jump a shorter distance, run slower and respond sort of sloppily. maybe the health things could be reversed, so you take more damage but respond better in high focus, but dont get slaughtered if youre having a bad day. eh, either way, you cant change form in low focus mode, and when you change on above 50% high focus, a shockwave comes out of you as you change, a bigger one the further above 50% you are, damaging all enemies and stunning some.
that brings me to my next point - changing forms levels your focus back to 0%+/-
it would be an interesting game mechanic, and make chaining jumps and rolls and generally showing off have some rewards.

[Animator]

Plot-wise: We could make the story based on 3 robotic brothers separated by space and time, and are on the search to find one another. You face different bosses for each one.

Game-Wise: I just thought of a boss, which could work as a wormhole/blackhole. Basically, at first, you'd have to run from it in order not to be sucked up (acting at first as a blackhole), and then at the very end, you'd have to shoot it in order to close it as it spews out random chunks of matter at you. I'd like to call this entity the Schrödinger-Paradox. I feel it's fun and nice, but I want critique first. Also:

oh, just had a new idea, i thought id put it here before making a misc. ideas section in the wiki page:
what if we have a focus meter? it would go up whenever you damaged an enemy or had a near miss with a bullet, or changed from one field of gravity to another, and maybe from chaining jumps, rolls etc., and go down from losing health (from falling, core damage or enemies), and standing still for too long.

Let's not complicate ourselves thoroughly. I think there are already enough complex ideas as it is (especially since we're already re-visiting time-space theories and quantum mechanics at this rate). Let's get the ideas and mechanics rolling and then we'll see what takes us from there. I like the idea, but again, we're not Nintendo, and the coders can only do so much.

Finally: GET ON IRC. #metagame It'll make life easier with closer contact.

[squibbles]

Plot-wise: We could make the story based on 3 robotic brothers separated by space and time, and are on the search to find one another. You face different bosses for each one.

Hasn't that already happened in a mario game animator ;)

[Animator]

Hasn't that already happened in a mario game animator ;)

You mean a fat plumber rescuing a princess from a dinosaur/turtle? I believe not. And no, it won't be like the DS game. Completely different. QUIT DIGGING UP REFERENCES.

[mattk210]

focus meter: yea it's complicated but what if focus let you switch instead? That'd be awesome

Also, misc ideas is uncecessary, just put it in general mechanics or start a new section

Animator's plot idea: ok, but that wouldn't make much sense with switching in-level. Do we want switching in-level? Generally the best practice is to design a game then make a story around it to avoid limiting yourself.

@IRC: not sure if it's timezones or incorrect configuration but whenever I go on there's no discussion happening. Plus I'd rather take a break from work, read some posts, make a reply then log out rather than have a big discussion.

[capt_weasle]

What if only part of the planet appeared at any given time? In terms of being 2D, you could have the character move forward on the planet to do whatever it needs to do.