Retro games

[Connors]

I guess we have to be sure the gameplay fits in the Kongregate scale. I don't think they force you to make THAT small but just be sure.
And I figured out control panels. Have the player click on it while nearby to toggle things, instead of shooting it activates. But only if you're right nearby and you click right on the panel so it shouldn't get in the way of shooting though it might slow you down a bit.

[Zoo]

Dynamic scaling thing doesn't work on firefox. I'mma try chrome. Ok, it works. But it's REALLY laggy on crome.

[Gan]

Oh, umm. The main menu only dynamically scales. The actual game doesn't scale. Instead it scrolls.

And yeah, I'm working on making the scrolling smoother.

[Connors]

Obviously you don't want to draw anything outside the screen. In fact, instead of going through and checking whether a tile's on-screen before drawing each time just start the FOR-loop where the edge of the screen is and that way do fewer checks. Just an idea. Fewer operations in total, kind of like how the zombies only need to make one pathfinding grid for all of them and then separately find paths to you.

[Gan]

Good ideas...

[Circuit]

How does the pathfinding work?  Does each zombie calculate the full path to the player every 1/30th of a second?  If so, I think I know of a way to make it more efficient...

[Gan]

Nah, it only recalculates the path when the zombie or target moves. Or if the level changes shape. Like a door open.

[Circuit]

That's good.  And I think I know how to make it even more efficient.  You could divide levels into areas, and create an array to store the shortest overall paths between all areas.  When a zombie was aware of the player's general location, he could look up the shortest overall path in the array (which represents the zombies' combined knowledge of the level's layout).  Then, with that general path in mind, he could use your pathfinding code to find and follow a series of short specific paths from one waypoint to the next, rather than finding and following one long path to the player's body.  The player's movement would only affect the zombie's overall path in instances when the player moved from one area to another, in which case, the zombie would instantly change his overall path to the path in the array.  The zombie would follow the overall path until he was in the same area as the player, or until he was within 1 area away, or until he could see the player.  Then he would target the player's body.

The array data would look something like this: path[3][5] = [3,4,5].  Where subscript 3 is the zombie's area, subscript 5 is the player's area, and 3, 4 and 5 is the overall path from area 3 to area 5.  Alternatively, each element could be a pair of coordinates representing a waypoint.  Also, every tile on the map would have an area associated with it, so that the player's area could be determined no matter where he was.

[Gan]

Ah man, I'm trying to comprehend this.

So we take like a map and chop it into 3x3 pieces, then... alright I'm lost. Failing to comprehend.

I do feel I can optimize if be gettig rid of unnecessary loopage when calculating movement routes.

[Zoo]

If it gets rid of some lag it's a good idea. 

[x]

What Circuit is suggesting is what (used) to be used in a lot of production level games. It would work brilliantly here. In essence it is just adding "waypoints" to your map, to get to a certain place the AI pathfind to the nearest waypoint, instead of having to calculate their way to the player. To help find the nearest--or most appropriate--waypoint, you split your game world up into areas. Then, based on what area your path finding entity is in, and its target, you can get the first appropriate waypoint. For example

{   1   A}{B   2   }
{   3   Y}{X  4   }

This is an extremely contrived example. However, imagine you have an array: map[2][2]. Say you are a monster in 1, wanting to go to two since the player is in two. You look up map[1][2] and find that you need to to waypoint A, then to waypoint B. After, you are closer to the player, and you find a path from there.


Also, what are you doing for collisions? Remember, you can always x or y sort a bunch of entity objects, then do collisions for them faster by stopping when you reach an x or y value that is impossible to collide with--since you know all further values will be too high. Also by not bothering to check values that are too low.

eg.
Say you have an array of entity locations to check collides with
locations = {1,2 | 4,5 | 12,12 | 67,56 | 34,56..etc}

rough pseudocode
sort locations on X axis //merge sort is usually best since it takes into account temporal localtity
myLocation = 10,10 //or whatever you are checking for collisions with
foreach locations as i
 if myLocation-width> i+width
     skip collision check, go to next in loop
 elseif mylocation+width< i-width
     skip collision, go to next in loop
 else
     do expensive collision check
endforeach

Obviously this lets you cut out as many collision checks as you can. This is a big boost, since collision checks, especially pixel perfect ones, are slow. Even bounding box collisions checks can be sped up by this simple approach.

 Better yet, you could use an quadtree. I've used both approach in games, since I have always found collisions to be my bottle neck.
(http://en.wikipedia.org/wiki/Quadtree)

Finally, don't bother drawing stuff that isn't on screen. Some checks like the following in the draw methods.
if (myXLocation+width < screenLeftX)
    skip drawing..
elseif (myXLocation-width > screenRightX)
    skip drawing..
//then the same for y values

[WarHampster]

Are you currently using the pathfinding from Hacksilver? I actually think that a tree approach would be easiest and make the most sense here. Find the relevant nodes, flood fill, pathfind.

With a quadtree, you break the map down into four rectangles, each of which is broken down into four rectangles, recursing until a certain size limit is reached. This is useful for pathfinding, collisions, etc (I use it in my voxel renderer to optimize raycasting) because it limits the area relevant to a given path, collision, whatever.

Example:

[Connors]

These ideas would be great for optimization but I agree with Kurt... They don't need to be top priority yet and would require a lot and I mean a lot of changes.
(said the one who has done basically NONE of the coding himself )
You know maybe I really ought to either help more with this or work on my own game for a while. I've just been commenting, I don't know how much I'm going to do with it personally unless we start making levels and working on gameplay.
EDIT: Gan, isn't this oddly similar to all the work you did looking at a binary search, and trees, and indexing and all the ways you can search for a name?

[Gan]

Ah man, this is going over my head.

[GMG Kurt]

yeah I think the only thing we should have in mind is polymorphism, or adaptability. so that we can change everything in one place instead of searching all over the code. Such as using macros over integer constants, especially the ones used more than once. and most things through functions. I may go through myself and try to do that.