:::: MENU ::::

Pucaj Update – Major changes, Entity-component system

It’s been a while and I apologize for that.

Over the past few months, I’ve nearly abandoned my game project. However, the process didn’t follow the blog exactly. First I did some major changes to the architecture and advanced the process of making Pucaj miles ahead of what it was. Then I abandoned it for over two months, only to return to it a few days ago. Because of that, it took some time to reintroduce myself with code, but it also exposed some holes in code readability and maintainability that I will now be able to fix. This is almost a completely different project now, so I’ll try to make a short list of what’s new.

What’s new?

  1. Shift from a purely object oriented design using a sort of MVC architecture to an Entity-Component System
  2. Removal of old graphics and switch to single color placeholder tiles.
  3. Removal of the shooting mechanic and action controls with keys.
  4. Addition of proper touch controls, including gestures.
  5. Map generation using a slightly modified diamond-square algorithm.
  6. Menu system using the Scene2D UI functionality.
  7. Background asset loading with a loading screen.
  8. Basic AI.

So let’s go through this one at a time

Shift to an entity-component system

An entity-component system (ECS) is something completely new for me, but I’ve been reading about it a lot and the more I look at it, the more it makes sense, so I made the shift.

I won’t explain in detail what it is, but in short, instead of a hierarchical relation between game objects, we now have a world object which holds a list of entities.

What is an entity? Each entity is a simple identifier, in my case an integer, nothing more. You use this integer to give an entity components. So what’s a component? A component is an object holding some data for an entity, related to some aspect of it. A map position is a component holding the X and Y coordinates for the entity. Sprite is a component holding the texture for the entity. Animation is a component holding an array of sprites for an entity. Movable is a component holding an array of coordinates the entity can move to.

The important thing here is that entities should not contain logic, only data. For logic, in an ECS, you use systems. Systems are basically entity processors. They maintain a subset of entities currently existing in the game world, that have certain components. A movement system would have access to all the entities in the world that have the position and velocity components. On each tick, it would go through all of these specific entities and use the velocity data to update the position data.

Again, there is an entire science behind this, so instead of going into details, I’ll just give you some links…


This is an entire series explaining the idea behind an ECS. If you’re interested in this approach (and I really think you should be), go and read it. It will give you the basics and explain the logic and motivation behind some aspects of the ECS approach.

This is another good article that explains the idea behind it all. It’s a shorter read, but it’s a bit quicker to go into the practical approach.

Another good read. Be sure to visit the articles and sites he’s linking to also, just like with all the other links.

A good idea is to also visit gamedev.stackexchange, since there are plenty of specific questions about ECS there.

In the case of Pucaj

In the case of Pucaj, I’m still working out the details, but here’s where we’re at for now:


  • Abilities – for any entity that has access to abilities. This one is likely to go away, break apart or change completely in some other way, as I’m still working out the actual game mechanics.
  • AI – for controlling a computer unit/player. It’s a very dumb AI implementation and will likely be replaced by several different AIs, or possibly even a sort of network of AIs, working together.
  • ColorAnimation – for entities that change color over time.
  • Cursor – not used anymore. I had an idea to have a key-controllable cursor displayed on the map, but keyboards controls have been removed for now.
  • Damage – for giving damage to an entity.
  • Expiration – for an entity that will be removed after a specific amount of time.
  • FadingMessage – for displaying a message that disappears after a while. It should probably be broken apart into something like TextSprite + Expiration + Movement + Fading or something.
  • MapPosition – for entities that are placed on a spot in the map grid.
  • Movable – for entities that can be moved, so they need to have possible places to move to displayed.
  • Movement – for entities that are currently moving along a path.
  • Player – for entities controlled by the player.
  • ScaleAnimation – for entities that change size over time.
  • Selectable – for entities that can be touched/clicked on.
  • Sprite – for entities with a simple graphic.
  • SpriteAnimation – for entities with an animation graphic.
  • Stats – for entities with stats. Like Abilities, this one is extremely likely to go away, break apart or change in some other way.
  • Velocity – for entities that move at a certain rate in a certain direction. Not used for now, since this is a grid-based game. It might be used later, for missile entities.

