Robo war competition

[Thumper]

Disch wrote:

I didn't see your reply until now, Thumper.

So many replies happening at the same time, lol.

I like your ideas though. I'm all for everything being an independently operating turret. That would probably make things more interesting.
The reason I mentioned a fixed camera would be because a robot would need to have a bare minimum build; the set of things it has before it's bought anything. Would that bare minimum be nothing? Or would you include a fixed camera in that? Suggesting that a robot would have basic life functions to begin with.
Now that I think of it I kind of like your vision more in this aspect. Your beginning robot is a blob that has one function: movement. All other equipment is a turret-like add on.

Disch wrote:

I don't envision the robot even having a front

How would we deal with motion then? If it's not tile based motion then it would have to be something like "tick forward at this angle". I think it adds an additional layer of complexity to AI if the AI has to worry about changing the orientation of the robot itself in order to accomplish movement.

Disch wrote:

SFML already has this implemented

Oh, cool. I didn't know SFML had that implemented. Wonderful! Forget what I said then. =P

EDIT:

Disch wrote:

If the walls are tiles, then we might have to reconsider how the camera reports their positions.

If, say, we decide to give walls some kind of thickness, perhaps we could report a set of points of distances from the robot to a point on the wall. This would make edges of walls interesting to deal with on the AI side, and it would be somewhat realistic as well. When making autonomous robots IRL, there would be some form of ultrasonic distance sensor strapped to the robot that would continually feed distance information to the robot. This data, over time, could be built into a "map" of the environment its in.

EDIT2: OCW course I got into a while ago. The image at the top of this page kind of envisions what I was talking about above.
http://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-01sc-introduction-to-electrical-engineering-and-computer-science-i-spring-2011/unit-4-probability-and-planning/

EDIT3:
This also forces us to consider how complicated we want localization to be. Perhaps it would be better to go with line segments for walls because it would be sad to require that all of our participants be super adept at real-world probabilistic state estimation or have to use some other complex search algorithm in order to be able to localize the position of a robot.

[3qX21hU5]

I'm OK with whatever works. But it's not just collision detection we have to consider, we also need to report wall positions back to the camera somehow. If the walls are line segments, this is some accomplished with some relatively straightforward math. If the walls are tiles, then we might have to reconsider how the camera reports their positions.

Hmm ya that is true. I'll think on it a bit more tonight and maybe do a quick prototype of both methods to see which might work best.

[Computergeek01]

So as far as our plug-ins interacting with the engine, are we talking about a message queue like in the original game? Does each bot get it's own distinct turn? Or are we thinking some kind of "real time" processing? If my opinion counts for anything I vote for the message queue at least at first.

I really like this idea. I would really like to contribute.

@ Disch: I'm thinking about the proxy\remote mines that you proposed, what if they were themselves "friendly" drone type bots? As in the player would have to buy them parts, build them and give them their own set of instructions. This would allow the player to choose between paying for a bare bones bomb on wheels or a more expensive armored smart bomb without the need to balance them against the rest of the game. This would also help keep the code for targeting them straight forward because they would just be regular enemy targets. Do you spend the extra money on a camera knowing that the drones purpose is to blow itself up? Or do you give it a cheap Communications suit and try to feed it directions from your main bot?

I also have a ton of ideas for more bot parts but I'm also the kind of person that enjoys the "needless complexity" in games like Armored Core and the early editions of Mech Warrior.

[G30oGNh0]

May I suggest having a glance at this game?

I believe it to have similar principles.

http://armorgames.com/play/563/

Chassis can only hold a certain amount of weight, Allowing people to enter certain fights, i.e light, medium, heavy weight. I guess this could be used as a leveling thing, the more fights you win, the more money you get to build heavier, more powerful bots.

The weight also allows for a tactical trade off, heavier armor takes more damage, but your weapon will have to be lighter, dealing less damage.

[Disch]

Computergeek wrote:

- Processors with attributes like cache latency? Have each 'turn' divided into X number of 'ticks' and having lower latency processor allows your commands to be processed at an earlier 'tick'.

The original RoboWar I played had something like "processor speed" which meant your robot could only perform X commands every tick. I hated it because it forced oversimplicity onto the player. You couldn't really make a complex robot because the processor was just too slow. I don't think we should penalize heavy computations here.

But I'm not sure if that's really what you were getting at. A 'tick' would just be a logic update. IE, every tick all robots get one call to their update function, and then their positions and stuff get updated and all the collision detection happens and all that good stuff.

- Something to track multiple targets in case we want to do a Battle Royal.

Can you elaborate? I don't see a reason to impose any limit on the number of robots that can be in a fight at once. 1-on-1 fights get boring after a while anyway.

Though the AI can track whatever it wants. That's up to the user. I don't think we need to (or even can) add any robot parts to make a distinction here, unless I'm misunderstanding.

- Some kind of radar so that you can track targets that you do not have LoS to.

This is a good idea... but it would have to be "weakened" somehow so as not to make the camera totally worthless.

- Power Plants so that we can fine tune designs and prevent bots from grabbing all of the best parts and mashing them together.

