It has been a while but, truth be told, little progress has been made. Quite frustrating to have a silly “make it work better” item keep the latest alpha build from being released. I could make a few levels and send it out “as is”, but I don’t think that would be for the best. Might as well make the enemies as good as it can reasonably be done at this stage before sending it out.
What I really need is time to work things out on paper, and a long 3-hour+ coding marathon some night, to get the complex ideas down in code. I find it hard to work on this part of the game in small chunks of 1 hour or less. The next change I need to make is a medium sized one that will rework some of the enemy state machine logic for AI. I don’t want to do this over the span of several days. I need the time to modularize it a bit more and make it configurable.
One idea I had is to make this as configurable as possible and allow the level creators to toggle switches for enemy behavior. I’m not completely sold on the idea but basically it is this: Each enemy has several attributes that are definable for it, such as appearance, travel type, damage type, etc. So you could have a Whirlygig that moves randomly, moves randomly with jumping, moves randomly with jumping and lightning bolt attack. You get the idea. I think for the game’s sake I will have standard entities that follow appearance and behavior throughout the campaign, otherwise the inconsistency will just annoy the player and would be a dirty trick. But making the enemy behavior plug n’ play like this, even if it’s not as random as the above, may make things easier for myself in the long run.
So I have been on a bit of hiatus towards the end of this summer. No excuses, just not a lot of hobbyist programming going on at night. Well that all changed today when I decided to take a 3 hour chunk of time and dedicate myself to finishing something important in the game. The result? Enemies which chase the player.
Of course, whenever I add something to the game I stress test it. The result is a scary form of flocking behavior when several dozen spheres (the collision model used by Whirlygigs) come after my marble. Their target is quite simple (seen as a small red dot), it is merely where my marble will be in the future, at their level.
As cool as this is, it is not 100% done yet. The enemy behavior has little quirks in it, and they will happily roll right off an edge to get to you. I believe I will have to make it a bit more complicated but it must be done… If the path to the player is safe (no missing tiles), the target itself is a pass-through target, meaning the enemy can barrel ahead as fast as it wants. If the path to the player is not safe then the target is a stop-at target similar to what Random Whirlygigs do. I’m sure there are other problems with the system, but it works well at a basic level.
The only big problem I see with seeking enemies, is if they are all clumped together pushing against the wall or some other immovable object, the framerate of the game drops dramatically due to the physics engine. I’m still trying to figure out how to remedy this through code, but for now the level designs will simply not contain the potential for this scenario (dozens of enemies pushing each other into a corner).
Hey there! This blog started exactly two years ago today. The game has come a long way. Not as far as I had planned, but we have still made some good progress. Who knows? Perhaps when this game is done it won’t have to be played in an emulator? 🙂
No new demo available to celebrate, unfortunately. Progress has been a little slow in June but I should be back on track shortly. I added a box for a moveable object, I may add more sizes of boxes, for variety and different uses. I may make some sweeping improvements to the Enemy AI before I add the chasing behavior, that will make it take longer but in the end I think it will make for a better system. I am thinking about modifying the Restart widget process. so when the player restarts after falling certain moveable objects will be reset as well.
Videos of new stuff should come about in the next couple of weeks.
So I beefed up the To Do List, to be more accurate in what I’m planning to do for the “Beta” version. A few more widgets were added. I might even add a “damage” tile to the list. For most maps this would be a “lava” type tile, although perhaps something else could be for other maps (poison, electrical, etc.) Whatever it is, it would have to be animated, which is something these tiles do not do yet. I’ll have to look into what I need to do for that. I think it is merely changing an image reference for the landscape object, which won’t be too bad.
Next is moveable objects for some fun physics puzzles, and putting enemies in the editor. Enemies shouldn’t be too bad now that I’ve got the Widget/Special system defined. After those items there are some big editor improvements, such as widget popups and level info popup. The level info popup screen will be a big screen with all the level “options” on it. User can pick a theme, camera types available, goal type (require all gems, time limit, etc.), and all sorts of other things.
So a couple late nights of coding and I have some progress. First off, I “fixed” the textures of the coins. I didn’t put my ugly mug on them but that can come later. For now I have this simple star pattern I took off the interwebs.
Coin collecting ... will it have a purpose in the game. Purchase powerups inbetween levels, perhaps?
I was able to check off a few items on the to do list as well. I was able to finish the Specials reworking to behave more like Widgets in the editor. Specials now are faded unless they can be placed, with some being able to be rotated, and can be larger than 1×1. To prove this is working I made a Prop (static object) of a large “mound” which takes up 2×2 grid squares. Right now it has the texture of stone but really it could be anything.
Unfortunately I didn’t tweak Widgets enough to make some grand unifying design where everything goes through the same code to place/store items on a level. There is now a bit of code duplication, with more to come for Enemies. I was stressing about doing this, because I hate duplicated code, but the way I store the Widgets vs Specials vs Enemies, there wasn’t a nice way to do it in a general sense anyway. I could have called the same functions but put in a big select…case statement everywhere for all three types. Or I could have a large “Entity” data type that stored all the data for any type of item on the map. These are not quite worth it, in my opinion. Especially when I’d be stepping on code that is a few years old. If the language was OOP there would probably be a clearer path, but I just didn’t see it with what I’m using. Maybe I’m getting old. Or lazy.
I must say, like a kid who rediscovers just how good sugary soda is, I find it quite tasty to get quick results with several copy/paste/adjust sessions. I can see why code duplication and minor tweaking is so tempting under a time crunch. I still don’t like it, but I’m willing to live with it.