Hi all! I have recently begun to be interested in making a Battlebots/ Robot Wars/ Robotic, etc. I have several ideas, and I am dedicated to stick with this project. Be prepared to read a sort of medium type read. :P
*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*
Bot Movement:
What my main idea is to utilize pixel movement for this. Using this,it would make the movement seem more natural in the game. The speed of the bot would depend on the weight of the bot and the power of the engines.
Weapons:
The game will have many type of weapons, that will have to be attached in ways. When in Bot construction, there will be a certain option that will hide the top of bot, revealing the inside of the bot. You will have a certain ammount of room to place pistons and such for weapons. Also, on the inside of the bot, you'd have your batterys (required for bot to work), Co2, and your control panel (also required, so you can set up your controls.
Arenas:
The arenas will be as real as possible. We will try to match the physics part of the game as closely as possible, but it will not be added until later. There will be many traps and such, like fire, spikes, razors, pits, electrical currents, BashBots, etc.
BashBot: A computer controlled bot.
Battling:
There will be many battling types, including 1 on 1, 2 on 2, King of the Hill, Tabletop battling, and tournaments.
Your HP will depend on the type of armor you have. I am even hoping to get someone to do voices explaining the arenas, yelling when there is a hard hit, maybe, even explaining a few BashBots, or user created bots that have sent in their own sound files describing their bots.
Competitions:
Thjere will be many type of comps. including those like in BattleBots, Robotica, and Robot Wars.
Extra Junk:
I do have one problem. Macro progamming. What I'm planning is having the usr set up his/her controller using Macros. When the usr makes a button on the controller, the game will prompt the usr the assign the button a certain button on the keyboard to activate a weapon that the usr also chooses. Any ideas?
Next up, Sound chips. These will work a lot like the weapon macro system. When you hit the macro, the sound will play.
Textures and Decals-- Woohoo! Next up is the complete customization part! The usr. will have access to put many different types of textures on his/her bot, along with decals.
**********************************************************
Wow...I didn't know I'd be that long! Well, I'm looking for some help, and ideas.
If you have any ideas/ questions/ or comments, reply to this post.
Tiko587
T587
T
ID:153731
 Mar 23 2003, 6:24 pm
