html5

When I first read the theme “Small World” at the theme voting, I thought in making a circular world again (just like my last LD game). However, everybody is gonna do that! So, after a 2-hours brainstorming, the 2 first hours of the competition, I came back with the game idea.

I love the aesthetics of Besieged. All levels show a small village or a small campsite merged into a white-ish background, creating a very cool mix of white emptiness and green alive. With this mixture, you have the feeling that the whole world is just that small portion of green you are seeing. I love that, and I would like to try something alike.

After deciding the aesthetics, I had the feeling that a board game would fit well in this style, where the tiles kind of merge to the background. With a board game in mind, I decided the base rules, which are based on Zombicide: multiple missions, swarm of enemies, climax during the gameplay, varying missions, etc.

All set. A board game inspired by Zombicide and Besieged.

And as usual, even before the theme voting phase, I decided that this game would have something technical that I haven’t developed before. LD#30 was behavior trees, LD#31 was flocking algorithm, LD#32 was circular world and complex behavior trees, and, finally, for this LD#38 I wanted to give more time to animations – not the animation like in sprite sheets, but the animation effects like moving a piece, spawning an enemy, changing scenes, etc…

What went right?

  1. Although the game is not very good, I could finish it, and that was the biggest achievement this time. Sure, other Ludum Dares I worked as hard as this one, but this time the schedule was very, very tight – 3 hours to end the competition I was considering giving up because it missed so many things – but I could complete the base project scope that I have decided at the beginning.
  2. There were, impressively, very few bugs during the development, even the A star algorithm I could code in minutes without any problem. Most bugs I could fix in the last hour.
  3. I could do some cool animations and developed a nice animation scheduling (see below for more details). The animations are not perfect, but they were fun to implement, in special the enemy spawn and enemy movement are very cool!

What went bad?

  1. Very, very tight schedule so that I could barely finish the base of the game. Everything went as I expected, but who wants to barely finish something?
  2. Unbalanced and not fun, again. This is the problem I find in most of my games. I dedicate so much time on the mechanics (usually a bit complex) and the visual that I don’t the time to make it good. I should probably focus that on the next game.
  3. The game provides a few visual feedbacks only, but the player don’t have much idea of what is happening within the combat, or the player can’t even track the pawn actions properly.
  4. No music or sound, but that has always been my Achilles heel.
  5. I implemented a great customization system in which I can add new pawns, enemies, tiles, maps, or event different goals very easily to the game, but I only had time to create one map. If a jam game have lots of customization and lack of content, the customization was just wast of time.
  6. Developing a board game is really hard. I expected it to be complex and take a lot of time to code the game rules, but it is really hard to change and tweak how the rules work and interact during the development. If I will ever implement a board game for a Ludum Dare again, I will keep the rules very very very very simple.

Technical details

Some details of implementation:

The board game logic is completely independent from the visual and the user interaction, which made things really easy later. When the user select an action, the game (visual) asks the board (logic) for more information and render things. When the user perform an action, the game sends it to the board, the board perform and compute everything internally and returns a list of events that occurred internally. For instance, if the user attacks an enemy, the board returns the events pawn attack, enemy defense, enemy damaged, enemy killed, etc…

This messaging system is really great for board games, in special because I wanted to animate all actions, one by one, sequentially. Each message have a different payload, which is used to update the visual object properly. You may see the messages while playing the game if the developer tools is open.

Animations are trick to do. The problem with animations is that you must wait it to finish in order to continuing the operation of the game, thus, making its operation asynchronous. However, as any asynchronous system, other things are happening while the animations are working, such as the user clicking and moving the mouse everywhere (which causes a bug on buttons, don’t know how to solve that yet). To create this system, I added a job function attached to the scene, which can create multiple jobs and run that in parallel.

The job functions receives the duration of the job, the delay to start it, an update function which will perform the animation, and a complete function which is called when the job finished. Moreover, the programmer may stop every job at any time.

At last, I just want to recommend the Affinity Designer, it is a wonderful software for vector drawing, and it save a lot of time with the automatic exporting. I used it together with the Texture Packer and a small script to make the sprite sheet. It was really efficient: I save the document; the Affinity Designer export everything to a specific folder; then I just click export sprite sheet on Texture Packer (I only have to add new sprites if I create new ones); and run the script (I have a console ready to execute it), and done.

Images

Links

Read more

Ludum Dare is great! Not just because it motivates me to create (and finish) a new game, but also because I use it to update Creatine. So, as usual, after the compo I’m releasing another version creatine, now the release 1.0.0!