I don't understand this one either =x. What would the power plant do?

The parts would be obtained in the shopping step prior to the fight. A robot wouldn't be able to grab up all the best parts because there's a fixed spending limit that'd be enforced by the 'store'.

Thumper wrote:

Your beginning robot is a blob that has one function: movement. All other equipment is a turret-like add on.

It wouldn't even have that. The idea is that ALL the robot interactions have to go through its 'parts'. So the wheels (to operate movement) would also need to be a part. So if the robot doesn't buy wheels, it'd be a sitting duck.

The bare minimum robot would have no parts and would have not way to interact with the outside world. It'd just be a rock.

Building in other minimal functionality is possible, but would complicate the API for the AI... because then we'd somehow have to give the robot parts that it didn't ask for during the shopping step.

Making wheels a part opens up the possibility for different quality of wheels. Like fast rotation, acceleration, top speed, etc.

How would we deal with motion then? If it's not tile based motion then it would have to be something like "tick forward at this angle". I think it adds an additional layer of complexity to AI if the AI has to worry about changing the orientation of the robot itself in order to accomplish movement.

Wheels would be just another turret. I outlined this in my previous post where I did that block of pseudocode.

You'd orient them just like you'd orient a camera/gun and then set a target speed. The robot would accelerate/decelerate until it reached that speed.

So as far as our plug-ins interacting with the engine, are we talking about a message queue like in the original game?

I'm imagining it'd be turn based. The game has a list of pointers to robots... those robots all have their 'update' method implemented. Then every 'tick' it just serially calls each one... then the robots move and collision is detected... etc, etc.

I'm thinking about the proxy\remote mines that you proposed, what if they were themselves "friendly" drone type bots?

That could definitely be done. It'd just have to get worked into the camera system somehow so they'd be identified. I don't think it'd be proper to identify them as just another robot.

I also have a ton of ideas for more bot parts but I'm also the kind of person that enjoys the "needless complexity" in games like Armored Core and the early editions of Mech Warrior.

When I say "needless complexity" I mean keep the work of doing a simple task simple. I don't mean we can't introduce more complex tools for the robots to use. In fact I welcome that!

Though maybe we should start more simply with the game engine before tackling really advanced stuff. Never hurts to discuss things though!

[Computergeek01]

@ Disch:

The idea for the processor was based on the thought that we were going to be using a turn based message queue. Kind of like in a pencil-paper board game where the character with the higher "agility" trait goes first. It sounds to me like you want to process each bots tick-actions simultaneously which is fine.

As for being able to track multiple targets this is more of a game balance idea. If six pea shooters cost and weigh around the same amount as one big cannon then the added utility of being able to target either six enemies at once or focus all of your pea shooters onto one poor sap without the need of additional equipment would ensure that no one ever uses the big cannon. I play a lot of board games where, unfortunately, "Meta-Gaming" like this is a large factor.

I'm afraid I can't think of much to balance the radar against the camera except for maybe making the radar a high end and expensive version of the camera. We could include jammers or reduce their 'resolution' so you only have an idea of where the target is but that seems like it would make them too weak. This one may have to be balanced in live trial or with the power plant as I explain below.

The idea for a power plant probably won't be popular with most players but it's the kind of design limitation that makes me enjoy games like Armored Core that much more. The idea is that the bots would have two power attributes, generation and capacity. Capacity is how much power a bot can store and generation is how much power they get back at each turn. The bots would start each round with a full charge but every action would require a certain amount of energy, firing lasers or pinging enemies with the radar would take more energy then say firing kinetic energy weapons or viewing them with a normal camera. But lasers don't have a limited ammo supply and cameras can only show you LoS so trade offs have to be considered. I prefer this over individual weapon cool down times (NOT the same as rate of fire) because it makes players think twice about "Glass-Cannon-Rushes-The-King-For-An-Alpha-Strike" tactics since doing that may not leave them with enough power to duck behind a wall before someone else takes a shot at them.

I think the drone bots have a lot of potential if for nothing else then sheer pixalated carnage. ID'ing them separately from regular bots makes sense since they would have a different targeting priority.

[Thumper]

Disch wrote:

Wheels would be just another turret. I outlined this in my previous post where I did that block of pseudocode.

Oh, that makes so much sense that I feel silly. Mmk, we're on the same page.

I'm starting to get really into this idea now. I'll let some of the ideas settle in my head and then start writing a few pieces together after I get a feel for how the code's going to be structured. Starting the first pieces of a group project is always difficult for me.

[o1vk4iN6]

I'm afraid I can't think of much to balance the radar against the camera

Think that is quite easy, the radar only tells where the enemy is, not if you have line of sight or you can shoot at them. You can make the radar "pulse" so you only get an updated position every couple ticks rather than every tick. If the camera is used to identify what parts the other robot has than the radar won't have this capability.

If six pea shooters cost and weigh around the same amount as one big cannon then the added utility of being able to target either six enemies at once or focus all of your pea shooters onto one poor sap without the need of additional equipment would ensure that no one ever uses the big cannon. I play a lot of board games where, unfortunately, "Meta-Gaming" like this is a large factor.

