Posts Tagged ‘techniques’

« Older Entries
Newer Entries »

Scripting with Artemis Entity System Framework

Sunday, November 13th, 2011

Artemis is a component based entity system framework made in Java by Arni Arent (appel) and Tiago Costa (spiegel).

The core of Artemis is small and it is based on four main concepts. The Component, where all information about an Entity is stored. The Entity, which represents a game object. The EntitySystem, where custom logic, for entities with one or more component, is processed. And finally the World, where Entities and EntitySystems live. The idea is to grow over those concepts by making your own Components and EntitySystems.

The problem

There are some cases where it depends a lot how are you using Artemis, to feel it is helping you or not. For example, when you want an Entity to have some custom behavior on a specific level you could follow the next approach.

First, create an SpecificBehaviorForLevelComponent to declare that an Entity with that component will have that custom behavior and then create the SpecificBehaviorForLevelSystem which performs the logic.

The problem with this approach is that you will have an empty Component used only as a mark to let the EntitySystem work over it. Also, you will have an EntitySystem that will perform logic only in a specific moment of the game and then it will be useless.

If you have to create more than just one custom behavior, then you are a bit doomed and you will hate Artemis. However, it is not Artemis, or any component based entity framework, fault.

Script Framework, a possible solution

To simplify working with cases like the one mentioned before, we created a scripting framework over Artemis, composed by three main concepts: the Script, the ScriptComponent and the ScriptSystem.

Script

This is an interface which provides the following three methods:

  • init(world, entity) : called once when the entity enters the world.
  • update(world, entity) : called in each world update
  • dispose(world, entity) : called once when the entity leaves the world.

It should be implemented and added to the ScriptComponent of an Entity in order to perform the behavior.

ScriptComponent

This is an Artemis Component which contains a collection of Scripts and it is used by the ScriptSystem in order to know which Scripts to process on each Entity.

ScriptSystem

This is an Artemis EntitySystem responsible of calling, for each Entity, the init/update/dispose methods of each Script declared in the ScriptComponent of that Entity.

For the previous example, where we wanted a specific behavior for an entity in one level, we could create a SpecificBehaviorForLevelScript and, when loading that level, add that script to the ScriptComponent. So, instead creating Components and EntitySystems, we can create only Scripts.

Pros

  • Clear and simple API.
  • Easy to add/remove a Script vs add/remove a System.
  • Scripts are easily reusable (when you want two or more entities with a custom behavior).
  • Logic localized in one place.
  • Allow different implementations of the Script interface, for example, a Groovy implementation.

Cons

  • Not good for global stuff like rendering, an EntitySystem keeps being better for those cases.
  • Hard to know the right balance between which code should be on Scripts and which one on Systems.

Conclusion

The Script Framework is some point in the middle between Entities with no logic at all and Entities with all the logic. It should be used with care, learning to balance which code should be on Scripts and which code on Systems is not easy.

Artemis is only a small core, a foundation of classes to work with. The real power comes from the custom Components and Systems you create over it. For example, in our case we created several Systems that we reuse between games, some of them are the RenderSystem responsible of rendering the entities with the RenderComponent using libGDX and the PhysicsSystem responsible of processing the Box2d world.

References

There are a lot of resources about components based entity systems, however the best/correct solution between all these references is not so clear.

Hope you like it.

VN:F [1.9.11_1134]
Rating: 5.0/5 (2 votes cast)

Tags: , , ,
Posted in Gemserk | 2 Comments »

Making buttons using Inkscape – part 3

Monday, November 7th, 2011

This is the third part of the buttons tutorial series, in this case I will show how to make more complex shapes to be used inside the buttons.

As I did on previous posts, I will show images with the steps to follow to make each icon.


This image explains the steps to follow to make a question mark icon.

This image explains the steps to follow to make an icon for high scores.

Finally, a time lapse video showing how I made all the stuff:

Here is the link to download the question mark SVG and here is the link to download the high scores icon SVG.

As always, hope you like it.

VN:F [1.9.11_1134]
Rating: 5.0/5 (1 vote cast)

Tags: , , ,
Posted in Gemserk | No Comments »

Making buttons using Inkscape – part 2

Tuesday, November 1st, 2011

Following the buttons tutorials, in this case I want to show how to make square buttons and how to make simple inner shapes to be used over the button base.

First, the next image tutorial explains a bit how to make buttons to increase/decrease values by using plus and minus symbols.

Here is an example of using it to modify the volume of a game:

The next image shows how to make square buttons with a similar style used for the circular buttons of the previous tutorial.

And here is a time lapse to show how I made the square button:


(note: watch it in 720p, youtube killed the video when converting it to 360p and 480p)

If you want to use this templates, you can access here for the SVG file used for the tutorial, and here is the SVG with several shapes to be used with these buttons.

Finally, I made a new icon to show our android market games at the icons widget in the right side bar, if you like it, feel free to use it. Here is how it looks like:

Hope you like the post. Next time make complex shapes like the high scores goblet/cup.

VN:F [1.9.11_1134]
Rating: 5.0/5 (2 votes cast)

