Posted by Khatharr
on 01 September 2016 - 07:44 PM
My suggestion would be to save up $10 every week and just start out doing what artwork or planning you can. Before long you should have enough to buy a decent graphics card. You don't need to spend anything like $300 for a card if this is all you're after. I've been using this http://www.newegg.com/Product/Product.aspx?Item=N82E16814127783 for quite a while now and it runs everything I need just fine. Apparently there's a slightly cheaper version of the same chipset as well (http://www.newegg.com/Product/Product.aspx?item=N82E16814127836) though that's clocked a little lower. You're probably going to want to use Blender to make 3D assets, and I'm not sure you can pull it off with what you have right now, but the card there will do it just fine.
If you're interested in visual scripting then you may want to take a look at UE4 once you have capable hardware. It uses a visual scripting system called Blueprint that's decently straightforward, and is fairly similar to Unity. There are a lot of tutorials on their site as well. Game Maker Studio is free now, if you're interested in 2D. I'd recommend poking around and deciding what best fits your needs.
Posted by Khatharr
on 01 September 2016 - 07:29 PM
Is this only for the character, or also for projectiles, etc? Are your walls always perpendicular to the ground? If so then you can do circle-vs-edge, since your problem would effectively be 2D. If your geometry is static then you can tessellate it into regions beforehand and skip the broad phase entirely, since each region will know exactly what walls are within reach.
If you have your visibility volumes worked out then you can just calculate visibility/cover geometrically on a simple collision primitive. If you put an AABB around the target then work out your visibility you can just figure what percentage of the AABB overlaps the visibility volume. If you do it in 2 dimensions it should be straightforward. You're just comparing the volume of the overlap with the volume of the AABB. If that's not precise enough for you then a circles could work too.
Half-decent hashing can significantly reduce the performance impact of using strings.
What you're describing is something that scripting languages are really specifically designed for though. Be careful not to spend months working on patchwork solutions and then decide to embed an interpreter and end up throwing all that work away.
Looks like it's got a few techniques that it's delegating to based on distance from the player character. If it's too close it backs away slowly, if it's slightly too far then it plays back recorded player positions, if it's significantly far then it just approaches the player as quickly as possible.
Over-engineering appears to be cathartic to a sizable population of engineers. Making things that feel more elegant to you can be satisfying, even if it doesn't actually meaningfully improve the project.
Rather than determining the winner twice (once in the loop and once after), why not use an int instead of a bool? The int could be called "winnerID" and a value of zero would indicate that nobody has won yet.
p2score increments by 2 every round. You can express that as p2score += 2.
What would happen if the scores started at 1 instead of zero?