Hello, everyone! :)
Whew, finally, the second level is done! ^^ Now the level's boss area also becomes more challenging, compared to the previous week, that I thought was too easy.
There's a bug, though. In this level, I made a dynamic enemy that will react to the player. Thus, it needs a PlatformerObject behavior assigned to the sprite. Instead of just running on the floor, it can jump, but somehow, sometimes it's stuck on the wall when doing its action XD
Although I think this is more to GDevelop's bug instead of the tile placement, I guess I should find a workaround.

I also considered to add more sound effect since the second level seems to need it, with its more opponents and mechanisms compared to the first level. But I think I'll do that later after more level designs are done to see what more sounds I need to add.
Now with the second level out of the way (:p), it is time to work on the next level, level 3! I has actually made some tiles that I planned to use on land/grassy scene, but I decided to simplify the style, so I made new ones.

Hello, everybody! :)
Well, I simply continued the work on the second level this week, but hey, it is almost finished! Things are already in place up till right before the boss area, in fact :)
Actually, I already placed the tiles on the boss area, but I think it is still not satisfying for now. I need to iron the area out before calling it done. I has also started working on the boss fight game mechanism, but it still needs more time to complete.

I did some tests on the level, and... it is more challenging than I expected XD With more dynamic area and more dynamic enemies compared [...]

Hello, everyone! :)
Okay, I got some trouble last Saturday (err.. with my tooth X__x ), but I won't make that as an excuse. I'd just say that this is going to be a rather quick recap.

By testing the touch control, I noticed a bug in the dialog scene. With touch control, it is very likely we enter the dialog scene while pressing a button. That button won't be displayed on dialogs, since we only need to tap the screen or press the Fire key to advance the dialog. Thus, when we release our finger after entering the scene, the dialog would advance, resulting in a chance to miss reading the first displayed dialog. This also happened with keyboard control, if we enter the dialog scene while shooting. Release the Fire key after entering the scene, and the dialog would advance.

Hello, everyone! How's your long weekend? :)
I was in my hometown this holiday. Well, I spent more time with my family than with the project this weekend, and I'm posting this entry on the train to Jakarta. I did some touches on it, but there's not much to tell about the level design. However, I can tell all this below regarding the touch control :)

I continued the implementation of the touch control, fixing some things that need fix such as the shooting mechanism. It works well with keyboard, but worked strangely with the touch control. It does shoot when the button pressed, and it shoots to the angle the player is facing, but when the player turned to the other side, the bullets also changed direction ^_^;
Previously, I added the commands to determine the bullet's direction as subevents of the shooting event.I fixed it by defining the bullet angle at the main event itself, by defining the direction as a variable depending on where the player character is facing.

Hi, everyone! :)
Continuing the test on the touch control from the previous week, after doing some searches on GDevelop Forum and tinkering with GDevelop commands, I finally got the right formula for it :) Basically, we need to state that the button only works when a touch is held, and when the said touch is stopped (lifted or moved from the button), the button will be considered unpressed. Err, looks like it would be easier to just show the actual command, so here it is :)

For the testing purpose, I only activated the effect of movement and shoot buttons. Now that the button mechanism seems a lot better, the next thing to do will be implementing a complete control of the game :)

Hello, everyone! :)
Okay, so, I finally got the chance to test Proto Blast touch interface on mobile device :)
I had to resize my harddisk partitions to give more free space to my system's /root partition. And.. whew, resizing hundreds of gigabytes actually takes quite a time, eh? XD But after that, the Ubuntu SDK didn't behave anymore :)
I installed the kit for my Ubuntu phone, and tried to run Proto Blast on it..... to find that it didn't run as intended.

First, after simply running it from the exported code (with GDevelop's Export to the web menu), that was the one I get. The text appeared, but the images that serves as the option buttons (keyboard or touch) is nowhere to be seen on the screen.
Okay, since it is a phone, I tried to workaround it for the time being, by defaulting the control to touch, but, then what I got is.. simply a grey screen. Considering that Ubuntu Touch is still under development, I wondered whether this was a current limitation of its HTML5 engine. It is strange, though, since there are many HTML5 games that runs well on Ubuntu Touch. Then, I tested it on Android by directly open the HTML page on Android's Chrome browser, only to find the same result.

Hi, everybody! Welcome to another weekly recap of Proto Blast development :)
Aside from some touches on the design of the second level, I started materializing something that I concepted a good while ago: touch control for mobile devices.

First thing first, player got to decide how he/she will control the game character, with keyboard or touch. If touch is selected, a touch-based control will be displayed on top of the game scene.
It works during my tests on desktop browsers. However, after the game is closed and reopened, it didn't remember the selected options and popped up the control options again. It happened on both Firefox and Chrome.

Hello, everyone! :)
I am still working on the comic project this week, but other thing made me split the time even more: due to the (let's just call it) craziness in my office, I had to to work on a video project for my office's event on my weekend :(
Even worse, my stomach acts weirdly this weekend. An annoying productivity hinder. But, well..

I do small touches to the design on level 2, but it is still far from being complete. Regarding the implementation on loading mechanism to continue from the last-played level, I did some tests and it works well in the browser, both on Firefox and Chrome. Well, to test as a standalone app, it still needs a lot more time, though.

Hello, everyone :)
I am still working on the comic project that I want to publish this month. Gotta be honest, I didn't get much time to work on this project this week. I'll also still need to split the time with the comic project again next week.

I continued working on the conversation backgrounds and the design of the second level. There are still a lot of things to do about those.
Aside from that, I also tested changes to the control of the game. With the special attack and healing included, I wondered whether there are too many buttons to control with the left hand compared to before. While the demo version only got jump + shoot to control with left hand, now we've got jump, shoot, special atack, and heal. That's just too cramped to do with left hand only (Shift, z, x, and c key on the keyboard).

Hi, everyone :)
I had to split the time again for this week since I am working on a comic project that I want to publish this month. So, yeah, this is another quick recap.

I continued the work on designing the second level, but I think there's not much to tell since it still needs a lot to be done. Aside from that, I also started working on backgrounds for the dialogues.

That's the background for dialogues that take place on level 5. I thought drawing a cave was simpler than the rest of the levels, so I decided to draw it earlier, but it actually is not as simple as I originally thought XD But I will continue, of course :)