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:
- 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.
- 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.
- 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:
- The child Enemy can copy one from the Parent.
- 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.
- 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.
This past week I’ve been lazy and complacent but mostly lazy. I set out to add more content to the game, mostly new types of enemies. I’ve had this idea of “compound enemies” where you basically form one bigger enemy from other enemies. Then you could make traditional end-of-level-monsters, which would have several different weapons to be destroyed piece-by-piece quite easily. And so, adding playable content led me into tweaking the functionality as well. We’ll see this Friday what I’ve managed to come up with.
At TIGforums there’s one brave individual who’s determined to make one game a day throughout October. Since I don’t currently feel that I fail often enough, this has given me a similar idea. I’d spend November, not just failing at growing a beard, but also making one new enemy per day!
Before that, I really really really have to get the functionality to a level that I didn’t need to spend time working on it.
Last Saturday I published Goldwingu v. 0.20 without even remembering to make a post about it. The reason was that I wanted to make a post on Reddits /r/gamedev subreddits Screenshot Saturday thread and was busy making everything pretty. Subsequently my post was buried under the pile of awesomeness of other fine Indie games. I did manage to make a video, and even upload it to YouTube, action which removed practically all detail from the video.
“Marketing is not optional” goes the old Indie wisdom and I can hardly do any worse from here.
Next iteration will focus more on adding playable content. I will try and see what the current platform can accomplish. Adding content (such as different types of enemies) always leads to ideas to add to the platform as well. I guess what you can learn from this is that if you ever get stuck in your game development with not knowing what you should focus on next, try honing the game side of it. Add something new, change the balancing or reach out and acquire outside feedback.
On the other side of things worth mentioning, I found out I have a copy of Garage Band in my old MacBook, which might prove useful in crafting some music, although I didn’t manage to get dirty enough guitar out of it. ZZ Tops Ninja Shack opening chords dirty that is.
Maybe I should just do some GIF-animations of different explosions.
I went ahead and bought the 9th Humble (Indie) Bundle as a belated birthday present for myself. HB9 carries some heavy-weight names such as Fez, Bastion, Limbo and Mark of the Ninja (among others). It would be easy to make the claim that Indie Gaming is rapidly turning into a superstar fueled business where those already well-known games getting more attention.
I am sure the truth has more shades of gray than this, partly because I’m at the bottom rang of that Indie Game barrell. I’ve got nothing to show for myself but my game, with no industry connections, with practically no skills whatsoever. Outcome looking grim. Better step on the gas.
Then there was re-factoring. I have been pounding my head to the desk, trying to get my label system working as I want it to. Labels are practically just text imposed on the screen, what I’ve been doing about them is very low level and nasty. These labels have or are planned to have the following characteristics:
- Labels can be combined together to make new labels (e.g. Component name + it’s condition shown in the Tactical Display)
- They are read from the disk and transformed into an array of Atoms, that can be chugged for my existing drawing routine without major changes.
- Some effects are applied, where necessary.
- Should be dynamic, i.e. the Label describing a component name + it’s condition can be changed easily.
#4 has been the headache inducer for me. Where should the combining and updating of Labels be handled? As I write this I get a feeling that Labels should be immutable but their appearance should change as needed. You’d have them stashed in your Model, with a reference in your View. Should be easy to update all the player related stuff (namely TD) as well as other GUI stuff. You’d have static helper class for some manipulation stuff (such as combining labels together).
All I need is at this stage is one way of doing it that you can beautify and trim later on. I hate being stuck in a rut like this.
The benefit of being a total amateur is the amount of learning and finding out how to do stuff in a better way. This week I’ve been re-factoring my god-awhul mess of a drawing routine and it’s slightly less ugly now.
Naturally when you touch software somewhere, it almost invariable allows or demands changes elsewhere as well. In these occasions I’ve noticed that usually doing things The Right Way forces you to do things The Right Way elsewhere as well.
My main nemesis this week has been OpenGL and my inability to get Alpha blending to work with GL_POINTS with using glBlendColor. This is such a minor detail, but as is probably familiar to most devs, it drives me crazy because it should work the other way (with glColor4x) too!
Making changes to my drawing routines has caused changes in some of the datatypes I’ve made and it will probably cause an overhaul on a number of GUI elements I’ve made. I should have plenty of time to take it apart and put the pieces back again, better this time, before 27th, which is the release date for the next version.