Well, now you can -- your latest build works 100% perfectly:
Wow, that is just awesome! Thank you so much! I was cheering out loud when I saw this at work, it was such a relief to see this wasn't a completely wasted effort.
Sorry for not replying to this sooner, I'm trying to avoid spamming this thread unless I've made some progress.
...and now you can consult the actual code yourself:
https://github.com/keendreams/keen
Cool! Looks interesting and well commented... Actually learned something right away from this. Apparently the handle game actors as a linked list (which I didn't even know existed about before reading this).
Might be useful for MagiDuck as well. Currently it has an unordered array of objects and an ordered index-pointer array, which refers to the object array. A linked list would probably consume more memory though.
Here's how things are looking at the moment:
I've tackling with basic gameplay and enemy behavior. Here are some conclusions I've come to on different approaches:
Rainbow Islands / Bubble Bobble type gameplay:
- Relies on large screen size, which allows player to make many seconds worth of decisions based on level layout and enemy placement.
- Many enemies and pickups on screen.
- Player decisions mostly about finding an optimal route for collecting pickups and avoiding enemies in very chaotic situations.
* MagiDuck screen size doesn't allow player to be informed enough for this type of gameplay.
* MD sprite routines would completely choke on this type of design.
* MD physics would fit well though.
Megaman type gameplay:
- Very linear levels with precision timed enemy spawns and movement.
- Many isolated rooms that are crafted for a specific enemy type and player strategy.
- Projectile dodging is a big part of the challenge.
- Variety relies on numerous enemy types and player powerups.
* MD would benefit from tightly scripted enemy spawns and movement patterns, since they would be easier to optimize for minimum object count per situation.
* MD's vertical levels and small screen size probably wouldn't allow for very interesting situations.
* MD won't have many enemy types or a complicated powerup-system. I don't have the time for it
* MD physics would fit this fairly well.
* Dodging projectiles works for MD too.
Mario 1 type gameplay:
- Challenge is mostly based on intricate physics.
- Game objects are very dynamic and provide for interesting strategy and unpredictable situations. (Turtle shells can benefit you or render some areas hazardous etc...)
- Few objects on screen at once and very easy to optimize for 1-direction scrolling playfield.
* MD would have to change to horizontally scrolling levels.
* MD can't handle intricate physics, because of the low resolution. Horizontal movement happens in two-pixel increments, making it even worse.
* Dynamic and bug-free objects sound like a huge amount of work.
* Creating game mechanics that wouldn't be a complete Mario ripoff might be beyond my capacity...
Duke Nukem 1 type gameplay:
- Very coarse physics and small screen size.
- Levels based on exploration, rather than well programmed enemy waves or any specific mechanic.
- No real threat of dying, unless player makes numerous very hasty moves. Very generous health pickups.
- Challenge seems to be about optimizing score in situations with destructible pickups and enemies on screen.
- Satisfying effects and destructible environments / pickups make for some fun gameplay, even if it's extremely flat.
- Interesting level layouts and lots of variety in graphics to keep things fresh.
* Kind of what MD has been so far, except with minimal exploration.
* Making Duke1 with less graphics and effects doesn't sound like fun.
* I really don't want MD to be a straight up shoot'em up...
Where MagiDuck is going at the moment:
- Tower climbing platformer with some shooting.
- Lower edge of the screen kills the player. Choosing routes becomes important since there's no way back down.
- Most enemies will shoot. Projectile dodging while shooting back is important for the player.
- Killing enemies in good spots in order to collect their pickups.
- Finding keys that open chests for sweet loot.
- Time is a big part of the final score, so speedrunning will be rewarded.
I don't really know what to say about the coding part though... There are multiple things that could be optimized in the BASIC code still. I already changed most of my collisions from rectangle-rectangle-tests to point-rectangle-tests. I'm thinking about seperating collisions from sprite data, so each object would just have a predefined collision rectangle. The engine would be slightly less flexible after that but it probably doesn't need to be.