Grid based movement and random generated levels

0 favourites
  • 4 posts
From the Asset Store
Grid - snap to grid
$1 USD
80% off
Snap to visible grid - perfect solution for any game genre
  • So I just found C2 and have played around with it quite a bit. I'm a programmer by trade and <3 code, but this is certainly faster lol.

    Anyway, Im just wondering if anyone can provide me with a jump start on grid based movement (IE, push left arrow you move left one grid space) and random level generation (IE, a random grid for player to move around in with walls (that make sense) and openings etc to form room).

    I rather expected at least some form of easy grid movement but its not there that I can see.

    For the level generation I'm just looking for advice from someone thats done it, how did you generate it in C2? Random numbers for each spot on grid and spawn sprites based on that etc?

    Did a brief forum search, but didn't find anything directly useful.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • I don't recall where I found it (somewhere on the forums) but for snapping something to a grid I've been using

    On whatever event:

    Player.X = round(Player.X/16)*16

    Player.Y = round(Player.Y/16)*16

    This works for a grid where the spaces are 16x16, you would change it for different sizes.

    As for movement I'd just use keyboard bind WASD (or whatever you prefer) to set the player's sprite however many pixels over.

    W => Player.Y = Player.Y -16

    A => Player.X = Player.X -16

    S => Player.Y = Player.Y +16

    D => Player.X = Player.X +16

    Then just run the snap to grid event to make sure the player stays in it's space.

    I'm not totally familiar with dropbox so I hope this link works.

    Grid-Based Movement

    Sadly, I cannot help with random world generation as I don't really know how to either. There were a couple posts I found but they were rather vague.

  • GRID MOVEMENT

    I'm doing something similar, except I have a few different size grids that the player can drag and drop items from (inventory grid vs game grid). When the object passes from one grid to another, I have to adjust the various x,y coordinates.

    floor( (coordinate-offset) / scale ) * scale + round( ( scale / 2 ) ) + offset

    coordinate - is the X or Y coordinate to snap

    scale      - the size of a grid square

    offset     - if your grid doesn't start at (0,0) this would be set to the x or y value at the grids top left spot (you'd use the X offset of you're calculating the X value and the Y offset for Y)

    In my particular example, I want to drop items in the center of the grid square, hence adding scale/2.

    I plugged all of this into two functions.

    fnGetGridCoordinate( x, y ) - takes layout x,y values and returns grid compatible coordinates. This function figures out which grid the point lies on and calls the snap function with the appropriate scale and offset values. Returns grid snapped X and grid snapped Y values.

    fnSnapGridCoordinate( layoutCoord, scale, offset ) - takes a single coordinate, scale, and offset to calculate a compatible grid coordinate.

    These two combined can give me any arbitrary grid coordinate for any arbitrary scaled number of grids on my screen. The beauty part here, at least from an efficiency perspective, is that all of the redundant checks to see what kind of grid, what kind of scale, etc. are all done centrally, freeing up my object movement code and inventory management to not have to worry about it.

    EDIT: I didn't know if it was interesting to anyone else, but since my two different grids have two entirely different scales (the inventory is 30x30 while the game is 40x40), I resize the objects as you drag and drop between them.

    When moving from the game grid to the inventory:

    Width = round( sprite.Width * inventoryScale / gridScale )

    Height = round( sprite.Height * inventoryScale / gridScale )

    When moving from the inventory to the game grid:

    Width = round( sprite.Width * gridScale /inventoryScale )

    Height = round( sprite.Height * gridScale / inventoryScale )

    RANDOM GRID CREATION

    Since you are using a grid, I assume that you will be using some sort of tile approach to populate your world. I don't know if this helps, but when I thought about doing this myself, I thought of assigning a number to each type of tile you would place (ground, water, path, etc) and then randomly populate a 2d array with values.

    This would cover the basics and setting various thresholds of probability would give some structure to it. Your most common tiles that are non-blocking (grass, for example) could have a larger probability of being selected over blocking or other types of special items (like rocks or trees).

    If you wanted to have specific complex formations of tiles, like a connected series of road tiles that winds through your map, you could have a second pass go through your world array and overwrite those elements on top of whatever was randomly put there. Your road loop could choose to create a random number of roads at a random length and then randomly build them by walking one tile at a time and randomly choosing the location of the next tile (perhaps limiting it to the four tiles sitting in the cardinal directions).

    All of these loops could be enriched with various checks to make sure that the map feels playable (don't add rocks if it will block off a section of the map, stop adding water if you hit the max amount of water on the map). You could even include a further refinement that takes prefabricated complex structures (boss room, special castle) and drops them wholesale into your randomly generated world. This would let you blend in traditional level design elements with randomly generated ones.

    At this point, any map element that you can come up with is just a variation on these themes. I'm sure you could get some really dynamic game worlds with this approach. All it would take it some tweaking and tuning of the probability models.

  • OK nice, i go to test the movement.

    Thenk you

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)