Throw Punch!! A one button fighting game for two players.
This was a little idea I had to try and make an interesting fighting game with only one button. The aim is to knock your opponent off the mountain. Both players gravitate towards each other and can press their button to throw their fist. When a player throws a fist it moves with the player's momentum plus a factor. However the fist decelerates then moves back towards the player fairly quickly, and your own fist can knock you backwards towards the edge! The idea is each player wants to press the button as late as possible but before their opponent... Or is it as simple as that?
Version 1.2 adds a little polish: a splash screen, a couple other stages, a transition between rounds and games and structures each game into 5 life stock battles.
Version 1.1 is here for those who want to play the older version of the game with no menus or transitions
Wow, this is a surprisingly effective little mechanic. I wonder if there's any way to build on it?
Cool, i'm glad you like it! Yeah I've been brainstorming it - i'm thinking of adding different stages and a simple AI bot. Any suggestions would be appreciated!
I dunno. I mucked around with your code a bit and changed it from 1D to 2D, but couldn't come up with anything more compelling than the original. :)
Oh awesome! Could you post your variation here? Just curious to see what you came up with - might give me some ideas too :)
My 2 cents:
- might work in a top-down road rage game. Bikes fet pushed off the road (eg out of the circle)
- sumo game? adding left and right keys to dash sideways would expand the gameplay
Next game idea is $5 ;)
Mine's currently broken, but if I get it going again I'll put it up. I didn't want to step on your toes. :)
Yo it's cool put it up if you want! Just make the credits say by Davbo and Felice :P
Also if you've not looked just fyi I tidied up the code a bit for 1.1 by putting momentum when attached onto the fist instead of the player which simplified the collision reaction. This fixed a bug with fists getting stuck in each other.
Okay, well, it's working again, and I mucked around a lot more in the process. You, uh, might not recognize a lot of the code anymore.
It does basically work the same way. I just abstracted a lot of stuff out and set it up for 2D and 2 fists so that, technically, it can be extended to use the whole arena in a rock'em-sock'em-robots kind of way.
Right now it doesn't apply any torque for a single-sided punch, so you just slide back and forth. I think it'd be cool if you could twist off-axis, either as part of your punch or as part of getting hit. Then, on top of that, maybe you could also get knocked away from the central track, too. I think I'd have the two players oriented towards each other on springs, so they'd always be trying to point at each other, no matter where they were, but could get disoriented by a hit. I dunno, just thinking in the big blue sky here. Right now it's still locked to 1D.
Anyway, here it is. Sorry for the massive changes. Hope you can still follow it.
Wow! This is cool!
I've not been coding in pico 8 / lua for very long so learning from this code. Didn't know you could define tables like thing={a=1,b=2}, that's a little cleaner than I was doing it.
For lines like
a.rmx=(target.pos-a.pos):norm()
What does the colon do? Something to do with this quick 2d vector lib?
the debugging stuff is cool too - I've just been getting by printing stuff to the screen with that 'test' variable on my projects so far.
On the game design - this version has a very different feel to it. On a quick play with someone feels a lot more like a squabble than my one since you seem to get two or three punches out before you actually break away from each other again. Both players feel a lot heavier.
I found myself throwing both punches at once which effectively makes it play the same as the original. I think if two people had played the first one a lot and had got used to thinking about if the other player was going to punch early or late and if they were going to punch early or late they would enjoy this upgrade since they have to think through the same ideas but for two arms at once.
Pressing buttons that are next to each other to trigger fists that are up from each other is a little confusing. For blue up being the bottom fist and down being the top fist is also confusing. Could rotate the game 90 degrees so each player has a right and left button mapping to a right and left fist?
Rotating the players is something I really want to do. I was thinking of like auto-rotation, or the stage rotating, or one player having a button that accelerates the axis the players face off through anti-clockwise and the other player having a button that accelerates it clockwise. However this idea of having two fists and getting punched by a right fist rotating the player anti-clockwise and the left fist rotating the player clockwise is really cool. There could be a stage that is really thin which would encourage players to split up their two punches to try and rotate their opponent to be backing offstage. It is a whole other dimension of complication tho.
When I find more time for it I'm going to expand my original with other stages, then may absorb some of these ideas into that one. Thanks for putting in some work into this idea, it's really cool to see! :D
Yeah, communicating the impulse from the hit(s) back up to the shared body was tricky and I'm not sure I got quite the same result. I'm not experienced in physics programming, so I probably got something wrong.
The gameplay merely functions at this point. I know there is no balancing. There should really be a penalty for throwing both punches at the same time, but also an advantage. You should be forced into a rock-paper-scissors sort of situation when facing off, where picking the complement of the other person's attack tends to win the hit. Not sure how to do that.
As for the colon, it's for object-oriented stuff. Normally, to call a method on a table/object, you do this:
object.method(a,b) |
But if you want access to the table itself, you call it like this:
object:method(x,y) |
And Lua will insert 't' in the first arg, pushing the rest of the args down one slot. It's as if you called it the first way, but with the extra arg first:
object.method(object,a,b) |
That fits with declaring the method with a colon:
function object:method(a,b) |
This will quietly provide that first argument as a hardcoded self variable inside the method. Same as the self or this in other languages.
You can do methods traditionally, too. These two produce identical results:
v2={x=0,y=0}
function v2:set(x,y)
self.x,self.y=x,y
end
function v2.set(self,x,y)
self.x,self.y=x,y
end
-- even this
v2.set=function(self,x,y)
self.x,self.y=x,y
end
-- both call types work in all cases
v2:set(1,2)
v2.set(v2,1,2)
|
There are also things called metatables that allow you to do stuff like provide common methods and values to a whole class of objects, along with operator overrides. I use that to do direct math on the v2 objects in that code, and to provide some common methods. I'd suggest poking around the relevant docs on lua.org.
Oh, you know, I just thought of one thing I did change about the behavior, which might indeed make them feel heavier:
You lose some of your speed when you throw the punch. This, in addition to how you also lose a little when it comes back and "bump!"s you.
This is one idea I had for making it dangerous to throw both punches at the same time, since it makes you more vulnerable if you're hit afterwards, having been slowed down a lot.
Maybe if that effect were stronger, hmm.
Oh, and by the way, you could easily change mine back to your single-fist version just by editing the skeleton to have only one arm bone, change that arm's bone to 0,0, and hide the body by setting its radius to 0.
In configure():
function configure()
player_defaults=
{
{
pos=v2(15,63),
rad=0, <====
col=12,fistcol=1,
btns={
{{0,0},{2,0},{4,1}},
{{1,0},{3,0},{5,1}}
}
},
{
pos=v2(112,63),
rad=0, <====
col=11,fistcol=3,
btns={
{{0,1},{2,1},{4,0}},
{{1,1},{3,1},{5,0}}
}
},
}
--player skeleton
arm_bones=
{
v2(0,0) <====
}
fist_bone=v2(8, 0)
end
|
Technically, you can give players any number of arms. :)
You can also add more than two players, but I wouldn't bet on it working well. :)
aahh, that : thing is cool, for a different project I had
effect.update(effect) |
which seemed all kinds of wrong, so now I know.
I'm planning to have an options menu for stuff like 2 player/1player vs bot, gravity strength, etc so could make it like a menu option to have two arms or one. Then if there was only one arm but both where off centre it could work into this potential rotating mechanic... So part of the extra received force could rotate player a clockwise and likewise rotate player b anti-clockwise. Then that would get the rotation mechanic involved while still being purely one button.
And yeah that losing speed on throwing the punch makes sense - I think there's a commented out line in 1.1 to that effect. I guess it just needs a lot of play testing and fiddling with numbers to get the best balance. I think the game would be best if it was purely elastic - so the amount of energy in the game is defined by gravity and how far away the players are from each other. At the moment adding a factor on throwing the fist and then halfing the force when re-connecting to the fist means the amount of energy in the system isn't consistant. But if on releasing a fist that energy that is added on comes from the player's movement energy, then on re-colliding with the player that energy is just re-distributed that would work.
I think that's basically what I'm doing when I throw and receive the fist. Thing is, I'm not taking mass into account anywhere. So basically there are just two sources of impulses, the fists, and their effects are distributed evenly. If the arms and body had some mass, the forward inertia induced by gravity would matter more.
BTW, as I mentioned, I'm not really a physics programmer, so I may be misusing the term "impulse". I basically mean the momentary force applied to each actor, or transmitted to a connected actor. Technically, I should be applying each frame's gravity as an impulse as well, I guess. The math would end up the same, but it'd be more functionally consistent, rather than collecting the final impulse generically and then adding the gravity vector by hand.
Really, that would all come into play if each actor were a proper physics object of its own, rather than a component of a single body that might or might not be disconnected. Then constrain where necessary and apply torque if the constrainted positions differ from reality.
I haven't worked on it since uploading. I have a weird problem with my nervous system that makes it hard to focus on programming most of the time. When I can, I work in hurried spurts before I get all distracted again. Haven't had another of those yet. :) I'll keep you posted if I come up with anything.
yeah there's some fiddly questions that need answered to make things concise - that's physics! It was nice to get away with my ad-hoc applying of forces in the tiny original but yeah scaling up would probs fall apart pretty quick. Learn a lot doing it by the book as well.
There's another cart I was working on before I had this idea so I'm going to try and finish that before coming back to this but yeah I'll keep you updated as well when I get back to this :)
Couple of suggestions. The title screen is entirely unreadable. If you can't make the text work, get rid of it. Secondly, it would be way better if the players were circling around each other, just to add some dimension to the game. Lastly, some sort of catch or charge would be good. Something more than just "press button at right time". Like if while your fist was flying from you you could hit the button again and charge up a shot that will go with your fist the next time. Or if you hit the button just as your fist hits you you can negate the bounce back. Or both. Just something so that the game is more than "Vis de finger, das key pokin."
[Please log in to post a comment]
