- Forum
- Lounge
- Robo war competition
- Page 4
Robo war competition
closed account (3qX21hU5)
I think this is getting a bit off topic...
So Thumper if you want to create a CMake build system that would be great I would definitely use it. And we will keep the QMake build system in there also it is relatively easy to keep up to date and it should be no problem to have both. In my opinion more options is never a problem.
So Thumper if you want to create a CMake build system that would be great I would definitely use it. And we will keep the QMake build system in there also it is relatively easy to keep up to date and it should be no problem to have both. In my opinion more options is never a problem.
This sounds like a great idea from the OP, as you said though I'm sure there's many like it... However I can't say I've seen any in the past few years so why not?
I do have a little advice on the dll front though. You say you'd use dlls to store the workings about different vehicle parts, I imagine this is so you can just make a new one whenever you like and throw it in?
Now to do this you'd already need to have yourself some form of base for all the dlls to be derived from so that you can easily incorporate them into your program. I suppose the easiest way is a base class (for generalisation) and this will be full of core functionality and enums telling us what sub types are available (the vehicle parts such as wheel/guns/etc), then you have the actual dlls containing just the derivation of the base class and a load of set variables (that where present but not set in base).
I suppose you could do this, but since you'd need to set out a base line structure I suppose you could just use this base structure on it's own and just save these set values into a simple txt file? Of course in a dll you can redefine functionality but you're still limited to how it effects the base class.
Anyways, good luck!
I do have a little advice on the dll front though. You say you'd use dlls to store the workings about different vehicle parts, I imagine this is so you can just make a new one whenever you like and throw it in?
Now to do this you'd already need to have yourself some form of base for all the dlls to be derived from so that you can easily incorporate them into your program. I suppose the easiest way is a base class (for generalisation) and this will be full of core functionality and enums telling us what sub types are available (the vehicle parts such as wheel/guns/etc), then you have the actual dlls containing just the derivation of the base class and a load of set variables (that where present but not set in base).
I suppose you could do this, but since you'd need to set out a base line structure I suppose you could just use this base structure on it's own and just save these set values into a simple txt file? Of course in a dll you can redefine functionality but you're still limited to how it effects the base class.
Anyways, good luck!
closed account (3qX21hU5)
I believe we decided to go against using .dll to inject the players AI code since it poses a security risk.
Personally what I was thinking for the AI and might have a go at when I got more free time in a month or two is building in a built in editor that players can use right in the game to code their AI's. I was thinking the easiest way to do this would be to incorporate a scripting language (Or subset of one) like Python or Lua. But I guess a customer scripting language could be made up also but that is probably being unrealistic at this point.
Though that would be quite a far ways off and that is even if it gets implemented (It was just a idea I had). But I believe at least for the early stages of the project we are going to stick with just players submitting their AI scripts to be compiled into the client.
As for the AI's architecture of it I was thinking a component architecture would probably work best in this case instead of a traditional class hierarchy. Since as it sounds from discussions here players will have a good number of parts to choose from that will affect how the robot preforms and using components would simplify that process greatly in the long run.
Basically the user coding the AI would do his shopping and whatever components he buys are added to his robot (Along with their functionality of course). This makes it simple to provide the user with only the functionality that you want, to create new robot parts and the list goes on.
Personally what I was thinking for the AI and might have a go at when I got more free time in a month or two is building in a built in editor that players can use right in the game to code their AI's. I was thinking the easiest way to do this would be to incorporate a scripting language (Or subset of one) like Python or Lua. But I guess a customer scripting language could be made up also but that is probably being unrealistic at this point.
Though that would be quite a far ways off and that is even if it gets implemented (It was just a idea I had). But I believe at least for the early stages of the project we are going to stick with just players submitting their AI scripts to be compiled into the client.
As for the AI's architecture of it I was thinking a component architecture would probably work best in this case instead of a traditional class hierarchy. Since as it sounds from discussions here players will have a good number of parts to choose from that will affect how the robot preforms and using components would simplify that process greatly in the long run.
Basically the user coding the AI would do his shopping and whatever components he buys are added to his robot (Along with their functionality of course). This makes it simple to provide the user with only the functionality that you want, to create new robot parts and the list goes on.
Last edited on
Topic archived. No new replies allowed.