Archive: Making a game with AVS


25th November 2004 03:17 UTC

Making a game with AVS
I was playing this game and was reminded of a few presets. And I got to thinking how cool it would be if you could actually play a game with AVS. Got a few questions first:

-How "good" is the keyboard input? Is there too much latency/inaccuracy to make an effective game?
-Is there a better way to store data between frames than megabuf? I've heard its slow, and if the keyboard input isn't too great, we'd need to get as much speed as possible, plus I'm looking to store a LOT of data.

What I was thinking is, you just piloted a ship down the tube, dodging the walls. The shapes of the walls are dictated by the music, and score is kept based on how fast you're going, with points being deducted for collisions. If anyone would like to help me out on this project, I'd appreciated it.


25th November 2004 11:05 UTC

The problem with keyboard input is that a lot of keys are already in use by WA itself, which includes the arrrow-keys.
ASDW cannot be used either as S toggles the shuffle function. Mouse input (x,y coördinates) works great, but the left mouse button throws you out of fullscreen if you want to play in fullscreen. I've had an attempt to create AVScad once, there I used the mouse coördinates combined with unused keys (crtl mainly for drawing a line). You need two hands for it, but it's a good work-around.

megabuf isn't global, gmegabuf is; just as variables reg00, reg01 .. reg99. not sure what's faster though. gmegabuf in itself is faster, but often used with loops and stuff which make it slower again..

//edit: yay! this is my 500th post! I'm a 'major dude' now! (not that I care, but I thought: let's mention it:))


25th November 2004 15:40 UTC

ooh nice game. too bad one can't disable the music.

edit: ah, i can replace it :D


25th November 2004 16:08 UTC

Hm. Maybe you could just use the mouse to steer, and two vertically adjacent keys on the keyboard to accelerate/decelerate.

Anyway, I'd like to collaborate with someone on this project, since it might get a little hairy at times. The whole thing could probably be done with one superscope to render the tube, and a couple others to put objects in, and several render/texts to display score & such. Anyone know the range of values that (g)megabuf can take? or regxx, for that matter.

What's wrong with the music? :(


25th November 2004 16:10 UTC

I'm playing that game, it's mad fun!

You can make games in AVS, but they are greatly limited by the things already mentioned.

/edit-When did I become a major dude? I didn't even notice...


25th November 2004 18:00 UTC

I like a challenge :D That's the whole point behind this 'project'.

Also, I've been thinking of how to render the 'tube' as a wireframe. It'd be most efficient if it was all rendered as one continuous line, but directly rendering each gridline results in a lot of overlap. I was thinking of doing something like this:

|_|-|_|-|_|

(I'll be damned if I can remember what the ASCII code for the Overscore is.)

For each 'ring'. The only missing lines would be on the first and last rings. Also, since it's a closed ring, the jumps between rings will be smooth.


25th November 2004 18:19 UTC

[offtopic]
Congrats WoTL!
It has been a while since someone "upgraded" around here :D I remember in the begining everyone was posting like mad and everyone was congratulating each other for senior member, major dude, forum king... *sigh* I kinda miss that silly tradition :p
[/offtopic]



Anyway, Making AVS-games like you said xerol, is very very hairy business indeed. Just the sheer ammount of code for example collision detection is mind boggling (just a reference). I have made one AVS game though, which im quite happy of: Kill Visbot. Tho, don't take it as a example of how you should do things, it's very badly coded.

But all in all, it's not impossible to make good or even enjoyable games in AVS, but takes a lot of time, effort, skill and you need to squeeze every last drop of fps you can get from it.

Wish you luck :)


26th November 2004 07:02 UTC

The keyboard input 'feature' (where wa uses most of the keys already) is by far the most annoying of all the problems, personally I only ever use the mouse for input.

The 'hairyness' isn't really a problem if your a competant coder and you make sure you keep your code very tidy. Although I would strongy advise against it unless you have a fair bit of experience coding in AVS. Realistically there are only a dozen or so people I can think of who could pull off something as complicated as that game you linked to.


26th November 2004 22:29 UTC

