Tuesday, December 2, 2014

Status update / going mobile

It's quite long time from my latest blog article, so I try to catch up what has happened lately. 

First of all, we got "Dualball" flash game released to both Newgrounds and Kongregate. For some unkonwn reason, this game was extremely hard to get ready and published. And to be honest, there were some planned features we dropped out from the released version. We just had no motivation to implement those. Also, at summertime we planned to have Android version too, but that is not on our plans at the moment. There has been some queries from flash version players for us to create mobile version, but at this point I don't promise anything.

Another change has been the slow migration from Stencyl to Construct 2. The reason for this has simply been the HTML5 capability of the latter one. Exported game can be played on almost any platform you can imagine, and the HTML5 output can be converted to some kind of "native" application e.g. for Android, iOS, WP, etc. 

Our first native Android game is progressing and it will be created with C2. The exported HTML5 is converted to apk using Crosswalk (Intel XDK). I will probably create a separate blog article to describe the process and the issues we have seen with that flow. 

During the last month I've been learning a lot: Construct 2 usage, HTML5, Crosswalk, Google Play project setup, and so on. There have been several problems with various tools, but yesterday we were able to upload the alpha test version of our first Android game to Google Play! It is still for testing purposes only, but anyways it is visible at Playstore (for limited audience, of course). :) We are hoping to get beta release available soon for wider audience. 


Wednesday, November 19, 2014

sine wave (construct 2)

Apparently, I had a need to create a scene where the X position of consecutive objects was determined with sine function. Simultaneously, objects were moving from top to bottom, keeping their X position all the time until they exit the screen.

Please see sine wave demo (html5) to get an idea what I was trying to do.

The ready-made "Sine" function of Construct 2 was not suitable in this case, because I did not want to make the series of objects to look like a worm. :)

Task is not too complicated and math it pretty easy, but anyways I decided to create an example showing my solution. Please find an example .capx file here: gamaan.com/files/sine_demo.capx

If you are not willing to download .capx from my own server, the screenshot below shows the most critical points to implement this behavior:

Basically, you will need following events and variables to make things working:

xPosDelta determines the "steps" in which the objects are created. You can try to change the value of this variable to see how it affects to the sine wave. X coordinate for each object is calculated using xPos variable:

sin(xPos)*100 + 200

Where 100 is amplitude and 200 the offset of sine wave. You can also try to modify these to see how sine wave changes.

When object is created, xPos is increased by xPosDelta. If xPos > 360 (full circle), then the value of xPos is resetted to initial value (2*xPosDelta). This is just to keep sine wave continuous.

"Bullet" behavior is required to implement vertical movement. I also added "DestroyOutsideLayout" behavior to make sure that objects are destroyed when exiting the screen.


Friday, November 7, 2014

"DualBall" released

This is just to inform, that "DualBall" flash version was released yesterday to Newgrounds (click picture to access the game). Judgment process has already been passed, and users have rated the game to 2.88 stars (out of 5) currently.

But it is a bit different story if this was worth all the effort.

For some reason, this game has several setbacks during the development process (HDD failure, migrating from Linux environment to Windows, some lack of motivation, lost asset library, etc.). Anyways, we were able to finish and publish this game.

We started developing this game somewhere in the beginning of August. I had an obsession to try how two objects could be controlled by turns using just one mouse button (or touch on mobile device). Even if I have not yet released any mobile games, I have spent lot of time thinking the UI for them. Anyways, when you are planning a game for mobile devices, you should keep in mind that controls should be as simple as possible. There is no keyboard attached in most of the touch screen devices, so in most case it is wise to limit input according to that.

So from this kind of a starting point we launched the development of "DualBall". :) Original idea was to make both flash and Android version using Stencyl, but at some point Android version was dropped out from the plans.

In practice game is working well on my tablet, but my current plans does not include buying the Stencyl license. I have already acquired the license for Construct 2, and it should be enough at this point. But if it turns out that there are tens of thousands of players for this game in Newgrounds, then I might consider the mobile version. :) 


Tuesday, October 28, 2014

Detecting the input device (C2/HTML5)

While getting familiar with the Construct 2, I started to wonder would it be possible somehow detect what kind of a device is used as an input device for HTML5 game. In principle, HTML5 will run on almost all platforms, so it would be very useful to see whether the player is using mouse or touch screen as a input device.

I created a simple Breakout game clone to find out how the control method could be detected easily. You can load the Construct 2 .capx file from our server, if willing to see the full example game and want to try it yourself.

Breakout clone

Game is very simple one, and it has no extra features included. I also tried to add some comments to ease up understanding what has been done and why. I am not too sure if everything is done "correct" way, but anyways this example is working somehow with my own devices (Android tablet, Lumia phone, Linux and windows computers).

Game events 2-4 are the most interesting ones from this article point of view. Please see the .capx or the picture below to see how detection was done in this case.

Detect whether mouse or touchscreen is used as input device

controlMethod variale is used to store the information about the input device.

When game is in "init" state game will wait for user input. If Touch event is triggered, game gets hint that touch screen is used as an input device and controlMethod variable value is set to "touch". Mouse detection works similar way, except it is triggered by mouse LMB release and controlMethod variable value is set to "mouse".

After mouse is clicked or touchscreen touched, the game will move to "run" state and ball starts moving. Bat object is moved horizontally towards the targetX X-coordinate on every tick. controlMethod variable is used to decide whether the bat targetX position will be based on mouse cursor position (Mouse.X), or last known touch position (Touch.X). Details can be seen from the .capx project file or the figure below.

