czwartek, 30 lipca 2015

#Stencyl: Zerg terrain infection

Part 2: Checking if it's ok to place building and dealing with effects of placing new building

  • Algorithm for placing buildings
  • Adding new matrix
  • Checking if it's ok to place building
  • Effects of placing building

Behaviors used in part II

  • main scene behavior (scene behavior)
    • when created
    • trigger event <building_check>
    • when mouse pressed
  • building behavior (actor behavior attached to buildings actors)
    • trigger event <placed_on_map>
Main variables:
  • main scene behavior (scene behavior)
    • building_check - Boolean; true if it's ok to place building
    • building_list - Matrix; contains as records x,y, x+width, y+ height of buildings actors already placed on map
  • building behavior 
    • matrix_index - Number; index of <building_list> matrix
    • number_of_rows - Number; number of rows in <building_list> matrix

Algorithm for placing buildings
  • In <building_list> matrix we store as records coordinates of buildings already placed on map
  • We have already picked the building we want to place and we are trying to place it
  • We go through each record of <building_list> matrix comparing position of picked building with data from record to see if picked building is trying to place itself on place occupied by another building already on map.
  • If there is free place we place building on map and add its coordinates to the matrix as new record. Otherwise we play beep sound and mark that tasting for placing building was failed.

Adding new matrix
-> when created

In <when created> we add <building_list> matrix.

Checking if it's ok to place building
-> trigger event <building_check>

We assume at first that's it's going to be ok and set <building_check> to <true>. Next thing we want to do is to see if building we are about to place won't interfere with buildings already on map. To do this we will go through each record of <building_list> matrix.

Firstly we need to know how many records are there in the matrix. We learn it by triggering <get_data>. This gives us information about number of rows and index of <building_list> matrix.

Then we go record by record searching for something that would tell us it's not ok to place building. If we find something like this we play beep sound and set <building_check> to <false>.

  • #0 - x of building actor already on map
  • #1 - y of building actor already on map
  • #2 - x + width of building actor already on map
  • #3 - y + height of building actor already on map

We doing this with 2 checks: <First check> and <Second check>.

4 picture represent that all it takes for placing building to be wrong is if one of the building points is inside of the area of building already on map. This is checked by <First check>.

(Picture has been zoomed) The smaller building (red) is already on map. The bigger one (green) is about to be placed. Placing bigger building like this illegal because it would squash the smaller one. This Picture represents why <First check> is not enough.

<First check> checks if one of the points of building being placed is between points of already placed buildings. <Second check> checks if one of the points of already placed building is between points of building being placed.

Effects of placing building
-> when mouse pressed
-> trigger event <placed_on_map>

In Part I of the tutorial we placed the building. Now we need to add record with coordinates of the placed building so that in future we may check if building we are about to place doesn't overlap building already on map.

After creating building in <when mouse pressed> we trigger event <placed_on_map> for placed building in behaior <building behavior >.

To choose other part follow the link:
#Stencyl: Zerg terrain infection

Part 1: Creating building, making building follow mouse, placing building

  • Choosing building on keyboard key
  • Cancel chosen building
  • Make building follow the mouse
  • Placing building

Behaviors used in part I

  • main scene behavior (scene behavior)
    • when created
    • when e pressed
    • when r pressed
    • on mouse-click
    • when d pressed
Main variables:
  • building_active - Boolean; if there is a building following the mouse
  • tile_size - Number; size of tiles in pixels
  • active_building - Actor; Stores picked building

For tiles and building actors we change Physics->General->What kind of Actor Type? to <cannot move> and Physics->Advanced -> Actor Mode to <Simple>.

In when create we declare tile size(<tile_size>) in pixels. We declare <building_active> to false. <building_active> says if we picked building. We create <building_list> matrix that will be used in checking if there is a place for placing picked building.

Choosing building on keyboard key
-> <when e pressed>

We check if there is no building picked by checking (if (not(<building_active>) ) ). If this is true we create building. We set <building_active> to <true> since we picked building. We set <active_building> to <last created actor>. We move <last created actor> so that it has center on the mouse position.

