Talk about anything: Page 71 - Godot Community Forums

Talk about anything

DaveTheCoder

I watched the video, but I'm skeptical.

Besides making the code less readable, it depends on looking at the code generated by the compiler. But what if the compiler is changed, or if you move the code to a different platform which involves using a different compiler?

This technique is micro-optimization, which should only be used after profiling your code to determine critical areas where that level of optimization is needed. And there may be better solutions, such a refactoring the code at a higher level. For example, those functions in the video might be called less frequently by reorganizing the program.

cybereality

I didn't watch the video, but for general programming, it's not much of an issue. CPUs are fast these days, so branches are not a problems at all. However, with shader programming, it makes a big difference. Since shaders are massively parallel (possibly thousands of threads) branches have a huge impact on performance. And, at run-time, it cannot know which branch will be taken, so usually all are run at the same time and when it comes to the branch, it picks the right one at the last second. So if you use lots of if statements, both blocks are getting executed and it's wasted (plus the cost of context switching). So it is better to find ways to get answers to questions without if statements. A couple if statements is probably okay, sometimes it is impossible to avoid, but in general, most stuff can be reworded to compute answers without if-else logic.

some_lame_kid

I noticed this with shaders and was about to say that this only seems worth it there. I've done "stress testing" to see how sloppy you can program a shader before it gets noticable, and I found there's not a lot of room for wasted logic. Like @DaveTheCoder said, it's only worth it for specific instances of necessary micro-optimization.

Megalomaniak

There's a reason we have branch prediction on CPUs. Downside is it can still fail and then be slow but it helps immensely.

Bimbam

I totally wasn't spamming refresh I swear

Audiobellum

When mushrooms talk, it sounds like Jazz:

Calinou

@cybereality said: I didn't watch the video, but for general programming, it's not much of an issue. CPUs are fast these days, so branches are not a problems at all. However, with shader programming, it makes a big difference. Since shaders are massively parallel (possibly thousands of threads) branches have a huge impact on performance. And, at run-time, it cannot know which branch will be taken, so usually all are run at the same time and when it comes to the branch, it picks the right one at the last second. So if you use lots of if statements, both blocks are getting executed and it's wasted (plus the cost of context switching). So it is better to find ways to get answers to questions without if statements. A couple if statements is probably okay, sometimes it is impossible to avoid, but in general, most stuff can be reworded to compute answers without if-else logic.

Using branches in shaders isn't as much of a problem nowadays as it used to be. In fact, it's your greatest ally against stuttering during gameplay:

Kojack

@Tomcat said:

@Audiobellum said: I just want to record, edit and then share a video of what I've been working on in Godot. If it's still relevant.

Screen Capture: * ShareX

Capture and Edit: VirtualDub DaVinci Resolve * Shotcut

There's also VirtualDub 2, which is a fork of VirtualDub (which was discontinued 9 years ago) with support for more file formats like MP4. http://virtualdub2.com

OpinionatedGamer

Getting ready to do some basic AI in my fps game so I can start getting a feel for the gameplay (I have movement and a basic weapon down). I looked at Navmeshes and it looks like they are not the best currently (doesn't have collision avoidance, can't be baked during runtime, looks like you can only have one agent size per navmesh?), can't wait for Godot 4.0 where these features will be added, but for now I need to work with what I've got. Do you guys recommend using navmeshes in their current state, or is their a better system?

Bimbam

I've not tampered with the FPS genre, but suspect 'realistic' behavior could only be achieved through manually defined waypoints that take the benefit of cover into account.

For example, if you were fleeing from cover to a room's exit, would you beeline straight for the door ignoring all other cover options in a line that's entirely predictable? Or would you zigzag and dive for cover nearby between you and the door.

Others may have more to say on the matter, but I suspect that 'good' FPS games are less about AI behavior being crazy complex and more about intelligent level design that enables emergent behavior from simple rules. Take the demon movement in Doom as a case study.

I think unless you're going fully open-world, many FPS games stick to small structured rooms and scripted event-driven engagements. More I think about more I want to play with something ^{^.}

fire7side

Godot 4 is just going to build on the current navmesh so the more you know now, the less you have to learn in the future. There are probably work arounds for those problems if you scour the internet. But it's good to experiment with alternatives, also. You really can't lose no matter what you do. There are some plugins also that may be helpful like behavior tree and finite state machines. Then again, it's also good to start from scratch on those things, too. I like to start with something simple, myself. A simple finite state machine and some steering behavior. The thing about that is you can use it in lots of games besides fps, which I actually haven't done so probably take my advice with a grain of salt.

cybereality

The original F.E.A.R. probably had the best FPS AI of all time. You can look it up, the devs discussed how it worked. It was basically goal orientated. So sort of like an FSM, but on steroids. Like one goal could be to attack the player, another to protect itself, to find cover, help a teammate, etc. And they all have weights and percentages which affect the choice in any moment. Honestly the AI before that, and since, has been weak. Most games simply have waypoints and scripted events and there is no real logic at all.

