I'm not aware of a C++ alternative, but there are some things that you'll have to take into consideration when using strtok(). It's not thread safe, so be careful with that when mutli-threading. It also modifies the original string, it returns a pointer to the start of the token and places a null terminated character at the start of the delimiter, so if you need the original string for some reason(I don't think you do in your case) you'll have to make a copy or restore the string.

You could also write your own strtok() like function that's thread safe and doesn't modify the original string.

I appreciate both responses, though they seem a bit conflicting. Many of the sprites will be the same. Similar to Terraria, there will only be a few different types of blocks, which will be repeated several times.

They seem conflicting because it's situational. I'm not sure how efficient Processing is in rendering a large amount of tiles, but it wasn't good enough in my situation. You're not using Processing, so you might not run into the same problem. I actually used a tileset from Terraria btw.

It sounds like I can always go back and find more efficient methods of displaying many sprites later on, if it comes down to them causing too much of a problem, so perhaps I can just see what happens when I place all of them, and change it if needed.

I'd suggest you do that, don't need to fix what isn't broken. However, If you do find it to be insufficient, the solution I posted is probably as efficient as it can get.

I recently made a platformer using Processing(Java) and for simplicity's sake I rendered each tile individually. It turned out to be too slow so I rendered the static parts of the world into much larger sprites(512x512), which reduced the amount of draw calls from about 800 to 2. I know that you can destroy/build tiles in Terraria, so if you're going for something like that you'll have to update the larger sprites when necessary.

As for keeping track of the entire level, I'd advise you to only render what's on screen. It's fairly easy to implement.

That is not what you're looking for. You want the tower to shoot when the enemy is in range of the tower right? To calculate the distance between two positions you'll have to use Pythagora's theorem. To keep things simple, to calculate the distance from point A to point B you get this:

Now if you want to check if something is in range, you don't need to calculate the actual distance, you only need to compare the squared distances. In your case you only have to check whether distanceSquared <= radius*radius.

If any of that is unclear, let me know and I'll try to explain in more detail.

You could map the creature partially to the skeleton, ignoring the leg bones or you could map it fully and it'll look...weird I guess. You could also allow the user to set how much the bones actually influence the doodle.

In 3D games creatures of different shapes and sizes often share the same skeleton, allowing one skeletal animation to be applied to different models. This works because the models are, so to speak, mapped to the skeleton.
I think you could something similar in 2D: create a 2D skeleton with animations and map the doodle to the skeleton and then deform it accordingly during animation. Mapping the doodle could be done manually or by some algorithm.

Yes that's correct. Another option is to temporarily change the camera angle so that the camera goes up, in most games there's hardly any obstacle that prevents the camera from going up. I went with 'first person view' when the camera gets too close because the camera angle is of significant importance when using the mouse, sudden changes would be very annoying to play with.

Im leaning towards option B. I think thats how most game cameras deal with intersections. Either way im doing a swept rectangle test. Except for option B i use the furthest position instead of closest.

What do you guys think? Would this produce satisfactory results? Is there a more efficient way?

From what point are you intersecting? I'd start from the player and backup until an intersection occurs, that'd be the nearest intersection. I use a sphere instead of a rectangle, easier to handle for me.

If you want strength to be equal to 0 on the edge of the radius and linearly increase to WellStrength when getting closer to the centre, you can use the following equation: strength = (1.0f - distance / radius) * WellStrength.

I'm not sure, but from looking at your picture I think a good place to start would be:

For every edge of the triangle, intersect the n-gon for the first vertex to the second vertex and the other way around. If there's an intersection and the intersection point does not overlap with an existing vertex of the n-gon, add the intersection point to the n-gon.

For every edge of the n-gon that lies within the triangle, look for a triangle vertex that makes up a non-intersecting triangle.

For every edge of the triangle that does not intersect with the n-gon, look for a n-gon vertex that makes up a non-intersecting triangle.