A really small walkcycle (and a demogame)

[WHAM]

A very small down walkcycle for a top-down 15x15 tile based game I'm starting work on.

With helmet (2x original size)


Wothout helmet (2x original size)


Tear me a new one, people!

[Moresco]

I like it...it's VERY top down.  Can't see much, it's like a black spot....maybe go a little more Gauntlet with it, and get a slightly angled top-down view for a bit more details?  Or not! It's cool.

[Dualnames]

Personally I find the design to be okay, but the colors blend a bit TOO much. Try making that blue a bit lighter.

[zabnat]

With helmet it rally looks like just a black blob, I can't really figure out which way he is really facing. Try to put in some details that will help pointing out the orientation of the character.

[WHAM]

I was afraid the helmet would be a bit unclear on direction. I lightened the colours a little bit to bring out the blues, and added a lighter patch to the frontal section of the helmet to make it a bit easier to see where he is facing. I'm aiming to make a tile-based game where the tiles are just 15x15px, so making the characters and environments more angled would, in my opinion, just make a few outlines thicker. I don't want to goo too angled, because then it would just look silly.



Improvement?

As soon as this basic walkcycle is approved, I'll do variations with different weaponry, as well as some shooting etc animations.

[WHAM]

I take it that nobody has anything to add so far. I'll probably upload a "playable" proof of concept in this thread this evening, where you can see the walkcycles in action. I'll also see if I can find the time to make new walkcycles with the character holding weapons, as well as animating him firing said weapons in at least four, maybe all eight directions.

Does anybody know if AGS has a way to rotate a sprite in-game? ie. an exact way to make a sprite rotate to face a certain X-Y coordinate?

[WHAM]

Here's a link to a proof-of-concept test game I made for the character.

www.whamgames.com/downloads/success/POC.rar

Controls are:
arrow keys to move character around
space bar to interact with objects (not much to do)
F to bring up a targeting cursor (for picking targets to shoot at in the final game), or to turn the targeting cursor off.

The game uses a very simple system to keep player from walking through walls. The walls are painted with a hotspot that is named "BLOCK". Whenever the player (or an NPC in the final game) attempts to move to a direction, the game checks if the move woulc cause the player to collide with this BLOCK hotspot. If so, the move is not executed.

The only thing I am not too happy about is the mouse cursor flickering when you keep an arrow key pressed to walk a longer distance, but I doubt there is much I can do about it at the moment.

[Dualnames]

I have to say this is quite nice and impressive. But I'd prefer if the targeting with the F made the cursor change instead.

[WHAM]

I have to say this is quite nice and impressive. But I'd prefer if the targeting with the F made the cursor change instead.

You might want to change your weapon, access inventory etc while in the targeting mode. You need the mouse cursor for this. I also wanted to bind the targetting cursor to the same tiles as character movement, as the shooting script uses an object that is moved from the center of one square to another to calculate line of sight.

[Shane 'ProgZmax' Stevens]

I agree with dual.  The current method of toggling between walk and fire is extremely unintuitive while just toggling the mouse cursor mode would work much better.  There's no reason why a left click can't be fire and a right click pickup/interact for the mouse, and as for clicking on the gui that would have entirely different behavior anyway...You could even use the middle mouse button for inventory if it's important to have a unique button assignment for it.

[WHAM]

But my main idea was to create a game that can and should be player 100% with the keyboard! Mouse interactions are just a bonus for some of the menu's. There is also the fact that if I use the mouse to target enemies, then I need to create a separate script to allocate the target coordinates of the mouse click to the center of the tile the player clicked...

Drat! I thought this was a good idea but now it seems that everyone else disagrees. I'll have to look at ways to bring more mouse interactions into the game...

Or I could just be a dick and remove the mouse cursor altogether, making the game pure keyboard one.

[Jim Reed]

Code: ags

function get_tile_number(int x_position, int y_position) //mouse coordinates
{
  int tile_num=(x_position/TILE_PIXEL_WIDTH)+((y_position/TILE_PIXEL_HEIGHT)*ROWSIZE);
  return tile_num;
}

If you hold your tiles in a simple one dimesional array, this function will return you the array index of the tile you clicked on.

For example, if you had a 8x8 tile playfield, and you stored them in an array of 64 elements, this should work. You may have to add the viewport coordinates to the mouse ones if your map has scrolling though.

[WHAM]

That's the catch: there is no array to keep track of. I hope this clarifies a bit as to what I'm actually doing under the bonnet, so to speak.

Code: ags

// *********************************
// CHARACTER MOVING FUNCTION 
// *********************************