controlMethod variable usage in "run" state

So when the gameState is "run", loop is executed on every tick (approx. 60 times per second). When mouse cursor (of touch) is between left and right boundaries, targetX value will be set to Mouse.X or Touch.X, depending on the value of controlMethod variable. If cursor (or touch) is not between the boundaries, targetX is fixed close to left or right boundary.

Bat movement is done in events 11-14, using the "bullet" behavior. Nothing special, just defining the bat direction and then enabling/disabling the "bullet" behavior as needed.

That's it. I hope this example is useful for you.


Wednesday, October 8, 2014

Example Construct 2 game (html5)


I received some questions concerning my previous blog post on Construct 2 if-statement. Therefore I decided to put the project file (.capx) available to everyone who needs it. This game is very simple one, but I think it is just suitable for getting familiar with the tool.

Load Construct 2 capx file for "shootTheBox" game.

The HTML5 version of game can be found from our server.

shootTheBox.capx file usage

You will need Construct 2 for opening this file. Free version can be downloaded from https://www.scirra.com/.

.capx file can be opened by double-clicking it, or alternatively from C2 menu (file -> open).

shootTheBox game events

Since this is a simple game with just one layout, there is only one event page too. The screenshot is attached below. I added some comments to describe what each event block is supposed to do.

shootTheBox in Construct 2 event editor (with comments added)

There are handful of global variables in this game. One of them is the "gameState" variable, that holds the information whether the game is in "init" or "run" mode. In "init" mode game is not running and "Click to Start" text is visible.

When mouse is clicked (or screen touched) game state changes to "run", and game starts to spawn coins and boxes on every second. The starting location of coins and boxes are defined by using random() function. Box color selection structure is explained in detail here.

If mouse cursor is over a box and it is clicked, the box is destroyed and Score counter is increased by 10 points.

If coin hits a box, the coin is destroyed and Lives counter is decreased by 1. When lives run out (<=0) game ends and state is changed to "init".

The values of score and lives counters are updated to HUD on every tick (about 60 times per second).

There are certain behaviors attached on box and coin objects, e.g. bullet, destroy outside layout, sine, etc. The parameters can be tuned by selecting the object and then using the panel on left hand side of the screen. 

That's it. I am sure I missed something, but please have a look to the contents of .capx file, make your own modifications, and try how the game works with them.


Tuesday, October 7, 2014

Construct 2: if-then-elseif-else statement

Do you have an idea how to implement IF-THEN-ELSEIF-ELSE statement with Construct 2? At least I had to think for a while how to do it. It seems that this basic structure is not so straightforward to implement in C2.

I was creating a very simple game where boxes were moving from left to right. See example below:

The color of each box is chosen randomly, so it required the usage of random() function and if-then-else statement. There are probably several ways to do this, but I wanted to make this as simple as possible inside one single event and action box. 

Normally I would create a if-then-elseif-else structure like this to select color for the box (pseudo-code just for an example):

if randomNumber == 0
      set colorOfBox = "red"
else if randomNumber == 1
      set colorOfBox = "yellow"
else if randomNumber == 2
      set colorOfBox = "green"
      set colorOfBox = "blue"
end if

But when using Construct 2 things were bit more complicated for me: tool is event based and I don't have deep knowledge about the possibilities of it. So I decided to find out a solution that fits for me.

In my implementation the output of random(0,4) function was stored to randomNumber variable and the color of the next box to be created was chosen according to this table:
value  color
  0    red
  1    yellow
  2    green
  3    blue

If you want to use if-then-else statement in the parameter field of some action box (like Animation field inside Set animation action), the syntax to be used is like this:
condition ? if_true : if_false

For example, the return value of statement is set to "true" if a<10. Otherwise return value is "false":
a<10 ? "true" : "false"

As you might notice, the statement above implements just the regular if-then-else structure. But how to make the "else-if" part, if such is required? My answer is to use nested statements, so if-then-else structures are chained like in following figure:

Interesting part is surrounded with red box. There are total of three chained if-then-else statements, which will select the color of the box according to the value of randomNumber variable (see the table above). The else branch of each if statement will be executed if the condition is false. True condition will return the value from "true" branch. I tried to clarify this a bit with the following figure:

Figure shows how the randomNumber value is checked in the if-then-elseif-else statement. Different stages of statement are marked with different colors.

If the value of randomNumber is 0, the color of the box will be red. If value is something else (not 0), execution moves to second stage and will check if the value is 1. If that is true, then the color of the box will be yellow. If value is still something else than 0 or 1, the third statement checks whether the value is 2. if that is true, box color is green. Any other value will make next box to be blue (This is so-called "else" -branch, that covers all condifions that have not been met in previous stage).

Everything is done inside one event, so my target was achieved with this solution. There are probably more clever ways to do this, so please let me know if you know one. :)


Thursday, October 2, 2014

Testing and polishing

I've been bit busy with my daily work for last couple of weeks, so gamedev activities have got less attention than normally. But still there has been some progress since my last update.

My original plan was to finish and release "Dualball" flash game in the end of September, but now it seems to take some more time. Game itself is in pretty good shape: the mechanics works, there are no detected major flaws currently, and 75% of planned levels are ready and tested quite well. 

