So work continues at a snail’s pace. I have not fixed up the coins. I played with Classic view a bit but wasn’t happy with the result so we are back to the original Classic view for now. Not much has been done for fixing up the Specials in the editor yet.
Really what it is, is that I have some trepidation about making some large-scale changes to the Editor, and how it handles Special types. Specials can be a variety of items: railings, obstacles (static objects), gems/coins, powerups, moveable objects. All those things. I want to make the Special type act like the Widget type in the Editor. Namely, be able to be larger than 1×1 tile, rotatable, and ghosted/solid based on placement. No doubt it will improve the editor immensely and allow me to make larger obstacle types. It’s just consists of gutting a lot of existing code.
I’m also teetering on the edge of reworking the Widget logic in the editor to be more general so I can just use that, instead of copying the code and tweaking, which I hate to do. However, I feel that the language’s data structures and procedural methodology will make this tricky. So it may end up being a copy job, because Specials are just different enough from Widgets to make it difficult to join them up.
I have time off in the next few days, so perhaps some late nights will be possible and I can finish up Specials so I can then move onto Enemies in the Editor!
As promised, the Whirlygigs are slightly more “map aware” and will avoid picking a target spot which will cause them to fall off an edge. I tried using raycasting from the physics engine but I had a few issues with my use of it, so I’ve adopted a simple grid-based detection system by looking at the map data itself. Not as neat a solution, and it can miss some things (obstacles), but it works for now. I’m having trouble with Hypercam2 at the moment, so you’ll have to trust me that it works without a video. 🙂
There is room for improvement in enemy awareness, of course. Sometime in the future I will look into making the enemies know when they are heading for an edge and try to avoid it.
Something else added is a zone awareness, where if the player is X distance away from the enemy, it will wake up and become active. If the player gets further away the enemy will go back to “sleep” at certain times. The necessity of this intial sleep state is when a player puts enemies on a level, if they are across the level from the start position and the enemies can move around before the player gets to them, they will be all out of place and not where they should be. This could ruin a level’s difficulty or predictability. It’s an obvious thing to code for, but still took some time to implement.
I’m going to take a break from coding and spruce up the coin graphics and visual properties in the game. Then I will try to touch up the Classic View (camera) so it works better with no Z-fighting and uses a proper backdrop. After those minor touch-ups it is on to the editor additions I have been planning since I finished gems and coins. This includes a small overhaul of how “specials” are handled. Right now they are all 1×1, but I think it would be much better if I could make them larger, and treat them like Widgets are treated. This is a pretty big change, as I will be breaking something I just got working a few months back, but it is worth it in the end!
So it has been a while since I’ve done the raw numbers. Here they are:
Marble Maze Game: 6528 lines of code
Maze Editor: 7482 lines of code
So what’s next on the agenda? I would like to tighten up the logic used for deciding which target the Whirlygig will pick. I will be making it so the Whirlygig can slowly stop at the target coordinates. (This will help it not fall of the edge, and look a little more realistic.) I need to get a death sequence for the Whirlygig (fade away).
Once the Whirlygig is all set I will most likely move onto the Editor portion. There is a lot of Editor work that needs to be done, and not just for adding enemies. In order to get the Special/Props system I want, I’m going to have to rework Specials so they are more like Widgets. In that they can be rotated by the user, show up on the map faded until placed, and be larger than 1×1. Once that is done, there will be a lot of cool possibilities with props and moveable objects.
Props are just static models that can be placed and will give character to a level. They will all fit into a predefined “shape” category. For instance, in the jungle theme there will be a prop which is a “mound shape”, that will be textured like a boulder. In the snow theme it will just be a mound of snow the marble rolls over.
Moveable objects will be used for particular physical puzzles. A large box type moveable can be placed near a trench, and dropped inside to make a bridge. A thin/wide moveable can be knocked over to be used as a bridge, or when leaned against a short wall, used as a ramp. These are typical in many marble games so nothing new, but it will be fun to play with nonetheless.
So whenever I add a new component to the game engine I like to stress test it. You know, push it to the limit and gauge the results. So after plugging in a bare-bones Enemy system (copying some stuff from the Widget system) I decided to add 400 Whirlygig models (animated via rotate limb) to the game engine to see how they fared. They did pretty well from what I could see.
If this were not a test, the player would probably be in a heap o' trouble.
Don’t get too excited, the only thing these guys do is sit there and spin. Nothing happens when you touch them (except normal collision) and they don’t move at all. They just sit and animate. This will probably be the only time 400 enemies will be on a level… once the movement/AI is put in another stress test will be done.
I’ll be working on the game engine for the next couple of weeks to flesh out these little guys and get them moving on their own. After my hard-coded enemy placement is complete and they work well in the game itself, I will then make them available in the editor. Which hopefully won’t be too bad… but I have hoped that before. 🙂
All hail the powerful Whirlygig!
Today I have finished the model for the Whirlygig, which is the first enemy I will put in the game. I think it came out okay according to Funcy Standards. I took a basic cylinder and shrunk/expanded the scale at various heights to make a type of stumpy, glass shaped object. Hey, if I ever make a 3D RPG I will already have a model for the health potions! 🙂 The fan blades will whirl around (hence the name) when the object moves across the floor. This is pretty much a steal from the enemy Peahat in the 8-bit Nintendo game “Legend of Zelda”. I hope nobody minds…
There are at least a couple types of Whirlygigs planned for. One will move randomly, stopping and starting in random directions, ignoring the player. Another kind will always move toward the player if the player is in its vicinity which is a little trickier to avoid. It may also move faster or more often as well.
On related news: Despite lack of updates, work has continued on the marble game in other areas. I am close to finishing coins. The coin behavior will be the same as gems… roll over them and they rise and shrink into nothingness. It’s an easy trick to do on an object.
For the short term I need to finish the coins, place enemies in the editor (which shouldn’t be too bad), and then I will start on the enemy system in the game itself!