Forums » Help » Question update Update() (More about style than anything)

This topic is somewhat broad and theoretical and has to do with code style/smells.

I realize there are no right/wrong ways to do things, but I know there are good, better, and best.

With all that said, I noticed that the lines of code in my Update() methods for entities tend to climb in pretty high.

Does this happen to anyone else?
I've definitely coded myself into a corner by having massive update methods.

How do you keep them lean and mean?
Refactor into smaller methods (and have those methods call other methods)?
Use many levels of inheritance to break up the Update() methods, and using this.parent() to call them on each game frame?

I would definitely be interested in your wisdom and experience, since like I said, after a while I end up coding myself into a corner, and adding a new change feels like a game of Jenga.

One thing I like to do is break input away from the update function.

update: function() {
    this.handleInput();
    this.parent();
},

handleInput: function() {
    // Set movement velocities based on input.
    // Handle other input such as firing a weapon.
}

It might even make sense to break things down a little further:

update: function() {
    this.handleMovementInput();
    this.handleAttackInput();
    this.parent();
}

Thanks Joncom,

That is definitely a lot cleaner.

I wrote a plugin that helps me break up cross-cutting behaviors into their own classes. I found it&039;s not just the #update method; I often also use check and handleMovementTrace and on and on... So code that handles the player jumping is in update, but also in handleMovementTrace... and maybe I want to turn off jumping later for some reason? Now all that code has big if statements around it making it suck.

I haven&039;t written up the documentation for the code (and I should really make an example) but, for instance, in a game I'm working on now I have a class called #StayOnPlatform. Once I call enableBehaviors(EntityEnemy); in my entity&039;s file, I can then add the line #this.addBehavior(new StayOnPlatform());.

Now my enemy stays on the platform. Not just that, though, but it's a re-usable piece of code that I can easily add to other enemies without changing anything.

I split up a bunch of player behaviors into their own files so I can disable them at will. So, if the user is reading dialog I can call this.behaviorsByName['respondsToInput'].enabled = false; to turn it off and on again. That also makes it really easy to give players capabilities with special items and remove them when they drop those items without a bunch of messy if statements.

Man, I should really clean up that repo. ( =

A few thoughts:

Your game logic needs to be somewhere. So, there is definitely a place that does have a lot of code.

I would definitely be interested in your wisdom and experience, since like I said, after a while I end up coding myself into a corner, and adding a new change feels like a game of Jenga.

See, this is the basic idea of OOP or software architecture. Writing structured code is pointless if you write software that's done in one shot. A good software architecture deals with change to the project. If your software never changes, just dump everything in the update method. That's fine.

So, as you've said already: There's no right or wrong. There are only principles that allow a bit more flexibility later and some that allow less. You could for sure write a Tetris game that can be turned into Street Fighter. However, this is probably quite a bit over-engineered and doesn't serve the purpose to get that game out there.

The key is now to identify core functionalities that apply to many different games. Just have a look at the many different plugins for Impact. All of them solve problems that are similar in many games. For example, this is a nice path finding plugin that does a lot of work under the hood and you have to call only one function.

Your update method calls followPath and the rest is done by the plugin. It can be used in a Command and Conquer style game or in a Pacman clone. Doesn't matter.

So, if you find core functionalities, you want to try to make them as widely usable as possible. As a consequence, the core functionality itself is hidden in another object or class (OOP principle encapsulation) and your player entity doesn't know anything about pathfinding anymore. It delegates the pathfinding to this other class. It's not really an entity, because it's not present in the game world. It's more like a manager or something like that.

It's even possible to give an entity functionality that it doesn't even know that it has. Compare this to a board game, say, Chess: You have different pieces. Do the pieces know by themselves how they move? Or is there an instance that knows the movement of all pieces? In the latter case, every piece (entity) doesn't even know that it can move, but there's something like a puppet master that moves pieces. Then, you have two players. Do they move pieces? Or is there an invisible third instance that knows the rules how to move pieces and players tell this instance which piece they want to move? This would allow more than two players and it would also allow different piece movement. You could have a "classic chess piece mover" and a "fancy chess piece mover" that has different rules.

Again, no right or wrong here, just different approaches with different goals and different sophistication to deal with changes to the software.

And to make this post a bit more practical and not only some abstract braindump:

I do similar stuff like Joncom.

The minimum I do for readability is to break up stuff in different methods.

The next step is to use other classes that handle stuff for the entity.

Even more advanced would be to use general plugins that are not necessarily custom to my game that entites can use or that inject functionality into entities.

Again, depends on the size of the project, my idea of the game, how fast I want to finish it and whether I expect changes or not.

I really do appreciate everyone's rich responses.
Thank you.

As I eventually put these theories into practical implementation I look forward to helping others as you have helped me.