We have done thorough testing ourselves and a number of serious bugs have been found and corrected during the process. Gameplay tests have been run on both computer and touch-screen tablet to get some extra coverage. It has been interesting to see that some bugs are not easily visible on both platforms: E.g. "ball ground check" routine worked fine on computer, but on tablet there were strange malfunction with it. So I strongly recommend you to test your games on multiple platforms in early development phase also, if possible.  

I have tried to have more focus on graphics than with my previous games. So most of the sprites, backgrounds and UI buttons are ready-made open-source assets found from the internet. 

Here is the latest preview video of "Dualball" game:

Video has been captured using my Linux laptop that clearly has not enough computing power for the task. So the framerate and quality is not the best possible. But anyways, I believe you will get the idea. 

Now it seems that this game will be released just for Flash. I will probably skip the Android version, because it would require buying the Stencyl Studio version and I have already decided to switch to Construct 2 tool after this project. 


Sunday, September 14, 2014

Turbomole statistics update (part 2)

I am sharing one more chart showing the daily "Turbomole Trial Run" views over last 61 days. So it's about 2 months since we released this flash game to Newgrounds.

Total number of views is at the moment 46082, so there has been in average 755 views per day (source of data: Newgrounds Statistics). The number of daily views has varied between 35 and 3620. I am pretty happy to these figures, because two months ago we were expecting no more than 5000 views in total.

Ad revenue has been very modest for "Turbomole". There is just one ad shown before title screen, and that's all. I didn't want to irritate players with large number of ads, so there are no between-scenes ads at all in this game. Also, the eCPM seems to be quite low for flash ads. Pre-roll ads would provide better eCPM, but the number of those has been disappointingly low...

What makes the chart interesting is the recovery that has happened couple of times: The number of daily views has first declined close to zero, but then for some mysterious reason it has recovered again. I have followed Newgrounds statistics data on daily basis to get an idea why this has happened. It seems that these "peaks" have occurred because of new sites have taken the game to their list. This has enabled new players to find the game and it can be seen as peaks in daily views chart.

Currently, there have been total of 97 hosts sharing "Turbomole's Trial Run" game (according to NG statistics). In practice, 90% of all views have generated by 6 hosts. It seems that most of the audience has been located at Japan, Turkey, and South Korea. Rest of the world has ignored the game so far.

Based on this information I think it is very important that you find the right websites to spread your flash game. But it is an another story how to find them. At least I don't have direct answer to that.


Tuesday, September 9, 2014

"Dualball" the Game

We have been working on two separate game projects in parallel. Now one of them is in quite mature condition and it is likely that it will be published in a couple of weeks. So it maybe is time to shortly introduce the game concept?

Working title for the game is "Dualball". This is a platform game where player controls two balls at the same time with single click (or touch, depending on the device). The challenge comes from the parallel nature of this game: you must be able to do some multi-tasking and time your clicks correctly. Timely performance is rewarded with coins that are spread on the levels. Collecting all coins is not always straightforward, and you have to carefully think what kind of a sequence is required to clean up the level.

We have been testing "Dualball" on flash and Android platforms, and it seems that the latter one is bit more convenient for this concept. However, game will be released in flash format first. Android version will follow if there is enough interest to this concept.

Originally this "Dualball" was started as some kind of a technology trial where we tested parallelism and simple controls. One development branch was to try loading levels directly from our own server. We also created a level editor that was running on Excel and Libreoffice. Levels were written out in .csv format, to keep things as simple as possible. Basically all server/client stuff worked quite fine, but there was some performance issues visible and we decided to leave loadable levels out from this version. But this is something we definitely can use in our future projects.


Sunday, September 7, 2014

Creepy carrots for Mole (video)

I created today the following piece of art:

As you can see, this is not a gameplay video at all. However, it is loosely related to our "Turbomole Trial Run" game (_very_ loosely!).

Just look the clip and enjoy! And you can of course start following our Youtube channel too. :)



No matter how simple your game is, or how well you plan it. In any case it is 110% sure that there are several bugs included in your masterpiece. And fledgling game developer surely has more bugs than the experienced ones. :) Here are my thoughts of this matter.

Major and/or often occurring bugs are usually very easy to detect, and they are relatively easy to find from your code. You just need to find (or know) where certain functionality is located in your code and check the difference between desired and existing operation. Fixing the bug might not be so straightforward, but at least you know fairly well where the fault is.

But then there can be very nasty bugs that occur rarely or even randomly. Sometimes it is very hard to understand if some behavior is really a bug, if it can't be easily reproduced. And locating these bugs from your code is very difficult if you don't have clear idea where to look for them.

Luckily here are some ways to ease up bug hunting. I am using very often a method where variables likely to be related to the bug are simply printed on the screen continuously. Then it is possible to see how variables behave during the gameplay and that helps so resolve the problem. The method of implementing this approach is tool-dependent, but it should be possible no matter which gamedev environment your are using.

Game development tools migh also have different ways to ease up debugging. I have found out particularly useful the feature where collision boxes are made visible. Each collision can be seen visually during testing when that feature is on.

In general, debugging a game might require a large amount of creativity and ingenuity. There are some ready-made solutions available, and using them may make your life easier.


Sunday, August 31, 2014

Youtube "Fan Finder"

Today I decided to create an introduction video for Westsloth Games Youtube channel (or rather, I practiced to do some kind of a marketing video).