So those are the components I have right now. As I said, entities only hold the data, so most of them contain some fields or properties and a constructor. A select few, such as Player are completely empty and only exist to serve as an indicator. Their attachment to an entity itself is the data – a flag indicator.


Systems are there to handle the logic. Each system handles a subset of entities that hold specific components and processes them on each tick (or in some other way, depending on the type of system.

  • AISystem – handles entities with AI components, making decisions for them. For now, these entities also need to have a Stats, Movable and Abilities component, but that’s bound to change eventually. A good example of where it might change is if we ever have a stationary turret – it would not have a Movable component.
  • CameraMovementSytem – this is actually a system that doesn’t work with a list of entities. It simply moves the camera in certain ways as needed.
  • ColorAnimationSystem – handles entities with the ColorAnimation component and changes their color as indicated by the component data.
  • DamageSystem – handles entities with the Damage, Stats and a MapPosition component. It creates damage labels (entities with FadingMessage), handles removal of dead units, etc.
  • ExpirationSystem – handles entities with an Expiration component in a very obvious way.
  • FadingMessageRenderSystem – again, a very obvious system. Handles fading messages.
  • HudRenderSystem – another system that doesn’t deal with components directly. For now, it just renders the FPS counter.
  • MovementSystem – handles entities with MapPosition, Movable, Sprite and Movement using the data to update the position.
  • PathRenderingSystem – obsolete. It used to render a dotted path from the current position of a unit to the target position.
  • ScaleAnimationSystem – this one should be fairly obvious. It handles entities with ScaleAnimation and Sprite in order to change their size.
  • SpriteAnimationSystem – much in the same way, this one handles entities with SpriteAnimation and Sprite. It sets the sprite texture to the current animation frame.
  • SpriteRenderSystem – very obvious. It takes entities with Sprite and MapPosition and draws them on the screen. It also uses a list of SpriteAnimation entities to handle their insertion into the world and set their initial frame.
  • TurnManagementSystem – this one handles entities with Stats. It determines their acting order.

I also  have a few classes that currently aren’t actual Systems, but will probably become systems in the future. I’m just having trouble figuring out how to best do it.

  • MapRenderer and MapHighlighter render the map and the movable to area around the unit once you select it. I’m thinking they should be fairly easy to transform to proper systems, but I didn’t get a chance to do it yet.
  • Various input controllers – I have several different input controllers, each handling a different aspect of user input. Some should be easy to transform, but some not so much. Most people seem to agree that the input layer should be mostly decoupled from the ECS and communicate with it via a system of intents, but I haven’t completely figured out what those intents are supposed to be and how it would work with a turn-based grid game.

Switch to new graphics

Let’s be honest here. I suck at graphics. Using the old set I’ve been spending hours to make is useless for me, since they are bound to be different eventually. Because of that, I’m keeping it simple. I kept the tank graphic I was using and switched to single color tiles for the map. Once the logic behind it all is in place, I’ll start worrying about making actual, proper graphics. Who knows if this will ever be an actual game – it’s better to worry about those things later.

Pucaj Map Tiles

Pictured: The current set of map tiles I’m working with.

The tiles I have now are easy to maintain and simple to work with.

No more action controls

This was expected, since it wasn’t supposed to be an action game. I was just playing in a sandbox previously. Instead..

Addition of proper touch controls

You can now zoom the camera in and out and move it around as you please. Even better, it works with a mouse as well as touch gestures. You can scroll and/or pinch to zoom in and out and you can drag to pan. A double click/tap smoothly moves the camera to the active unit.

Map generation

I found some guides and I made a map generation. I’m not completely certain maps will be generated in this game, but it was a fun side-project to do and figure out, so I did it. Look into Diamond-Square if you’re interested in it. Basically, it generates sort of realistic looking topography maps and is well-suited for square based grids, but it could also be adapted to hex grids, for instance.

The current parameters make a relatively small map, so the above video won’t make it look especially great, but you can go way bigger if you want to.

Here are a couple of screens of a slightly bigger one:

Pucaj Map Screenshot #1 Pucaj Map Screenshot #2 Pucaj Map Screenshot #3

See those tiny little dots on the pictures? Those are the tanks from the video above. Also, all three of these screenshots are different places of the very same map. Fun stuff, right?

Menu system

Scene2D, which is part of libGDX, has a built in menu system I’m currently using. It’s not pretty, but it’s functional. I haven’t decided yet if I’ll keep using it, modify it, or go with something more visually oriented.

Background loading and loading screen

This should be self-explanatory. I don’t have many assets right now, but I’m expecting the amount to grow, so there will be a need for some sort of preloading mechanic. Since it will hopefully be a relatively tiny game, I feel it’s best to just preload everything into memory at start-up.

Because of that, I designed an asset loading singleton. At game start-up, this manager loads everything into memory and holds it there. Instead of loading each individual asset as I need it somewhere in the game, I now simply ask the manager to give me the desired asset. I use a loading screen to notify the user of this process.

Now, as I said, the amount of assets is very low right now, so the loading screen goes away quickly. I actually had to add an explicit delay in order to show it during testing.

Basic AI

I also implemented a very dumb AI player to control the two enemy teams. Right now, as you start the game, three teams are generated – the player team and the red and blue AI teams. It’s a free-for-all so everyone is fighting everyone. You can see this in one of the previous videos, the one demonstrating the menu system.

As I said, the AI is extremely dumb, but it does heal and execute attacks, so it’s fun for messing around with. I’ll make it smarter and try to give it more personality at a much later stage.

And that’s it! This is the scope of the changes that happened to my “game” over the last few months. I’m back into it now, so hopefully, you’ll get more frequent updates for a while.

Pucaj Update – Shooting, Major Refactoring


I’ve been slacking off a bit lately, but not long after my previous update, I did add some improvements to the existing code.

The first thing I did was to apply a sort of MVC pattern to the code structure. For this, I’ve created a Level class and paired it with LevelRenderer and LevelController classes. The Level class is the base model in this situation. It contains all the properties required to represent a single level in my future game. As such, it’s always instantiated first.

The Level class contains the player, which is an instance of a Tank, which, in turn, contains a Weapon. Since Tank and Weapon are still relatively simple, they don’t have dedicated Controllers or Renderers yet.

Once an instance of a Level is created, the LevelRenderer and LevelController are created by passing in this instance to their constructors. The renderer is in charge of drawing the level, while the controller handles updating everything related to the level. This means I actually took out part of the code in the render method and placed it into a new update method. This makes the game loop more akin to the standard loop I’m familiar from my stuff in XNA. There’s initialization/creation, updating, drawing and destruction.

I decided to make my level Orthographic camera much simpler. Since levels should be sized in tiles, I  made it’s inner coordinate system an 8×8 grid, simply to avoid dealing with complex calculations in the future. The level is also drawn in a separate gl viewport, again, to make things simpler. This way, I can draw the level without worrying about drawing the interface or anything like that – the interface will be drawn within the global viewport.

With that, resizing is now working much better. The graphics scale with window size and resolution and follow an internal, virtual resolution to keep things simple.


I’ve also added basic shooting to the basic weapon. My initial plan was to make a bullet factory/manager which would be initialized at level creation and handle all the bullets currently live within the level. After some time spent badly implementing this, I realized there’s no need for that. Since the game will be turn based, it would probably be much better to simply have each weapon handle their own ammo. Firing will simply be an effect to show on the screen, while the actual damage dealing, aiming, hitting and missing will be handled by math in the background.

Of course, there’s no real turn based system implemented yet, so the basic weapon now simply shoots on whichever part of the screen I double-tap. The double-tap is actually faked to. The controller simply keeps track of how long it’s been since I last tapped the screen, and fires a bullet if conditions are set. Because of that, it’s possible to spam bullets if you just keep tapping.


Finally, I started using the screen system libGDX offers through the com.badlogic.gdx.Screen namespace. This is done by creating the initial GameScreen class and setting it to implement the Screen class from this namespace.

All the bottom-tier logic was moved from the main Game class to this one, making the Game class extremely simple now:

import com.badlogic.gdx.Game;

public class PucajGame extends Game {

	public void create() {
        setScreen(new GameScreen());

setScreen will allow me to switch from main menu, to options menu, to game, etc. very easily, so I’m glad I started using it this early.

GameScreen also implements the  InputProcessor class, which brings with it methods required to handle user input, such as keyDown, keyUp, keyTyped, touchDown, touchUp, touchDragged, mouseMoved and scrolled. Since GameScreen is supposed to be the screen where the currently active level is handled, these methods communicate with LevelController to delegate the input to the level. On the other hand, Screen methods (render, resize) communicate with LevelRenderer to handle the drawing.

The Result

The game now scales as I resize the window, I can move and shoot and it looks pretty cool (at least from my point of view). Here it is in action…

As usual, you can see every line of code in my repository – Pucaj on GitHub.


Pucaj Update – New Graphics and Basic Weapon

I didn’t do too much development, but this time, I’m aiming to add something noticeable with every update to keep myself motivated and keep at it, instead of abandoning the project like I did with every one of my previous ones.

I used Gimp to create a new set of sprites for the basic tank. This one looks slightly better than the last one, but isn’t anything amazing. In the end, I’m not artist. While I was at it, I also added a basic cannon/turret graphic and a weapon class. Each tank will have a weapon which is drawn right on top of the base. The weapon can rotate independently from the tank and for now, rotates based on where you click.

The idea is for the weapon class to become a base or even an abstract class from which all other weapons will inherit.

It took me a while to figure out the rotation math, mostly because I was confused with the camera. For some reason, I decided to position the (0,0) coordinate of the LibGDX orthographic camera in the center of the screen, but this just ended up giving me trouble. Because of that, I put it in the bottom left, which makes much more sense to me. I did it the following way:

camera = new OrthographicCamera(Gdx.graphics.getWidth(), Gdx.graphics.getHeight());
camera.setToOrtho(false, Gdx.graphics.getWidth(), Gdx.graphics.getHeight());

The false parameter indicates that the y-axis starts at the bottom. Setting this to true makes it start at the top, which might be more familiar to some people.

A slight issue here is that the y touch coordinate in Gdx.input.getY() starts from the top, but the fix here is simple. You simply subtract it from the camera height to make it go from the bottom.

Vector2 touchPos = new Vector2(Gdx.input.getX(), camera.viewportHeight - Gdx.input.getY());

I decided to calculate rotation not from the exact touch coordinate, but from the center of the tile nearest to the touch coordinate. This way, it’s more of a discreet feel and in the future, when I’m actually targeting enemies centered on that tile, it will look better.

I’ve noticed everything seems a bit too small, though, so I’ll see about increasing the size of everything. Maybe an 8×8 or a 6×6 grid would work a bit better. Ideally, I would have zoom functionality, but that’s a bit beyond me at this point.

Here’s the latest video:

In any case, the game is progressing and I’m still at it. I think my next goal will be to add a basic bullet factory/manager class and add shooting functionality. Either that, or I’ll work on increasing graphics size and maybe try to make the code a bit better. That’s putting me in danger of getting ahead of myself, though.

Pucaj Update – Grid Based Movement

I’ve been thinking about what Pucaj should actually become and I’ve decided on a turn-based RPG with tanks/robots. The vehicles would have parts you can upgrade, or buy, or collect maybe, and you’d move and fight on a grid based map. None of it is really completely decided on and it’s all a blur right now, but one thing I can be pretty sure of – I need grid based movement.

I ditched Box2D, because there really isn’t any need for it, and also ditched the “rotate the tank towards touch coordinates feature I had.

Instead, I implemented the movement based on a grid system.

The first thing I needed to do was to set up scaling of coordinates, so I can work with what are basically integers, instead of screen coordinates.

Since the current map size is 10×10, the player’s position can be stored in a [0..9][0..9] vector. Based on the provided input, it then changes . Since it needs to also look nice, I added a class with static easing methods to interpolate between the new and the old position. The easing methods will be very universal, so I can use them for other things as well. They will require the initial value, the amount that value needs to change for, the duration of the entire process and our current position in the process, as in elapsed time.

Basically, we have something like this:

newValue = easeFunction(elapsedTime, initialValue, totalChange, totalDuration);

For now, all I have is a quadratic easeIn function, but I will be adding more as I need them.

I’m having trouble on deciding how to detect the player’s desired action via touch. For now, I determine the four rectangles the player can move to from the current position and then look if the player has touched a coordinate in any of these rectangles. This works, but it might not be the best approach.

A possible alternative would be to calculate the centers of these four rectangles and then move into the rectangle with the closest center to the touch coordinates.

The first option has the advantage of precise movement, but it also feels a bit stiff. On the other hand, the second approach allows for more freedom, but could also cause unwanted movement.

With the keyboard, this is much more straightforward. You use arrow keys to move and that’s it.

Also, since I don’t want diagonal motion, direction is prioritized in the order of UP, LEFT, DOWN, RIGHT. In the context of the keyboard, this means that if you push UP and LEFT at the same time, you will go up, etc.

In any case, I made a video of what I have and uploaded it on my painfully slow connection. Here it is:

My laptop is complete crap, so it stutters even with this. I promise that if I ever have anything substantial to show, I will use my more powerful PC.

You can see in the video that both touch/mouse and keyboard support exists. When the mouse cursor isn’t moving, but the tank is, it means I’m using keyboard keys.

Impressive, right? /s



Let Us Begin – Current Projects

First of all, hello!

I’m Nikola Begedin. I’m a software developer and I work and live in Croatia.

I have this dream/fantasy that I’ll finish some sort of amazing side project, get rich, retire early and then continue to play games and dabble in development until I die of old age. It’s never going to happen, but it doesn’t stop me from trying.

Unfortunately, my procrastinating personality does stop me from following up on any of my projects or ideas.

Luckily, I have people who at least try and sometimes succeed at pushing me into doing something. I now also have this blog, which I will use to keep track of my projects and ideas and hopefully do a better job ad working on them.

So here goes…

Current projects

Aside from work, where I’m right now learning a lot about JavaScript, SPA (Single Page Application) development and various modern JavaScript frameworks, in my spare time I also study for my Microsoft certification exams and, more importantly, dabble in game development.

Off the top of my head, I can list a couple of projects. I will try to make updates on each of them as soon as I have anything substantial to talk about.


Pucaj simply means Shoot in Croatian. The idea of Pucaj is for me to get to know LibGDX and Android Development Studio while making something that might one day be called a game. Right now, it’s just a bunch of code without a clear goal in mind.

Pucaj - Grid and player

This is what I have right now. The tank follows your finger/mouse and turns towards it.

LibGDX allows me to develop simultaneously on Desktop, Android, iOS and Web, but right now, I’m only using the Android and Desktop capabilities. With some tricks, I managed to import the project to Android Development Studio, so that’s great to.

You can track my Pucaj repository on GitHub.

Dice and Roll

Dice and Roll is a browser game I’ve been developing with a colleague from work, Ratko. If it weren’t for him, this project would not have existed, so he should get most of the credit. We’ve been working on it as a sort of presentation to show at a local conference, which my company is organizing every year – DevArena.

Ratko has his own blog where he mostly talks about Lync development, but who knows, it might mention games at one point to.

In any case, Dice and Roll, in spite being very basic, was quite well accepted, so we decided to keep up with it. We’d like to at one point transform it into a multi-platform game, running in browsers as well as a native C# Windows 8 App.

For now, you can even try it out. Our company is hosting it, but there’s no guarantee it will be there for long. Keep in mind, it’s only currently current. We will be pushing updates to our production version soon.


NESjs could hardly be called a project. This guy called Alexander has this blog, where he is making a guide on how to create a Nintendo Entertainment System emulator in JavaScript. I’ve been basically doing the same thing he’s doing, hoping to learn something about how to properly structure JavaScript apps through the process, and maybe even learn a bit about emulation.

Really, you shouldn’t follow what I’m doing with it. Instead, follow the guide I’m following.

As with Pucaj, you can track my NESjs project repository on GitHub