Thursday, May 29, 2014

Smoke animation with Construct2

I started sketching a game for FGL's "week long game jam", and noticed quite soon that I have a game idea that would need smoke animation. I did not have previous experience how to create one, so it was time for few trials. One of them proved to be useful for me, and here is description how it was done with Construct2.

First of all, I tried different styles of "particles" or objects for a smoke. My target was to create something like volcano-style smoke, meaning that it will appear in certain point and starts ascending slowly to the sky. Simultaneously, this puff of smoke expands and gets thinner (=opacity decreases), and at some point it disappears totally. Just like in the still picture below:



I tested couple of options for creating a smoke object, and ended up something like described in the picture below:

Somehow, round shapes looked the best, but I tried cloud-like objects also. The background was light blue, so dark colors were better in this case.

Smoke object is using "Bullet" behavior for movement. Default settings are used, except speed is set to 50. Second behavior I would recommend to use is "DestroyOutsideLayout". It will take care of removing single object if it goes outside the layout area.

I created also a background scene for testing how smoke looks in real use. I was using total of 3 layers for this experiment. First I did a gradient fill using two shades of blue, and placed that to the lowest layer on Construct 2 layout (layer0). Secondly, I drafted some kind of landscape with a volcano on the right, and placed that to the topmost layer (layer2). Picture below shows how the final layout view looks.



Next phase was to animate smoke as described above. After some trial and error style working, I found out that suitable interval between two smoke objects was ~0.1 seconds (speed=50). The angle for each object is defined with random function, as well as the initial size. In my case the opacity is selected to be 100, but also lower values can be used if more transparent smoke is desired. Smoke objects are created on layer1, the one behind the volcano layer. This is just to make an impression that smoke rises from the crater.

When smoke is rising towards the sky, the "is visible" event will make it larger and more transparent. When the opacity of single smoke object is low enough (<10 in my case), it will be destroyed.

The complete event view is shown in the picture below.



You can try change e.g. angle, initial particle size and opacity, growth and opacity change rate, etc. to make this fit better to your own purposes. 

-Jussi.

Tuesday, May 27, 2014

HTML5: one build fits all?

I started evaluating new game development tools for a few weeks ago. My target was to find out which kind of tools are available for creating games for e.g. HTML5, Android, facebook etc. During the search I happened to find out that there was a Construct 2 jam ongoing at Newgrounds, and realized I did not know anything about the tool. So I installed it to my windows desktop and started to find out how it works. 

Tool itself is quite easy to use, and so far I have created couple of demo HTML5 games that can be run on almost any platform. Tests have been run without problems on linux and windows PCs (using browsers), Nokia Lumia (Windows 8 phone), and couple of Android phones. Earlier I was skeptical about the performance of HTML5 games, but to my surprise at least these specific demos were running smoothly on all tested devices.

Even if I have not much experience on developing game for multiple platforms, I have at least one guideline to share: Keep in mind what input devices you have available on different target platforms. E.g. if game mechanics requires simultaneous use of mouse and keyboard, then it won't probably work properly on touch-screen only devices (or at least player will get very frustrated). The simpler the control is, the more likely it works on different devices. 

Today I started working on small game concept that is intended to run at least on HTML5. If everything goes fine and no major issues are found, I will also make it run on Android. This is just to get experience about publishing game on mobile platform. 

BTW, there is also "week long game jam" ongoing at FGL. The purpose is to create a game on a given theme ("Burning") in one week. Probably I will try to make rapid prototype that fits to the theme and participate to the jam...

-Jussi

Monday, May 12, 2014

To mobile, and beyond!

Yes, I am still alive and kicking, although no blog postings or games released for a while. Sometimes it is a good idea to have a little break and take a closer look what you have done recently.

After releasing Explopool, I have mostly been planning and creating different game prototypes. I've also explored various game development environments and engines to get an idea what kind of tools are available. There are plenty of choices, but I have not yet decided which one to try next for releasing a game. Haxeflixel might be a good candidate, but first I have to get better understanding on it.

Stencyl 3.0 came available couple of months ago, and I've been gradually migrating to it. Android support has been the main driver for that, because I really want to go mobile at some point and Stencyl is the most familiar development environment for me currently.

Since I am running my game development activities over Linux, it's not always so straightforward to switch to a new tool or new version of previously used software. For example, migrating from Stencyl 2.2 release to 3.0 was bit challenging to do over an year-old 32bit Ubuntu 12.04 installation. There were just too many conflicts with the libraries. Finally, a successful Stencyl 3.0 installation required migrating system to 64bit Ubuntu 14.04. But now it is working just fine and I am able to run latest Stencyl on it.

I have already converted couple of my old Stencyl games for Android just to get an idea what are the pitfalls there. It seems that most of them will require some work before they are ready for possible release. Flash versions are typically running on PC hardware which has more computing power than mobile devices. So careful CPU usage optimization has not been compulsory in most of my games. Also, mobile devices have quite limited amounts of memory compared to laptops or desktop computers, and the memory usage should at least be tracked. Luckily, I have experience on creating software for embedded systems, so I have an idea how computing and memory intensive parts can be optimized so that they will run also on devices with limited resources.

I have discussed with my brother how to proceed in the future with game development. So far this has been mostly a hobby-based activity, and we will continue in the same way at least this year. However, our plan is to improve gradually the overall quality of upcoming games and publish them for Flash and Android platforms. Also, graphics has clearly been the soft spot in all our previous games, so we are seriously evaluating the possibility to get an artist to join our team...

-Jussi