next »

[gimymblert]

The other things is that even though we see objects in game almost as tangible, what's really going on is interactions, the more objects the more exponential interactions.

There is a case to be made for "functional" procedural programming, in which you declare objects as struct or any data bags and encode directly relation between objects or type of objects explicitely (the interaction). That would actually resemble a game design doc (I'm a designer first), each interactions is basically contained in its own paragraph. Problem is changing objects mean tracking down all the interaction (though it can be down to document formatting, ie structuring like a design doc with clearly label section in dedicated file).

But this tangible way of looking at games don't work well with more ambitious mechanics in which we quickly need nested swappable objects. An edge case would be a RPG (think xenoblade x) where you have a custom character, party member you can possess, and vehicle you drive, and which you cannot fight and jump in social area, with cinematic dialogue, streaming open world and persistent key npc, with smart objects that tell you how to operate them ... Who is the player? he is certainly not the visual because of custom and equip, he is not the controller because vehicle and place can swap that, he is not the main character because you can swap character to control. Add to that a physics  system (I mean they don't like player input that add too much energy) and welcome to hell (at least for me, I haven't figure it out).

[InfiniteStateMachine]

Does no one else feel that the challenges of game programming are such that many of the usual pros and cons of OO don't really apply.

Like, games have a lot of objects that really represent physical objects. And we have a lot more "cat bites dog"  problems  (i.e. functions that involve functionally unrelated objects) than in other domains.

I'm reminded of the Flixel framework. When I first encountered it, the idea of having objects that simultaneously represented a graphic as well as an enemy was abhorrent - it doesn't separate concerns at all. But now I realize, for games, it doesn't matter. You don't write for re-use, you write that which expresses a single thing as effectively and flexibly as possible. You could call Flixel OO if you like, but it's not objects like I'd see anywhere else.

Yeah Flixel is a great counterpoint. I've never made huge games with it but wow, I've never used a framework that went so smoothly as flixel for getting a game done.

[InfiniteStateMachine]

Regarding parallelism and OOP on my way to work I remembered that the Actor model is essentially completely reliant on oop and is extremely compatible with going wide. So much that you can abstract over hardware or clusters of computers without too much thought.

[qMopey]

Regarding parallelism and OOP on my way to work I remembered that the Actor model is essentially completely reliant on oop and is extremely compatible with going wide. So much that you can abstract over hardware or clusters of computers without too much thought.

Hey I'm curious on how it relies on OOP? Or did you just mean keywords like encapsulation (which by the way existed long before OOP ever did)?

[InfiniteStateMachine]

Regarding parallelism and OOP on my way to work I remembered that the Actor model is essentially completely reliant on oop and is extremely compatible with going wide. So much that you can abstract over hardware or clusters of computers without too much thought.

Hey I'm curious on how it relies on OOP? Or did you just mean keywords like encapsulation (which by the way existed long before OOP ever did)?

Yeah encapsulation is the main thing needed for the actor model to work in that you need an object with private data where it can only be modified by being passed some message. I guess that also means it covers inheritance/polymorphism since an actor would implement IActor (inheritance) and some external source would treat them as one object in a collection (polymorphism) and call various methods like AcceptMessage.

If OOP is defined as a datatype with associated functions that may or may not implement those 3 rules then you could say every single feature of OOP existed before OOP existed.

[qMopey]

That makes sense. Lately I've been really liking actor-model, mainly to bolster API design and reduce dependencies. It's great.

[Ordnas]

An edge case would be a RPG (think xenoblade x) where you have a custom character, party member you can possess, and vehicle you drive, and which you cannot fight and jump in social area, with cinematic dialogue, streaming open world and persistent key npc, with smart objects that tell you how to operate them ... Who is the player? he is certainly not the visual because of custom and equip, he is not the controller because vehicle and place can swap that, he is not the main character because you can swap character to control. Add to that a physics  system (I mean they don't like player input that add too much energy) and welcome to hell (at least for me, I haven't figure it out).

Unreal Engine 4 has a really good concept of who is the player, using a "player controller": if you want to play, you need to define a player controller, otherwise you are a spectator. In case of your example, I can swap vehicle and character detaching the player controller from the vehicle to the character and viceversa.

For now my rule of thumb is, if you can, just use composition first, and if you see some pattern and/or advantages, then use inheritance. Inheritance puts you in a really bad pratice of creating very long monolithic patterns.

Someone used to say that OOP initially was popular on banking programs, because the concept of hierarchy fitted really well with inheritance. Maybe for this reason OOP spread out as a main subject in universities. OOP was saw like a "panacea" for all sort of problems. Now we can see that it is far from the truth.

[gimymblert]

The problem back then was different too, first we had the goto, then we got unruly procedural, then we had cow boy dev who only writes for themselves, OOP was a solution to that. But the principle have now inspire people to write even old procedural in OOP style (struct + dedicated function) and pay attention to variable name, we got to separate the paradigm from its principle.

I'm still a bad programmer and still want to do a xeno X style game.

[Garthy]

Some days ago I ran into an obscure bug which didn't make sense.

I was building a single target source file from a number of generated files that are combined using the C preprocessor. The target file was building, but failing when run. On inspecting the source file, it seemed fine. I examined the individually generated files in detail, and they were all fine. Reverting a bunch of changes, I took the code back to the point where it was pretty close to the build that had been working the previous day. Again, it failed.

After several hours of experimenting with weird test results that simply made no sense, I was able to determine that the target file did not match what should have been produced by the individual files. Digging further, it turned out that I had the include path wrong and it was pulling in files with the same name from an old build that happened to produce a target file that could compile, but would never successfully run when built. I got rid of the old files, and everything was working within minutes.

It was one hell of an obscure bug. I had the kind of awkward laugh you have when you realise you've just wasted hours tracking down a bug that you'll just never see again, made a note to track down the specific issue with the include path at some point, and moved on.

Time passes.

Yesterday I ran into an odd bug where the single target file would occasionally gain or lose an extra semicolon in the build. Since the target language is VHDL, the extra/missing semicolons are quite significant, and it caused build failures. There is some filtering code that produces the file that can add and remove semicolons, so I thought it might be this. I spent a few hours digging into it, and couldn't track down why extra semicolons snuck in, and why sometimes they just vanished. Why just semicolons, and nothing else?

A short time ago, it dawned on me. Ignoring the fact that it was semicolon-specific, had I seen this before? And wasn't I doing separate test builds in different directories with slightly different changes relating to the semicolons? Could these produce a near-viable build if they were combined in the wrong way? Oh no...

I cleaned up the separate build directories both automatically and manually, and restricted myself to just the one build directory. Again, everything was working again in minutes. I had just been bitten by the exact same bug that had caught me before, but this time it was due to a completely different set of obscure coincidences that just happened to produce a result that looked like it was something else.

So, after wasting upwards of eight hours total due to this one specific should-never-occur-twice-but-did-anyway bug I basically said: Stuff it. I'm tracking down and solving this specific bug right now, everything else can wait.

So I tracked down the bug, fixed it, and tested the fix. Total time to find and fix the bug that cost upwards of eight hours of development time, and quickly test the fix?

Two minutes.

FML.

[qMopey]

So what was the bug 

[Garthy]

So what was the bug 

It's a bit convoluted, so bear with me.

In both cases the script that generated the Makefile that contained the command that ran the preprocessor for the target source file got two elements of the include path the wrong way around. It was supposed to check for files in the build directory first, and the source directory next. It was backward.

This would only really cause an issue if there were two files with the exact same name in each of the two directories, which was generally not the case. However, it could occur for generated files if you happened to do a build directly in the source directory, then started a new build in a different directory, without cleaning the code in the source directory. Now this would occur occasionally, but the generated files in each case would typically be the same, unless you made certain changes between the two sets of builds, which required some effort as they were controlled by the same file. If this occurred, the changes that could cause major problems were extremely rare, and those that could cause major problems but hide most of their symptoms were obscure. Given the workflow for that particular bit of code, the situation came up very rarely. Since the complete rebuild of this component took around two seconds, I would do this regularly, meaning that I would generally avoid or recover from this situation quickly without ever realising what was happening.

The perfect storm hit both times when I had two different build environments for this component, was doing a build in both the source directory and a separate build directory together, had an incomplete or kludged build in the source directory that I had a good reason to avoid cleaning out (eg. I had performed some steps manually and a rebuild would produce a different result), and had certain differences in settings that would trigger the failure (runtime in the first case, semicolons in the second), but with differences so restricted that everything else worked, and the symptoms pointed away from there being a failure in the build system. That's one hell of a run-on-sentence, but it literally required all of these things to occur simultaneously for the problem to manifest.

When I encountered it that first time, I expected it to be difficult to track down, and obscure enough to almost certainly not happen again. I was working on something substantial at the time so I dealt with it by adding it as an item on my TODO list. On the second time I realised it was not as obscure as I had thought, was hard to detect, and very costly in terms of recovery. So I set about to solve it. I had expected the problem to be one that came about from some obscure interaction in the build system. I was wrong. It ended up being a fault on a single line of code that contained the relevant part of include path in a single string. It took a few searches and a trivial amount of reading to find it. The solution was literally: highlight part of the string, cut, move cursor, paste, save, rebuild.

It was a timely reminder to myself that any bugs that can potentially cause costly, misleading, and hard-to-detect errors go right to the top of the priority list.

[InfiniteStateMachine]

That makes sense. Lately I've been really liking actor-model, mainly to bolster API design and reduce dependencies. It's great.

I haven't used it in any production systems but I toyed around with Akka and read the Orleans docs. It really does seem like a great way to build a large system where there might be programmers all around the globe having to collaborate but not always able to communicate directly.

I'd really like to try it out for real some day

[qMopey]

That makes sense. Lately I've been really liking actor-model, mainly to bolster API design and reduce dependencies. It's great.

I haven't used it in any production systems but I toyed around with Akka and read the Orleans docs. It really does seem like a great way to build a large system where there might be programmers all around the globe having to collaborate but not always able to communicate directly.

I'd really like to try it out for real some day

But that's basically how all distributed/cloud systems work. Not only good for API design, but also good to create asynchronous systems.

[Photon]

The other things is that even though we see objects in game almost as tangible, what's really going on is interactions, the more objects the more exponential interactions.

There is a case to be made for "functional" procedural programming, in which you declare objects as struct or any data bags and encode directly relation between objects or type of objects explicitely (the interaction). That would actually resemble a game design doc (I'm a designer first), each interactions is basically contained in its own paragraph. Problem is changing objects mean tracking down all the interaction (though it can be down to document formatting, ie structuring like a design doc with clearly label section in dedicated file).

But this tangible way of looking at games don't work well with more ambitious mechanics in which we quickly need nested swappable objects. An edge case would be a RPG (think xenoblade x) where you have a custom character, party member you can possess, and vehicle you drive, and which you cannot fight and jump in social area, with cinematic dialogue, streaming open world and persistent key npc, with smart objects that tell you how to operate them ... Who is the player? he is certainly not the visual because of custom and equip, he is not the controller because vehicle and place can swap that, he is not the main character because you can swap character to control. Add to that a physics  system (I mean they don't like player input that add too much energy) and welcome to hell (at least for me, I haven't figure it out).

This. The problem isn't necessarily the objects themselves, its how the objects interact and how they should regulate themselves. Think about the real world: physics just happens. A car does not need to acknowledge the existence of another car for them to collide, they just do. In the programming world, we not only have to define and regulate every interaction between each object but, barring parallelism/multithreading, they all have to be processed one-by-one in a fairly binary order. It becomes even more difficult once you have to start handling "exceptions" to the rules and when those anomalies propagate throughout interactions.

The approach I tend to take now is that most interactions are never handled at the object level, which is to say there is a parent object that handles all interactions of a given type. As a simple example: when a dog bites a cat, some form of damage-control parent will look at the dog, determine the strength of the bite, and apply the damage to the cat. The parent has all the information from dog and cat available to it so that the dog and cat don't have to ping-pong said data between them. This gels very well for me since I use a lot of ECS these days where a system can track all objects of a particular nature.

[JWki]

The other things is that even though we see objects in game almost as tangible, what's really going on is interactions, the more objects the more exponential interactions.

There is a case to be made for "functional" procedural programming, in which you declare objects as struct or any data bags and encode directly relation between objects or type of objects explicitely (the interaction). That would actually resemble a game design doc (I'm a designer first), each interactions is basically contained in its own paragraph. Problem is changing objects mean tracking down all the interaction (though it can be down to document formatting, ie structuring like a design doc with clearly label section in dedicated file).

But this tangible way of looking at games don't work well with more ambitious mechanics in which we quickly need nested swappable objects. An edge case would be a RPG (think xenoblade x) where you have a custom character, party member you can possess, and vehicle you drive, and which you cannot fight and jump in social area, with cinematic dialogue, streaming open world and persistent key npc, with smart objects that tell you how to operate them ... Who is the player? he is certainly not the visual because of custom and equip, he is not the controller because vehicle and place can swap that, he is not the main character because you can swap character to control. Add to that a physics  system (I mean they don't like player input that add too much energy) and welcome to hell (at least for me, I haven't figure it out).

This. The problem isn't necessarily the objects themselves, its how the objects interact and how they should regulate themselves. Think about the real world: physics just happens. A car does not need to acknowledge the existence of another car for them to collide, they just do. In the programming world, we not only have to define and regulate every interaction between each object but, barring parallelism/multithreading, they all have to be processed one-by-one in a fairly binary order. It becomes even more difficult once you have to start handling "exceptions" to the rules and when those anomalies propagate throughout interactions.

The approach I tend to take now is that most interactions are never handled at the object level, which is to say there is a parent object that handles all interactions of a given type. As a simple example: when a dog bites a cat, some form of damage-control parent will look at the dog, determine the strength of the bite, and apply the damage to the cat. The parent has all the information from dog and cat available to it so that the dog and cat don't have to ping-pong said data between them. This gels very well for me since I use a lot of ECS these days where a system can track all objects of a particular nature.

Yes that's a sensible approach - what I think is an issue with OOP and game development often is that people go like "okay so objects in my game should obviously be objects in my code" - which to me stopped making sense. I mean I can see where it's coming from and I used to think that way but nowadays I think that while obviously you need a way to distinguish between objects (as in objects in the game) in your code, mapping them 1:1 to class instances doesn't make sense - rather you have to look at how best represent your game world and objects and everything in your game state in a way that makes sense for how you process it.
Components and ECS and what not kinda appreciate that but really I don't think that you need to express this in the generic way that ECS implementations do for example. As in, using objects (AGAIN) to model these kinda things.
Instead, I tend to try to think about the different subsystems in my application, what data they need to manage and what logic they need to implement, and then try to implement each subsystem in isolation instead of having some sort of standardized framework that I squeeze all subsystems into. Sure, you might end up with something that looks like an ECS, but I think going off the most concrete code you can write and then generalizing that is a better way than the other way around - coming up with a general solution that you think will fit your problems - and sadly in OOP circles the latter TENDS to be encouraged.

[gimymblert]

Personally, even though I haven't completed a full complex game due to difficulty with architecture, BUT I see myself sleeping in what I call teh breadboard model, I don't know if that make sense. But basically I create unit that are very self contain with clear input and output, ie basically electronic component. Since every project need some specific coupling, I have dedicated objects to handle the coupling that is the breadboards, ie it connect the elements with very specific direct link, ie dogs don't know about cat but the breadboard does and handle any exception self contained in its definition. Breadboard can be nested. It's similar to the componenent system, as I understood it, but instead of having external system, the breadboard handle the codes, it's basically the bag of links. Not sure if best practice lol, but for now it's what works best for me and allow to separate modular part against specific/exception. In the end it's the exception that is the identity of teh objects, what makes it unique.

[Photon]

The other things is that even though we see objects in game almost as tangible, what's really going on is interactions, the more objects the more exponential interactions.

There is a case to be made for "functional" procedural programming, in which you declare objects as struct or any data bags and encode directly relation between objects or type of objects explicitely (the interaction). That would actually resemble a game design doc (I'm a designer first), each interactions is basically contained in its own paragraph. Problem is changing objects mean tracking down all the interaction (though it can be down to document formatting, ie structuring like a design doc with clearly label section in dedicated file).

But this tangible way of looking at games don't work well with more ambitious mechanics in which we quickly need nested swappable objects. An edge case would be a RPG (think xenoblade x) where you have a custom character, party member you can possess, and vehicle you drive, and which you cannot fight and jump in social area, with cinematic dialogue, streaming open world and persistent key npc, with smart objects that tell you how to operate them ... Who is the player? he is certainly not the visual because of custom and equip, he is not the controller because vehicle and place can swap that, he is not the main character because you can swap character to control. Add to that a physics  system (I mean they don't like player input that add too much energy) and welcome to hell (at least for me, I haven't figure it out).

This. The problem isn't necessarily the objects themselves, its how the objects interact and how they should regulate themselves. Think about the real world: physics just happens. A car does not need to acknowledge the existence of another car for them to collide, they just do. In the programming world, we not only have to define and regulate every interaction between each object but, barring parallelism/multithreading, they all have to be processed one-by-one in a fairly binary order. It becomes even more difficult once you have to start handling "exceptions" to the rules and when those anomalies propagate throughout interactions.

The approach I tend to take now is that most interactions are never handled at the object level, which is to say there is a parent object that handles all interactions of a given type. As a simple example: when a dog bites a cat, some form of damage-control parent will look at the dog, determine the strength of the bite, and apply the damage to the cat. The parent has all the information from dog and cat available to it so that the dog and cat don't have to ping-pong said data between them. This gels very well for me since I use a lot of ECS these days where a system can track all objects of a particular nature.

Yes that's a sensible approach - what I think is an issue with OOP and game development often is that people go like "okay so objects in my game should obviously be objects in my code" - which to me stopped making sense. I mean I can see where it's coming from and I used to think that way but nowadays I think that while obviously you need a way to distinguish between objects (as in objects in the game) in your code, mapping them 1:1 to class instances doesn't make sense - rather you have to look at how best represent your game world and objects and everything in your game state in a way that makes sense for how you process it.
Components and ECS and what not kinda appreciate that but really I don't think that you need to express this in the generic way that ECS implementations do for example. As in, using objects (AGAIN) to model these kinda things.
Instead, I tend to try to think about the different subsystems in my application, what data they need to manage and what logic they need to implement, and then try to implement each subsystem in isolation instead of having some sort of standardized framework that I squeeze all subsystems into. Sure, you might end up with something that looks like an ECS, but I think going off the most concrete code you can write and then generalizing that is a better way than the other way around - coming up with a general solution that you think will fit your problems - and sadly in OOP circles the latter TENDS to be encouraged.

ECS is more of a starting point for me than the end-all be-all. ECS, behavior trees, highly-specialized code... if I think one or a combination of things will work, its not off the table. Really, I think the big thing is to try and find a sweet spot: if you're too generalized (a definite risk with ECS in general,) then even basic functionality can be incredibly cumbersome to setup and customize properly; if you're too specialized with your code, you risk ending up with duplicate code and hard-to-track bugs that propagate from multiple, isolated places. Its like trying to develop a programmer's "sixth sense," in my opinion, where you have just enough foresight to operate in and out of the gray zone of different paradigms.

When you talk about different subsystems, I don't see how that's much different than the ECS approach (which you allude to.) A specific piece of functionality can be associated with one or two components, and the subsystem will track and operate on any entities that possess those components. That approach, in my opinion, is fairly uncomplicated.

EDIT: Sort of related, but I talked about this a bit on my website...

https://gamingobservatory.com/2017/03/20/technical-talk-flexing-the-muscles-of-ecs/

[GuiltyGreens]

An input->process->output system works well for me. At the lowest level there is little to no coupling between systems. A collision detection system is implemented independent of a behaviour tree system. As the level gets higher, there are more dependencies added between systems but only through the inputs and outputs. When the player presses the Jump button, an animation is played, velocity changes, and other data may be affected. In my game, there is a Level class that pipes output data as input to other systems and thus also defines the execution order of systems.

For the car example from Photon, there may be a collision and physics system. To make a car, you relate the appropriate collision and physics data. You create the necessary collider and set the appropriate physics attributes(mass, friction, constraints, joints, etc) for each collider. The realistic crash response between cars is defined within the physics system, which itself may not necessarily define a "car". It does not need to.

[InfiniteStateMachine]

That makes sense. Lately I've been really liking actor-model, mainly to bolster API design and reduce dependencies. It's great.

I haven't used it in any production systems but I toyed around with Akka and read the Orleans docs. It really does seem like a great way to build a large system where there might be programmers all around the globe having to collaborate but not always able to communicate directly.

I'd really like to try it out for real some day

But that's basically how all distributed/cloud systems work. Not only good for API design, but also good to create asynchronous systems.

Lately it sounds like the way they get around a lot of this stuff is to not have an actual service running for very long. Like a serverless setup where the program is compiled once per access making it impossible to have any state. At that point the only persistent layer is the database.

I was looking into Azure for some work I was doing and the gamut of services they offered was staggering. From extremely stateful ASP applications to Azure "functions" which are on the opposite side of the spectrum.

I believe in Azures case the exact service for an actor model they offer is called Fabric (which I think is another name for Orleans). Or something with the word fabric in its name.

If stuff starts to go that way then it would be interesting because then a fully async web service would actually be slower and more wasteful than a synchronous solution.

[Ordnas]

Personally, even though I haven't completed a full complex game due to difficulty with architecture, BUT I see myself sleeping in what I call teh breadboard model, I don't know if that make sense. But basically I create unit that are very self contain with clear input and output, ie basically electronic component. Since every project need some specific coupling, I have dedicated objects to handle the coupling that is the breadboards, ie it connect the elements with very specific direct link, ie dogs don't know about cat but the breadboard does and handle any exception self contained in its definition. Breadboard can be nested. It's similar to the componenent system, as I understood it, but instead of having external system, the breadboard handle the codes, it's basically the bag of links. Not sure if best practice lol, but for now it's what works best for me and allow to separate modular part against specific/exception. In the end it's the exception that is the identity of teh objects, what makes it unique.

Isn't it the same principle of ECS what you're mentioning? I favor components over OOP first if I can. There are cases that it is better to refactor when you have 20+ components attached to an actor, performance-wise also. For example an actor in Unreal Engine 4 doesn't like too many components attached.