This version is big. It has a lot of new stuff and a lot of changes for the old features. But before talking about the modifications and additions to the library, let me talk about how I was felling about creatine 0.2…

To be honest, I wasn’t happy about the previous version, I added several classes to handle storage, sound, layout, scenes, among other things. But they weren’t working together, there were some annoying bugs (in special with transitions) and I was spending a good time rewriting the same base structure for new games, over and over.  So I decided to rethink some things: how can I make my development easier and faster? My conclusions and desires after that:

  • I want to use a visual editor to build my scenes, something like Overlap2D or one tool of my own.
  • I need more flexibility for fast prototypes (sometimes I just want to test some idea).
  • Modularity is cool, but is not a great deal. A class that controls all modules would be more useful and would save some time by eliminating the base common structure that I was rewriting every project.
  • I need more fluffy things, more juice, which means that have to be easy to add particles and visual or sound effects to the game.
  • I want to have a physic system and other predefined behaviors easy to use in my games (such as a platform system, or 2d top-down movement and collision system).
  • Other details that I don’t remember right now (it is Sunday 11PM, give me a break!).

With these things in mind, I started to update creatine.

Game

The main addition to creatine is the Game object. The game is now the core of my library, because it is the responsible to create and initialize all game systems. For example: it is the game that creates the canvas element; the game also stores all creatine helpers (now called managers), such as the director (SceneManager), the device,  display and many others.

The game class is based on Phaser core, so if you know Phaser you may find this familiar. A game has 5 states: ”boot”, “preload”, “create”, “update” and “draw”. In the boot state you can initialize 3th-party libraries and some configuration of the engine. In preload, you will set which files should be loaded by the engine and may be show a preload scene. In the create state you will create and initialize all game objects, including scenes and object pools. The update and draw states are the main loop, and are executed every tick. You can use these state by passing functions to the game:

var game = new tine.Game(null, {
  boot    : function() {},
  preload : function() {},
  create  : function() {},
  update  : function() {},
  draw    : function() {}
})

The first argument of the Game class is the configuration object. This could be only an url to a JSON file containing the configuration. Notice that, with this, I will try to keep all engine data-driven, so you will be able to configure everything using this parameter. Right now, it has the following default values:

{
  project          : 'creatine_game',
  width            : 800,
  height           : 600,
  container        : null,
  framerate        : 60,
  background_color : '#000',
  resources        : {
    base_path : './',
    manifest  : []
  }
}

To set configuration you can do:

var game = new tine.Game({framerate:30, width:300, height:500});

or yet:

var game = new tine.Game('myconfig.json')

where ‘myconfig.json’ is the json file containing the configuration values.

Resources and Factories

Creatine now have an interface to PreloadJS (the ResourceManager) and a factory manager. The resource manager helps you to load general assets in a more pleasant way and also helps you to load specific assets (such as spritesheets and audiosprites) in an easier way. For example, now you can set which files you want to preload in the preload state:

var game = new tine.Game(null, {
  preload: function() {
    game.load.image('id', 'src.png');
    game.load.spritesheet('id2', 'src.png', data);
    game.load.json('id3', 'data.json');
    ...
  }
});

Or you could define these assets in the manifest (pretty much like how you do with PreloadJS):

var game = new tine.Game({resources: {
  manifest: [
    {id:'id', src:'src.png'},
    {id:'id2', src:'src.png', data:{stuff here}, type:'spritesheet'},
    ...
  ]
}});

With your stuff loaded, you can create objects easier:

var game = new tine.Game(null, {
  preload: function() { ... },

  create: function() {
    var bitmap = game.create.bitmap('id', {x:100, y:400, regX:'center', regY:'bottom'});
    var sprite = game.create.sprite('id2', 'animation');
    var map = game.create.tilemap('id3');
  }
});

 

Scenes and Transitions

Scenes now have some default method that you should override to use, such as “enter”, “pause”, “resume”… To create a scene, you must define a new class inheriting the scene class, an easy way to do that is by using the new shortcut:

var MyScene = tine._scene({
  initialize: function() { ... },
  enter: function() { ... },
  update: function() { ... },
  ...
});

You can also create your scenes before starting the application and register them to the director, using an unique identifier:

var game = new tine.Game(null, {
  create: function() {
    // Create scenes here
    ...

    // Add your scenes to the director
    game.director.add('menu', new MyMenuScene());
    game.director.add('level', new MyLevelScene());

    // Run a scene
    game.director.replace('menu')
  }
});

Transitions are now working as they should be! You can use any transition in any function (replace, push or pop), repeatedly, or without having to wait the current transition.

