Long time no update... This is just a quick post to "confirm" that the project is still ongoing, and some of the (few?) things I've done since last time..

Before we start, a small digression and an update to my last post on http://www.beedesign.no/construct2-vs-gamemakerstudio-2.

For the time being - and probably for good - I've stopped playing around  with GameMaker: Studio 2. At the end of the day, the price just killed it for me. So, when Construct 2 went on sale during the holidays, I went ahead and got myself a license (30% discount).

I know it's a Windows only program, and I did have major problems running it in a VM environment previously, but after some testing, I found out the problem wasn't Construct 2 at all, rather a bug in VMWare Fusion. I am currently running Construct 2 in Parallels Desktop with no problems what-so-ever, other than the fact that my tired, old faithful MBA is experiencing some sluggishness now and then... As expected.

Back to the subject matter. Progress? What is progress really? Is it progress to take a few steps back when it eventually will make progress? Personally, obviously, I would think so. Hence, I started Goldroids with blank sheets. I will reuse most of the code I've already done, but I found the project needed a bit more structure to be able to progress further. I needed a more flexible setup of the code, really. Right now I was creating all events and actions in one "Level" layout, which is fine as long as you only have one level to think about. But - "unfortunately" -  I'm opting for a dozen (or so) levels (at least). Imagining if I decided to change something towards the end of the project. With my original setup, I'd have to change the same events in each layout (for every damn level) to make one change. This is not a good way to work. Trust me, I've struggled with this in multiple previously (unreleased) projects.

So I decided to look into include files. I'm planning (and doing) to make separate event sheets for blocks of events that will be used in each level. The "Level" layout will more or less only be a visual "set up" of the level and I'll include the different event sheets needed to make the Level work. This way, if I need to fix something, I will fix it in the include file and it will be reflected in every layout where this include file is used.

I also had a major fight with the player animation. This turned out to be the most "advanced" piece of code I've done in Construct 2 so far. Not going into too much details (ref. screenshot below), I wanted to have a directional based animation (not flipping the sprite, rather reversing the animation when needed) based on the player's movements. I really had to think hard about this one, and luckily I found some good advice along the way in Scirra's Forums. Thanks a bunch! It turned out the trickiest part of this was to crack the repeat-to-frame part of the actions. And also deciding which animation to be more dominant (when moving). A 50-50 multiplier just never looked right. Making the horizontal animation more dominant looked - and felt - much better.


So, right now, visually, it looks like I'm way behind on progress - there is only a menu and the player on screen - but I believe in the long run, these were the correct actions to take.

I almost forgot, I did a major redesign of the background tiles. Seing as a level can have several different background colours, it was really an idiotic way I started designing my tile maps. Previously, I had 8 different tile maps for each level. They were really identical, only the background colour was different. I now have 1 tile map for the walls, 1 tiled background for the floor (same for ALL levels) and changing the background colour based on variables in-game. This means, for each level I have to design, I only need to design the walls (once). This makes everything much easier. Imagining designing 8 tile maps for each levels. What WAS I thinking... hehehe Well, you learn from your "mistakes", I suppose.

Another thing I'm looking (vigorously) into at the moment is the game flow. I'm planning to have Global and Instance Variables controlling everything, not just jump from one level to the next. It needs to be flexible as the player can choose whatever level he wants in the mining map (eventually). Although I believe I have most under control (in my head), at some point I need to implement this in the project. And "sooner, rather than later" springs to mind on this one :) I've controlled the game flow like this in previous (unreleased) projects, but I'm sure it needs some fine tuning to work "flawlessly". After all, if I get this right, now, I will be able to reuse this method in other projects down the road.


For the time being, the "new" Goldroids project can be tested at the following link:

http://beedesign.no/Games/GoldroidsNew/

In this version you can turn music on/off by pressing 'M' on the Startup Screen (for now), except in Safari, as there apparently are some issues there. Note: The "tune" is a 5 minute effort in Lmms just to check out some C64 arpeggios I found in the "Commodore 64 Synthesizer Sessions DELUXE" package. I recommend trying out the game in Safari to make sure you don't get to hear the music ;)

You can also press '1-4' for different background colours, 'X' for player invisibility and 'ESC' to return to the Startup Screen.

Note: In Goldroids, the player has to move in order to be able to shoot. This is by design, not by accident. Honestly!

The old version of Goldroids can be found on the following link:

http://beedesign.no/Games/Goldroids/

There are several keys you can press in this version as well, but, honestly, I forgot them all...