Fledgling Videogame Developer

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

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" else       set colorOfBox = "blue" end if But ...

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

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

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

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. :) -Jussi

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