If you have an idea or suggestion for the game, please write it in this page.
The mouse/aiming cursor should be a circle that grows bigger and smaller when firing shots. This mechanism can be used to simulate recoil so that the more rapidly the player shoots the harder it is to aim precisely. Also there should be donut shaped meters for ammo and reloading progress around it.
- Aren't the current controls already like this? The cursor is always relative to player, ie if you move around, the mouse does not stay in the same point on the map. As for making WASD parallel/perpendicular to cursor, I found that this makes movement confusing. It actually goes against keeping the player movement and aiming separate. -- priomsrb
- Not quite. That's a side effect from the camera. The player's (character) direction still changes when moving around. I'm saying moving around shouldn't change the character's direction (the mouse should do this, just like in FPS games).
Actually, I think the camera or movement code isn't exactly working 100% correctly. Now that I think about it, the way it seems to be designed, it *shouldn't* change the character's direction but it does (move perpindicular to cursor). So the movement/direction is mostly separated.
I guess the WASD could be confusing. That could be fixed by making the player's sprite constantly facing one direction and rotating the world around it, although that's less practical... so nevermind. The goal behind this was finer movement controls (as opposed to being bound by 8 directions).
- I still don't fully understand. Moving around doesn't change the player's direction (unless the mouse is in the center of the screen. Thats a bug I need to fix).
- Aim the character directly to the right. Now move directly up and down (don't move the mouse). The character "wiggles" a bit when accelerating. It's not that noticeable though so it's not that big of a deal. Although idk you might have fixed this in a later code version (I'm running the latest "stable" release, where you fixed the 64 bit compile problem).
This should replace the current system (where it changes the bullet's direction by some random degrees). Simulate recoil by moving the cursor some random distance after each shot. Depends on type of gun and whether full auto or not.
Algorithm (avoids trig functions):
- Create a static array (c++ vector) that stores points.
- Loop through the square area that encloses the circle and add all points that are inside the circle (to the array above).
- Generate a random integer and use that as an index into the array (above). This will randomly select a point in the circle (because all points in the array belong to the circle).
- Since there are only so many guns and the recoil radius isn't that big, it doesn't require that much memory. Expected memory usage: 2 (x,y) * 4 (bytes) * 100 (10x10 square area) * 0.8 (circle to square area ratio) * 10 (weapons that recoil) = 6.4 KB. Round up to 10 KB, this is an acceptable cost. This algo avoids trig functions and only uses a RNG once.
I'm still contemplating whether to use integers or floating point. The method above is probably faster but a floating point algo would be... more accurate, i.e. allowing any point in the circle rather than just integer points. Although... instead of checking each pixel, you could check each subpixel (instead of moving one pixel over, move half a pixel over). This would allow finer granularity but still not as much as full floating point algo.
Recruit0 18:03, September 10, 2010 (UTC)
Approximate realistic view with fog of war. Then, reveal a circle area centered on the cursor (instead of the character). The player can only see where they're aiming at, so they need to watch their back. Not sure what size circle should be. Maybe half the screen width (so that if they're aiming directly to the right, they can only see what's to the right of them).
Also it could become smaller at night time (reduced visibility) unless the player has a tactical light or night vision goggles (or something else that would help them see in the dark, e.g. shooting a flame thrower).
Later this can be replaced with a more advanced system (where the player can see everything in front of their character rather than what's in the targetted circle). The targeted circle view system is an optimization to make it easier on the CPU/GPU (while providing a reasonable view). An upgraded version can be made by using line intersection or dot product to detect what's in front of the character. Dot product is used in 3D systems for hidden surface removal (yes I'm familiar with a lot of stuff, not just guns, lol). I'm not sure which would be faster (targeted circle view or dot product hidden object detection view). The dot product algorithm probably uses less CPU than the targeted circle but it may use more GPU (draw more).
Analysis (Prediction): Per unit (on the map), the dot product will use 2 multiplies and an add. The targeted circle will use 2 subtracts, 4 multiplies and 1 add. ALTHOUGH, the targeted circle can eliminate a large number of units from ever being processed for drawing. BUT, it uses about 2x more CPU than the dot product... My oppinion: targeted circle is easier to implement but dot product is probably faster on average. Assume the GPU can clip out/ignore all the units that are outside the screen very quickly (probably true), then it doesn't have to draw that much more units than the targeted circle. In which case, it uses less CPU and drawing isn't a problem. Also, assuming a CPU operation costs more than a GPU (in general) then the dot product based view is more desirable.
The only problem is reducing the viewing area with the dot product algorithm (for night time). I'm not sure how to make it optimal in this case. It could be accomplished by applying a constant-defined rotation to the unit's coordinates but this results in 4 extra multplies... (although 4 multiplies is better than using a trig function).
For now, it may be better to just try the targeted circle algo since the dot product view is more complicated. Later, the more accurate dot product view can be used to make the game "fancier".
Recruit0 01:45, August 30, 2010 (UTC)