Videogame theory - sources, player interactions etc.

[mika]

Ok, long shot maybe, but hopefully someone will be able to point me in the right direction.

 

I am looking for - ideally - comprehensive (but some basics will do, too) sources on 'player' or 'sprite' interaction, and ways of implementing in videogames. I will try to briefly explain below, as I myself doubt if I was clear.

 

Trying to design a game I am looking at the gameplay on Atari 2600. Leaving missiles, ball and playfield for a moment, we end up with what basically is 'player0' and 'player1'. Now trying to design challenging gameplay one must notice that there are two basic states of relation between them:

 

1: collision

2: non-collision.

 

Now trying to break this down further

 

1: collision

a - collision from the top

b - collision from the side (now if you think this split is unnecessary, just picture Mario and Goomba in SMB - if Mario collides with goomba from the top - he kills it; if he collides from the side - he is killed instead!)

c - full collision (i don't know how else to describe it, 'overlapping' of sprites, possible Keystone Kapers and using lift, however its' probably not done via sprites - you need to be "within" other object to trigger it, not simply touch it)

d - partial collision (hmm, Pitfall! maybe and Harry jumping on alligator with an open jaw - if he lands on the head it's fine, but he dies when he lands on his mouth)

 

 

2: non-collision at first it looks simple, no collision means no collision, but I can think of:

a - proximity - so technically there is no collision between players, but for example a preset offset of pixels can trigger certain action. I'm not exactly sure, but doesn't Pacman have something like that? When ghost is 'close' enough he 'feels' the presence of pacman and starts chasing him (I don't know if it actually works like that, but let's say it's possible non-collision situation

b - 'sighting' - hope you get an idea, not sure what example can I use (wasn't it used in Halo 2600?) - players0 and 1 have no collision present, but one is exposed to others line of sight, is spotted in other words, which determines further action by spotter

 

 

All the above obviously only make better sense in actual gameplay when results of interactions are rewarded. Rewards can be both positive or negative (or both?!) eg. 1a in Super Mario will give you 100 points, 1d in Pitfall can take your life etc.

 

So the very basic of player0 interacting with player1 is above, but I'm pretty sure someone has produced a detailed analysis of the mechanisms and techniques.

 

Which leads me to the question again: do you know of any reference source that contain detailed analysis of all the types of gameplay affecting interactions? Any books, online articles, essays? (Ideally online!)

 

Actually now after reading it, I just want to clarify that I am interested in all interactions, including missiles, ball - I only used players only for simplicity of the examples.

 

If anyone is able to help, I will really appreciate. I don't even know what to type in google for a start, and how to judge credibility of the sources.

 

[+5-11under]

There was a blog on Gamasutra that I used to read fairly often... .

[mika]

There was a blog on Gamasutra that I used to read fairly often... .

do you remember the name? link? is it still there?

[+5-11under]

Maybe not exactly what you're looking for, but anyway...

https://www.gamasutra.com/view/authors/2003/Ernest_Adams.php

[mika]

Thanks! I started reading and find it very helpful, but yes - not exactly what I'm looking for! I am adding to bookmarks anyway.

 

David Crane's interviews and presentations are/were an equivalent of these for the Atari era (his post memoriams for Activision titles especially), but I hope someone covered videogame theory deeper.

[ZackAttack]

(now if you think this split is unnecessary, just picture Mario and Goomba in SMB - if Mario collides with goomba from the top - he kills it; if he collides from the side - he is killed instead!)

 

SMB uses Mario's vertical velocity to decide who wins in a collision with a goomba. If Mario is traveling in a downward direction when he makes contact it will kill the goomba regardless of where the collision occurs. I point this out because it has the potential to greatly simplify things and it's fun to watch.

 

https://youtu.be/xOCurBYI_gY?t=650

[bjbest60]

This is a really interesting question. I think fundamentally you're right, most games (especially for the Atari) are predicated on whether or not things are colliding.

 

But I can think of a few examples where it isn't collision that drives some elements of game play, at least with sprites. One goal rather than dealing with enemy sprites would be to simply move a player or object to a certain location. All racing games eventually have this--you cross the finish line. Sports games, too. For Pong, your goal is to make the ball not collide with the other player, and you only score a point when it goes off the screen. A maze game is probably the purest example of this. If you get from point A to point B, you win, no other sprites required. But the pits in platformer games are lethal for precisely the same reason--you cross a certain location. And you can only win Adventure by dragging the amulet to a particular location--inside the yellow castle. (Of course, all of these games do have collision aspects, too.)

 

There are also ways a player might indirectly destroy a sprite without colliding. Some shmups offer a sort of magic bomb that can destroy all enemies on a screen, for example.

 

I'm sure there other examples I'm not thinking of. (Dark Mage comes to mind. It's a text adventure, which offers a completely different conception of graphics and their usage.) Other icon-based games (such as simulations) or puzzle games might conceive of sprites differently than standard player/enemy usage.

 

There are a lot of good books out there that cover all aspects of game design. One I'd recommend is Level Up!: The Guide to Great Video Game Design by Scott Rogers. It's skewed to more contemporary games, as you might expect, but he has a whole chapter on enemies. The various types that he lists are chasers, shooters, guards, flyers (i.e., they can fly), bombers (they don't directly touch the player, but the bombs can), burrowers (they can hide and reappear), teleporters, and blockers (resistant to player attacks, either temporarily or permanently). Beyond behavior, he says enemies are also defined by their size, speed, movement, and attacks.

 

I'm sure there's much more to say on this, but those are some thoughts for now.

[mika]

very interesting. That SMB example - my jaw dropped, thanks Zack for pointing to that video (interesting channel, subscribed!). No wonder it had so many views.

 

bjbest, great input. By reading it I realized that location is in a way collision with something predetermined in a way, isn't it? It may not actually involve player vs player collision, but eg. playfield or just coordinates. If we look at finish line it may be coordinate x, or a playfield block. Can even be player!

 

I will try to find some excerpts from the book you recommend.

 

I am looking at my favourite game, Pitfall - I realized that Crane is using all types of collisions with all types of different outcomes, and when talking about the location - if we exit screen from top it uses different reward than when we exit screen from underground! So he is potentially using coordinates x and y to determine where to jump in his polynomial (or whatever was it's name, writing from memory) counter. I say potentially, because I have no idea what he is actually using to determine scene change, but something like that would make sense - so if we go left out of the screen:

 

for x<0 and y>=(ground level) = scene-1 ; y<(groundlevel) = scene-3.

 

[every time we pass underground screen in Pitfall! it skips 3 scenes instead of 1, so you can actually get quicker to your target]

[Thomas Jentzsch]

So he is potentially using coordinates x and y to determine where to jump in his polynomial (or whatever was it's name, writing from memory) counter. I say potentially, because I have no idea what he is actually using to determine scene change, but something like that would make sense - so if we go left out of the screen:

 

for x<0 and y>=(ground level) = scene-1 ; y<(groundlevel) = scene-3.

 

[every time we pass underground screen in Pitfall! it skips 3 scenes instead of 1, so you can actually get quicker to your target]

That's correct.

 

If you can read assembler (or comments ), you may want to have a look at my Pitfall! disassembly.

[+SpiceWare]

You can find Thomas' disassembly, along with many other useful things, at MiniDig.