FFFFFFFF- I've been typing up a response for a good hour now on how to structure RPG projects, and only now I read that you're actually doing an RTS. Derp!
>if I want people with macs to play it, I'm going to need a programmer who is proficient with Objective-C and Cocoa to help me port this
Not a good idea! Making an RTS is hard enough, making a multi-platform application is even harder, but porting a finished game with a presumably large codebase to an entirely different language and underlying technology is madness. Especially when you consider that even a "finished" game will change - bugfixes and the likes will force you to update your code, and maintaining two codebases in different languages under these circumstances is very tedious and error-prone.
These are the kinds of things you need to think about beforehand - what platforms do I want to support and which language do use? Remember not to choose the language that is the most convenient, but the one that is best for the job.
C# is okay, but you will have to give up on multiplatform support (well, I guess you could include Linux, but Mono support is a little flaky).
>Ideally this game with have multiplayer (though thats a secondary concern, the primary goal is to get singleplayer working. One step at a time)
Multiplayer support is not something you can hack in later - you need to decide on these things beforehand and design your engine accordingly.
>Each faction would have the same number of units (I'm thinking between 8-10) and buildings (somewhere between 5-8 I'd think), and would have units and playstyles which match the feel of the faction
Before actually making the game, you need to specify *what* units and buildings there are and what their capabilities are. You can't create an engine if you don't know the requirements. It's also probably not a good sign that you're trying to get other people to join when you don't even have the core elements of the game pinned down.
To avoid looking like every other "I need artists for my game" request, you need a complete gameplay description and a few references to show what you're capable of - a paragraph of plot to set the context and "I'm a CS student" won't do ;)
>I'm a firm believer in bottom-up design, so it won't look like much for a week or two
The trick is to not post about your project until you actually have something to show. This makes it much more believable that you have what it takes to finish the project.
Since you're doing an RTS, it's very easy to make it look like something - if you've played Supreme Commander before, they offer a simplistic view of the map by displaying only icons for units, buildings and resources (pic related). In movement and combined with a cool-looking landscape (tilesets for which you'll find on the internet), you can get something good-looking very fast.
Pathing is among the most difficult topics in RTS games, and it's very important do get it right. Nothing is more frustrating than having your units slaughtered despite being superior because they got stuck or travelled back and fro because the pathing system can't handle huddled units.
The collision response you have is very basic, but it kinda misses the point - what you need is collision avoidance (i.e. clever pathing), not collision response. Simply not letting units clip through each other instead of adjusting the respective paths will break if you have a bunch of units on close space (say, when trying to move your army through a narrow maze of buildings).
I'm pretty sure there are resources on how to deal with this problem out there - try googling it.
Graph based pathing algorithms don't make much sense on a tilemap, since your nodes are in a completely regular grid and the edges always stay the same. Dijkstra on a tilemap simply reduces to a less efficient flood fill implementation :) (don't even try A*).
Usually though developers try to cut down on the number of nodes by using a pathing mesh layed on top of the tilemap, in which case graph based algorithms are useful again. But still, it's hard to deal with dynamically moving units when trying to avoid collisions and still moving them around on the map efficiently.