We want to see if the user is holding down the key - not if they just pressed it. For rapid-firing weapons, we don't want this. GetNewNeedState checks that the user has just pressed the key during the current frame.
#Bugdom cheat code
At the very top of that function, there's a bit of code that determines whether or not to call ShootWeapon (which actually spawns the bullet and gets it moving).
#Bugdom cheat update
The player's update routine calls CheckPOWControls on every frame. If (GetNewNeedState(kNeed_Shoot)) // see if user pressed the key I won't go through them all here - the one that's relevant to us is in Player_Weapons.c: void CheckPOWControls(ObjNode *theNode) If we grep the code for kNeed_Shoot, we get about ten hits. How does the code refer to the shoot key? In input.h, there's an enum of all the possible inputs ("needs") that the game can respond to: enum The first thing we need to do is find the piece of code that fires a bullet when the user presses the shoot key. Okay, here's how I'd go about adding rapid-fire to Otto Matic:
#Bugdom cheat mac
I'd only ever played the Mac version in the PowerPC days. Huh, I had no idea IFD's version had this! Interesting. We should definitely do some testing here to see whether or not the game gets noticeably harder after lifting those limits. However, the game does run into, e.g., MAX_BRAINALIENS right at the beginning of level 1, even with the PPC version's draw distance. I'm thinking of the GiantLizards in level 6 they're large and carefully spread out across the map, so it's probably best to do away with those enemy-specific caps altogether.įor all other enemies, those caps might not have much gameplay value. On the other hand, some enemies that are important milestones in the flow of the level probably shouldn't be capped at all.
I can think of the following infinitely-respawning enemies that may need a hard cap for balancing: Corn, Onion, Tomato, Blob, EliteBrainAlien. For example, in level 2, without MAX_BLOBS, you'd quickly be swamped with blobs as soon as more than a couple frozen slime balls start thawing. Some of the enemy-specific caps are meant to keep the game balanced. Note: the global enemy count can be viewed in-game by pressing F8. It seems to be less extreme with a supertile active range of 8. Some areas of the game hit 20 simultaneous enemies pretty quickly indeed, such as parts of level 6 with a supertile active range of 9. I'm pretty sure we can safely raise it because the enemy-specific caps will limit the amount of enemies anyway.
I believe the global enemy cap (gMa圎nemies = 20) is purely meant to help with performance, as opposed to having any kind of role in gameplay balancing. Some levels aren't really designed to look good with a long draw distance anyway - I'm thinking of ugly gaps in the terrain in level 2. Perhaps it's worth looking into lowering the supertile active range just a bit it'll relieve some of the pressure on the enemy caps.
_-_Level_Cheat.png "bugdom cheat")
The code supports values 4 through 9 - any other values will fail to compile. I believe the PPC version had a range of 5 active supertiles or so. This version uses a range of 9 active supertiles, unchanged from the code dump I got from Pangea. To test different draw distances, you can tweak SUPERTILE_ACTIVE_RANGE in terrain.h. Here are some things we can try to tweak: Supertile active range I think we'd need to do some thorough testing to see if it throws off balancing in any way. Wow, great observation! I hadn't noticed this.
0 kommentar(er)
