<matt> so let's talk weapons
<matt> i prefer a generally pacifist game because 1) it's easier to code, 2) if you can't kill enemies it's a lot easier to design levels where the enemies are permanently doing a specific role
<Geti|emo> me and orange think everyone should have some sort of weapon, there should maybe be a grenade lobber for run mode and jump should have a powerful cannon. enemies can have any weapon
<Geti|emo> especially lazers.
<matt> elaborate on powerful cannon
<matt> please
<matt> like a fast dynamic object?
<Geti|emo> some sort of either beam or bullet weapon.
<matt> hm
<Geti|emo> none of the players ranged weapons should be spamable, they should either have an ammo -> reload time system (yes to you question) or a cooldown system
<matt> that could work i guess
<matt> but what do you think of enemies that are unkillable
<matt> i was thinking the cannons and big stuff would be unkillable
<matt> so levels can be designed around them
<matt> and maybe the small respawning stuff can be killed
<Geti|emo> mmn, bigger enemies maybe.
<Geti|emo> we generally agreed that the enemies should take 1-3 hits to kill unless they are large.
<matt> how would health of an enemy be represented?
<matt> physical changes (color), health bars, or nothing?
<matt> 1-3 hits sounds ok
<matt> but if levels are big (like they will be), then some enemies will be left on half health
<matt> and I think we need some sort of visual indicator for that
<matt> do we even want backtracking? there's so many elements we haven't decided on yet
<Geti|emo> mmn.
<Geti|emo> maybe.
<matt> I think the key things are 1) player control and movement, 2) level structure and 3) enemies, their frequency etc
<matt> and we haven't formally decided on any of these
<Geti|emo> mmhm.
<Geti|emo> i think if enemies are generally weak, but there are strong ones, level designers can go as crazy or as controlled as they like.
<Geti|emo> and i think control with WASD [rebindable] and a mouse is the best with weapons and being able to look around. with a flippy camera that maybe eases slightly, but jerks a little if you roll or something.
<Geti|emo> and when you get hurt
<matt> so the flippy camera, does it flip based on the player's flips and stuff in the air, or does it align to the planet and its gravity?
<matt> im thinking align to gravity
<Geti|emo> mmn.
<Geti|emo> i think the player, but easing.
<Geti|emo> if the player usually flips to land with its feet towards gravity thats simmilar anyway.
<matt> the reason we considered the flippy camera is so that on a planet, pressing left makes you go left and stuff, even around a planet
<matt> if the camera is constantly spinning as you spin in the air, pressing a direction will cause the player to wobble in relation to the world
<Geti|emo> mmhm.
<matt> so if we do align to player, we'll need to solve this problem too
<matt> (but i suggest against it)
<Geti|emo> if the camera eases it will just sort of wobble when you jump.
<matt> that sounds unwieldy
<matt> so you mean easing as in simple go towards angle
<matt> let me show you something
<matt> hang on a sec
*Matt fails to find a demo. He finds it later in the log.
<matt> and that would mean if you spin in midair, it spins for a while after
<matt> which is even worse
<Geti|emo> and mmnkay. align to gravity then. i think the player should be able to be pulled between bodies though. none of this "only one body attraction" thing. maybe only bodies within 200% of the planets width or something..
<matt> are you referring to the notes I made in the topic
<matt> ?
<matt> I guess I kind of worded that wrong. What I meant was that interaction with a planet's geometry would be limited to 1 planet at a time, which is purely a coding thing. gravity is of course universal
<Geti|emo> oh ohkay.
<Geti|emo> yes, i suppose.
<Geti|emo> thats fine :P
<matt> because otherwise checks would be performed every frame on every object on every planet, and that's incredibly inefficient when you know that stuff can't move off the planet
<matt> I remembered noting something in the wiki about having run-man with hand-to hand combat, hover-man with no weapon and jump-man with a gun
<matt> i guess you dont think much of this?
<matt> the idea for this is to balance the characters. If hoverman can go into space and move around anywhere he's infinitely easier to use than the others
<Geti|emo> i like that a little.
<Ignate> depending on who the most maneuverability, that one should probably have no weapon. so yeah.
<matt> and the jumping guy would be really hard to use, having to calculate each jump rather than just pressing a movement key like everyone else
<Geti|emo> and i dont think hover can go into space that well though. i kinda think it would have some kind of thrust, and if that wasnt enough to get anywhere, too bad. youd have to use a jump to get into space.
<Geti|emo> and if you wanted to change your direction in space, you would use hover man.
<Geti|emo> shooting in space to change your momentum sounds a little silly
<matt> i was thinking of recoil
<Ignate> maybe jump-man has like a, jump meter? Like if you charge longer you jump higher?
<matt> it would still be harder than just walking around though
<matt> and probably slower
<matt> so do we want to be able to switch in space?
<matt> I'm a bit partial to condog's idea where you have to be still to change -- you need to establish a safe area where nothing moves you around
<matt> but if you can switch in space it solves the problem of getting stranded
<Geti|emo> thats kinda what i thought.
<Geti|emo> i like free switching, with it leaving you a little uncomfortable afterwards :P
<matt> what if switching made you stationary for a few seconds?
<Ignate> There also was a suggestion about switch points.
<matt> that could work too
<matt> it would let us design puzzles for a specific character
<matt> but it would result in less freedom for the player
<Geti|emo> i like the one where it ties in with focus..
<Geti|emo> ohkay, let me type a huge thing up.
<Geti|emo> if focus ties in with health, it could be a dynamic variable that effects a lot.
<Geti|emo> if you are on low focus/health, you would react slower but take less damage (to prevent people who are getting killed in 3 hits from the penalties) and could not change form
<Geti|emo> if you were on high focus/health you would react faster but get damaged more.
<Geti|emo> standing still brings your focus back towards the middle (50%)
<Geti|emo> if you are on at least 50%, you can change form.
<Geti|emo> the further above 50% you are, the less time you will be vulnerable (unable to attack) after changing, however, changing form brings your focus back down to 50% straight away.
<Geti|emo> that would just be a dynamic variable that changes how high you can jump, how fast and far you can roll, etc.
<matt> too complicated I think
<LittleViking> Come to think of it, how do cannons and grenades work in space? There's no oxygen to ignite it. And for that matter, sound can't travel. The effects guys are going to have an easy job.
<matt> grenades can be magnetic i guess
<matt> sound... I don't know
<matt> it'd actually be interesting if the sounds didn't reflect real sounds - like a grenade doesn't go 'boom', it makes an abstract sound
<matt> like in some of those futuristic shooters
<Geti|emo> heh it would.
<matt> space invaders extreme has a musical tone when you shoot or something explodes
<matt> it sounds awesome
<Geti|emo> and if the planetoids are close enoug together for someone to jump between them, they would likely share an atmosphere.
<matt> planetoids don't have an atmosphere
<matt> or an active core
<Geti|emo> i think some should.
<Geti|emo> or blah, what do i know :P
<matt> now i'm really interested in the abstract sounds thing
<matt> does that sound plausible or a bit lame?
<LittleViking> Yeah, I like that.
* Geti|emo does concept arts.
<LittleViking> I mean, not that anyone's ever called out a space game for having "boom" sound effects. But it would bother me now that I've thought of it.
<Ignate> Is there a partcular site that has sound effects? I'm sure there are.
<matt> i use the freesound project
<Ignate> Maybe I could search through a bit.
<Ignate> And yeah, abstract sounds should be good.
<matt> by the way, since i'm listed as a coder, does that mean I can only code? I want to work on vector artwork too, and maybe even some sounds.
<Geti|emo> you can do all.
<LittleViking> Yeah, you can do anything.
<matt> I think I found that easing rotation thing (I can't actually load it). http://www.senocular.com/flash/source.php?id=0.70
<matt> try spinning it fast
<matt> this is a counterargument to aligning the camera to a player, even though it's a bit late (it's kind of been resolved)
<LittleViking> I was just reading about the flippy camera up there. I think we'll really have to look at that to decide what's best.
<LittleViking> If it's aligned to the planet you're on, and the player is jumping from planet to planet, then it'll be flipping around all the time. It would be chaotic and hard to follow.
<matt> I was against the camera rotating at all from the start, but my suggested compromise is to have the camera align towards gravity: so running around a planet means the camera rotates around the planet with you, and going between two planets results in a single flip
<Geti|emo> if both are coded we can try both.
<matt> coding the align to player will be harder
<LittleViking> Also, I vote camera aligns to gravity rather than camera aligns to player. When the player does a flip or a roll, it's just a ball moving to the code. The animation will show it flipping, but the ball won't have to flip with it.
<matt> thats what I was going to say
<matt> so we'd have to store special data for the orientation of the player for that
<matt> and if we do that, we'd better be fairly sure we want it
<Geti|emo> how?
<Geti|emo> and why?
<matt> the player would be functionally a ball. the net gravity will act on this ball to make it move towards the heaviest and closest bodies. The camera would inertially ease to this summed vector
<matt> for the player orientation easing, we need to store player orientation data for each animation, or if they're calculated dynamically we need to calculate orientation too, and align to this vector
<matt> which means a fair bit of work
<Geti|emo> cant you essentially code a camera object and attach it?
<Geti|emo> we might not be working in flash.
<matt> this is language-independent. then the camera needs to be animated with the player
<matt> which also means more work
<matt> everything i say about coding to non-coders is language independent
<matt> basically, the only differences between languages is ease of implementing something and the speed of various operations