The work was done using the proven quick&dirty method, meaning that I dug out some old gameplay videos and screenshots of our previously published games, and edited the video using the Kdenlive software.  Resulting video can be found below:

There is a feature called "Fan Finder" ("Fanimagneetti", in Finnish) available at Youtube. It enables you to display your video as a trueview ad for no extra cost. I added the video above to this service, so let's see how this works...I don't have any big expectations at this point. 


Friday, August 29, 2014

Android back button usage in Stencyl

By default the back button of Android device sends the active application to back. However, in many mobile games back button is used e.g. to return to the menu (or any equivalent action). This is possible in Stencyl also, but you have to configure the behavior first to match your needs. Here are simple steps to do it:
  1. Go Settings -> Mobile -> User Input
  2. Activate "Override Back Button". This makes back button to act like escape key
  3. Go Settings -> Controls. Check escape key bindings (name: Escape, Key:Escape)
  4. Open your game scene and go to "events" tab (or edit behavior)
  5. Create keyboard event for escape key, as shown in Figure1 below (Add Event -> Input -> Keyboard). Set control as "escape".
  6. Add transition block and fill in your menu scene name + other required information
Figure1: Keyboard event for escape key

That's it! Now you can exit from your play scene to menu screen. 

But wait, did you forgot something? Yes, Since the default action of back button is now disabled, you can't exit the game normal way. So we probably have to do something for this. Here is one way to implement exit behavior with nme.lib.exit(); function from NME framework:
  1. Open your main menu (or any scene you might want to exit the game)
  2. Add "Import" block to the scene: Add event -> Advanced -> Custom Import
  3. Write "import nme.Lib;" to the Code field as shown in Figure2 (imports NME framework)
  4. Create keyboard event for escape key (Add Event -> Input -> Keyboard). Set control as "escape".
  5. Add code block to the event (Select from palette: Flow -> Advanced -> Code )
  6. Write following to code block (see Figure3):
    #if android
This code makes game to exit when back button is pressed on Android device (not active on other platforms)
Figure2: The "Import" block for main menu (or equivalent)

Figure3: Code that is executed when escape is pressed

Now we should have nicely working back button in our Android game, assuming I did not forget anything....


Thursday, August 28, 2014

Android video capture issues

Edit 13.7.2017: This article is bit outdated, because nowadays Android Studio provides tools for recording video from Android device. And also Google Play Game Services app has a way to record your game directly. 

I tried to find video capture program for the Android tablet to get better quality gameplay videos from our own game projects. Unfortunately, it seems that there are not so many solutions available, or at least I was not able to find any suitable for my needs. 

Most of the Android video capture tools seems to require rooting, and I was not willing to do that right now. As far as I understand rooting will void the warranty (according to this article), and my Tab3 is approx 3 weeks old. So it was very easy to decide that rooting is not a solution here.

There were also some video capture tools that were told to be "no-rooting-required" (according to their developers). But I did not manage to get any of them working in my tab. I also found couple of tools to be used with computer + USB cable (in developer mode), but I had problems to get them running without problems (maybe it's my Linux laptop?).

I decided not to install any video capture tool to Android tab. Instead, I installed a tool called "simplescreenrecorder" to my Linux laptop. After that it was very quick and easy to create flash version of game and record a short clip of "dualball" gameplay. I will get back to Android screen recorder sometimes later, because I really would like to get some videoclips also from tablet. 

Anyways, the resulting gameplay clip is attached below. 


Dualball game concept (preview video)

We have been working on two new game concepts for a while, and introduced the preview video of the more mature one for couple of days ago.

At this point game has a working title "Dualball" and that describes quite well what the game is going to be. In short, the target of the game is to control two balls with single button (or touch, depends on the device). There are lots of obstacles and traps inserted to the route and balls should be steered past them. Naturally, rewards are not forgotten and there are certain number of coins on each level to be collected.

Basically "dualball" is very simple and easy to play game. The challenge comes from the fact that player has to keep two separate objects in control using single click (or touch) as an user interface. It is far more difficult than you would think in the beginning!

Currently, we are generating more levels to the game. Target is to have 24 levels in the first official release later this year. As you might guess, there is also lots of polishing and optimization to be done. One pain point will be the quality of graphics (what a surprise!), but we are trying to use ready-made assets where we can.

We are still using Stencyl for game development, so the target platforms are limited to flash and android for the first release. Other platforms will be evaluated later, if it seems that there is enough interest to this game. 


Friday, August 22, 2014

Turbomole statistics update

Here's the latest chart showing the daily "Turbomole Trial Run" views over last 38 days.

Total number of views is at the moment 36105, so there has been in average 950 views per day (source of data: Newgrounds Statistics). Still going strong, although the momentum is gradually slowing down.

I decided to publish this game also on Kongregate, because it required very minor modifications. Basically, all I had to do was to remove Newgrounds API stuff and replace them with Kongregate equivalents. Since game was created with Stencyl, it was just matter of removing some blocks and selecting the new ones from the list. Another thing to do was to setup the Kongregate Statistics for the leaderboard implementation. And, of course, you had to remember add the block called "Setup Kongregate API" in the startup scene, to make sure that everything works as expected.

BTW, there has not been too many views yet on Kongregate, but at least one comment was already received:
"Actually a really fun game. Needs work on the art though! Should be called turbo potato as well! (Greatolded)". 

As I have mentioned before, we really need to consider if it would be possible to get an artist to work with us in future game projects. Currently, I see that as the only way to improve the visual side of our games. But the main problem is that we do games as a hobby, so we are operating with zero budget. Free assets from different "open-source" collections in internet might also be a choice, but let's see...


Monday, August 18, 2014

Fledgling game artist...or not?

Most of the negative feedback on our games has been related to the poor quality of graphics and/or animation. I have to admit that these comments are appropriate: Our gamedev "team" currently has no artist at all, and actually all graphics are so far been drawn by me. And I'm really bad at drawing.

Anyways, there has been a need for graphics and animation in our games. So I have tried learn to draw at least something using Gimp, Inkscape or Aseprite. Tools itself are not an issue here: there are plenty of tutorials and online manuals available. But even if you could use all tool features perfectly, it does not help a lot if you have no eye for art.

I thought at some point that pixel-art would be a solution for me, and I dug out this tutorial: Pixel Joint forum: Creating Pixel Art. Basically this tutorial was fine and everything was understandable, but I did not have enough perseverance to follow the guidelines. The theory of anti-aliasing and dithering was quite clear, but using them in real drawing was something I was not able to understand fully. :)

