Maybe naming this Windows OS Theme would have been a better name and not misleading.
I assumed it was to add a background pic or color into a window... aah, guess not.
But its still cool looking.
I can do that too...and I'm running on AMD Athlon 64 Dual Core Processor 5600+ 2.80 GHz, along with 8.00 GB of RAM. I reckon I just want my PC to perform the best of the best. lol
*Fixed the colours on the mob drops. Easier to read now.
*Fixed a bug where sometimes a bullet hitting one zombie would take out not only that zombie but sometimes a random other zombie.
I have mob drops up and running now. Tinkering with the colours to provide the easiest presentation (my initial box at $rgb(133,133,133) and arial 8 $rgb(255,0,0) is kinda hard to see).
So far I have the health and the machinegun drop. Drops will automatically disappear after a short time (standard feature on games of this type, hope you understand ;D).
Machinegun is up and running. Looking into the rocket launcher and shotgun since those are more than just simple "one bullet traveling in one direction until it hits something".
Also, I'm looking for weapon and pickup ideas. I already have some picked out:
Pistol (already included): Single shot of course, fires once every 40 frames.
Shotgun (planned): Multi-shot (I'm thinking 5), will fire once every 30 frames. This is going to be tricky for me, I may have to do $sin and $cos after all, but I'm betting I could figure out something else with the framework of bullet movement that I already have.
Machine gun (planned): Single shot, fires once every 5-10 frames. I haven't exactly set a rate for it yet, since there are performance issues with a lot of bullets on-screen.
Rocket Launcher (planned) Single shot, fires once every 40 frames. Will travel slightly slower than bullets, but will have an AOE upon contact with an enemy of as-of-yet undecided radius. Then again, this is if $inellipse will let me :\
Health (planned): Obvious.
The reason I haven't used those functions is because I hate them :( and I can't figure out completely how I would do it, anyway. I can drawline with them in a given angle, sure. But I have no clue how to make a zombie use $cos and $sin and figure out which is the best way to move, given that they only move one pixel per turn (forgot to mention. zombies have "turns" so they move at a set slower rate than the player, though their turns speed up as the player accrues kills).
Having zombies that "meander" toward you seems like a good idea. :D I may look into that.
Also, I changed it to > 2.5, and it gives a decent homing that works like so:
Imagine a line drawn at 22.5 degrees as compared to due north, from the player to the edge of the map. Then another line 45 degrees further, then another, until I have a "pizza" of eight slices. When the zombies are within the confines of one of these slices, they will move the appropriate direction for that zone. Using my current homing math and increasing the check to > 2.5 not only does this, but when they land on one of the dividing lines between two zones, they follow the line (performing one down movement, then a down-left, repeat, for example). But again.... sounds like meandering may be one method of making this more interesting.
As for wandering until they become aggressive.... all zombies always spawn at the edge of the screen. SReject suggested this, but with my current concept it would present to the player that the center is the safest place to be, yet in order to kill the zombies without them coming too close with the eight-direction firing you will have to get out of your comfort zone at least to an extent.... and probably moreso if the center area has too many zombies piling up into it. Also, for some reason $inellipse() was mega glitching for me (returning $true as long as the zombie's X coordinate was (Player's_X_COORDINATE +/- 1) no matter how far away the zombie was. So I had to resort to using $inrect to loosely define the "player" to them.... so I could imagine how proximity homing would go for me. I'm using 7.19 but had seen nothing reported in bugfixes about $inellipse.
that would cause the zombies to move straight towards the player, which could get quite difficult when there's a lot of them. on the other hand, it's also quite predictable.
Illogic, yours is very similar and uses "> 2" where SReject's would use ">= 1", which probably results in a slightly more playable environment.
the behaviour of the zombies could be the most interesting aspect of the game, from a coder's perspective. it's a lot of fun to think of certain movement patterns and try to figure out how to express them mathematically. or to tweak / generate algorithms and observe their effects on the zombies. how about zombies that wobble towards you, taking 'steps' in a random direction between +/-45° relative to the player? or zombies that wander around until you come close, then move towards you with greater accuracy as they get closer to you? have fun with this, and don't restrict yourself by avoiding $sin / $cos. if you need to use trigonometry then you need to use trigonometry! :P
Where %zomb.px = Player's X Coordinate, %zomb.py = Player's Y Coordinate, $3 = Zombie's X Coordinate, $4 = Zombie's Y coordinate.
Also, an update on the progress:
Hit Detection (kinda) Completed. However, right now it involves a filter embedded in a filter, so it's not the most efficient. I am looking deeper into it now.
Game Over Screen Completed: When your health reaches zero, it provides the obvious "You're Dead!" screen along with how many kills you made. It pops up an $input() to ask if you would like to play again.
