slayemin

Unity3D is my first recommendation. You can get something up and running pretty fast. Admitedly though, I'm not very experienced with Unity at the moment. I've spent about a week on it. I like that it supports C#, but the built in IDE just doesn't compare to Visual Studio.

If Unity3D isn't suitable, you could use XNA. With your time budget, I think you could reach your goal without too much pain. Though, you'd have to recreate engine features, like particle engines, which come out of the box with Unity and is quite powerful.

The other fun part is decomposing light into its components so that you can apply Snells law of refraction. It's would increase your rendering time by a lot, but that can be alleviated by running mulitple threads or distributing the render jobs across multiple computers.

When I wrote my proof of concept, I defined light as a series of wavelengths and then looped through each wavelength and matched it to a color table. Thus, you could have pure white light, use chemical light sources like an argon, neon, or sodium, and simulate the spectral diffusion. Cool stuff! I can send you details if you're interested.

Considering your C++ background, I'd recommend picking up C# and going with XNA. You can have a simple game up and running in hours or a day (simple, like asteroids).

The net coding isn't too hard in C#, but it will take some planning and effort. Here are some questions to think about:
-What data do you want to send to other players? How are you going to organize it? (you're going to have to serialize and deserialize data off of a "stream")
-What happens if a player loses their connection?
-What if there is a data mismatch and your game states get out of synch?
-Are you going to use a peer-to-peer model or a client-server model? If client-server, how do you decide who is the server?

These are areas you shouldn't waste your time on:
-Shrinking the size of a data packet (you're on a LAN)
-Network and application security (This is a school project, not a public release)
-data validation (Use TCP/IP and just trust your clients)

My recommendation is to get something super simple up and running first. Then build the networking component, then make the game more complicated.
Example: Get two player controlled tanks to sit on flat terrain, each taking turns to shoot each other. Keep it simple. It should take a couple hours. Then, write the net code to get the games to connect and talk on a LAN, and then sharing game state data. You've now got a basic, networked, multiplayer game! Now, you can add features, update the network protocol, and see the changes in game play.

As far as network coding is concerned, most of the answers you're looking for a a google search away...
the basic outline is something like this:
1. Create a thread which listens for connections on a port
2. When a connection comes in, handle it and then wait for more connections
3. When a connection is established, think of both ends as reading and writing data from a file stream which can change under your feet. Before you write data out to the network stream, it has to be converted into an array of bytes (serialization). What those bytes mean is up to you to decide. When you get a stream of bytes, its up to you to decode and decipher their meaning as well. So, the common practice is to create a "header" which contains something to identify the type of data being sent, the byte length of the data, and then the data itself.
Trivial example:
suppose I have a "Mage" class like so:

class Mage
{
unsigned int ID = 1;
string Name;
}

If I want to send an instance of the Mage who has the name "Tim" to another computer, my serialized data would be:
[ID][Length][Name]
[1][3][Tim]
(but all the data would be converted to bytes)

The receiving computer will get an array of bytes containing this data. It reads the first byte, which is the ID. Then it says, "Aha, I know that I'm going to be deserializing a Mage object! The next item will be the length!", and then it reads off the value "3". Then it says, "Aha! The next value will be the data and its length will be three bytes! This data is going to be the name of the mage, so I should read it as a string!" and then it reads the next three bytes and converts them into characters which form the name "Tim".

You can also add extra metadata to handle the basic C.R.U.D. principles of all your objects (create, read, update, delete). You're also going to have to decide how you want to handle weird shit, like you sent a "Create" command for an object, followed by an "Update" command, but the "Update" command gets there first, so its trying to update an object which doesn't exist yet (which suggests adding frame numbers to the packet meta data and storing actions in a queue, but that may be getting unnecessarily complicated). It's great fun

Amazing!!!

So, could you get a rainbow by shooting a ray of light through a prism?

Okay, let's back up a bit... what problem are you trying to solve, and why did you choose frustum culling as the solution to this problem?

A lot of turn based strategy games can make good use of a minimax algorithm. This is good for deciding which action is the most effective one before executing it. Do you run away and heal your character?  Or do you close in with the enemy and try to deal more damage? With the minimax tree, you can play out all the possible scenarios and responses to see which one is best. So, if the enemy is a warrior and you run away and heal, the warrior will have to chase you to attack the next turn. But, you can run out of his range, so this is a "good" move. If the enemy is a wizard and you run away and heal, he'll just cast a ranged fireball at you, dealing more damage than you'd heal. So, its more beneficial to just attack the wizard and do what damage you can.
If you build your game model correctly, you don't have to write pages of complicated If statements to capture this type of reasoning. Just give your minimax tree a list of the possible actions your character can do each turn, the possible responses, counter-responses, etc. and let the algorithm calculate the best move based on the scenario.
For complicated games like Chess, where there are dozens of possible moves each turn, your tree is going to get a lot of breadth. Since the essence of chess is thinking further ahead than your opponenet (and not making mistakes), breadth * depth will start to great very large trees. This will create some memory and processing limitations as the tree grows large. So, typically the tree depth will be limited to a set point. If the player chooses the easy difficulty setting, then the AI may only maintain a depth of 5 tree. If they choose medium, the AI will maintain depth 10 tree. If they choose hard, they'll get  a depth 15 tree. The harder the AI is, the more time it will need to spend building deep and wide trees and evaluating the best branches to traverse. If you want to go insane, build a super computer with massive banks of CPU's and RAM and let the depth go really high, like 40. You'll get something like Deep Blue which can take on the worlds greatest chess players.
One technique you can use to save yourself some processing and RAM is to prune the tree a bit. If there is an obviously bad move (such as putting yourself into checkmate or losing your queen), you can stop traversing any subsequent moves down the tree. This is what people are really good at. The techniques for trimming and pruning your decision tree is where the specialized AI programmers differentiate themselves from the unspecialized programmers (I'm just a unspecialized programmer).

If your game is running in real time, you *may* be able to still get away with using this. If every ability has a cooldown time before it can be executed again, you can create a turn which is a set timespan in which actions can be performed, ie, you can swing your sword three times every five seconds, so a standard turn lasts for five seconds. Scripting complex if/else statements consisting of actions may also be a good way to go.

Every point on a circle can be calculated by:

x = radius * cos(theta);
y = radius * sin(theta);

Where, theta is all values between 0 and 2PI, and radius is greater than zero.

So, to draw a circle, you can could either plot a bunch of pixels to the screen at the X,Y coordinates as you loop through every value of theta...
or you could draw line segments between each of the X/Y value pairs for all values of theta.

I've experienced the mouse problem. What I do is place a graphic on the screen which represents the mouse cursor. Then, I update the mouse cursor position based off of the change in the mouse position relative to the last frame. I think there's even a function which will give you the dx, dy for mouse. Then, all you have to do is make sure that the mouse cursor is constrained to the screen dimensions. The part you're going to have to decide on is how you're going to handle the right edge of the screen -- do you let the mouse hot spot move all the way to the edge of the screen and clip a part of the graphic, or do you always display the entire cursor icon? What if you have a GUI element, like a scroll bar, on the far edge of the screen?

As for the UI offsets, it sounds like you're not finding the edges of the client rect correctly. You're going to have to step into the debugger to see exactly what's happening with your GUI element positioning.

Okay, I think I understand.

I didn't see this mentioned in your post or in your code, so I'll bring it up. If the player is on the edge of the map, how do you handle it? If you have a grid of 100x100 tiles, the view is always centered on the player, and the player is located at (0,0) (top left corner), what happens? Do you keep the player centered or does the player move to the top left corner of the screen?

(x).ToString() + "_" + (y).ToString();

You don't need to surround your variables with parentheses.

I think your whole approach is flawed, and I'm not saying that to be mean. Here is what I'd change:
1. Use a camera.
2. Store your tiles in a 2D array.
3. Use a quad tree for collision detection.
4. Use "layers" in your map (terrain, static terrain objects, creatures & items, etc).
5. Break your map class up into more objects.

Use a camera:
What you want to do is to create a camera viewing rectangle. If map objects are within the viewing rectangle of the camera, then they are rendered. If you treat your view as a viewing rectangle, you can do a lot more with it (panning, zooming in and out, centering on an object, tweening between points, etc). Rather than rendering everything relative to the character position, you render everything relative to the center position of the camera and, for the most part, keep the camera centered on the player. This makes it much easier to handle the map-edge cases. You could also do interesting features, where if your character is moving in a particular direction very quickly, you can adjust the veiwing area of the camera to show more of the world space in front of the character so that they have more time to react.

Store your tiles in a 2D array:
You can either store the tile objects directly, or just store an index in a 2D array. How you store your tiles should be independent of how you're moving on the tiles and viewing the tiles. Your character movement can be simplified into an X & Y position, and handled with requests to the map manager. Character tells the map "I am at this position. I want to move left one space", and the map manager reads the map array and says "Okay, that's a legal move! you can set your position there." or "Nope, that can't be done. There's a tree there!" or "Nope, you're on the edge of the map and you can't go left any further!"

Use a quad tree for collision detection:
Once I understood the concept, it didn't take me more than an hour or two to get a quad tree datastructure up and running. The idea is to put your spatial objects into the smallest box which will contain them, and keep dividing the box into fourths until its empty. Then, when you're doing collision detection, you only need to compare the objects in the largest box against all of its child cells. This changes your collision checks from O(N*N) to O(log N) (best case). The tiles which are being viewed would be all the tiles which collide with the camera viewing rectangle (don't necessarily need a quad tree for camera rect, you can also do a rect.Contains() call against all tiles in the game model which is more computationally expensive but works)

Use layers in your map:
Terrain is the first, bottom layer. This tends to make for boring maps because they're plain. So, create another layer and add trees, flowers, rocks, and any other terrain objects. These static terrain objects are non-moving, so this simplifies collision detection a bit (you're not checking if a tree is colliding with another tree every frame). Then, you'll also have another layer for moving objects (monsters, player characters, bullets, pick ups, etc). These objects may move every frame, so they can collide with other objects in their layer or objects in the static objects layer. By layering your map, you can be a bit more flexible. A tree can sit on a dirt tile or a grass tile, instead of creating a tree-dirt tile and tree-grass tile.

Break your map class up into more objects:
You're currently trying to do too much "stuff" in one class. Break it up a bit. You've currently got a class which contains map metadata, tile information, character information, character movement logic, screen resolution logic, and resource loading logic all in ONE class. This makes your class design VERY rigid and all of your object interactions are hardcoded. This makes your class have 430 lines of code. You want all of your objects to be as decoupled as possible and interacting with each other via class method calls. I like to use the model view controller design pattern. The model doesn't know about screen resolutions, it only cares about maintaining the game state and game logic, and updating it. The view doesn't care about the game logic, it only cares about correctly rendering the game state to the current rendering settings (resolution, anti-aliasing, shadows, etc). The controller doesn't care about rendering very much (except for getting its controls rendered, such as buttons and drop down menus), it only cares about interacting with the game model.
Some people like to break it out even further and add a data layer to handle data read/writes to and from a file or database. I generally include that in my game model objects.
So, I'd create at least the following classes:
-Map
-Tile
-Character
-Camera
-Player (inherits from character)
-Monster (inherits from character)
The map class would contain one or more 2D arrays of tiles, any meta data about the map (like map name, map size, etc), and methods for loading and saving to disk.
A tile class would contain tile specific information, such as the tile texture, tile dimensions, tile type, movement point costs, etc.
The character class would be an abstract game actor class which contains generic data about a character (hitpoints, name, position, dimensions, etc)
A player class would mostly have UI and controller specific methods
The monster class would be an extension of the character class, maybe with some added AI scripts to control it and do monster specific logic.
I like to keep a global class of loaded art resources (and call it a texture database, or TextureDB for short). Whenever I create a new object, I set its texture to point to one of those stored art assets. By doing this, I can centralize all of my resource loading into one object. Then, all I have to worry about is making sure that the TextureDB has all of the correct art assets loaded up. I can also load art assets into the TextureDB by reading a file for a list of needed art resources (art manifest), so if I load a game level, the level data would contain a list of all the art resources it uses. The textureDB would load those assets into memory, and off we go!

Warning: general hand waving to follow:

As for your rendering code, all you should be doing in the draw function is calling each object and telling it to render itself according to its current state. So, if you have a map object, your render code should be this:

Map.draw(spriteBatch);

Since the map contains a list of tiles which will know how to render themselves, it'll do the following:

//you'd also do a foreach for each layer, so you render terrain first, followed by static objects layer from top to bottom, followed by moving objects layer, etc.
foreach(Tile t in TileList)
{
	 t.draw(spriteBatch, position);
}

To move a character on a map, you'd make a request call to the map manager, something like this:

if(KeyboardInput == MoveLeft)
MyCharacter.Position = Map.MoveTo(MyCharacter.Position, new Vector2(-1,0));

And the map manager would get the request and handle it something like this:

public Vector2 MoveTo(Vector2 Pos, Vector2 Dir)
{
	 Vector2 RequestedTile = new Vector2(Pos.X + Dir.X, Pos.Y + Dir.Y);
 
	 if(Tile[RequestedTile.X][RequestedTile.Y].isPassable() and not Tile[RequestedTile.X][RequestedTile.Y].isOccupied() and blah blah blah conditions)
	 {
		  return new Vector(RequestedTile);
	 }
	 else
	 {
		  return Pos;
	 }
}

I find the Model-View-Controller framework to be a helpful framework to keep in mind and to design to.

Your game is the "model". This would contain all of your data structures, game objects, game states, the state of your game objects, process the next frame, turn, etc. It's the guts of your application. It doesn't care at all about rendering stuff to the screen or collecting input to change the model*. It's very abstract.

Your "view" has the sole focus of representing the state of the "model" to the user. It doesn't do game logic! I like to think of it as the artistic manifestation of your model. Since it's "artistic", that means that you could interchange one view with another to get a totally different view of the same data. Real world example: I've got a database driven application. The model is the data and how it all interacts. The view can be rendered as either a windows application or a webpage. I wouldn't have to change any code in the model because its completely unconcerned about rendering.

The "controller" is how the user interacts with your model. Sometimes, it's intertwined closely with the view (use the mouse to click on a button!), but its not necessary (press "F1" key to fire torpedos!). A controller will send a command (better to think of it as a request) to the model and the model will decide if it wants to honor it and change its state accordingly ("okay! I've created a torpedo!" or "nope, you have no torpedos left or its not ready to fire again!"). Again, we are NOT putting game logic into the controller. We're using it as a way to interact with the model which contains the logic to do the requested action.

So, just by looking at your code, I can see that you have a single class which is concerned with rendering. This would fit within a "view" portion of the MVC framework. It's not enough to tell you anything about whether or not your classes are well architected because we can't see how they're interacting with each other.
One slightly worrisome thing I'm seeing though is your liberal use of public access for internal class variables. Do you do this with your other classes? It may not be a big deal for small projects, but you will start to run into problems with larger projects. I like to assume that I'm writing my classes to be used by the biggest idiot in the world (me). If there is a way someone (me) can completely screw it up, then it's only a matter of time before it happens (sleep deprivation, forgetfulness, laziness, sloppiness, etc). When that screw up happens, I have to waste time debugging to isolate the source of the problem ("OH! I'm getting errors because this completely unrelated class thinks it should be allowed to come into my class and muck around with its variables?! He wants to divide by zero?!). So, when you're designing your class, think of yourself as a miser who will only give access to your class if and only if there is a good reason to, and that access will be on your terms rather than the users terms. If something is public, it's free game for a legion of monkeys to use. Would you like a legion of monkeys twiddling with your class methods or class variables?

From my experience, the greatest obstacle for your team will be motivation. You can pretty much plot the average team motivation level with the function: f(x) = 1/x, x > 0;
The y-axis is the motivation level and the x-axis is time. As you can see from the graph, it starts pretty high but it quickly dips and starts to taper off. Your people will have a hidden parameter which they don't know and you don't know, and it is their minimum required motivation to continue with the project.

if(currentMotivation <= randYVal)
LeaveProject();

There's also this weird phenomena where as a person's current motivation approaches their minimum motivation level, the amount of work they do decreases as well. The symptoms of this are flakeing out, laziness, lachrymose, etc.

As the project initiator (and presumed manager), the good news is that you've got control of this!! Your goal is to keep team morale as high as possible and lengthen the time it takes for it to taper off to project failure. Ideally, you'll have a project which has a completion time well before motivation failure. You can control when the project gets completed and when motivation failure occurs by ensuring that the size and scope of the project is attainable, by making significant progress on the project, by keeping personality conflicts to a minimum, by paying team members, by keeping poisonous personalities off the team, by setting a high standard and holding people accountable to it, and being realistic about current circumstances at all times. Eventually, the initial appeal and zest for the project fades away and everyone has to put their nose to the grind stone to complete it. It stops being "fun" and becomes "work", so when this happens, it becomes the true test of your project management skills, team cohesion, and the infrastructure you've put in place.

Ultimately, you need to take a realistic assessment of your team and its capabilities and pursue an achievable project which can be completed before morale failure occurs.

uart777: I learned a hard lesson a few years ago: The person playing your game doesn't give two shits about whether you wrote the code in ASM, C, C++, Fortran, C#, Visual Basic, LOLCAT, java, javascript, Malbolge, etc. All they care about is whether or not the game works and whether or not it's fun. In 2012 (going on 2013), you have LOADS of language and platform choices to choose from to make a game. Whatever language/platform you choose, your end user won't care because it doesn't matter. If it DID matter, then the language used would be prominently featured on the box art. Today, we've got multicore processors which run around 3.5Ghz , gigs of ram, hard drives with terabytes of space, and graphics cards supporting hardware so beefy that they're practically super computers. We can afford to be a bit more lax with our bits. It's a waste of programmer time to worry about how bits are laid on the wire when there are platforms and technologies which have already figured it out.

Since the programming language doesn't matter much anymore, we are free to be a bit more picky about what language we pick. Here are my principles:
-How robust/flexible is the language?
-How easy is it to learn?
-How easy is it to maintain the code after its writen? (I'm looking at you, x86 ASM!)
-How much boiler plate code needs to be writen to get a feature rich game running?
-How well is the language specifications and API documented?
-How much industry support is there for the language?
-How portable is the language to other hardware and software platforms?
-What is my (or my teams) language proficencies and background?
-How much of an existing code base (libraries) do I have?

If(making games)
{
If you're doing it right, you're sweating over high level design decisions and choosing the best algorithms for the job you're trying to do. Doing this well is much more valuable than sweating over the bit order of a pixel residing in memory.
}

If(Writing hardware device drivers)
{
Okay, sweat over the most efficient ordering of bits for your hardware device. I assume you're working for nVidia or ATI and working very closely with the hardware engineers to maximize driver performance so your end users (API & game devs) don't have to.
}

Back on topic....

To OP: I follow a similar pattern. I consider myself somewhat of a novice at designing game architectures, so take what I say with a grain of salt:
I have a base class which every game object inherits from (already may be a bad idea). The class is abstract and pretty much worries about assigning an incrementing ID, possibly accepting a given name, maintaining a queue of messages, and enforcing the implementation of update and init functions for classes which inherit from it, and acting as a generic object which can be used by containers (pretty much polymorphism). That's it. Any inheriting classes will extend this base class.

Here is the C# code for my base class:

public abstract class GBO
{
	 UInt64 m_ID;
	 static UInt64 m_nextID = 0;
	 protected string m_name;
	 public Queue<GameMessage> Messages = new Queue<GameMessage>(10);
	 
	 public GBO()
	 {
		  m_ID = m_nextID++;
	 }

	 public GBO(string Name)
	 {
		  m_ID = m_nextID++;
		  m_name = Name;
	 }
	 public UInt64 ID
	 {
		  get { return m_ID;}
	 }
	 public string Name
	 {
		  get { return m_name;}
		  set { m_name = value;}
	 }
	 public abstract void Update();
	 public abstract void Start();		  //I use "Start" instead of "Init" for Unity3D
}

Looking at my base object and thinking about it, it does have some weaknesses:
If I decide to create particle engine and each particle is a GBO class, do I really care about the name of a particle or any game messages it may have generated? Not really. I could slice those two variables out. The ID is mostly used as a key for dictionaries and hash tables, but would a particle ever be stored in a hash table or dictionary? Not really. So, if I slice that out too, then my base class would just have an abstract "Start()" and "Update()" method. Do I even need those? I already know that all of my game objects have to implement initialization and update functions, so enforcing it is a bit of a moot point and possibly restrictive since they don't have input parameters. I might as well have a completely blank base class to support the most flexibility... but why even have an empty class if it doesn't do anything? Do I even NEED a base class?
"Oh, what about using the base class as a generic container object? That way, you can have a single list of all your objects in the game and call their update() method!"
Well, every inheriting class would have a corresponding manager class. The manager class itself can have update called on it and we'll let the manager worry about updating its objects.
Instead of:

foreach(GBO obj in m_allObjects)
	 obj.update();

we can do this:

MageMgr.Update();
MonsterMgr.Update();
PlayerMgr.Update();
BulletsMgr.Update();

Is this "better"? One immediate disadvantage is that we explicitly have to create and call the update functions for every list of items we have in the game. This adds extra programmer overhead. But, is there an advantage to asking the manager to update its contained items? I think so. The manager can worry about the game logic in regards to the object. So, for example, your mage manager would not only call update() on all of the mages in its list, it would also manage the list of mages by removing any mages which are dead (hitpoints >= 0) or perform any other trivial object specific management.
If you really like the super simple single update, you can let your manager classes derive from an abstract manager class which has an update function. Then, you'd have a list of managers, for which you update every frame:

foreach(GameObjMgr mgr in m_managers)
	 mgr.update();

Then, you just have to worry about instantiating a manager class and inserting it into the manager list.

Anyways, I really don't know much about "good" software engineering and game architecture. I may be oversimplifying the core of game development: Managing lists of "stuff" and applying rules to them.

I think I understand what you're asking.
The advantage of using a Rect is that it saves you CPU cycles and it simplifies your code. If you're not using a quad tree and just going with a dirty O(n^2) collision check, your going to have to spend extra cpu cycles calculating the bounding areas of each rectangle. You're right about the rect consuming more ram though.
Idea #1:
You could create your own rect class. Have two versions:
Version 1: It's just a wrapper for the build in Rect. If this becomes too ram heavy, switch to version 2:
Version 2: Assuming your rects are all squares of a fixed dimension, all it stores is the center X/Y coordinate. But, it has the same methods as the built in rect.

Idea #2: Collision detection with really fast objects.
The general idea is to draw a line from your moving objects current position to the next position its going to occupy. Then, do a line intersection test with all collidable objects. If there isn't anything colliding with the line, it's safe to move the object to the next position. If there is a collision, then you know the position on the line you're colliding at and you set your objects position to that point on the line. If your moving object is thicker than a pixel, then you have to find the edges and draw two lines to represent the thickness. Example: If your object is 5px wide and is falling straight down, then your first line starts at x, second at x + 5, and the end points are the velocity position with the same X offsets.

Ooh... I think you might be over thinking this a bit. C# comes with a Rectangle class, which comes with a built-in collision check method called Contains. If you use that, you can probably reduce your 54 lines of complicated looking code into about 5 lines of code. Ideally, this is what your code should look like in your update method:

pseudo code:

public void Update(GameTime gameTime)
{

position += velocity * gameTime.elapsedMS;

foreach(GameObject obj in AllMyCollidableGameObjectsList)
{
	 if(obj.rect.Contains(this.rect))
    {
		  this.HandleCollision();		  //varies by what your colliding with (bullets, terrain, items, etc)
    }
}
}

The collision detection is overly simplistic here just for illustratation purposes. In your code, you'd want to handle the extra stuff, like object elasticity, overlap of bounding areas, pushback, changes in velocity, etc.