Remake of 'Greenie'

letmethink

  • *
  • Posts: 2547
So... I decided that I was going to remake one of my original games: Greenie. One of the main problems with Greenie on my end was that everything was made manually as I didn't know how to generate terrain. This greatly limited my game design and meant that I couldn't fully explore the game design. However, I recently overcame this by generating the tiles by calculating collision shapes to create.

Therefore, I also was able to implement two different types of blocks that can be phased through - one that starts on and one that starts off.

Here is a demo of what I have so far - of course all of the graphics will be reworked from the original as well as the game resolution (probably).

<a href="http://static.stencyl.com/games/28871-0.swf" target="_blank" class="new_win">http://static.stencyl.com/games/28871-0.swf</a>

z to phase, arrows to move
~Letmethink

ceosol

  • *
  • Posts: 2222
This could allow for some intense puzzle or platformer levels. I like it.

merrak

  • *
  • Posts: 2241
Did you use terrain, or did you merge the collision boxes of the tiles at runtime? If it's the latter, I'd be interested in hearing how you did it.

letmethink

  • *
  • Posts: 2547
Did you use terrain, or did you merge the collision boxes of the tiles at runtime? If it's the latter, I'd be interested in hearing how you did it.

I created terrain on runtime from a bunch of placed actors. The method I used could be used in a level creator.

If you want later I'll post a full entry logging my logic for this creation.
~Letmethink

merrak

  • *
  • Posts: 2241
Did you use terrain, or did you merge the collision boxes of the tiles at runtime? If it's the latter, I'd be interested in hearing how you did it.

I created terrain on runtime from a bunch of placed actors. The method I used could be used in a level creator.

If you want later I'll post a full entry logging my logic for this creation.

After I wrote my last post, I did a little more research and found the "createBoxTerrainRegion" function. I had a hunch you used terrain. I'd still be interested in reading your logic for the non-rectangular shapes in your level, but I think I have my own problem solved (for now). My levels are very long and rectangular, and a simple box-shaped terrains seem to do the trick. I don't need the player character to be able to move around inside the terrain. I just needed to reduce the number of individual collision boxes, so that larger levels didn't grind to a halt.

letmethink

  • *
  • Posts: 2547
I originally had this problem maybe around a week ago. I was bored of spending ages making each level as the process I used for the original was very tedious – it involved drawing the terrain using tiles, taking a screen-shot of the arrangement of tiles. Cropping the screen-shot. Importing the screen-shot as an animation. Placing the 'phase' actor in the scene and arranging it blind – it was on its default animation – changing its properties so it knew which animation it had and then finally placing invisible sensor actors and resizing them to fit the box shape – one for each line.

Clearly I had a problem. To begin to solve this I had quite a deep though. I wanted to created lots of lines that simulated a physical shape but had no middle. Therefore I was curious – what defines a vertex for a collision shape. Of course I could just join up lines, but that method seemed to complicated to me as I wasn't able to manipulate pre-existing collisions shapes easily. After a few hours of thinking I realised that if I had an array of points of each vertex of a tile (or an actor, it doesn't matter), the points would overlap and only the points which aren't shared, or are shared by three actors should be vertexes – I had to think about this, but two diagonally opposite tiles doesn't need a vertex as I am not making something solid, just lines and those crossovers would be joined by points anyway.

Anyway, I set about implementing this into Stencyl and it worked particularly well. I had an array of points all where a vertex should be. However, at this point I had no way of linking the points together as all they were were points, they had no idea where the lines would connect from or to. Therefore, along with adding the position of the points to a list to check for duplicates, I also added the directions of the lines going from that point – for example for a top left point, 'r' and 'd' would be added to another list. Once I had these, I knew the direction the points should go in. This worked well for vertices with only one point from a shape. However, for the one with three points they thought they were drawing in every direction. However, these entries were longer so I was able to distinguish these from the others with a length check. With these I then draw in the directions that there was only one of. Thinking about it logically, for an inverse corner, it will be added to the list by everything except the part it is going around. Therefore, the directions it is going in will only appear once, with the others appearing twice. This allowed me to now have an array of points with directions the lines from them are going in.

Next knowing this, I began to draw the lines. My logic for this was that I would draw the lines from the points going right and down. The lines would be drawn to the closest point along that axis checked using a simple distance check. I didn't do it for left and up as well because if I did I would be left with 2 of every line.

Finally, with the list of lines, I used the 'createBoxTerrainRegion' function to create the lines – each had either a width or height of 0 ad my program is only for square tiles.
~Letmethink

letmethink

  • *
  • Posts: 2547
Yesterday, I drew a couple of characters sprites, and I greatly optomised this generation and also made it less work on my end. However, I did see the need for a 'for every tile on layer:' block to stop me having to loop 300 times.

The first thing I did, was spend about 4 minutes deleting blocks. I had accidentally made a copy of the main behaviour and it was in the same event. This meant about 800 blocks there. I first split the main event up into custom blocks and then I had to painstakingly delete it one block at a time. Note: I had to do this twice as I had it in the keypress event and in the created event. Once I had these custom blocks, with relatively little effort I was able to make the program way more efficient - I hadn't done this before as working with the behaviour had been too slow and I didn't have the patience. Before, each time the 'z' key, was pressed the program didn't only just create the collisions shapes, but it also calculated them, causing a slight slowdown on my very low end laptop. I believe that combined with what else I would add, this would have a dramatic effect on most computers. Now, what I did was store the points of both actors in one list that are both calculated in a when created event. When the 'z' key is pressed, all the program is draw the collisions for a certain list.

