Followers 0

# Where does game play come in?

## 10 posts in this topic

So over the past couple days I have learned a lot about design patterns and game architecture but now another mountain has appeared.

Using a lot of resources(books, articles) I have created a project that implements objects that have components (completely de-coupled) from each other, a rendering manager that draws all my objects and physics system that detects collisions etc.. Now this is good and all but I am missing the most important piece of this puzzle: where should game play specifics be implemented then? I mean for it to be a game somewhere there must be rules that define the game.

Where in this whole process will I code:  If the player is near the tree, the squirrel must fall out.

Is there some crucial part I am missing? It seems completely illogical for me to have these behaviors defined inside the classes because that would couple all of my entities and make it impossible to re-use them. Or am I misunderstanding the re-usability thing. Should it be that the classes themselves such as Player and Squirrel  know about each other and can then be thrown away in terms of future use (then only the systems and components are re-used).

Please don't tell me to just try and "finish" the game. This is not an attempt to finish a game. I am trying to understand how the core of a game is supposed to work and how all of these different patterns and systems work together to produce a finished product. I really hope this post makes sense.

Thank you.

Edited by PragmaOnce
0

##### Share on other sites
Maybe create a game logic function within the game class? This is because your main loop should be something like WndProc stuff, get input, do things with input, update all your objects, draw all your objects if you don't have a multi-threaded approach.
0

##### Share on other sites
You can't treat game logic as totally abstract. Depending on the type of game, you might need a level editor in which you can create arbitrary objects such as trees and squirrels in a totally data driven way, and link them through mechanisms as described in the previous post.

Or you might be looking for a scripting system. Is it a very specific case that a squirrel appears? Will there be many different behaviours like that in the game?

Writing tree and squirrel classes might make sense if these are very common concepts throughout the game and you always want them to behave the same way. Still, you would want to minimise the responsibility of these classes and make them work as much as possible using other, more generic systems.
0

##### Share on other sites

1.  Attach a trigger volume around the tree.  Anything which enters the volume triggers an event which can be piped to functions or other components.
2.  Attach the trigger event to a 'filter' which only passes the event if it is caused by the player object.  Could be another component or a customized event/message proxy system.
3.  Attach the filtered event to a spawner.  Set the spawner to spawn a squirrel when triggered.  Attach this to the tree also and route the event to trigger this spawner.

So, your "logic" is built up from simple concepts which can be reused and combined in many ways for other things.  You have avoided putting any of this case specific logic into the player, so it gets to remain a nice focused object. You have attached the trigger to a static item so it is actually pretty low cost (moving trigger volumes are considerably more expensive).  And the squirrel is the only "specific" item in the whole solution.  Obviously to "spawn" a squirrel, you need a squirrel to spawn.

So basically I will have like 100+ events specified in a very generic way? Then I set up some observer / listener messaging system so that every object only registers for certain events and then respond on it? I must say thinking about this in such an abstract way seems alright but I guess it will be a nightmare to implement in reality :/

You can't treat game logic as totally abstract. Depending on the type of game, you might need a level editor in which you can create arbitrary objects such as trees and squirrels in a totally data driven way, and link them through mechanisms as described in the previous post.

Or you might be looking for a scripting system. Is it a very specific case that a squirrel appears? Will there be many different behaviors like that in the game?

I don't know enough about level editors or data driven development to implement something like that. Is it absolutely necessary to script game play behavior or can it be hardcoded?.

0

##### Share on other sites

Thank you for clearing that up for me Jtippets. I really appreciate all the advice you guys have given me. It seems I will be doing a lot more research concerning event systems and behaviors the next few days.

All of the examples have been used in terms of a reasonably complex game where the game needs to be broken in pieces to fit into our heads. But what about small games like pong or snake. Surely the event based system is complete overkill. Would it be better in these situations to have a universal Game class that handles all the specifics? For example if the ball hits the paddle in pong you would have this in Game.update():

if world.collide(paddle,ball)
{
soundManager.playSound(ball_hit);
ball.physics.bounce();
}


I can see this will become a huge problem if you don't know the exact boundaries, scope and specifics of the game.  Are there any alternative methods that could be used when dealing with smaller games?

Edited by PragmaOnce
0

##### Share on other sites
Even in small games, you should make an effort to hold to good design principles. Small games, after all, are where you learn the skills necessary to make larger games. While a large universal Game class that handles everything might be okay (probably not optimal) for Pong, it simply won't translate well to larger or more complex games. In essence, you're leading yourself down a dead-end by using a universal know-it-all class.
0

##### Share on other sites

Okay, I guess the only way to separate the game play then would be to delve into data driven development. But one thing I have been wondering is - you know all those tutorials on the internet on creating a game, they all create their entities and then the functions inside are specifically tailored for certain situations. Then everything just gets updated and checked inside the main loop.

Why do these guys promote programming based on bad design principles?

Edited by PragmaOnce
1

##### Share on other sites

Sorry for a late reply, was sitting in a car with a pissed off cat for 20 hours yesterday coming home...

1.  Attach a trigger volume around the tree.  Anything which enters the volume triggers an event which can be piped to functions or other components.
2.  Attach the trigger event to a 'filter' which only passes the event if it is caused by the player object.  Could be another component or a customized event/message proxy system.
3.  Attach the filtered event to a spawner.  Set the spawner to spawn a squirrel when triggered.  Attach this to the tree also and route the event to trigger this spawner.

So, your "logic" is built up from simple concepts which can be reused and combined in many ways for other things.  You have avoided putting any of this case specific logic into the player, so it gets to remain a nice focused object. You have attached the trigger to a static item so it is actually pretty low cost (moving trigger volumes are considerably more expensive).  And the squirrel is the only "specific" item in the whole solution.  Obviously to "spawn" a squirrel, you need a squirrel to spawn.

So basically I will have like 100+ events specified in a very generic way? Then I set up some observer / listener messaging system so that every object only registers for certain events and then respond on it? I must say thinking about this in such an abstract way seems alright but I guess it will be a nightmare to implement in reality :/

I do this considerably differently which doesn't require a bunch of intermediate structures and message "crackers" etc.  I actually use std::bind and wrap that in a generic functor so there is no translation.  All the work of figuring out what data to send gets wrapped up in the bound function and/or with the case of compositing you can basically write a little script of things to do and not just a single emitted event.  If you can't tell, I love std::bind flexibility, understanding it can be a bit of a pain though.

Anyway, "event" is just a descriptive term, whatever you use is up to you.  It can be messages, bound functions, or like my system bound functions sent as "messages" but they simply call functions when you actually 'dispatch' them.

Edited by AllEightUp
1

## Create an account

Register a new account