https://www.gamedeveloper.com/design/building-the-ai-of-f-e-a-r-with-goal-oriented-action-planning

Audiobellum

@Bimbam said: I've not tampered with the FPS genre, but suspect 'realistic' behavior could only be achieved through manually defined waypoints that take the benefit of cover into account.

True. It should also take into account how enemies can work together as a team. It would be cool if enemy AI used move and fire movement tactics(AKA leepfroging) to pressure the player into behaving more aggressively.

Others may have more to say on the matter, but I suspect that 'good' FPS games are less about AI behavior being crazy complex and more about intelligent level design that enables emergent behavior from simple rules. Take the demon movement in Doom as a case study.

Funnily enough, the first FPS( and first game I made) had enemies that didn't even move from where they're placed and the game is still challenging. The level design would force confrontation between the player and the enemies. It didn't matter if the player ran away, because the enemies were literally preventing player progress. Even though the player had freedom to move around, I took influence from rail shooters. The game was more of a proof of concept more than a game proper. You can check it out right here if you want( it's completely free):

https://audiobellum.itch.io/project-genesis

I think unless you're going fully open-world, many FPS games stick to small structured rooms and scripted event-driven engagements. More I think about more I want to play with something ^{^.}

It would be cool if you tried it out. The hardest part about making an FPS in Godot is the enemy AI and that's it. The YouTube tutorials on how to do everything else are generally great. Admittedly, I had to come up with a few ideas/solutions on my own. However, I'm sure that wouldn't be a problem for you. When it comes to Youtube tutorials, I recommend checking out Garbaj first, their videos are the best:

Still, they're tricks that you won't learn from their videos. For example, I had to come up with my own solution on how to merge old school weapon switching with picking up weapons. I plan to share how I did when I'm finish making my next game but, I think more experienced programmers might know how to do it too.

some_lame_kid

I have never programmed an AI in my life. I take that back, I made some real barebones black jack AI once. @cybereality I know you're not my librarian, but you know books. You know any books about AI in the realm of video games?

OpinionatedGamer

@Audiobellum said:

When it comes to Youtube tutorials, I recommend checking out Garbaj first, their videos are the best:

Still, they're tricks that you won't learn from their videos. For example, I had to come up with my own solution on how to merge old school weapon switching with picking up weapons. I plan to share how I did when I'm finish making my next game but, I think more experienced programmers might know how to do it too.

Garbaj's videos are great! I am using his videos for a lot of stuff.

Yeah I'm going to make a custom weapon switching system too. It's going to be really simple. I'm going to have a scene for each gun, and each gun has a function called fire. The player script calls fire on whatever weapon is the current weapon. I currently have a script that will work for most basic raycast weapons with values that can be changed per gun, I'm planning on adding one for projectile weapons, maybe one for shotguns. Most people would probably use an class based object oriented system for this, but I think this way will work better for me personally and I still will be able to reuse code. I'm still relatively new so I'm sure it's not the best system but I think it'll work really well.

cybereality

@some_lame_kid said: @cybereality I know you're not my librarian, but you know books. You know any books about AI in the realm of video games?

Actually, I'm a professional librarian. LOL. I've wrote book reviews for most of the game dev books I've read in the past few years. I did read before that, and I sometimes read books and forget to do a review, but most of them are listed on my website.

https://cybereality.com/

This book is probably the best for traditional AI in games:

https://www.amazon.com/Programming-Example-Wordware-Developers-Library-ebook-dp-B0029LCJXE/dp/B0029LCJXE/

Bimbam

I do data science for my day job so I'm funny about the word 'AI' in general as it's usually not ;)

I have written some simple agent based simulations and figure that'd be the angle I take for this, which is basically what thay Fear article is talking about (though they obviously went far more complex than I).

Maybe my twilight city concept should be less crazy taxi and more starfox

fire7side

Gamedev has a pretty nice overview for beginners: https://www.gamedev.net/tutorials/programming/artificial-intelligence/the-total-beginners-guide-to-game-ai-r4942/

cybereality

@Bimbam said: I do data science for my day job so I'm funny about the word 'AI' in general as it's usually not ;)

Well I think that is why they say ML, and other related terms, because AI means basically nothing now.

fire7side

@cybereality said:

@Bimbam said: I do data science for my day job so I'm funny about the word 'AI' in general as it's usually not ;)

Well I think that is why they say ML, and other related terms, because AI means basically nothing now.

When you look at the definition, it is. Artificial intelligence (AI) is the ability of a computer or a robot controlled by a computer to do tasks that are usually done by humans because they require human intelligence and discernment.

It's not like anyone expects it to actually be conscious.

« Previous Page Next Page »