State Machines

The Partridge Family were neither partridges nor a family. Discuss.
albinopapa
Posts: 4373
Joined: February 28th, 2013, 3:23 am
Location: Oklahoma, United States

Re: State Machines

Post by albinopapa » April 4th, 2019, 7:53 pm

You're probably right, the majority of the software out there is business apps and utilities, which probably don't require a lot of state changes and user interfaces are pretty constant so even using polymorphism for UI elements wouldn't be that big of a deal. As far as games go, a lot of the work going on is calculations on data which can either be organized in a cache friendly manner, optimized for multi-threading and/or offloaded to the GPU which increases complexity, but has a higher return for the effort.

With that line of thinking though, I don't see the point in most of the STL.
If you think paging some data from disk into RAM is slow, try paging it into a simian cerebrum over a pair of optical nerves. - gameprogrammingpatterns.com

User avatar
chili
Site Admin
Posts: 3948
Joined: December 31st, 2011, 4:53 pm
Location: Japan
Contact:

Re: State Machines

Post by chili » April 5th, 2019, 5:26 am

I'm only considering games here. It is shortsighted to assume that game=everything needs to be optimized. A large proportion of games simply don't have enough game logic entities to warrant that sort of developer resource allocation. You first have to consider what type of game is being made. You have to see the forest for the trees.

Also, not sure what you mean about the STL there. Seems like a non sequitur.
Chili

albinopapa
Posts: 4373
Joined: February 28th, 2013, 3:23 am
Location: Oklahoma, United States

Re: State Machines

Post by albinopapa » April 6th, 2019, 2:25 am

Just wanted to say, this is an open debate not an argument. Chili usually has a pretty understanding of how things works, so I like to push a little to learn something new.

My point about the STL thing was, if you are going to spend time on getting the most bang for your buck, then you'd use SIMD instructions or send your data to the GPU and as far as I know the STL doesn't support either of those right now, so since you brought up cost benefit analysis, if you are going to spend the time to make your program faster, you aren't going to be using the STL and it's algorithms, you're going to be spending that time setting up SIMD algorithms and/or GPU compute shaders/kernels making the STL completely useless. NOTE: I had to look up non sequitur, and you may be right because I can't seem to clearly state my intention of saying it and this is the best I could come up with.

The idea that std::variant requires more man hours to implement than traditional polymorphic behavior kind of baffles me once you learn how it can be used/implemented in a project. The coupling thing is an annoyance though. I'm kind of at a loss then as to what kind of benefit would come from std::variant if using it only benefits a few cases as you claim. Honestly, std::variant would be harder to use with more than a handful of different static types because of some of it's requirements. It's not just about speed, it's about type safety and book keeping as well. Not having to rely on maintaining an enum or accidentally casting to an incorrect child type or using the tradition visitor pattern ( which also has coupling issues ) helps a lot.

Just to be clear about something though, my decision to use std::variant for the different game states had nothing to do with speed. I needed a case of showing a state machine and instead of showing something that could potentially be a bottleneck, I wanted to show something that would be more efficient and reduce the learning curve in using std::variant. It took me a while to come up with different ways of using std::variant and std::visit.
If you think paging some data from disk into RAM is slow, try paging it into a simian cerebrum over a pair of optical nerves. - gameprogrammingpatterns.com

Post Reply