|
|
I myself was working on a game of this sort... In fact, a while back I was talking about Theodis's pixel movement demo, and making my own collision detection system... That was for this project...
I ran into a wall in the form of some problems with said collision detection system... Since pretty much all other game systems I had in mind hinged upon the successful creation of a collision detection system (one that also checked what area of the vehicle was hit, to see what part of the robot would take the damage), not being able to set up a satisfactory system ended up grinding my development to a halt... I'm sure I could overcome the obstacle, but it sapped my motivation, and the project's been mothballed...lol And since then, I've taken on another project (besides my continuing work on DBTC), so I doubt I'll be getting my own robot combat game going anytime soon...so I wish you the best of luck, Tiko587... And perhaps I'll share a few of my ideas with you so they'll at least see the light of day...lol | |
Yeah...I'll have the game playable in a bit, but the collision is going to be a problem. Does anyone have any ideas on what I should do?
| |
Nice to see this type of game being talked about again. About a year ago there were some attempts, you may want to do some searches for them by various robot wars etc names.
As for your detection problem. What we do in the C++ programming world is create a box just inside the actual icon's limits. So anything hitting this invisiable box area is counted as a hit. You may set up 4 sided detectors for this box and just do a random effect as to the type of damage that was done on that side of the bot. Also I'd through in some random events for critical hits like if rammed hard enough the other bot explodes into a ball of fire. Some gets knocked loose and a random part of the bot stops working. Just a few rambling ideas there. Cheers! LJR | |
Hmm...now how would i do that in Byond? *ponders* I'm not exactly sure, but I'll try to do it. ^_^
Special Bots: I also plan to have special bots that do a variety of things. Like Dust Runner. He can ride up the walls and onto the ceiling. We'll just have to see where the SBs go, but if you guys have any ideas/ comments/ questions, Just ask. :P :P I've already got a good deal of the icons done, now to start with the code!!! Tiko587 T587 T | |
LordJR wrote:
As for your detection problem. What we do in the C++ programming world is create a box just inside the actual icon's limits. So anything hitting this invisiable box area is counted as a hit. You may set up 4 sided detectors for this box and just do a random effect as to the type of damage that was done on that side of the bot. Also I'd through in some random events for critical hits like if rammed hard enough the other bot explodes into a ball of fire. Some gets knocked loose and a random part of the bot stops working. Well, a box approach would be good for some of the items, as long as it was a rotated box. Using boxes for detecting collisions between regular objects is a little thorny; more often circles make for a better calculation, and they don't have to take very long to compute. What I would recommend as an eventual collision algorithm for a game like this would be one that uses polygons and circles. The polygons would be best limited to simple rectangles, or triangles for things like spikes. I should add two caveats, though: First, full 3D collision detection I don't think it'd be wise to do. It might be best to eliminate some kinds of bots that would be powerful in the real world, like flip bots, wedge bots, etc. Handling the collision math plus the physics for all this would be a nightmare. Among other problems, you'd have to deal with moments of inertia for your bot around 3 axes to have realistic physics, whereas in 2D you only need 1 axis. The second thing is that I think you should put off the collision algorithm for now and focus instead on the internal logistics of how DM will view the bot and its components. Lummox JR | |
Among other problems, you'd have to deal with moments of inertia for your bot around 3 axes to have realistic physics, whereas in 2D you only need 1 axis. Going slightly off topic, that reminds me of the little conundrum I'm facing with my RPG/space sim in C++ -- I'm not much of a mathematical genius, so I've spent quite a while trying to figure out how much energy is translated to rotational velocity versus forward velocity when a thrust point is placed offset from the centre of mass. That's because my space sim individually tracks each segment of the ship -- you can blow holes through the hull in real time. Presumably, if one of the twin engines on the back of a ship gets nuked, and the other one still works, then the ship is going to fly crazily. Still haven't come up with any solution to that. | |
Spuzzum wrote:
Among other problems, you'd have to deal with moments of inertia for your bot around 3 axes to have realistic physics, whereas in 2D you only need 1 axis. That's why you need to know the moments of inertia. The moment of inertia for an axis is a lot like mass, except it's more like "rotational mass". I found a good page a while back that has a good collision algorithm for transferring energy from a collision via impulse. The one I found was actually the 3rd in a series of articles found here: http://www.d6.com/users/checker/dynamics.htm Lummox JR | |
So far this sounds very much like a project I had in mind myself last year. However the logistics of deciding how to set up datums for all the item connectors, and how to handle moving parts, proved to be rather a pain.
My idea was to have a basic shell, or some selection of shells, in which components could be placed at pre-determined connection points. Those could include wheels, saws, hammers, jointed arms, you name it. All parts would have connectors on them that could be attached in turn. The problem is there needs to be some kind of understanding of the spatial relationships, especially where moving parts are concerned. Does one connector slide along a groove? If so how will that affect the range of motion of the parts? If you have two jointed arms, can you adequately determine when they will overlap, and prevent it?
It's a tough job. I wish you luck with it. If you come up with any new insights I'd love to hear them.
Detail can help make the game feel more real, here: Make damage occur at certain locations along the bot. Armor might be punctured or sliced through (while weakening the blow), allowing access to an interior part.
This won't be doable at runtime. Instead I suggest you go with something simpler: Use the Center() command for weapons fire, and have some other interface (perhaps PgDn and PgUp, i.e. Southeast() and Northeast(), something to Tank Wars) for switching between them. You can also override Northwest() and Southeast() for, perhaps, control over an arm, while Insert and Delete could be overridden to switch between controllable structures.
You might also want to include some basic programming for the bot: Nothing fancy. But for example this might include a sequence of things that all happen at the same time, so you could, say, make a walker bot by making the arrow keys (cardinal directions) activate various movement sequences.
Doable and cool. If you get far enough along in the project, I just might be able to put something together to read user-supplied .dmi or .bmp files and shrink them for application as decals. I've already got some rough routines for reading some raw .dmi data in DM, and they could be adapted to read BMPs as well. .gif and .png probably not so much, unless icon/New() can be used to convert them.
I wouldn't get too far ahead of yourself on this part yet though; customization can always be done later, especially if you leave room for it. The hard part is deciding how bots are put together "internally" (that is, how DM looks at them, not the construction) and what limitations you might have to deal with in order to achieve your vision.
Well and there's the other hard part, collision engines. The less said about that the better; I'd hate to discourage you. So far your idea sounds like everything mine wanted to be, except I had in mind robots playing mini-golf in the process.
Lummox JR