• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
PragmaOnce

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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
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...  smile.png

 

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0