Next, as my program currently used actors for generating this, yet I was placing tiles in the layers anyway, I decided to change the calculation step of my program to involve tiles on a specific layer rather that specific actor types. This worked well, however it takes significantly longer to repeat for every tile and check if a tile exists there than it did for the 'for each actor of type:' block. In this situation I feel that a 'for each tile on layer:' block would have been very useful.

Currently, I am reasonably happy with my program. However, I know that it can be improved as the actual generation of terrain still has some useless loops - I did manage to take out one though.
~Letmethink

letmethink

  • *
  • Posts: 2547
<a href="http://cdn.fastswf.com/files/XB_PgK8/XB_PgK8.swf?AWSAccessKeyId=AKIAIWTOYM4XXIVL5IGQ&amp;Expires=1417344346&amp;Signature=qG2YbYn7l0pqonHfk%2BLO6PewyPM%3D" target="_blank" class="new_win">http://cdn.fastswf.com/files/XB_PgK8/XB_PgK8.swf?AWSAccessKeyId=AKIAIWTOYM4XXIVL5IGQ&amp;Expires=1417344346&amp;Signature=qG2YbYn7l0pqonHfk%2BLO6PewyPM%3D</a>

Here is the latest build. What it adds in addition to following build is as follows:

  • Implements the player animations, including a turning animation to make things smoother
  • Changes the generation of boxes slightly so that they are 2px shorter than previous. This allows the player to move freely without getting stuck on the edge of collisions. It seems to work well so far
  • Several back end changes such as organisation and commenting on my code.

« Last Edit: November 30, 2014, 02:23:33 am by letmethink »
~Letmethink

letmethink

  • *
  • Posts: 2547
Sorry for all of these quick posts - I'm having a productive day. I began to add more graphics, and I'm beginning to like the style. It is similar to the original 'greenie', but in my opinion a lot better.

<a href="http://cdn.fastswf.com/files/FvkmiYI/FvkmiYI.swf?AWSAccessKeyId=AKIAIWTOYM4XXIVL5IGQ&amp;Expires=1417355519&amp;Signature=9WV%2BTtLwCSDk8QOWaAIHv5Zz9Ok%3D" target="_blank" class="new_win">http://cdn.fastswf.com/files/FvkmiYI/FvkmiYI.swf?AWSAccessKeyId=AKIAIWTOYM4XXIVL5IGQ&amp;Expires=1417355519&amp;Signature=9WV%2BTtLwCSDk8QOWaAIHv5Zz9Ok%3D</a>
~Letmethink

ceosol

  • *
  • Posts: 2222
All I get is a white screen on the new ones

letmethink

  • *
  • Posts: 2547
Oh okay, the key I included in the link is probably locked to my ip. I'll try to host them elsewhere.

<a href="http://lmtproductions.weebly.com/uploads/2/0/7/9/20793336/greenie_2.swf" target="_blank" class="new_win">http://lmtproductions.weebly.com/uploads/2/0/7/9/20793336/greenie_2.swf</a>

I don't have the original one, but I have a newer one which is hosted elsewhere above. If you can't see it, give me a shout.
~Letmethink

ceosol

  • *
  • Posts: 2222
That works. I don't know how you feel about it, but I think it might be better with set jumping speed. Since you have to be constantly switching phases while in the air, it might lead to lots of overjumps or underjumps. But then again, having speed controlled by the player lets you develop skill jumps.

Its a toss up.

letmethink

  • *
  • Posts: 2547
That works. I don't know how you feel about it, but I think it might be better with set jumping speed. Since you have to be constantly switching phases while in the air, it might lead to lots of overjumps or underjumps. But then again, having speed controlled by the player lets you develop skill jumps.

Its a toss up.

I understand what you mean but personally I hate playing games with set jumping speed. That is basically I am allowing mine to be controlled. The levels will probably have less platforming difficulty than the example one I placed together there as I want to focus quite a bit about thinking and not making things obvious. Then again, it will probably turn into being skill based.
~Letmethink

merrak

  • *
  • Posts: 2241
.... Therefore I was curious – what defines a vertex for a collision shape. Of course I could just join up lines, but that method seemed to complicated to me as I wasn't able to manipulate pre-existing collisions shapes easily. After a few hours of thinking I realised that if I had an array of points of each vertex of a tile (or an actor, it doesn't matter), the points would overlap and only the points which aren't shared, or are shared by three actors should be vertexes – I had to think about this, but two diagonally opposite tiles doesn't need a vertex as I am not making something solid, just lines and those crossovers would be joined by points anyway....

That's a clever solution. It sounds like you could use the same strategy for the lines, too. Since the actors are square, remove the edges that both share. If you don't have to draw the edges in (counter)clockwise order--just get them down in any order-- you may not have to worry about the vertices at all.

letmethink

  • *
  • Posts: 2547
That's a clever solution. It sounds like you could use the same strategy for the lines, too. Since the actors are square, remove the edges that both share. If you don't have to draw the edges in (counter)clockwise order--just get them down in any order-- you may not have to worry about the vertices at all.

I understand where you are going there, I just feel like it would be more difficult to achieve as I don't have a 2d array of the actors, I scan them one at a time. Therefore I would have to create the lines using the vertices and I would also have to calculate how to connect up lines that are in a straight line. I did consider this, and my dad did actually suggest it, but I'm happy with my method as it is :)
~Letmethink