Omnimaga
Calculator Community => Other Calc-Related Projects and Ideas => TI Z80 => Topic started by: shmibs on July 03, 2012, 01:09:53 pm
-
it's a bit late to enter the contest, but i felt like making something related to the topic anyways, and have been playing a lot of Steel Storm (http://steel-storm.com) recently, so here's the beginnings of a tank fighting game of some sort. adding in smooth scrolling maps + bullets + collision detection will add a HUGE amount of overhead, but this is running with 11 AI's and at 6MHz, so i think it might be doable with 2-3 AI's at a time and at 15MHz, with some optimisation.
-
Oh wow this is cool :D by the way we should get more ppl into playing.
-
It's a lot late. Only 5 days left.
-
Not really, it's just procrastination at it's finest. I could still write an ok entry in five days if I threw most my time on it. :)
-
Not really, it's just procrastination at it's finest. I could still write an ok entry in five days if I threw most my time on it. :)
Couldn't have said it better myself. ._.
-
oooh shiny! What kind of rules to the AI's follow?
-
it's rather simple, actually. right now, they just have a 2/3 chance of accelerating forward, 1/3 backward, turn towards the player, and stop moving forward within a certain distance. i'm going to add in side to side motion as well and have them slide a bit ambiently and have a chance of swerving when the player fires his weapon/they hit a wall.
EDIT: builder, what do you recommend for a map setting?/me is worried that smooth scrolling would be too sluggish with this much going on, but that anything else would feel too crampt.
DOUBLE EDIT: what should i do for collision detection? is there a better method than progressional pixel testing?
-
It looks pretty cool, but the sprites remind me of race cars from some old video game instead of tanks. XD
-
It's looking nice so far!
Keep it going! :)
-
Cool! I considered doing something similar for the nspire, but changed my mind.
-
DOUBLE EDIT: what should i do for collision detection? is there a better method than progressional pixel testing?
I use a hackish radial-distance method for collisions in Embers - I pretend every enemy and item exists within a diamond given by distance=distancex+distancey, which is basically a optimal corruption of pythagorean distance=root(dx^2+dy^2). It's not as graphically perfect as using pixel masks but it sure is a hell of a lot faster.
-
That sounds like a pretty neat idea ...Tho it indeed sounds like an epic corruption O.o
-
it's a bit late to enter the contest, but i felt like making something related to the topic anyways, and have been playing a lot of Steel Storm (http://steel-storm.com) recently, so here's the beginnings of a tank fighting game of some sort. adding in smooth scrolling maps + bullets + collision detection will add a HUGE amount of overhead, but this is running with 11 AI's and at 6MHz, so i think it might be doable with 2-3 AI's at a time and at 15MHz, with some optimisation.
Looks awesome.
-
i doubt i'm every going to do anything with this, but here's the latest version of it, if anyone feels like playing around.
A is the executable, ACC and TANKS the source, and the arrows move you in directions relative to the tank, while 2nd and mode turn.
-
Looks fun. Looks like a good start for a game. :)
-
DOUBLE EDIT: what should i do for collision detection? is there a better method than progressional pixel testing?
I use a hackish radial-distance method for collisions in Embers - I pretend every enemy and item exists within a diamond given by distance=distancex+distancey, which is basically a optimal corruption of pythagorean distance=root(dx^2+dy^2). It's not as graphically perfect as using pixel masks but it sure is a hell of a lot faster.
Ok, in basic if i want to do that, i just do:
:root(abs(A-X)^2 + abs(B-Y)^2 -> C
:if C=1 or C=root(2
:then
:commands
:end
Where A and B are the coordinates of the (point or object) thats it collided with
And X and Y are the 'players' coordinates
Checking for root(2 is for diagonal collision and checkig the 1 is for checking for horizontal or vertical collision
This methode is just for 1 pixel colliding with 1 pixel, so much more checks would be nescessary for larger objects, i know this is an axe-topic but maybe you now have a simple idea of pythagoras?
Edit: this was meant for shmibs, not for squidget, the quote was just to tell that squidget is right about this being a good way
Edit2: ps: correct me if i'm wrong ;)
-
Wow seems pretty fun. You should at least add dying and make it some sort of survival game. :D
-
Ok, in basic if i want to do that, i just do:
:root(abs(A-X)^2 + abs(B-Y)^2 -> C
:if C=1 or C=root(2
:then
:commands
:end
I don't get the utility of the "abs()" right before the "^2" ;)
Also, we are here talking about Axe, not basic. So root(2) is equal to 1, which means that the second line has something redundant and that all your method loses precision. Instead of working with the distance, what you can do is working with the square of the distance, that you compare to 1 and to 2
-
Ok, in basic if i want to do that, i just do:
:root(abs(A-X)^2 + abs(B-Y)^2 -> C
:if C=1 or C=root(2
:then
:commands
:end
I don't get the utility of the "abs()" right before the "^2" ;)
Also, we are here talking about Axe, not basic. So root(2) is equal to 1, which means that the second line has something redundant and that all your method loses precision. Instead of working with the distance, what you can do is working with the square of the distance, that you compare to 1 and to 2
Like i said, i don't know much about axe
And indeed, that abs( thing was stupid of me that i didn't saw that