Input handlers

We have input now! Keyboard, gamepads, mouse and touch. They don’t work together yet, but they are pretty cool already. Instead of putting code here, I suggest that you take a look into the creatine example folder and into the API documentation.

In the next releases I want to create a common Input or Control object that group all type of inputs together. So instead of checking the state of the keyboard, mouse and touch, you could simply check game.control.isDown(‘action a’) . Moreover, you should be able to redefine the input commands.

Particles!

Particles are so so so so cool! Creatine uses the cocos2d particle style. So if you want to create some fire you do:

var emitter = null;

var game = new tine.Game(null, {
  preload: function() {
    game.load.image('particle', 'assets/particle_red.png');
  },

  create: function() {
    var image = game.create.bitmap('particle', {regX:'center', regY:'center'});
    emitter = new tine.Emitter(image, 500);
    emitter.emitX = 512;
    emitter.emitY = 288;
    emitter.angle = -90;
    emitter.angleVar = 10;
    emitter.speed = 100;
    emitter.speedVar = 20;
    emitter.life = 2000;
    emitter.lifeVar = 500;
    emitter.emissionRate = 150;
    emitter.startScale = 0.3;
    emitter.compositeOperation = 'lighter';
    
    emitter.start(-1);
    game.stage.addChild(emitter);
  },

  update: function() {
    emitter.update(game.time.delta);

    if (game.mouse.isDown(tine.buttons.LEFT)) {
      emitter.emitX = game.mouse.x;
      emitter.emitY = game.mouse.y;
    }
  }

})

Unfortunately, the current particle system has some limitations. For example, it cannot change the particle colors due to performance. It also must be updated manually, sometimes I forget that!

Sounds and Storage

The SoundManager is simpler now, it does not separate music from sound effects, but you still can add sound groups to it. The coolest thing is that sound works together with the StorageManager, so when you change the volume or the mute, the sound manager stores this information locally and you don’t have to worry about that anymore!

Legacy Stuff

Some things will be changed to a better structure, such as the layout managers and the custom display objects. They are still in creatine but they weren’t updated this time.

Moar of Creatine

To now more about new stuffs in creatine, check it out:

You can also contact me for any doubt or suggestion.

Read more

Beneath The Sea is the game I created to Ludum Dare 29, under the theme “Beneath The Surface“. In this post I will talk a little bit about how was the process to create it, including all the good and the bad things that happened on the way.

icon

The Game

As all Ludum Dare games (in the solo competition), this game was created in 48 hours. Well, actually, it was around 30 for me.

Initially, I was thinking in creating a platform game using physics and tiles. The player would have to run, jump, grab and climb to make his way out from a desolated and unknown cave. I would like to related this “run-away-from-a-dark-cave” game with clinical depression and how hard is to be free from it and how easy it is to fall into this dark cave.

That wasn’t going very well. I’ve implemented the tile system using CreateJS and Tiled and integrate the physics engine. But after 12 hours, I’ve realized that it is pretty hard to create a good platform game. I mean, you have to tweak a lot of variables to make a satisfactory gameplay. To make things worse, my plan also included pixel art, but I also realized that I have no idea how to create pixel art!

So, in half Saturday, I forgot my first idea and had to formulate a plan B. Now, I wanted to create something simple, using only the mouse or a single key button, and I wanted to create something using vector art, because I can do it on Inkscape pretty well.

Last week I was taking a look into the Orisinal games, and I remembered their Silent Water, which is an example of simplicity and which I could based my game.

With these conditions and references, Beneath The Sea came up. I thought in put the player in the charge of a battleship with the task of killing the evil summons of an ancient badass god, holding them as long as he/she can. I know that this isn’t an original idea, but it was what I could do with the 30 remaining hours.

Graphics

I’ve started with the background and the core sprites because I think it is easier to see want you will need in the game – despite the fact, that is so much better to program a game with pretty graphics.

I choose to use only silhouettes to represent the battleship, the bullets and the creeps because it was the easier and faster alternative I could find. Silhouettes also have the advantage to work well with a various graphical styles.

The background was based on classical vector art tutorials, other water games, and sponge bob. If I had more time, I would make the clouds, sun and water animated. I also wanted to put some bubbles and explosion effects, but the time was short.

Programming

Programming Beneath The Sea was pretty easy. I used the CreateJS bundle and some utilities functions (such as scene management, scene transitions, layout management and flexible images) I had here. Notice that, you can only use personal code if you make it public before the beginning of competition.

The code logic is pretty simple: create creeps and make them go toward the surface; create bullets and make them go toward the bottom; check collisions among bullets and creeps; check collisions among the ship and creeps.

