One of the first things I did with my gmk project is figure out how to do file I/O so I can write out to an event log so I can see what’s going on in the game. This is highly useful, since it allows me to track every action that happens, every value of every variable if I want to.
Once I figured out how to write a file I/O routine in gamemaker language, I put logging on a bunch of things in the game that I wanted to track so I could see it working and make sure that it was working the way I wanted it to. Mostly this was a check to verify that the way I understood the environment to work was correct.
After I’d written a logging routine on just about everything I’d built so far, I discovered that you can call scripts. So I got excited by the prospect of being able to write a reusable script that would save me from having to write out the same code again and again, like I’d just did. So I built my script, proved it worked, then went and ripped out all that redundant work that I’d just put in. I didn’t mind at all because it meant moving forward that I’ll have a lot easier time with building up code, and I’d discovered it way early in the project.
(I probably could have learned it even earlier had I read the manual cover to cover before starting, but I find it easier to engage with something if I play with it as I learn and read as I play with it whenever I get stuck.)
###
The next interesting thing I did was a feature I wanted to implement early. Trying to do the early stuff the right way is important, but you can’t second-guess yourself so much that you don’t make progress at all because you can’t decide what approach is truly best.
The feature in question has to do with the graphics. I wanted a way to graphically show the relative strength of the enemies to the player. Basically, we have a “strength” variable, and if you compare it to the player’s current strength, an enemy is either weaker, equal, or stronger than the player. I want to make this apparent to the player visually.
On my first development iteration, I simply implemented a separate object for weaker, equal, and stronger enemies, which all inherited from a base enemy class.
On my second development iteration, I figured out that I could have a single enemy class, and for the initial value of the strength variable, I can just assign a random number, and then based on this random number, compare it to the strength value of the player, and assign the appropriate graphic to the enemy. I got this to work pretty easily, and it eliminated the need for having separate objects to represent the weaker, equal, and stronger variant enemies. This might be a mistake, as it might make things more complicated to have a single object doing all three things. But I think it is the right way for now.
On my third development iteration, I needed to make the enemies update their graphics. The player’s strength increases during play, so as the player’s strength changes, the enemy’s relative strength might change from stronger to equal, and finally to weaker. I wanted to figure out a way to do this efficiently, and figured that having an event that fires whenever the player’s strength changes would be a good solution, and the “right way” to do it. I haven’t been able to figure out how to do this in GameMaker yet, however. It’s not an easy thing to do, and probably requires a bit more understanding of GML than I have at present. GameMaker handles instances of objects in a kindof kludgy way, and this quirk in the way the language works makes it harder for me to do what I want to do.
After trying to figure it out for about 4-5 hours, and not getting anywhere, I opted to go for something cruder but simpler, and found that it works just fine, at least for now. Rather than trying to fire an event that checks the relative strength of every existing enemy in the current room whenever the player’s strength changes, I simply created an event for the enemy class which checks its strength relative to the player each and every step of the game engine, and updates the enemy’s graphic. Obviously, this would not scale as well (I’m basically “polling” the objects 30 times/second, instead of simply calling a method as needed, which would be a much more efficient way of doing it.) So this approach may not work out so well if the game gets larger. But at the scale I’m currently working at, it performs just fine. I’ll have to revisit at some point if I have too many objects in play, but I’m not going to worry about that for now.