Tags: , , ,
Posted in Gemserk | No Comments »

Making buttons using Inkscape – part 1

Monday, October 31st, 2011

Inspired by the Gamasutra article named 2D Game Art For Programmers part 1, I was making some stuff using Inkscape and I want to share my learnings.

In this case, I want to share how I made the background for buttons to be used in games. As the article’s author did, I created an image explaining step by step:

Creating a button step by step
(note: click the image for full resolution)

After adding content to the background, we could create stuff like this:

Button examples

I will create another post explaining how to make those button content shapes.

You can download the SVG template from this link if you want to use it, and or modify it.

Hope you like this post, because I am planning to make more :D .

VN:F [1.9.11_1134]
Rating: 5.0/5 (3 votes cast)

Tags: , , ,
Posted in Gemserk | 2 Comments »

Detecting collisions using libGDX Pixmap

Monday, October 10th, 2011

I keep making prototypes about what I talk in the previous post, in this case I made an example of how to interact between the game entities (the bombs in the video) and the Pixmap data (the platform of the video) by adding some kind of basic collision detection checking the Pixmap’s pixels with alpha value different from zero. I only wanted to share the a video showing the experiment:

As always, hope you like it. Probably more information on next posts.

VN:F [1.9.11_1134]
Rating: 5.0/5 (5 votes cast)

Tags: , ,
Posted in Gemserk | 11 Comments »

Modifying textures using libGDX Pixmap in runtime

Thursday, October 6th, 2011

Since the beginning of Super Flying Thing, I wanted the game to behave in some aspects similar to Worms (and other games). One of those aspects is the destructible terrain, I love that feature and that is why I am prototyping some stuff to see if we can add that feature to the game or not.

The next video shows how I am using the Pixmap class of libGDX library to modify textures dynamically.

In the previous video there are two textures, they start with the same pixmap data. Then I start to paint and erase pixels from each texture to show how the pixmap operations works over the two pixmaps. Finally, I start rotating both textures and then paint and erase stuff again, to show how I am transforming from game world coordinates to each pixmap coordinates.

Pros

Destructible terrain. If that works, then we could add some new game play options, like throwing missiles (weapons!!) or killing yourself in order to destroy some part of the map and open paths. Or some power like a shield or something where you move through the terrain destroying it.

We could create some kind of in game level editor for people to make their own levels (and possibly share their stuff). We could make that now using tiles maybe, but I believe making the levels from textures could be easily used by any player (maybe kids). I feel like an in game level editor similar to Inkscape (what I am using right now) is advanced stuff for a typical player.

We could also make more interesting random levels (using some other techniques).

Cons

Having to handle all this texture modification information implies we have to use more memory since we can’t reuse textures, and that could be a problem in limited devices.

Another problem is that textures created with Pixmaps are not being managed by libGDX, that means if the game is paused (you had a phone call for example) and the textures were disposed, then when the games continues the texture data will not be automatically loaded by the library, so we need to manage the texture ourselves.

Also, we will probably lose Box2D collisions calculations as our world is currently made by Box2D polygons, and we will have to create our own bitmap collision calculations.

Conclusion

Working the terrain as textures is really interesting but also harder and we have to prototype more to know if this is possible or not. However, I will keep dreaming with this feature.

Hope you the post, and if you know some techniques that could help or want to make another contribution, feel free to comment, we will appreciate it.

VN:F [1.9.11_1134]
Rating: 4.3/5 (3 votes cast)

Tags: , , ,
Posted in Gemserk | 5 Comments »

First version of new random level generator for Super Flying Thing

Friday, September 30th, 2011

Two weeks ago I was working to improve random level generation of Super Flying Thing, the objective was to make the levels a bit more interesting.

Previous generator was really simple, the idea was to define where the starting and destination planet will be and then generate a lot of “garbage” in the way, sometimes with no possible path between both planets.

New level generator does more work to generate a bit more interesting level. Basically the idea is to use some pre generated tiles:

Tiles are defined by SVG groups in a SVG file with custom meta data defining with which tile can be paired.

Based on that information, the generator creates a pattern and based on that pattern and the tiles, it creates the level.

For example, if we have four tiles {A, B, C, D} where A is the where the start planet should be and D where the destination planet should be, and we have the possible links {A -> B, A -> C, B -> B, B -> C, B -> D, C -> B, C -> C, C -> D}, then a possible level could be ABBCBCD (using a regular expression could be defined with something like A(B|C)+D).

So, a very basic pseudo algorithm could be something like this:

	tiles.add(startTile)
	currentTile = startTile
	while (currentTile != endtile) {
		tile = getPossibleNextTile(currentTile);
		tiles.add(tile);
		currentTile = tile;
	}

Where getPossibleNextTile() method uses the meta data of the tile to define randomly a possible next tile.

Here is how a random generated level looks like:

As the title says, this is the first version of the generator, there are a lot of possible improvements to be made and/or create a new generator and throw this one to the trash can.

After writing the post I realized that there is not so much information and the algorithm is pretty basic but I hope it could be of help anyway.

