Developing a Robocode type game with .Net, for a School Assignment

Solution 1:

is this project feasible at all ?

It sounds big. I don't know how much time you have. Here's a rule of thumb:

• When the drop-dead due-date happens, if 90% of the system delivering 90% of the functionality is 100% complete, then you might say that the project is at least 90% successful.

• OTOH if 100% of the software delivering 100% of the functionality is only 90% finished (i.e., is not finished) then nothing is finished and the project is a failure.

A key to success, then, is "incremental development" and "continual delivery". Your project specification says:

We need to develop a Software Project, that basically incorporates a whole system.

To do this, I suggest:

1. Create (i.e., design, develop, and test) a small whole system
2. Repeat { backup or version control what you have; add a new, whole little bit to the system, and test it until it's satisfactory } until (you run out of time).

Solution 2:

When I began working with WPF (which is much the same as Silverlight) I ended up spending a lot of time figuring out how to do things. It is a very different way of making a GUI than what else I've tried and there seems to be a billion different ways to do things. My point is, that if you have no experience with WPF/Silverlight I suspect it is going to take a lot of time for you to wrap your mind around. I guess it depends on what you already know.

Apart from than, I wholeheartedly support ChrisW's suggstion about incremental development. I'll give you an idea of how you can approach the design of the game. Start out with a very simple API for the bots, say two functions with no events, input or knowledge of the world. Just start by getting the bots to move. The point is to get a fully functioning program with the simple functionality, including all parts from loading the client code to showing the resulting 'battle'.

Each bot should implement an interface with a single method run() and be in their own dll file. When the battle starts, each dll with the interface implemented is loaded (using reflection) from a certain location and instantiated. Then start a battle with a loop until 1 minute has passed (or whatever, just to see that something is going on):

while (time is not up)
   generate random sequence for bots
   call run() on each bot
   draw(world)

When the time is up, the battle is over. Now you have a skeleton application which you can begin to flesh out and which will let you have a working program, even if you won't have time to make all the functionality you would like. In the run method, the bots can call the couple of move actions you have defined in the API. Calling these will change the state of the world - probably just a grid of tiles, and the location of each bot.

The next step could be to add a view of the world to the bots' run method, changing the loop to this:

while (time is not up)
   generate random sequence for bots
   call run(WorldView) on each bot
   draw(world)

Let's say that the bots can still only perform a couple of move actions in their run method. Now they have the option of getting a view of the world (or their part of it) which allows them to move towards or away from enemies and avoid walls.

In the next iteration you could then create a single API function to shoot you cannon (or whatever is appropriate your game). Implement how this changes the world state, how the bullets are tracked and how the animation is represented, etc. The loop could look something like this:

while (time is not up and there are more than 1 bot alive)
   advance projectiles
   calculate projectile-bot collisions and damage
   generate random sequence for bots
   call run(WorldView) on each bot
   draw(world)

I hope this gives you an idea of how you can iteratively flesh out the program, all the while having a working program that reflects all the areas of the game. I don't have much experience with implementing games, so you should look at my advice with a critical eye but this is how I would attack the problem.

Solution 3:

It's very feasible.

I suggest starting with the back-end system and objects that respond to "compiled" robocode. What form that "compiled" code takes is all you.

Then, create the interpreter for the robocode. Or, it sounds like you might just be able to make the .NET classes. That's a freebie on the hardest part.

Finally, create any UI you might require...all set.

You might want to have the robots compile as .dlls ...nonetheless, you just have to create the common interface for them, and functionality.

Solution 4:

feasibility totally depends on your team's ability, familiarity with the framework, etc. I've seen people who could knock something like this out in a week, and others who couldn't do it to save their lives.

The reflection approach you mention sounds like the wrong track, unless I'm misunderstanding you. Your 'Robot' base class should allow developers to override one or more methods, from which they can call functions like 'Shoot', 'Move', etc..

One other app that was similar to this is Terrarium. Developers could code animals and pit them against others in a distributed environment. It was a .NET 1.1 demo app, and is a bit dated, but some of the principals may still be helpful to you. This guy has taken on rewriting it: http://weblogs.asp.net/bsimser/archive/2008/07/16/reintroducing-terrarium-now-with-2-0-goodness.aspx