Yeah, loop through the squares and see if the mouse overlaps. Keep track of the nearest one. At the end of the loop, you know what was clicked on. Sounds good.
You have to define what 'better' means. There's lots of opposing ways to make something 'better', and making it better in one direction almost always means making it worse in some other direction.
If you want it "better" in terms of minimizing the number of squares you have to test against the mouse, there's several things you can do. One way is to split the screen into a coarse grid and have a list of squares per tile. Then you get the tile the mouse overlaps and only loop over those squares.
You could organize the squares into more complicated structures like quadtrees, etc. to minimize the number of intersection tests.
There's other ways you could want it to be 'better'. Maybe you want the algorithm to be more paralellizable so you can run the algorithm across multiple cpu cores. In that case I would split the squares into batches, and hand each batch off to a core. Each core will find the 'best' match out of their set. Then take that reduced number of squares and find the best out of that.
Maybe you want it 'better' in terms of memory usage (minimized). Maybe that means you store the rectangles in a compressed format in memory. That may end up having a profound impact on the speed at which you can iterate over and do the intersection tests, but it will take up less memory.
A better way to think of it is you have more normals than *positions*, and positions != vertices. A vertex is a unique combination of a postiion, normal, and whatever other attributes belong to the vertex (uv, color, etc)
Typically data formats (like collada) have a set of indices per vertex - so for a single vertex, it will index separately into the position stream, normal stream, etc. This is different than what GPUs support, which is a single index per vertex that indexes into every attribute stream (typically interleaved) with the same index.
When building an interleaved vertex buffer for a GPU, you'll end up duplicating attributes across vertices. My typical approach is to create an 'index tuple' per vertex when reading the collada data, the index tuple contains the index for each attribute into the source data for that vertex - from there it's easy to take each index tuple and create a unique vertex for the GPU.
You can do simple stuff by casting rays against the terrain mesh and seeing if the rays intersect the mesh, and where
For instance, take the object's current position, and the new position (that you'd like to try and move to). Start a raycast from some distance above the new position, and cast straight down. That'll give you the height of the terrain at the new position.
If your desired position ends up below the terrain, you're trying to walk up a slope, and the difference in height from your current position and new terrain height is the slope - if that difference is too great, you may want to not allow movement ("too steep").
If the terrain height ends up below your new desired position, you may have just walked off of a cliff (transition to "falling" state + animation?).
If the difference is within some small threshold, you might just want to snap to it, so as to instantly follow the curvature of the terrain
That should give you a pretty basic system to start with.
EDIT: I should mention this assumes your terrain is a heightmap. If that's not the case, you'll need something more complex.
Original post by generic_username First of all, what program language is most commonly compatible with popular engines like Unreal Engine and others?
Unreal has its own script language (kismet). Lua is a popular script language in other engines, and sometimes as a designer you'll need to involve a programmer, which typically means C++
Original post by generic_username I've only learned HTML so far
HTML is just a way to mark up documents to make them pretty, it has nothing to do with programming
Original post by generic_username Does the Unreal Engine work well for games that aren't shooters? What 3D engine would be good for a 3D side-scroller or game with an isometric view?
first-person vs side-scroller vs isometric are just different camera behaviors - unreal can do all of them, you have to define what happens to the camera when you press left/right/up/down etc. For example - pressing 'up' in a first person game probably moves the character forward, whereas in an isometric game you'd want 'up' to just scroll the camera along the map - the engine has nothing to do with this, it just exposes a generic way to script camera/player behavior to do whatever you want
Original post by generic_username It should be said that I'm more interested in game design than learning complicated programming stuff, but programming seems to be involved in all entry-level positions in the video game industry, so I'm assuming that it's something I need to learn.
There's a number of different types of designers in the industry. It wouldn't hurt to have some programming skill. Technical designers / scripters need programming skills by definition. That said, if you mess with the visual kismet editor in unreal, it might not feel like programming