Then, after a long night of work, and an exhausting Sunday morning, I had the games mechanics ready to go.

Sounds

Sounds were my biggest problem. I had no previous experience on audio edition or composition and I only know how to use Guitar Pro.

As a priority, I created the main music, which is the most important audio in the game. You can’t put several sound effects without a background music! I’ve based on the Terminator theme, with a lot of bass beats. After trying several instruments, melodies and combinations, my music was complete.

For shoots sounds I’ve used drum beats amplified and equalized on Audacity. To the explosion I’ve recorded the sound me lightening a match, and slowed and equalized it on Audacity. Finally, for the overheat signal I’ve just whistled.

I hate the sound effects I put on Beneath The Sea, I had just a few hours to finish the game and I still needed to adjust the gameplay and the kongregate api.

Gameplay

I’ve tweaked the gameplay as fast I could. I added the overheating system to control the bullet flow and created a mechanism to increase the spawn rate of creeps and weapons relative to the time.

Summary

Based on my experience on this Ludum Dare, I can summarize some important things:

  • Keep It Simple, Stupid! I didn’t followed the KISS principle when I was creating the conception of the game on Friday night. As a result, I’ve lost a lot of precious time.
  • Do what you know. My first plan involved too many technologies, mechanisms and techniques that I am not familiar with. You can’t learn everything in 48 hours.
  • Take a break, periodically. The lack of sleep and fatigue are your enemies. Without sleep, you can’t concentrate very well, so you need to take some breaks periodically to rest a bit.
  • Make TODO lists. Without concentration, you lose efficiency and time, so, make TODO lists to keep tracking what you are doing. Before starting the development of the game, create the TODO of the features. Before starting each feature, make a TODO of the tasks need to complete the feature. Before each task, make a TODO of simple changes and additions to the game.
  • Prioritize the features of your game. You probably won’t finish your game, so, prioritize the core features. If you finish the important parts and got some time, then you can do the fluffy things.

Results

Check it out the screenshots of the game:

You can play Beneath The Sea on kongregate

You can see the entry on Ludum Dare

Read more

Almost all games needs to record certain information about the player progression. For example, you may want to have a local leaderboard to track the player best results of each round, or the story progression, or the name of the player, etc. Sometimes is interesting to record these kind of information even after the user closes the browser and turn off the computer, thus, the next time a user comes back to your game, the progression is saved there.

HTML5 provides a feature for this kind of offline storage, called Local Storage. The concept is similar to cookies: you have a key-value storage system and you can write or read information locally with it. It is really basic, all you have to do is:

localStorage['key'] = 'value'

and you have an information stored in the user computer. The user can close the browser and turn off the computer but when he or she opens you game again, the information ‘key = value’ is still there.

The problem is when the browser does not support the HTML5 Storage feature. When this is the case, you need to use a third party library for offline storage, store the information into some server, or don’t save the information at all. The third option is the easier (if storing information is not essential), because you don’t have to change all your code, just define a stub localStorage object and the life goes on.

A beautiful way to detect if browser supports localStorage or any other HTML5 feature is using the Modernizr library. Thus, you can add the following verification to your code:

if (!Modernizr.localstorage) {
    window.localStorage = {};
}

Take a look at http://html5demos.com/storage to see an example.

Read more

CreateJS Logo

CreateJS is a great suite of modular libraries and tools to make HTML5 games and other interactive applications. In the core of CreateJS, there is 4 libraries: EaselJS, SoundJS, PreloadJS, and TweenJS. These libraries are completely independent, i.e., they can be used isolated or even with other game libraries.

EaselJS is the main component of CreateJS. EaselJS controls the game loop, the event manager, the hierarchical organization of objects and the rendering system. It works above the canvas element, thus, providing an easy interface to draw shapes and bitmaps.

SoundJS provides a consistent API to use audio in different browsers. It works via plugins which abstract the actual audio implementation, so playback is possible on any platform without specific knowledge of what mechanisms are necessary to play sounds.

PreloadJS is used to preload all assets to your game, such as images, sounds, data, etc. It provides a complete API with an event system so you can track the loading progress and the connection fails.

TweenJS provides tween function for animations. It can be used independently and provide a simple but complete API to track tweening of object properties and chained commands.

Together with these four libraries, the CreateJS suite also comprises a set of tools to aid the game development process, from applications for exporting SWF animations to EaselJS spritesheets to code completion for editors.

Checkout the video below by the creator of CreateJS to have a better overview of what CreateJS is capable of.

Read more