this game you linked to is awesome, and addictive ;). But i also have the feeling that making a game like this with avs is very hard. (and never contradict the experts ;)). But has it to be a such a demanding game? O.K, its very funny & full of speed % looks very nice. But i remember a funny "click and clear" game made by m²k, i found some time ago.
It was a contribution to a "mouse-controlled-preset" competition here in the forums: some guy offered money for the two best mouse or kb controlled presets (but no one ever saw a buck). I still like to play this game sometimes.

//btw am i allowed to post that particular preset here as an attachment? Or would i have to ask the author for permission? Just wanted to clear off the legal situation before...


26th November 2004 23:58 UTC

Well, I wasn't going to make it as complex. It was just going to be a simple race-through-the-tube game, and you have to avoid colliding with the walls. Use the mouse to point the ship, and two keys on the keyboard for accel/decel. The only objects to be rendered are the ship and the tube(there was this one visualisation, it was a roller coaster track(sorry for not remembering who it was), shouldn't be too hard to make something a little more involved).


27th November 2004 01:42 UTC

Unconed made the roller coaster preset, and it is proabably one of the most complicated presets made. It has taken days for me to to dig through the code just to get a minor understanding of that preset.

It would be possible to make this tunnel game you are thinking about though. A superscope tunnel is not very hard to code, but the hard part will be making the ship move and interact with the enviornment. If you do plan to do it, I could help a little bit, but since I'm in school right now my time would be very limited.


27th November 2004 02:08 UTC

Well, here's how I was thinking of doing it:

Unfortunately, you really can't look ahead in the music(if you can, slap me) to construct the tunnel ahead of time. So, you'd just make the farthest ring in the tube be the latest music data.

Ok, lemme back up a tad. The entire track will be a closed torus, basically a cylinder with 360 rings connected end-to-end. Let's also say 30 subdivisions around each ring. The whole thing is aligned with the YZ plane.

Ok, so we've got 360 rings, the centers of which are along the circle r = oh, let's say ten. (Using informal math here :D ) Now, you've got 30 points around this ring, finding the original coordinates of which might be a tad of a problem. (I sucked at trig in HS.) I'm gonna work through this now, so pardon the sloppy ascii diagrams.

Ok, let's say we've got our circle at 0 degrees (centered at (0,0,10)). All of the points on this circle lie on the XY plane. Given o1 = angle of the centerpoint, o2 = angle along the ring, and the individual rings having a radius of 1, each point at o1 = 0 would be at:

(cos(o2), 10+sin(o2), 0)


Now, we account for the change in position for other points:

(cos(o2), 10*cos(o1) + sin(o2), 10*sin(o1))


Getting closer now. But also remember each ring isn't flat on the XY plane. However, all of the points are going to lie along a radial line. I'm pretty sure this would work:

(cos(o2), 10*cos(o1) + sin(o2)*cos(o1), 10*sin(o1) + cos(o2)*sin(o1))


BRB while I test this out.

EDIT: Ok, works brilliantly. http://www.lggaming.com/user/xerol/torusdemo.zip

I just fudged o2 for now, in reality o1 would always be 'locked' to one of the rings, and o2 would be 30 different steps along each ring.

From here, you add code to put the camera in the torus, and to modify the torus walls to move with the music, then controls from there.

EDIT2: If anyone wants to get on AIM and talk about this, maybe something could happen with this soon. I'm on for the next 3 hours or so under XerolOplan. If you're an antique internet user like myself and still use ICQ, 125672905.

27th November 2004 04:35 UTC

im became a member, (but u know nobody cares)


27th November 2004 05:31 UTC

Well, instead of a torus, I think it might be better for you to render something like a cylinder instead of a torus. It would be much easier to work with then the torus, and it could probably also be less FPS consuming.


27th November 2004 21:12 UTC

Same thing, the torus is just a cylinder bent so the ends meet.

Anyway, my problem right now is getting it to render in a grid. I've tried to do the square wave-style shape but it didn't work out properly; the only way it CAN work right is if there's an odd number of slices, so I'm trying to get that to work right now.

I'm going to re-upload to the aboveposted link with what i've got now; you can change the camera position by changing the xcam, ycam, and zcam values in the init portion of the superscope; no camera rotation yet, but I'm going to get to it eventually. I'd like to get the tube running properly first.