I actually see the opposite a lot more often. Having one big cannon is usually better than having 6 smaller ones. Just as an example if someone has the highest armor having 6 pea shooters won't be able to do the same amount as damage per second as one cannon could as basically the pea shooters will just bounce of the armor essentially. Giving customization is good but trying to balance it out so that one configuration isn't dominate as you said is a challenge.

[Mats]

Radar - Gives accurate position of opponent within x radius.
Stealth - Makes radar position less accurate.

Camera - Gives accurate position along line of sight of camera.
Gives info about seen enemy robots.

Neat idea Disch.

[Computergeek01]

Now that I've reread this thread it seems like I'm trying to balance a game that hasn't been written yet. I think I'll stop that now :p

[3qX21hU5]

Just a little update if anyone is interested i'll be pushing the very basic framework that I have for this into a github repo (Do we have one setup already? If we do let me know otherwise I will just create one on my account) tonight sometime after I get off work.

I mainly just took care of the state management (And if I get time during lunch I might code up a resource manager also) and that is about it but hopefully I will find some more time to work on it this week or weekend.

But anyways yea it will be up in a github repo sometime tonight if anyone wants to work on it (Just make sure to drop a comment on what you will be doing so we all aren't stepping on each others toes).

[Disch]

Zereo: That's great. I don't have anything on github so if you want to set it up that'd be awesome. Thanks for taking the initiative here.

What build tools/IDE is it using?

[3qX21hU5]

Disch wrote:

What build tools/IDE is it using?

Right now I just have it as a QT Project using QMake though I might write up a quick CMakeList for it so others can compile it more easily if I find the time (Though I am not the best with writing CMakeLists so fair warning lol).

Also managed to remote onto my desktop computer at home to do the push to the repo https://github.com/bjumbeck/RoboWars .

Here's a quick rundown of how I structured the code. I will try and get some comments into the code to help explain it more but hopefully it won't be to hard to understand.


main.cpp - This just runs the application and is for top level exception handling.

Application - This is the class that encapsulates the main game loop basically. It has a fixed time step and does basically everything a normal game loop would do.

StateStack - This is the the class that is in charge of managing the current states and state transitions. This class will also take care of drawing, updating and handling events for all current game states. Most likely you won't have to interact with the state stack directly instead everything will happen in each of the individual states.

State - This is the base class that all the states in the game will inheirit from. It provides pure virtual functions that you overload for drawing, updating and handling input events. It also provides functions to manage state transitions.

For example lets say we are at the menu screen and we need to switch to the LevelOne state. We would do something like this.

requestStackPop(); // Pops off the menu state from the state stack
requestStackPush(States::LevelOne); // Pushes the LevelOne state onto the stack. 

Context.hpp - This is just a object that I tend to use to pass information between different classes and states. Generally it will contain stuff like the current render window, resource managers, player controllers, ect.

StateIdentifiers.hpp - Just a basic enum which I use as ID's for the different states. Personally I prefer enums on smaller projects like this but I am open to other ideas and it doesn't really matter to me what we use.

[N36fSL3A]

I mean like each robot has a "weight class" in order for people to not spam certain weapons.

(I'll edit this at home when I get more time)

[Disch]

Lumpkin: Yeah I had a similar idea only it would be a "price class" rather than a weight class. Like you could only spend X dollars on parts.

[N36fSL3A]

But then you could spam weak parts and be unbeatable...

[Computergeek01]

@ Lumpkin: You're doing the same thing I was doing at first, trying to balance a game that hasn't been written yet. A lot of stuff is going to depend on how we implement game play to reflect certain features. Take armor for instance; I was thinking up strategies and gadgets left and right under the idea that it would be ablative, I didn't even consider that it might soak damage without deteriorating until xerzi made his post suggesting it. Let's get the code to at least pre-Alpha stage before we tweak it.

[N36fSL3A]

I understand.

Who's going to actually program the game? Will contestants have the source?

EDIT: Didn't see Zereo's post.

(Quick Question:)
What does this do? Never seen it till now:
virtual bool handleEvent(const sf::Event event) = 0;

[3qX21hU5]

What does this do? Never seen it till now:
virtual bool handleEvent(const sf::Event event) = 0;

The method itself is a pure virtual function that child classes have to override. Every global state (Like Menu Screens, Levels, ect) in the game has to inherit from the state class. And they have to define at least the 3 methods

virtual void draw();
virtual bool update(sf::Time dt);
virtual bool handleEvent(const sf::Event& event);

The draw method is where that state would put all it's drawing code into, the update method is where all it's update code executes and the handleEvent method is where all the event handling (User input) for that state is handled.

This way each state is pretty much self contained from the other states and I find it is much easier to keep all the different states organized.

As for your question on what it does, well it does what the name says ;p. It handles events for that state.

Edit: Thanks for posting that though noticed that I forgot to pass by reference in the parameter ;p

[N36fSL3A]

No, I mean adding a = 0 at the end. I thought you needed empty brackets.