I am sure that it is possible to improve graphics skills by practicing and practicing. But at the moment I don’t have the time nor the energy to to learn one more completely new thing for me. My game design and implementation efforts takes enough time currently, and I also work full time elsewhere.

But what we can do to improve the visual quality of our games? Well, I have couple of options in my mind:
  1. We start using ready-made assets from internet or gamedev tools’ asset stores. There seem to be several sites offering large variety of assets, but the problem is that it might be difficult to find exactly the specific asset you are looking for. So you probably have to compromise.
  2. We will try to find a suitable, visually talented person to join our team. The challenge at the moment is that we are doing gamedev as a hobby, so everything is done on zero budget and no-one gets paid (of course, the possible ad revenue will be shared fairly).
I guess we will try to find a suitable combination of these two options during next couple of months. 


Wednesday, August 13, 2014

Flash game statistics

The updated version of "Turbomole Trial Run" flash game was released to Newgrounds about 4 weeks ago, without much expectations. However, today game exceeded the limit of 30000 views, which is in our opinion pretty good achievement for game like this.

I have to admit that I have no idea what is the typical number of gameplays for the average flash game. However, the predecessor games "Turbomole Xmas Run" (Dec 2013) and original "Turbomole Trial Run" (Feb 2014) were released using already deceased MochiMedia's distribution network. In principle it was possible to get game distributed to thousands of flash sites. But in the end the number sites was something between couple of tens and one hundred for both of these games. The life span for Xmas version was about 2 weeks, and for normal version bit more than a week. Also, the number of players was around couple of hundreds for each of them. So, nothing special to mention with these ones.

For updated Turbomole version we did just some minor polishing, and most of the graphics was identical compared to the previous versions. Also, the number of levels was excactly the same than in the Feb 2014 version. Biggest changes were the update of background music and sound effects and the look of dialog windows.

Anyways, game was released to Newgrounds 15th July and here is the chart about the daily views over last 4 weeks.

First couple of days were quite typical for our flash games. But on the fourth day Turbomole found it's way to 7k7k.com game site making the number of daily views exploding. For some still unknown reason thousands of players started to play the game, and we were amazed.

The situation normalized after an week and daily numbers of views was less than 100. We were pretty sure that game had done it's job and the number of daily gameplays sinks close to zero. But then flonga.com added turbomole to it's list, and two days later game was found also on oyunkolu.com. These sites caused second rise in the chart, and the total number of views exceeded 20k.

Third peak started yesterday and this time it was caused by oyuncini.com. Today's figures are still counting, and it seems that the number of views is clearly smaller (~1000 views). There are still two questions left: how long this peak will last, and will there be new peaks in the close future? We look forward with excitement. :)

One interesting fact is that there has been barely 1500 views in Newgrounds, and >95% of all traffic has come outside from third party sites. Respectively, advertising revenue has been very modest (around $2.50 at the moment). I guess that's because most of the gameplays have come from low eCPM countries, and in general NG flash Ads seem to have low eCPM too. Pre-roll Ads would bring a lot more advertisement income, but those are shown quite rarely (as far as I know). Actually, I am not too sure if those are shown outside NG at all.

Anyways, big thanks for you all who have had time and interest to try Turbomole game! We are currently considering new release, but at the moment other game projects are taking all available time. Maybe later this year, let's see...


Tuesday, July 29, 2014

Unity3D, getting to know the tool

As most of you may know, Unity3D is a kind of "industry standard" game creation tool at the moment. I have the impression that it is versatile, reliable and generally works for people making games. And there seems to be very large and active user base for that.  But on the other hand it seems more complex to use than most of the 2D game creation tools I have tried so far. So there might be a little bit higher threshold for starting gamedev activities with Unity than with some simpler development platform.

However, My own experience on Unity3D is very limited: I have implemented just few demos for almost two years ago. At that time my gamedev efforts were just starting and I had no clear idea what I was doing. But somehow I managed to get something game-like up and running with Unity. :)

So far Stencyl has been my number one tool for developing games. All my released titles have been relatively small and simple, and the target platform has been flash (just to keep things simple). So from my point of view Stencyl has been useful tool for my purposes.

Currently I am exploring the possibilites of html5 based games, because I see them as a natural continuation for the flash. Also, there are several promising tools available for generating html5 games. But my longer-term plan is to take control over Unity3D, just at least to get an idea what large part of the gaming industry is using to create their games.