I assume that all created actors this way have width and height equal to multiplied tiles. Implementation for second building is pretty much the same expect it is <when r pressed> event.

Cancel chosen building
-> <when d pressed>

If player has made a mistake and picked the wrong type of building we allow them to cancel their choice. We check if there exists picked actor and if it's true we kill it and mark this fact by setting <building_active> to <false>.

Make building follow the mouse
-> <on update event>

First If <building_active> checks if building exists. If yes we set building so it's center is at the mouse position.

Then we check 4 ifs in order to prevent building from leaving the screen. If x < 0 and if y < 0 are obvious the other pair might seem strange(explanation on picture below).

The second pair of <set x> and <set y> snaps the position of building to the grid.

Picture shows the building in position to most right and it is last position acceptable in that direction(yellow). If the building was anymore to the right it should be limited to that position since otherwise some part of actor would leave screen.

Snapping to grid means that we should change the current position of actor(purple) to node of the grid(black).

Code analysis for x direction. In this project we set <tile_size> to 16. For x = 8; x/16 = 0.5. Since we apply floor -> floor (0.5) = 0. This means that purple point will be moved to the tile number 0 counting from the left. In order to update position of actor we need to return to pixel values so we multiply it number of tile by <tile_size> and we get x-position = 0 (value in pixels).

The floor function is nice because you know that coordinates of nodes to the right and bottom from checked node are limits of how far a purple point can get from the checked node point while still being snapped to it. It's much easier than using round function.

Placing building
-><when mouse was pressed>

First If <building_active> checks if there is a building picked. If yes we ask if there are no other building on space where we are about to place building by triggering <building_check> (more details in Part II). If that's ok we place building. Since the building is placed and we don't want it to follow mouse anymore we set <building_active> to <false>. Then we trigger <placed_on_map> to force building to do all the work associated with its arrival (Part II).

To choose other part follow the link:

czwartek, 23 lipca 2015

#Stencyl: Zerg terrain infection

Difficulty: (6.5/10)
Estimated time of work: 12 hours
(Together with matrix behavior)

Original request:

Video of finished project:


Instruction to project:
  • Press E to choose Base building 
  • Press R to choose Egg  building
  • Click on map with building chosen to place it on map. If you heard beep sound that means you are trying to put the building over existing one => game does not allow it.
  • Press D to cancel the choice of building
  • Press A to perform single infection-step
  • Press F to allow auto infection
  • Press S to reload scene (start from empty)

Problem overview

In some RTS games after you place building it will infect ground around it. In some cases it influences gameplay, other times it's pure graphical gimmick.

This project will be using grid of tiles logic. So while mouse can move normally buildings can only be build on tiles.

Zerg buildings in Starcraft II with infected ground around them

 Disciples II showing ground infected by different factions: Damned Legion(red) and Undead Hordes(grey)

Top view RTS with grid of tiles visible

Project in bullets

What we want:
  • Choose from 2 types of building (for variety)
  • Chosen building follows the mouse in grid-system
  • On-click if there is a place on map we place the chosen building on map, otherwise we play beep sound so that player may know that they are trying to do something stupid
  • Placed building infects area around it
  • On keyboard key pressed already infected area spreads to surrounding tiles in 4 way fashion (top, down, left, right)
  • Infected tiles changes animation based on its surroundings
  • We want to let infection to spread on its own ass time progress as well without being forced to press keyboard key

Problems to be solve:
  • How do we make building follow the mouse?
  • How to snap building to grid?
  • How to check if there is place for building about to build?
  • Algorithm for spreading the infected tiles
  • Algorithm for changing animation of infected tile

Project review
While concepts of project isn't really difficult the implementation gives plenty of chances to make mistakes along the way.

Project uses matrix implemented in <matrix behavior>. This are 2D lists limited in x direction and unlimited in y direction. For more info on <matrix behavior> follow the link:

Tutorial has been divided into 4 parts:

Stencyl, Zerg, Starcraft, tile, grid, RTS, infect, infection, disease, spreading, building, placing

sobota, 11 lipca 2015

About me - part I

Finished games
I publish games to Newgrounds:

Bachelor degree: Biomedical engineering
Master degree (in progress): Informatics

About the games:
  • World chaser - probably the game I am most proud of. Not everything worked and would change this and that if I ever decide to do a remake. 
    Some fault lays at Stencyl - game was created using version 2 which had inefficient graphical engine what resulted in lags. The main problem with game design is that playing longer doesn't necessary bring you closer to the end. It's because you are allowed to revisit worlds you have already completed. I would change that if I get second chance. 
    One of the extras I really like are album which contains worlds you have already visited. The other one is quotes contained in the instructions to each world. Finding quotes concerning some topics turned out to be more difficult than expected. The funniest thing about researching quotes was finding quote about ire/wrath/fury. As it turns out the only 'cool' quote came from the Bible (a.k.a. that book speaking of endless mercy).

  • Twin star - this game was made for LudumDare with theme 'Worlds connected' and it's quite a funny/sad story. You know how they say that you need to fail a 100 times and then you will succeed? This game is one-step from succeeding. I think the game itself was nice. I wanted to add gravity effects like in 'Oribtal' but had failed to do it so it remained only as concept and was never implemented.
    The main idea of the game is that you control a pair of stars with single gravity center - so if you rotate one star around it the other moves as well. I added some gravity to the stars - if they are close, gravity will take effect and it will be more difficult to separate them. I published the game, it made some views. Some time later I enter newgrounds and I see frontpaged a game called Binary ... (I think it was called Binary System).
    • The game had used the same idea of two stars with single point of gravity.
    • No extra effects.
    • No gravity between stars.
    • The game layout was worse - you could die because the enemy could jump from outside of screen.
    • Game used 3D graphics instead of 2D like mine (3D but nothing advanced)
    • Game made easily 10 times more views than my game
I must say I am extremely jealous about that other game but on the other hand I know that I am on good way and next time it will be me taking those views.

  • Treasure Hunt - this game is bad, really bad. It was my first LudumDare so I didn't know how it works really. My internet connection was bad so even if I were to finish my game in time I wasn't sure if I would be able to send it. I had terrible hangover from meeting my friends day before.

The game turned out to be extremely boring. I think there is some potential in the idea but it would need to be differently executed to give fun. The only good thing about the game was background.

The funny part: as this game is the worst game I ever did it has the most views.

I don't know how I got into Stencyl. Every summer I had promised myself that this is the summer when I would learn how to do games and one summer I did. I did crash course, which is terrible. On the other hand you need to do this. Now being one of the guys on the forum who helps newcomers there is nothing worse that a newbie who comes demands help and is not willing to do anything on his own.

Consturct 2
I had brief romance encounter with Construct when I got really angry at Stencyl (and stupid things that happen and are not covered in manuals). It has some pros and cons against Stencyl. The bottom line is that free version allows you only to give 100 events. At that time I wanted to do full RPG, with big dialogues interactions between NPCs etc. 100 events let me move my character and open dialogue and that was it. You want more? Buy full version! As you see Construct screams for your money. I would consider buying it if it was perfect but it is far from it.

This blog was created from variety of reason. Firstly I helped a lot on Stencyl forums. 2 hours here 2 hours there... I could use those 4 hours to make my own game and yet I got nothing in return. So now I got a blog. The other thing is that crash course is really terrible so I wanted to provide something better.

I don't do games for lazy people - if you want me to do your school-project pay me and I will do it. I do projects for this blog either because the problem is interesting or the project has good educational values.

The rules for using my codes are:
  • If your game is non-profit it's ok to use my code as long as mention me
  • If your game is commercial you are ought to discuss me about using my code - otherwise I will take legal action against you
  • Some things used in tutorial (pictures, music) don't belong to me - they belong to their owners.