Not too long ago I went through a period of wondering whether I should change the name of my game. This is usually down to frustration from spelling it out to people and the not-so-technomachobullshit nature of it. I always seem to not bother with it though. It always seem too much bother, if I could agree on a new name to begin with. The main good point of Goldwingu is that it doesn’t mean anything else; I get all those Goooogle result pages for myself, at least for now.

Contemplating a name change pales in comparison with some of the other problems I’ve tackled with lately. One big one has been actually producing interesting and balanced enemies. The way I finally approached that chest nut was good ol’fashioned analysis and breaking the problem down to a smaller parts. I started with coming up with a bunch of two-sided options: smooth vs. accelerating/decelerating movement, predictable vs. unpredictable movement, standard top-down movement vs. mixed movement. From these its easy to pick the easiest options and have an order of various options (i.e. top-down, smooth, predictable movement would be for the easiest enemy).

Add to the list a bunch of options for the bullets and you have a 40 different choices that can be put in an order for difficulty. Trivial options would have been to make difficulty be based on shield strength and number of bullets emitted but thats too easy for an ambitious person like me. Besides I think my chosen options make for much more interesting enemies.

Or does it?!

It’s been a month since my last confession so I guess it’s time for some storytelling. I’ve been stalled by general laziness, in connection with needing to do some boring boilerplate coding. I will have a new version out at the end of this week, the boring stuff isn’t ouright apparent. I have turned my attention to the Campaign mode and also to the appearance of things. I have tried to standardize everything to use pixel graphics, including all the text in screen I use. I’m kind of worried how deep a low code I’m prepared to do, even though there are some benefits.

Tactical display should be more awesomer now too. Also when players shields hit zero, he isn’t necessarily destroyed, but suffers from sub-system malfunctions, such as not being able to maneuvre to the left or not being able to shoot.

I recently became a member of IGDA Finland and I was at their first official meeting on Wednesday. It was surprisingly quiet, but as the meeting took place at Rovio HQ there was at least baguettes to bring home. Their other gatherings seem to draw much more people.

On the coding part of my life, I’ve turned by focus on the Campaign mode. Which led me to think about how to create Scenarios and I made a class for them. This in turn led me to re-factor my GUI-buttons (yeah, I’ve been doing some low level stuff). I’m quite happy how the new code turned out. It allows me to do for example some swanky hover-animations to add that professional polish.

You could say I got kind of sidetracked there, but thats how it goes when your code is full of hard-coded values and all manner of “temporary” solutions. It’s like cleaning your desk, then noticing that now the floor looks dirty in comparison and pretty soon you’re outside raking the leaves, even though its not your job.

I’ve purposefully left the publishing date for the next version as TBA to give myself some breathing room. I have been thinking about taking a week off from coding and just preparing all manner of PR material that needs to be done but the truth is that I’d get plenty done even in a day, especially if that day was every week, but so far the lure of unfinished code has been stronger.

As I mentioned last week, I have tried to put some effort in re-factoring my achievement/medals/upgrades system. No problems there, the functionality for it is somewhat more centralized now and not spread out in different classes. I have just one rub with it, my implementation seems too complex for the purposes right now. I’ve built it to accommodate more complex needs. My system at the moment is as follows:

• Theres the Achievement class, which e.g. holds the name of the Achievement but also a list of boolean values that describe the requirements for the Achievement.
• Then you have a list of boolean values that hold the state (relevant for Achievements) of the game world at the moment.
• And lastly you have the code that does the needed changes to the game world once an achievement is achieved.

Now, for my current Achievements a list of boolean values is a bit of an overkill. I’ve also been dissatisfied for not finding a practical way to create interfaces for those three elements, almost everything requires custom code. Of course once I have more Achievements built in, those interfaces might be more easier to see and build.

Now isn’t that interesting? Isn’t it?!

This week I have been tackling my Tactical Display issues and I have to admit I’ve pretty much managed to (re-)implement stuff that I wanted. It’s funny how easy problems seem to be when you’re solving them the second time around.

I want to use the tactical display for two things; mainly being a proper functional part of the game e.g giving the player information that isn’t needed all the time, providing the mechanic for missile usage and to also instill a sense of awesome power at your finger tips, which I think is a crucial part of Technomachobullshit.

Some of the functionality I have implemented for TD is:

1. Label can follow the players ship, it can appear from the side of screen or it can be a normal stationary label on screen. A label can be anything really, not just text.
2. A label on screen can be changed dynamically. At the moment I can display the score with this, but it would be trivial to implement this for letters as well as numbers.
3. TD is player spesific, but it isn’t handled very graciously at the moment.

I’m actually quite pleased how it has come around so far, but as I said this is my second time implementing this functionality (and then some).

Having been suffering from the weakest flu ever(*), I have also tackled one (hopefully one of the last) problem I’ve had with my Enemies. I have mentioned compound Enemies before, they are Enemy entities that are joined by a (one-directional) parent-relation, they have basically 3 distinct modes of getting orders:

1. The child Enemy can copy one from the Parent.
2. The child Enemy can have optional orders matching Parents orders. e.g. when Parent is set to shoot, the child can be set to fade-away.
3. The child can have separate stack of orders.

The last one provided me with a problem concerning movement. The child enemies can be “stuck” to the Parent on top of moving on their own. For example, a child Enemy moving in a circle without a Parent-relation, would be circling the Parent with the relation.

As usual the solution to this proved rather simple, although I really had to work for it and it took me awhile to get there. And as often is the case, my solution broke the carefully crafted house of cards of some previous functionality. I guess I’ll have to get this back to something more simple, it sucks being a beginner.

(*) Yes, the flu being weak, not me.