VN:F [1.9.11_1134]
Rating: 0.0/5 (0 votes cast)

Tags: , ,
Posted in Gemserk | 1 Comment »

Building 2d sprites from 3d models using Blender

Wednesday, July 20th, 2011

In this post I want to share the process used to create the ship sprite sheet of Super Flying Thing (STF from now on). I will assume you have a basic experience with Blender or software alike.

Model and texture

The first step will be to get or create a model you want for the sprite sheet. In my case, the ship was created from zero, following this excellent tutorial (a bit boring to watch, but great content). Of course, as I am not an artist and I only dedicated three hours, my model sucks a bit compared to the one of the tutorial.

Set the camera

Now that you have a model, you will have to configure the camera for the Blender rendering process. The idea is to put it pointing to the model, and bring it closer to the model until you get it in the camera view port. The next image shows an example:

In the case of SFT, I configured the view port to be 64×64.

Create the animation

Now, you have to create the animation you want to render. For SFT, I wanted to create the animation of ship rotating 360 degrees. As the speed of the ship is approx 300 degrees per second, and I was using a 30FPS animation, then I wanted to have the matching frames for the complete rotation animation, in this case, 36 frames. So I created one key frame for 0 degrees, 90, 180, 270 and 360 degrees. The last one is only used to complete the interpolation and is not included in the final animation.

ship animation key frames

Be sure to configure the animation to use a linear interpolation to match the frame with the ship’s angle, unless you want otherwise. To do that, open the Graph Editor, and from Key menu modify Interpolation Mode to Linear.

Finally, export the animation using Render animation from blender, it will create each frame of the animation in your temp folder. Be aware you will get a better result using an Anti-Aliasing algorithm, for example, Catmull-Rom, thanks void256 for the tip.

Here is the difference:


The left image is not using anti aliasing at all, the right one is using Catmull-Rom with 16 samples per pixel.

And here is the animation:

The process is tools independent, so you could use, for example, 3D Studio if you want. You only need a good artist, as we do.

As always, hope you like the post and it could be of help.

VN:F [1.9.11_1134]
Rating: 5.0/5 (3 votes cast)

Tags: , , , , , ,
Posted in Gemserk | 7 Comments »

Building levels for Super Flying Thing with Inkscape

Wednesday, July 13th, 2011

As we did for Archers Vs Zombies and Taken, we are using Inkscape for building Super Flying Thing levels too.

On SFT, levels are defined by the following information:

  • The position of the starting planet
  • The position of the destination planet
  • The obstacles, specified by a collection of vertices and if they are dynamic or not
  • The items, specified by their position
  • For dynamic obstacles, a list of vertices specifying the path they follow

To declare this stuff on Inkscape, we are using three layers: World, Paths and Obstacles.

World layer is used to declare starting positions like start and destination planets and items.

Paths layer is used to define paths to use for dynamic obstacles (and probably for other stuff too).

Obstacles layer is used to define the shapes of the obstacles of the level. If the obstacles are dynamic we could link them with a defined path to make them follow it in the game. To link it we are using, for now, a custom xml field named movementPath with the id of the path we want.

We also have a templates layer, used to define templates for stuff we want to replicate later in other layer, for example, premade obstacles. That layer is not being processed when the level is loaded.

Here is a screenshot of one level being edited:

Using Inkscape as level editor for Super Flying Thing works great, however, we believe it could be an interesting feature to have an in-game easy to use level editor, to let players create their own levels and probably share them with other players.

Hope you like it.

VN:F [1.9.11_1134]
Rating: 1.0/5 (1 vote cast)

Tags: , , , ,
Posted in Gemserk | No Comments »

Simplifying building bodies and joints with libGDX Box2D – 2

Tuesday, July 12th, 2011

BodyBuilder, which I commented on a previous post, has been updated to work with multiple fixtures, keeping simplicity.

Internally, it uses a FixtureDef builder named FixtureDefBuilder which lets you specify a fixture definition for each fixture.

Here is an example of how it looks now it supports multiple fixture definitions:

Body body = bodyBuilder
		.fixture(bodyBuilder.fixtureDefBuilder()
				.circleShape(radius * 0.1f)
				.categoryBits(CategoryBits.MiniPlanetCategoryBits)
				.restitution(0f))
		.fixture(bodyBuilder.fixtureDefBuilder()
				.circleShape(radius)
				.categoryBits(CategoryBits.AllCategoryBits)
				.sensor())
		.position(x, y)
		.mass(1f)
		.type(BodyType.StaticBody)
		.userData(e)
		.build();

The previous example shows how to declare two fixtures for a Body, one of them is a sensor. For you to know, I am using that code in Super Flying Thing to declare the destination planet (that’s the name for now), the sensor is to detect when the ship is near to trigger an event and then attach it to the planet by creating a Box2D Joint.

If you are a game programmer, it could be useful to maintain your code clean and simple.

VN:F [1.9.11_1134]
Rating: 5.0/5 (2 votes cast)

Tags: , , ,
Posted in Gemserk | No Comments »

« Older Entries
Newer Entries »