Jump to content

Open Project  ·  51 members

Arena Shooter

About This Project

Development of an open-source first-person tournament shooter with support for VR.

  1. What's new in this project
  2. JMK

    Bot Matches

    Yeah but it can still load LE4 maps.
  3. How did you create that map? I thought LE5 didn't have an editor yet?
  4. JMK

    Bot Matches

    Okay, LE5 beta now has static navmeshes. I tested with a loaded level. We have everything we need to start creating this.
  5. If the bot is low on health or ammo, it should prioritize those items instead. You can make it smarter still by not going to a health powerup if an enemy is close because it might be too risky. In this case it could hide and wait until the enemy leaves or find the next closest health (assuming it's in a different direction). You can get pretty complex with this if you want to make the bot smart. On the other side of that coin, most players won't analyze the bots' decisions too much.
  6. JMK

    Bot Matches

    This will serve as our first test map for bot movement. I will have basic pathfinding out soon: testmap.zip
  7. JMK

    Bot Matches

    I was thinking about power-ups, and if you have room full of them , you don't want the bot randomly going to each one. What you should do is first check for all powerups within a certain radius of the player, then trace a path to them with FindPath(). If the total path length is much longer than the direct distance, discard it, because you can assume it is out of reach or on the other side of a wall or something. Find the nearest powerup, by path length, not by simple distance, and move to that. Once you get there, repeat the process. This will make the AI scoop up powerups in a manner that looks more natural and is more efficient than just randomly going after them.
  8. JMK

    Bot Matches

    The power-up situation is interesting because it is a subroutine. Once that task is complete, the player goes back to whatever they were doing before, whether it is patrolling or fighting. Pathfinding will soon be available in the new engine so at that part we can start experimenting with this. There are two ways I can think of that we can handle the patroling. Recast has a FindRandomPoint() function I am integrating. So patrolling could just amount to find a random point in the navmesh, go there, then find another. The other way is to add "breadcrumbs". They don't have to be linked together and they don't require a clear line of sight, but they give the bot some points of interest they can travel around to. Perhaps powerups, weapons, and breadcrumbs could all be treated as potential destinations. Ideally I would like to avoid a situation where the AI gets to their destination and then doubles back on their path, because it would just look unnatural. But I don't want to make things to complicated either.
  9. The sequences you are describing would be actions in the behavior tree. They can be coroutine enabled methods. The benefit of the behavior tree is in structuring those conditions and actions together via configuration. It's the branching part that you mentioned of when to do what sequence. While it's fine Update() isn't used it's all being done in a loop somewhere either way (running the corourtines until they are dead) so either way. A behavior tree call in Update() would be behaviorTree:Update() anyway. You'd read the image attached left to right top to bottom. The tree is iterated over every tick for each bot. Each tree instance gets a "blackboard" which in lua would be a table that all child nodes can share. This is how nodes can store data and other nodes read it. You can do all sorts of tricks with the blackboard like add timestamps to each piece of data and some bots can remember only so long ago where others can remember longer, etc, to add cool effects. A neat feature of a tree is that sub nodes are just a tree in themselves, so you can add sub-trees to existing trees at run-time. That can create sort of a learning ability in bots, which for this game probably wouldn't be used much, but it's a cool concept.
  10. JMK

    Bot Matches

    The beta includes an example of a coroutine sequence. I think maybe this could be developed into the sort of system you are talking about. The base routine would be patroling, which consists of: Choose a random point on the map. Navigate there. Repeat. There are three events I can think of that would interrupt this behavior. Bot sees a powerup they like. Bot sees a player they don't like. Bot is shot by someone who doesn't like them. Each of those events would cause the behavior to branch off into a different coroutine sequence. Perhaps the entire bot AI can be defined in the Start function as a series of coroutines, and the Update() function won't be used at all.
  11. You know me I'm a systems guy lol! In the Dino game we did we used behavior trees. I found a lua library that supported that then used this site https://github.com/behavior3/behavior3editor/blob/master/README.md to visually design the behavior tree. I export to json I think it was then read that in and made some code to create the correct lua behavior library data structures. Since behavior trees are pretty standard AI mechanism these days I'm sure there are even more resources/libraries around this now compared to 5 years ago or so. This would really help extend AI behavior well beyond manually coding them. You code the specific behaviors and conditions then assemble them via the tree so decision making becomes easier to "see". Makes it easier to understand what is going on in an otherwise sea full of if statements that ends up happening in this kind of stuff. Make it more flexible to change too.
  12. I feel like what we found from the first person player script, was that a very linear way of designing this functionality leads to "messy" code that was hard for people to understand and extend. It's not necessarily about the number of lines of code that you write that makes something easy to understand and extend. It's about the end users experience while using your code. Often to make the end users experience easier and more extendable you have to write a good amount of code making systems. I feel like aiming for any amount of lines of code would be miss this goal. Looking at it from the standpoint of extendable/flexible systems and then just doing as much code as is needed to make it work would be ideal. Coming at the problem from the standpoint of a potential modder in something like this might yield better results. This would mean having a weapon system where it's very easy to make their own weapons with very little code, not copy/paste type code. This means movement systems to adjust things like speed, gravity, etc would help a developer extend or configure different classes. Thinking in terms of lines of code that you have to write to create such an example would really put you in a box. Let the users easily play around with stuff first. Then as they get more interested in learning more about tweaking your systems then they'll have the patience and attention to dig deeper. Also, it helps compartmentalize the design ideas. If someone wants to tweak something in the core system for weapons they know exactly where to do that. In the weapon systems. With something like the first person player script everything is intertwined together and it's very difficult to follow a script like that as different ideas bleed into each other in 1 script. These are probably not ideal situations with something like this. Just my thoughts on it and the past design ideas around creating things for users to learn and tweak in which this seems to be going down a similar path. It will get similar results.
  13. One player class? Yeah. I'm aiming for 1000 lines of code, maximum, and to keep it as simple as possible. The idea is to make a core game that is very easy to understand, and then let people go crazy adding whatever they want to it.
  14. I propose that for the really early alpha there is only going to be one class. Though, I taugth of a fun idea. There could be a stamina index that gets higher the more you sprint which will make your weapons more unprecise. So if you don't move much you can make cleaner shots but if you sprint almost all the time you can always get really close to your enemy for the price of lower accuracy.
  15. This character is pretty much perfect: https://cubebrush.co/fabianoribeiro?product_id=rynrgq
  16. I think it is an assault weapon, if there were hands it would be clearer. Here are some sounds I just made. railgun_inside.wav railgun_outside.wav
  17. If we make that the long-range weapon, you might want to put a scope on it.
  18. early version of the railgun at 2000 faces. railgun.blend
  19. Here's a good example of what the character materials should look like: https://cubebrush.co/fabianoribeiro
  20. A brainstorm program and a bit of photoshop later ... I will try to model this and see where it goes.
  21. Coming back to this after quite some time, this model seems pretty ideal, minus the swords. I can't think of any other style that isn't "annoying" or discordant. However, the white areas should really be the colored parts, for better visibility. Then we can either swap textures or make a custom texture that makes one character that is mostly blue, mostly red, etc. The feet make it obviously human, so this goes along with more of a theme of an athletic event, so maybe we go with a sort of "E-Sports" angle like I was saying with this:
  22. JMK

    Bot Matches

    I want them to all be bound by the same constraints. Behavior is what differentiates them. Here are some example behaviors I can think of that will make a bot better in a match: A bot that specifically goes for health when their health is low or ammo when their ammo is low will fare better than one that just walks over any available pickup when it is nearby. A bot that jumps and aims a rocket at its opponents feet or tries to hit a nearby wall will do better than a bot that just fires straight at them. A bot that switches to the appropriate weapon for how close their enemy is will perform better, since there is built-in randomness in their aiming accuracy. My general strategy with these types of games is to gain the high ground, find two enemies fighting below, kill the first one from above, and then drop down and finish off the second one while their health is still low.
  23. This could be fun, depending on the limitations of the base AI and the possibilities of the extended one. One other way to do it would be to have stat points you could allocate into skills. For example, if you put most of the points into movement speed, you could safely dodge rockets fired from a distance and jump larger gaps, which could get you to places others can't go. If you put a bunch into awareness, the AI would have greater perception and could see enemies from the corner of his eye (FoV) and hear enemies from greater distances. Just another way to go about it but this would involve more coding.
  24. That's the right general shape. I want to make this with CSGs and then place detail models throughout. The lower half of the map will have a lot of ramps up to reach the "balconies" in the main chamber. Nice bricks.
  25. Here a prototype (not yet with physics) added some ideas and its the shape like above db952b80b096b34b0d06d00997746dc2_dot3.tex db952b80b096b34b0d06d00997746dc2_dot3.bmp material_brick.mat material_brick.mat.meta db952b80b096b34b0d06d00997746dc2.tex level.mdl level.fbx test.map
  26.  
×
×
  • Create New...