Using the tool fluently will certainly require a lot of learning, but I believe it is worth the effort. I already found very promising-looking set of Unity2D video tutorials from Youtube, so I probably start my exploration with these. After that I can probably try to get something small and simple working with Unity.

Edit 31th July 2014: Oh, just forgot to mention that couple of years ago I used Unity Training (Free) from Walker Boys Studio to get familiar with Unity3D. Worked at least for me. 


Tuesday, July 22, 2014

Planning and prototyping

It is hard to know without prototyping how game concept would work. So during the past week I have built several prototypes to find out if I have something useful in my mind.

This process takes some time, but at least for me it is important to get some kind of a visualization how things work on the screen. Static modeling with paper models, sketch drawing, or even using Lego bricks may also help to visualize game mechanics or rules, but I need to have something more dynamic to see the full picture. At this point, few ideas seem to be better than others, so they probably are worth further development.

Although we are planning to move gradually out from flash games, it seems that we will still create at least one new game for that domain. The reason for this is that we know the tool (Stencyl) quite well and we are also familiar publishing flash games through Newgrounds and Kongregate. Publishing games to mobile and/or HTML5 is mostly unknown territory to us, so why not try to stay within our comfort zone for a while? :)

Anyways, I think we have to take a leap to unknown at some point and start to explore other platforms in near future. At the moment HTML5 sounds most promising for us: There are available several game creation softwares that can export your game in HTML5, and exported games will run on several platforms (mobile and desktop). For example, according to the FGL's developer earning stats HTML5 is fastest growing segment for FGL. So there are also commercial aspects supporting that.

We had plans to make new versions of couple of our previously released flash games, and this process was started bit over an week ago. Unexpectedly, that was a good decision: Turbomole Trial Run flash game has got surprisingly large number of players during the first week, especially on 7k7k.com. At the moment, the total number of views is bit over 12000 and it is still growing steadily. But let's see how long this lasts. We had initially some discussion on creating new levels to the Turbomole, but we have decided nothing yet. Another option would be create a sequel with much more levels, improved graphics and so on. But that would be a bigger project then.


Wednesday, July 16, 2014

Turbomole released

Ok. After lots of debugging, fixing, and other hassling we finally got Turbomole Trial Run flash game reproduction published at Newgrounds. Although to-do list was quite short for the day (only 3 items left), it took surprising amount of time to sort everything without breaking anything.

The judgement phase was passed quite fast, and during the first 7 hours there were over 300 views. Average rating is currently around 3/5 stars (about the level I was originally expecting). Gameplay seems to be working and major flaws have not been found (yet). Also the level design is quite ok at least from our own perspective.

It seems that sounds share opinions, but the current solution is about as good I was able to arrange within this schedule. For background music I was using "Fun in a Bottle" downloaded from Kevin McLeod's "Royalty Free Music" pages. All sound effects were created using the laptop microphone and Audacity software, so there might be some strange noises and poor quality in them. Apologies. :)

There are still lots of things in this game I am not satisfied with. First of all, the graphics and animation is as terrible as it was when we originally created this game. As you might guess, we are not experienced at all creating decent level graphics. So the visual look is as bad as you could expect. Secondly, there are too few levels in the game at the moment. However, we decided to start with current 16 levels and surely will create more if it appears that there is real need for them (=enough players in NG). There are also few very minor bugs left, but luckily those are very hard to see when playing the game normal way. :)

If interested, please have a try and give your rating via Newgrounds. :)


Tuesday, July 15, 2014

Game update: "Turbomole Trial Run"

As defined in the "roadmap", we decided to make updated versions from our two flash games. Because the plan was made and the work seemed to be quite straightforward, I started evaluating and updating "Turbomole Trial Run" flash game. 

Game was originally created with Stencyl and published using the Mochimedia distribution network. I had no intention to do everything again from the scratch, so I dug out the latest development version from my backup disk and started to explore how game was implemented about half an year ago. I have to admit that my old "code" (i.e. Stencyl blocks) is not too easy to understand, mostly because of the bad "coding" style and missing commment blocks. But anyways I got an idea what I've done before, and started planning the modifications. 

First task was to remove Mochimedia API blocks out from the game, and replace them with corresponding Newgrounds stuff (leaderboard mainly). I also started new game project at Newgrounds to get an API ID and encryption key. Then it was time to make some playtesting to get an idea what could be done better. 

"Turbomole" game itself works as before, and we did not find any major flaws at this point. But there was still something to be improved: the original background music was annoying, and I replaced that with a fresh one from Kevin McLeod's collection (incompetech.com). I hope the new one will last longer. :) 

After replacing background music it was time to re-evaluate other sound effects. I replaced couple of them with "better" ones, and currently I am quite happy with them. I wanted also make sure that muting the music and sound effects works fine, and noticed that there were something wrong with the original implementation: it was not 100% sure that music started playing every time and there was also some uncertainty how mute buttons worked in the original version. So I re-created the mute behaviors and added buttons to the HUD view of the game also. During the implementation work I found out that there is an easy way in Stencyl to make an object to disobey a camera: just use the "anchor <object> to screen" block, and that's it. I have done this in the hard way in the past, so now I learned something new. :) 

