Author Topic: Dooley and the Gameweavers  (Read 11144 times)

0 Members and 1 Guest are viewing this topic.

Offline dndfreak

  • 1942 Veteran
  • *****
  • Posts: 3766
  • The GM
    • View Profile
    • PathLosers
Re: Dooley and the Gameweavers
« Reply #75 on: May 08, 2009, 07:48:59 pm »
Computer: clarification for objective 026
Bump does not refer to the intersection of two bounding boxes, it refers to the event in which there are no pixels remaining between one bounding box and the next.  The hindering of movement does not stop all movement of the character either.  It simply means that the pixels of one bounding box can not intersect with the pixels of another bounding box and if one bounding box attempts to move into another, its coordinates will remain unchanged instead.

(I may be a programmer but I've done very little with flash so I'm not sure of the limitations of ActionScript.)

Offline Jaleho

  • Stargate Superstar
  • ****
  • Posts: 668
  • The Infamous El Guapo
    • View Profile
    • Inflatable Studios
Re: Dooley and the Gameweavers
« Reply #76 on: May 08, 2009, 08:39:48 pm »
Computer: clarification for objective 026
Bump does not refer to the intersection of two bounding boxes, it refers to the event in which there are no pixels remaining between one bounding box and the next.  The hindering of movement does not stop all movement of the character either.  It simply means that the pixels of one bounding box can not intersect with the pixels of another bounding box and if one bounding box attempts to move into another, its coordinates will remain unchanged instead.

(I may be a programmer but I've done very little with flash so I'm not sure of the limitations of ActionScript.)

The problem with collision is that explaining the mechanics behind a good working system confounds even the best programmers, and trying to get folks in a forum meta-game to describe it is just next to impossible.

I've got a funky little system I'm going to try programming tomorrow. As we define what type of gameplay we want in different modes or levels, folks can just modify the existing system to fit rather than try to explain one from scratch.

This image demonstrates, in a way, how the system will work:



Our room is just an image right now. I have a 3D model I built of it, but that means nothing. Any shot i take of it is just a picture, and switching between 1st and 3rd just swaps a picture. We'd have to implement more than that if we want it, so for now, we toss the image and just see a flat blue screen with a couple clouds for flavor.

Because of the four directional movements AND a jump, what the player is essentially doing right now is moving a floating platform, on which dooley rides. His legs may move later or not, and how the background looks may make it feel like he's moving away from the screen and he walks up, but the underlying system works like this. The point and click interface moves the platform just as if you had an analogue stick instead of arrow keys.

Jumping allows dooley to move ABOVE the platform. Moving the platform left and right drags dooley with it, no matter how high above the ground he currently is. This follows most video games, but in reality, you can't change the direction of a jump once it has started. By the way - moving the "platform" up and down also affect dooley's position. He has an "altitude" setting that defines how far above the PLATFORM he is, not above the bottom of the screen. Again, another unreal effect, but would make sense in a brawler where you could jump NORTH (away from the screen). For a platformer, you might just turn off the ability to read the up and down arrows except on something like a ladder or a doorway, and they'd work differently.

While it may look like the enemies are lined up in front of dooley, they have no depth. sure, one is in front of the other, but they're all wafer thin (as is dooley) so currently nobody can walk AROUND another character. Not good for a brawler, but great for a platformer. So in effect, the enemies are just ONE big wall of bricks for dooley to run into. He can tell which CLUSTER of "bricks" he is hitting, so the right speech balloon will go off, but he can't move between two sets (or two characters)

The characters may have tiny bodies and big heads, but when it comes to collision, they're all just boxes with pictures inside. For now, collision is rectangular bounding boxes.

There's also the issue of scaling. if dooley is flat against a wall and he opts to GROW, he might just become embedded IN the wall. Or enemy character, in this instance. And if he's too far in, he won't be able to get out without shrinking.

With this system, you should be able to jump on moriarty's head and walk across. If you walk or jump OFF you won't fall (since the "platform" moves up to the new height). You should also be able to get below his feet and jump up, hitting your head against his shoes and falling back to the platform.

SO.... if all goes planned, we'll have a system that half-works for any type of game we make, and you guys will have to modify it to fit specific instances.

Cross your fingers!

Offline Jaleho

  • Stargate Superstar
  • ****
  • Posts: 668
  • The Infamous El Guapo
    • View Profile
    • Inflatable Studios
Re: Dooley and the Gameweavers
« Reply #77 on: May 08, 2009, 08:58:09 pm »
Computer: clarification for objective 026
Bump does not refer to the intersection of two bounding boxes, it refers to the event in which there are no pixels remaining between one bounding box and the next.  The hindering of movement does not stop all movement of the character either.  It simply means that the pixels of one bounding box can not intersect with the pixels of another bounding box and if one bounding box attempts to move into another, its coordinates will remain unchanged instead.

(I may be a programmer but I've done very little with flash so I'm not sure of the limitations of ActionScript.)

The problem with "bump" is this: If dooley can move 10 pixels every frame (a little faster than he really does, but go with it) and he is five pixels to the left of a wall, and he moves right, on the next frame he would be embedded five pixels INTO the wall. To check for collision he either has to
1) see what his next move will do and prevent it (hmm, I'll end up in the wall, so no - you can't move right any more, you're still 10 pixels away)
2) allow the move to happen and THEN prevent more (ok, now I'm in a wall. I'm not allowed to move any further into the wall, but... OOPS! I  may or may not be able to move out of it either. and I look stupid while deciding, stuck in here)
3) calculate how close you CAN get to the obstacle while moving in the requested direction (Well, I can't move my top speed in that direction, so maybe I can move... 9 pixels? no... 8? 7? 6? 5? YES! 5 is safe, so move that far)

That third one would kill the machine with multiple obstacles of various sizes. A tile-based game or one with an advanced math could do it, but is that what we want me spending time on this early into the project?

Oddly enough, I *DO* use a version of this for the point-and-click, since I'm only checking two points - the registration of the character and the point you clicked. If the character is within a circle (simple squares math) the size of the walk area, then the program just "nudges" the character in to place and stops him walking. I did this because dooley was overshooting his mark -- if the point you clicked was 93 pixels away to the northeast, and he moved 10 pixels a frame, he might end up 3 frames to the southwest of the click point on one frame, then 7 frames to the NE on the next frame, totally stepping OVER his goal. Then he just kept walking northeast forever.

I'm using a second invisible bounding box (not the one Kenobro had me put in, but something similar) to "test the waters" before moving. If the box returns a collision, the character won't bother moving there. Also checks for hitting your head or landing on an obstacle that is "above" the floating "platform" when jumping.

I'm also trying to program it so that later the enemies can move as well in different ways, where the player can use one or both of the input schemes at the same time, where the player can change the direction keys (remap to WASD or ANYTHING) and it should still function.

Scale is a monkey wrench in this - I think I'll just have it check if growing will get it stuck and if so, prevent it.

I know I'm going way OOC here, but we've strayed into messy territory here. I'm not sure how long the metagame will hold up if it keeps getting this technical. We'll see.

Offline dndfreak

  • 1942 Veteran
  • *****
  • Posts: 3766
  • The GM
    • View Profile
    • PathLosers
Re: Dooley and the Gameweavers
« Reply #78 on: May 12, 2009, 04:38:56 pm »
I know I've been afk for a bit, but appendicitis is appendicitis.

So first of all I'm curious how you manage speed.  I see you're using pixels over frames, but why don't you use pixels over time?  Lets say you have a framerate of 32 fps and a movement of ten px/frame. that makes 320 px a second.  If you coded that as 10 Px per frame, it will have issues with every ten and collision.  If you set movement rate to 1 px every 320th of a second, there's no possible way that it could be stuck in something as you can't have a length less than a single pixel.

Again, I'm not sure if AS3 or AS2 or whatever you do the coding in will let you do it that way, but it saves a lot of hassle.

I did kill the fanbase with my technical talk, didn't I?

Offline Summoner

  • BurgerTime Chef
  • *****
  • Posts: 1246
  • I wont stab you... or will i?
    • View Profile
    • Summoners Deviant Art Page
Re: Dooley and the Gameweavers
« Reply #79 on: May 12, 2009, 05:45:40 pm »
Computer change character001 name to Johnny
-----------
Computer expand the visual area and move the characters so they don't collide together
-----------
Computer make the door go to a 1950's style living room
In the living room make it 4 walls,one windowed,brown wooden wall and a hardwooded floor.
In living room add the objects: a Radio,a couch,a rocking chair,a fireplace.
In the living room put a female character named Mom
-----------

Offline Jaleho

  • Stargate Superstar
  • ****
  • Posts: 668
  • The Infamous El Guapo
    • View Profile
    • Inflatable Studios
Re: Dooley and the Gameweavers
« Reply #80 on: May 12, 2009, 07:10:46 pm »
I did kill the fanbase with my technical talk, didn't I?

Well, I think it was bound to go that way.

I think the problem here is that I'm trying to code a game when I don't even know what type of game it is yet. Nailing that down FIRST would make it a lot easier.

It may be time to restart this game and set up some structure first, then folks can focus on adding all their crazy ideas and only I have to worry about all the coding nitty gritty, simply making it fit one group chosen style. Obviously I'll keep all the stuff I've done up to this point, so if we want to add it back in it'll be easy.

Offline Detoxicated

  • Pack M.U.L.E.
  • *****
  • Posts: 2296
  • Spirit of Monkey
    • View Profile
Re: Dooley and the Gameweavers
« Reply #81 on: May 13, 2009, 12:43:34 am »
I did kill the fanbase with my technical talk, didn't I?

Well, I think it was bound to go that way.

I think the problem here is that I'm trying to code a game when I don't even know what type of game it is yet. Nailing that down FIRST would make it a lot easier.

It may be time to restart this game and set up some structure first, then folks can focus on adding all their crazy ideas and only I have to worry about all the coding nitty gritty, simply making it fit one group chosen style. Obviously I'll keep all the stuff I've done up to this point, so if we want to add it back in it'll be easy.
i want a super crazy super mario like platformer with adventure elements
OK, both of you die and let us know what happens.

Offline Hydromancerx

  • Master of Orion
  • *****
  • Posts: 12388
  • Klaatu Barada Nikto!
    • View Profile
    • Sagan 4
Re: Dooley and the Gameweavers
« Reply #82 on: May 13, 2009, 12:52:35 am »
Computer Expand Screen from 556px 404px to 800px 600px.