function MoveChar(int CharID, int direction) {
  // This function moves the selected character (either player or an NPC) by a single square
  // CharID identifies the character being moved: 0 = player, others = NPC
  // The movement is blocking ONLY if it involves the player, otherwise the movements are run in five cycles or as needed
  // Dircerions: 0 = up, 1 = right, 2 = down, 3 = left
  
  if (character[CharID].Moving == false) { // Make sure the character is not already moving
    bool moveblocked = false;
    if (direction == 0) { // UP
      if (Game.GetLocationName(character[CharID].x-GetViewportX(), character[CharID].y-GetViewportY()-23) == "BLOCK") {
        character[CharID].FaceLocation(character[CharID].x, character[CharID].y - 10); // MOVEMENT UP IS BLOCKED
        moveblocked = true;
      } else {
        character[CharID].Animate(3, 1, eRepeat, eNoBlock); // MOVEMENT UP IS NOT BLOCKED
      }
    } else if (direction == 1) { // RIGHT
      //DEBUG mouse.SetPosition(character[CharID].x-GetViewportX() + 15, character[CharID].y-GetViewportY()-7);
      //DEBUG Display(" a %s", Game.GetLocationName(character[CharID].y-GetViewportY()-7, character[CharID].x-GetViewportX() + 15));
      if (Game.GetLocationName(character[CharID].x-GetViewportX() + 15, character[CharID].y-GetViewportY()-7) == "BLOCK") {
        character[CharID].FaceLocation(character[CharID].x+10, character[CharID].y); // MOVEMENT UP IS BLOCKED
        moveblocked = true;
      } else {
        character[CharID].Animate(2, 1, eRepeat, eNoBlock);
      }
    } else if (direction == 2) { // DOWN
      if (Game.GetLocationName(character[CharID].x-GetViewportX(), character[CharID].y-GetViewportY()+8) == "BLOCK") {
        character[CharID].FaceLocation(character[CharID].x, character[CharID].y + 10); // MOVEMENT UP IS BLOCKED
        moveblocked = true;
      } else {
        character[CharID].Animate(0, 1, eRepeat, eNoBlock);
      }
    } else if (direction == 3) { // LEFT
      if (Game.GetLocationName(character[CharID].x-GetViewportX() - 15, character[CharID].y-GetViewportY()-7) == "BLOCK") {
        character[CharID].FaceLocation(character[CharID].x-10, character[CharID].y); // MOVEMENT UP IS BLOCKED
        moveblocked = true;
      } else {
        character[CharID].Animate(1, 1, eRepeat, eNoBlock);
      }
    }

    if (moveblocked == false) {
      int tupu = 15;
      while (tupu > 0) {
        if (direction == 0) { // UP
          character[CharID].y--;
        } else if (direction == 1) { // RIGHT
          character[CharID].x++;
        } else if (direction == 2) { // DOWN
          character[CharID].y++;
        } else if (direction == 3) { // LEFT
          character[CharID].x--;
        }
        Wait(1);
        tupu--;
      }
      character[CharID].UnlockView();
      if (CharID == 0 && moveblocked == false) {
        playeractions++;
      }
    }
  }
}

// *********************************

[Jim Reed]

Ah, I see.

Btw, the game really makes think of Hard Nova for some reson. Must be the perspective.

[zabnat]

The first things that came in my mind when I tested this was:
1. Why don't I have free movement?
2. Why can't I target with the mouse?

In my opinion only acceptable control schemes are either keyboard for simple (viewport relative) movement and mouse for targeting (like in Alien Swarm) or then making the crosshair be always in front of the character and let the character turn freely 360 degrees and movement would be character relative. I believe both of these should be relatively easy to implement in AGS.

[WHAM]

1. The movement is restricted because the game will be turn-based. In a single turn you have limited actions and moving one square is one action, firing a weapon is one action and so on.

2. I am looking into making this game 100% playable using the keyboard OR a gamepad of some sort. Basically I am aiming for a retroish Super Nintendo (SNES) style. Instead of going for an alien swarm style I am aiming more for a style that combines elements from the old Alien Breed games and combines that with turn-based RPG elements (experience points, levelling up skills etc).

All in all, I might even be leaving out the mouse support altogether, as having the mouse cursor around seems to be leading players to expect more mouse-related interactions than I am actually planning to do.

[Shane 'ProgZmax' Stevens]

Yes, if you want it keyboard driven then definitely make it ENTIRELY keyboard driven.  You could add mouse support as well, but if the focus is using the keyboard then you want to design all the interfaces and control around making that as intuitive as possible.

[zabnat]

If the game is turn based, I can see some problems with the current movement. For example pressing arrow key one times too many and thus losing movement points. Why not show the possible squares where player can move and then choosing a square where the player moves? Or is this movement style chosen to create an illusion of free movement?

[WHAM]

The game works as turn-based only during combat. If there are no enemies around, the game works as follows: player can move freely just as youy can move now. AI characters make a single move every "tick", which is run as a non-blocking action every 5 or 6 seconds. During these ticks the NPC's check line of sight and certain stats to see if they have spotted the player. If they spot the player or the player activates the aiming cursor, the game moves into a pure turn-based mode and stays there until the player attempts to "end combat", at which point the game ensures that there are no active hostiles with line of sight to the player.