Jump to content
  • Advertisement
Sign in to follow this  
Timkin

Unity Advice/ideas needed: program/library organisation problem

This topic is 4150 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi folks, I've inherited a program for a subject I'm taking over the teaching of. The code is very poorly written, buggy and needs a rewrite. Hence, I'm taking this opportunity to review one of the key issues in the code design and I'm looking for advice/ideas on how to improve it, while still achieving the desired effect. The program is a game world that students must write supplemental AI code to control an object within the world. Presently they do this by supplying a DLL with a given name which exports a function with a set interface. The program calls their function each iteration of the game loop to determine the control actions for the object in the world (in this case a space ship). They essentially have to write the guts of the exported function (and all additional hidden functions they need to make their AI work). They can access information from the game world (this is presently passed to their function as a game state object chock full of data. Ideally, I don't want them having access to the code base for the game, as some students may attempt to exploit weaknesses or knowledge of the limitations of the game world (such as kinematic model parameters) to enhance their AIs performance (which directly affects their mark for the subject). In principal, all they should have access to is sensors for observing the world (or limited portions of it). From this sensor data they must determine the control action. Should I stay with the present AI-in-DLL model, or can you think of a better way? I need to be able to quickly run any students AI, so I want to avoid the need to compile each students work. I had considered having them script their AI, but that's too limiting on students (and requires too much overhead in the development of an appropriate scripting language). I also want to avoid having them submit compiled game code, on the off chance they might have hacked the game and cheated. My inclination is to provide basic source code for the game loop and hide the game world within a DLL that exports a sensor interface class that the students could use within their DLL to obtain data. Students can compile this game code as needed during their development, but they submit only a DLL. Is this sensible? Is there a better alternative? Feel free to ask whatever questions you think are relevant to determine a good solution...I'll do my best to answer them. Oh, the code is presently written in C++. Cheers, Timkin

Share this post


Link to post
Share on other sites
Advertisement
I think you *could* do the DLL method, although it wouldn't be my first choice. Messing around with DLLs is not very fun. If there are any problems with a student's build (like forgetting to implement a function), those errors are harder to debug when using a DLL than with other methods.

Also you'd have to teach them how to build DLLs, there are ways to do it wrong. Although I guess you could just hand them a template project and tell them not to touch the settings.

My first choice would be to use a scripting engine. (Unless of course, you're specifically trying to teach them C++ :) ) Don't write your own, just embed an existing one. One major advantage here is safety. You won't have to worry about one student screwing up another student's work with memory leaks and buffer overflows and whatnot.

Share this post


Link to post
Share on other sites
Thanks for the input pinacolada... some thoughts though...

Quote:
Original post by pinacolada
I think you *could* do the DLL method, although it wouldn't be my first choice. Messing around with DLLs is not very fun. If there are any problems with a student's build (like forgetting to implement a function), those errors are harder to debug when using a DLL than with other methods.

To be assessed for their project they must submit a compiled, operative DLL by the due date. If they don't, it's returned to them. They can fix it an resubmit it, with the usual penalties that apply for late work if it is after the deadline. They have a whole semester to get it right and a LOT of practical class time to get direct help with such issues. There really are no excuses for not getting it to compile.

Quote:
Also you'd have to teach them how to build DLLs, there are ways to do it wrong. Although I guess you could just hand them a template project and tell them not to touch the settings.

They presently get a very basic DLL project supplied to them. They fill in the blanks.

Quote:
My first choice would be to use a scripting engine. (Unless of course, you're specifically trying to teach them C++ :) ) Don't write your own, just embed an existing one. One major advantage here is safety. You won't have to worry about one student screwing up another student's work with memory leaks and buffer overflows and whatnot.


There are two principle reasons to avoid using a scripting engine:
1) Available engines are VERY limited in the AI that they can achieve (and very slow for complex AI without extreme hand tuning). Try implementing Q-learning, for example, in script. It'd require me to define a whole lot of additional functionality for the chosen engine. That leads to the second point...
2) You're limited to the techniques implemented by the engine. One of the major features of this unit is that students are not forced to solve the AI problem using any specific technique. They're taught a set of useful techniques that could solve the problem, but they have the freedom to explore their own ideas. Just as in industry, they are given a performance specification for their product and are free to work out how best to achieve that for themselves.

Share this post


Link to post
Share on other sites
Why not use C# for the core engine and scripting? You already limited your students to Windows since you use DLLs, so that shouldn't be a problem. In C# scripting can be done very easily. It would allow them to use all features C# provides. C# runs quite fast, so speed shouldn't be problem. Its syntax is also quite to C++, so if your students already know C++, it shouldn't be too hard for them to learn basics of C# quite quickly.
There was a thread a while ago how to do .NET scripting - Easy Scripting in .NET. It does not seem too complicated and should be powerful enough for all your needs. Game data can still be supplied to the AI update function as some kind of object.
The only problem may be that this would require massive rewrites on your part. So it is probably not an option if the code base you would need to translate to C# is too big.

Share this post


Link to post
Share on other sites
You could solve the "hacking" problem by having each AI run as a separate process which communicates with the "game world server" over sockets or some other IPC mechanism. Then students could use any language they wanted as long as it supported that IPC method.

Share this post


Link to post
Share on other sites
Thanks for the ideas. Some further feedback...

b2b3: I have a few problems with pursuiing C# for scripting. The first is that while I'm a competent C++ programmer who could presumably learn C#, the students are not. The engineering students who take this subject known only C... they get taught C++ during the course (we could change that to C#, but there's a lot less call for them to know that than C#). From next year our IT students will be taking the class as well. We're moving away from teaching them C# and going back to C++ (so in the long term this subject really should reinforce C++). Added to this, I only have about 5 weeks to rewrite the code... so I'll be hard-pressed getting it done without changing languages!

Barius: the idea of a client-server arrangement is a good one. I'm not certain I have time to explore that option for this year, but it might be possible for me to set things up to make the change for next year. It also expands on the possibilities that can be explored (like student's having their AI compete against each other in a modified scenario... currently its student vs environment + my enemy AI).

I think I'll stick with the DLL approach for this year but clean it up a bit and make it more OO (the current code doesn't implement OO principles very well). I could presumably provide an exported interface class within a skeleton DLL. Students then only have to write the meat of the methods and any other classes they need within the DLL and compile it. Within the game I can then simply create an instance of their AI class object and use it appropriately. Provided they don't mess up the class interface, it should work okay. As an alternative, I could create the interface class within the game and bind it at run time to their exported functions in the DLL.

Well, lots to think about.

Thanks guys. If you have any more suggestions, feel free to post them. I'll keep an eye on the thread for a few more days at least.

Cheers,

Timkin

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!