Currently, there are 16 levels in the game. You have to pass a level to be able to play the next one. The original implementation was done so that it was not possible to replay level after passing it without going to the menu first. It just came to my mind that someone might be interested to play level again to get the maximum possible score. So I added "replay" and "continue" buttons to the "level completed" dialog to make the game experience a little more comfortable. 

We did playtesting after every modification and at some point found a major problem in one level: mole was stuck somehow between the obstacles and the edge of the screen. To fix this I had to resize level a bit and after that game was working fine. It is still a mystery why this happened, but I think the root-cause can be found from the modifications I did during the evening. So maybe I spend a while looking at the game logic and try to find out what happened there. This just to be sure that similar problem does not occur in some other level after releasing the game. 

At the moment the to-do list for "Turbomole" is quite short:

  • general playtesting to make sure that everything works fine
  • check that replay/continue functionality works as expected
  • add few NG medals
Game will be released to Newgrounds after these tasks are done (probably this evening). 

Original idea was to add more levels and do general polishing to the gameplay and visual outlook. But I think we will release the game to Newgrounds maybe today and see what kind of comments and improvement ideas we get from players. It is very straightforward to add levels to this game afterwards, so they can be added as they are done and throughly tested. 


Sunday, July 13, 2014

Gamedev plans

First part of my summer vacations is over, and tomorrow it is time go back to work. Luckily, I have still one week vacation left in the beginning of August. :)

My game development activities have also been quite minimal for last couple of weeks. However, there is a small exception: I've been discussing with my brother how our gamedev activities should be continued for the rest of the year. And as a part of this process we have tried to sketch a roadmap for upcoming game releases. I work full-time in large telecommunications company and all my game development is done in leisure time, so there is a clear need for some kind of a rough plan to keep things progressing smoothly.

First of all, we have a plan to release three html5 games in the next six months: Two smaller ones and one large one. Smaller games are planned to have relatively simple graphics and gameplay, so we are able to finish them ourselves quite smoothly. There are already technology demos up and running for both of them, and we expect it takes approximately couple of weeks to get each of them ready for beta test phase.

The large game will be bigger and more complex than any of our previous productions. The working title for the project is "Silent Samurai" (final name will be decided later), and we are currently shaping the background story and will start developing a prototype for testing intended gameplay. Apparently, there will be lots of new things to learn, and we expect that graphics and animation will be a real challenge for us with this game. But I believe we will figure a way to get past all obstacles. 

All games will be created using Construct 2 tool, and they will be published at least for html5. The need for other versions will be evaluated case by case. I have also plans to test other gamedev tools, and I am planning to make trials and small demos at least with Unity3D. 

In parallel to the new html5 game projects, we have decided to do updated versions of two of our old flash games:

Both games were originally created with Stencyl and they were published using the deceased Mochimedia distribution network. The target is to add more levels, and do general polishing to the gameplay and visual outlook, if possible. Updated versions will be released as flash games to Newgrounds and/or Kongregate. 

On top of game development there will be several tasks like maintaining and updating our social media profiles at facebook, google+, twitter and so on. And of course the homepage of Westsloth Games is likely to be changed to more positive direction.

Oh, almost forgot to mention that we have some new hardware available e.g. for testing html5 games: We bought last week a Wii U game console and Samsung Galaxy Tab3 (10.1" LTE). Both of them seem to be running html5 games created with Construct 2, so this may open new opportunities for us. :)

This is our current plan, and progress will be tracked in this blog regularly. So be tuned! :)


Thursday, June 26, 2014

Post-mortem: Soccer Breakthrough

I decided to write some kind of a post-mortem analysis for "Soccer Breakthrough" flash game we released around 21st of June to Newgrounds (and Kongregate).

Overall rating for the game has been 3+ stars at Newgrounds and 2+ stars at Kongregate. But there has been huge variation in ratings from different players: Some players have liked game a lot because of it's simplified gameplay and medal system. They even have encouraged us to continue same way with future games. But then there have been several comments concerning the lack of realism, the fact that game gets boring quick, most of the sounds are irritating (in fact, they are), and so on. I have even received direct requirements to change literally everything in the game. Yippee.

Soccer Breakthrough was originally intended to be a HTML5 game with very simple gameplay and simplified graphics. However, we had very tight schedule because of my holiday trip, and we decided to make this release with Stencyl because it was more familiar for me (=faster to finish a game). We never thought to be doing a realistic football game, but rather a small game where player has to dodge other objects in the screen. And for some reason we selected soccer theme, and the rest is history. :)

It seems that this game attracted mixed feelings and aroused deep feelings. I believe the reason was that there are strong emotions associated to the soccer, and some people are in the game so seriously that our version may seen even sacrilegious to them. But my opinion is that game that evokes wide range of feelings has achieved it's goal.

In fact, I had several improvement ideas for this game just before it was published, but I had no clue how to implement them smoothly to the existing frame. So I agree that in it's current form game is not as good as it could be. Anyways, I think at this point I am not going to change anything to the game. I will rather make the sequel (or two) for the game and take comments into account, if applicable.

In general, any feedback is good, so please keep on rating games you are playing! It helps a lot when drafting new game ideas.

And remember: if you do a football or soccer game, then do it properly! :)


Edit 2.7.2014: some minor fixes to the text. 

Sunday, June 22, 2014

Soccer Breakthrough

Alhough I've been creating game prototypes with Construct 2 for last couple of months, I decided to do yet one more flash game with Stencyl. I am not too sure what was the original reasoning behind that decision, but anyways the game was published today.

"Soccer Breakthrough!" is currently available on Newgrounds. Game has leaderboard and also medals (or achievements, whatever). Now I just sit and watch how our little game will please gamers. I am also planning to create HTML5 and mobile versions of this game, but before that I will carefully analyze how flash version will do on portals. 

My vacation period started yesterday, and for next three weeks I don't have to think about System-On-Chip design at all. So I might have some more time for game development. But now I am having at least one week without any work or game related activities, and try to recover from the stressful last days at work...


Monday, June 2, 2014

Jam entry

As mentioned in previous blog article, my target was to attend FGL's "week long game jam" with one idea. However, after four days of work I realized that I am not able to make the game as playable as I wanted to. So I decided to freeze development work, and quickly drafted a new concept that was possible to get to up and running in less than one day. 

In practice it was ~7 hours before deadline when I started creating the game. But the development work went quite smoothly without any problems, and in the end I got the game ready in 5 hours. So there were still some margin left. :)

It works best with some touch-screen device supporting HTML5, but you can try it also with computer+mouse combination. You can find game also from FGL, if you have account there. 

Next step would be to polish the graphics and make some improvements to the gameplay.

Edit 7.6.2014: No special success in jam, but got some valuable feedback how game could be improved. The most important thing for me was to get game into such a condition that I dared to enter the jam. Thanks for all participants, you did great work! :) 


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. 


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...


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...


Wednesday, March 26, 2014

Stencyl and Newgrounds

Since Mochi Media is winding down the services in the end of March, I started to look for alternatives for publishing and spreading my own flash games.

Previously, I have posted couple of games to Kongregate just to test the flow, but there has been only handful of players for each of them (with zero marketing). However, I also posted Explopool to kong for a week ago, and this time there has been enough players to get the ratings visible (2.7 / 5.0 stars at the moment). Clear progress, I would say. :)

I have heard stories about Newgrounds and how demanding the audience is there. So it has been bit frightening choice for the fledgling game developer who is unsure about his own skills. Nevertheless, I decided to make a Newgrounds version of Explopool (with scoreboard and ads), and test how game publishing flow works there.

Basically, integrating Newgrounds API to game made with Stencyl was very easy: Just create game project at Newgrounds and copy the API ID and encryption key to Stencyl advanced settings. After that ads and scoreboards are available with ready-made Stencyl building blocks. It is just as easy as integrating Mochi features to the Stencyl game.

After I was convinced that I had not broken anything in my game, I did the required setups and uploaded swf to Newgrounds. Then I performed final playtests in preview mode, did some sanity checks, and after pressing "submit" button game was available for audience in judgement mode. This means that players can vote whether new game is added to the collection, or if it is trashed and deleted forever from the system. But believe me, it is somehow exciting to follow how many stars your game will get from the first visitors. :)

In Explopool's case judgement phase went quite well. After some hours there had been couple of hundred players and rating was around 3 stars out of 5. Game was also added to the Newgrounds list, so I was very happy to the result.

One important thing to remember when converting a game for Newgrounds: Flash games are displayed in canvas with 16x9 aspect ratio ("widescreen"), so it may require some scaling or letterboxing to fit your game properly there. I had designed Explopool mochi and kongregate versions for 800x600px canvas, and I initially decided to shrink Explopool to 640x480px for Newgrounds. But that was a mistake: The quality of graphics was totally messed with this decision. After couple of days I figured out that it is possible to use vertical resolutions >480px, so I resized the canvas to 1066x600px. Now original Explopool grahics can be seen as originally planned. Learning the hard way.  :)

Edit: 25.3.2014: I noticed that there is also StencylJam2014 contest ongoing at Newgrounds until 28th March. What a coincidence! So I just added the "stencyljam2014" tag to my game and participated to the contest. I can hardly wait to see which games are selected to be the best ones, because there seems to be couple of high-quality one posted to the contest.


Friday, March 14, 2014

We're done! (Explopool flash game)

It is somehow rewarding (and also relaxing) to get something finished.

I am happy to tell, that after all that debugging, polishing and problem solving we got "Explopool" flash game ready and released. Game mechanics is not too complex, but still there were challenges to be overcome before we were able to say that this (possibly) works.

The basic idea of the game is simple: place and set a bomb to pool table, wait it to explode, and see how balls are pushed by the shock wave. If ball goes to the pocket, you will receive some points and handful of coins. When coin meter (on the right hand side) is full, you will get one more bomb. There is also possibility to get 2x or 3x points, if you get enough balls to the pockets with one explosion.

There are few special features available to make game more interesting and challenging:
  • black hole: sucks all balls in certain range to the hole
  • color match: if this is activated, balls of same color will disappear if they collide
  • multi bomb: Bomb will explode 2-3 times at some point (does not decrease the number of available bombs)
  • Nasty cover: This is bad, really bad. If you get this, the hole is blocked by a cover. Makes game surprisingly difficult.

Following lines were added because of Mochimedia flash services shutdown in the end of March 2014.

Mochimedia winded down all services in the end of March. Original Mochimedia version of Explopool is still available at couple of hundred flash game portals, but the leaderboards are not working anymore in them.

So, I strongly recommend you to play Explopool at Newgrounds or Kongregate. Both of them have leaderboards up and running, and Newgrounds version has also some medals to be earned.

If interested on Explopool, please have a try:

Also, check our webpages for latest news: