calculating ddx ddy is as cheap as a subtraction. I would recalculate it. tex2Dgrad is mostly useful for when you have branching paths in your shader. If you ever branch you cannot cacluate ddx and ddy. If you need to sample a texture inside an if statement, you need to calculate ddx and ddy before the branch and pass them into tex2Dgrad.
Lua scripts are easier to treat a resource. You can have a file represent an enemy type or another dynamic object in your game. This file can include the name of a script to use as the object's behavior. This makes extending the game easy to do, and you really begin to see the benefit when your game has many different types of dynamic objects. You do pay the cost of having to create a binding layer between lua and c++. So the benefit may not be worth it if you aren't going to have many types of objects in your game.
When you loop through your list of tiles, you use localBoundsRect against each tile. You move the location of the player but don't update the value of localBoundsRect. If your player intersects with two blocks then the overlap is corrected for each block moving the player twice as far as needed. I would recommend setting the position of the player relative to localBoundsRect using the depth as an offset. You can repeat that multiple times without any negative side effects.
If you have determined that two shapes do overlap, determine the smallest amount you need to push one of the shapes to correct the overlap. This however, can result in objects passing through each other if they move fast enough. See separating axis theorem
The second option is to do a raycast aka swept collision detection. You find out how far in a given direction any obstacle is in front of the player and use that distance to determine if the player can move before moving them. Is actual practice, you usually do sphere casting or capsule casting. Its like ray casting except the ray has thickness. In essense it just determines how far a sphere or capsule shape can move before hitting something. Spheres and capsules, apart from being easier to do collision detection with, also have the benefit of not getting stuck on sharp corners. They just slide over them without a problem. Here is a simple example for a sphere/plane swept collision. http://www.gamasutra.com/view/feature/131790/simple_intersection_tests_for_games.php
Since we want to transform a plane from normalized space to world space we simply take the transpose of the view projection matrix and mutliply each of those six planes by that matrix
transpose(view * projection) * p
You notice that we don't take the inverse of the matrix since it is already the inverse of the matrix we actually want to transform it by. (view * projection goes from world to normalized space, we want to go from normalized space to world space)
The result of multiplying each plane will give a 4 dimensional vector. where x, y, z, w of the vector can be copied over directly to the plane a, b, c, d respectively.
On the other hand, a TD without real stats (and you have to guess) is not satisfying in my opinion. So maybe we can show stats but reduce their format: Instead of Armor: 120 we could display Armor: XX--- (=2/5) ? What do you think?
I agree with that. I few stats presented well in an organized way would definitely be useful. As long as you don't overwhelm the user with information I see nothing wrong with that.
1. Depth of strategy is best increased by having interesting combinations. For example, turret A and turret B my be okay on their own, but when combined they are much more powerful. You also want to make turrets counter specific enemies, but ideally there is more than one way to counter it. That lets the player choose a tower that best fits their strategy. This is a very tricky part of game design but if done right it can really make for a fun game. Another great thing to have in a game is some sort of risk reward system. They player should be able to choose something that has a higher risk of failure, but if they succeed they get a higher reward.
2. The player should never feel overwhelmed with options even though you want to give them many options. This is best done by incrementally introducing new gameplay elements into the game to create a gradual learning curve. Your towers and enemies should best convey their behavior based on appearance as much as possible through its design or attack animations. Any text descriptions of what things do should be kept very short. Most people aren't willing to read a paragraphs of text to learn how to play a game. If its clear what is happening when an enemy or turret attacks then the player can use that information when developing strategies.
I like them. They are very entertaining. I remember playing some as custom starcraft maps and put a lot of time into that.
Plants vs Zombies would be my favorite tower defense game. It certainly doesn't fit the mold of most tower defense games but some of the ways it varies from the norm is why I like it.
I think most tower defense games don't much to let you counter different types of enemies. Many don't let you know what is coming so you have to blindly make decisions or memorize the order of waves by trail and error. Many don't really have different kinds of enemies, just varying amounts of health. I also think many end up with a dominant strategy where you each level has a single solution that is obviously the best. Again, it often comes down to trail and error. Many of the games strategy simply comes down to determining the optimal places to place your turrets, other than that there aren't many interesting decisions to be made.
A few things I like about Plants vs Zombies. It lets you know what zombies to expect before each wave, this lets you prepare for that zombie type. There are many zombie types that are more than just a higher damage zombie. Each zombie type has a hard counter, magnet shrooms for buckets and football zombies, tallnuts for pole vaulters. The game has enough unique plants to let the player experiment with different strategies. A few strategies I like are using gatling peas with torchwood to produce a high damage per second. You can also you slow peas or blue watermelons to slow down zombies to allow for more damage over a longer time. A row of corn launchers is a fun one. Using onions to force zombies into only a few lanes full of spikes surrounded by gloom shrooms is also effective. There are probably many other strategies I haven't tried, that the freedom to play around with different ideas really adds a lot of replay value. One thing it lacks that I like from other tower defense games are the long winding paths that can very greatly between levels. I definitely see how that would not work in that game, but it would be fun to see a tower defense game that had a depth of strategy with interesting decisions like plants vs zombies, but with long winding paths that would vary greatly from level to level.
Pick a simple game to create. Just building an engine is nebulous. I've done it before, and I just ended up working on cool features that never actually get used. Feature creep was particularly bad. You can definitely still create the engine, but just view it as reusable code for your game projects. You could make a game as simple as 3d pong.
I've becoming more and more convinced that inheritance is a code smell. This article explains my sentiments http://www.javaworld.com/article/2073649/core-java/why-extends-is-evil.html I tend to agree with it because inheritance has caused me plenty of frustrations. I really appreciate what the makers of golang did. They got rid of inheritance and make use of embedding and interfaces instead.
Am I wrong to think that inheritance should be avoided?
Like JoeJ said, if you want to interpolate between to rotations I would convert them to a quaternion and do a slerp between them. You could even skip the rotation matrix and go straight from Euler angles to quaternions.
If you lerp the Euler inputs your rotation may not take the most direct path. A simple example is lerping between 10 degress and 350 degrees. Instead of rotation 20 degrees it will rotate 340 in the other direction.
Another simple example is if you have an airplane pointed upwards at 45 degrees. Now suppose you have a rocket also nearly pointed up at 45 degrees but rotated 180 degrees around the vertical axis. If you lerped the Euler angles from the plane to the rocket it would rotate 180 degrees around the vertical instead of rotating 90 degrees by continuing to pitch upward. This may be the desired lerping behavior if you were rotating a gun turret, for example. However, in most cases, the properties of a quaternion slerp are much nicer.