I am currently in my final year at school, studying for a Higher National Diploma in Computer Studies, and basically in this final semester, we need to develop a Software Pr
So, kinda like virii, then?
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.
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.
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
Real Robocode will get plugin for running .NET robots soon. It took me 2 years to achieve that. First year spent on refactoring original Robocode. Second one on Java to .NET bridge. And there are the alpha bits. This approach has benefit that you could fight with best Java robots. There is big treasure in the robots actually.
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: