• 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
Musikai

Game state communication.

6 posts in this topic

So i've been trying to make a game using a state machine/state pattern and im having trouble. So I have each state in its own class being managed by a state machine class (which is inherited by any class that needs multiple states). I've read many examples and tutorials on state machines but none of them seem to explain how the states communicate and share data.

 

I'l give some hypothetical game situations. What if, when playing an rpg you're in the "gameplay state" and you hit "M" to change to a "map view state", the map state is giong to need to know the players position in the world. What if you're in a "menu state" and change the games difficulty, then the "gampley state" would also need to know the new difficulty setting. If you're in an "inventory state" and you equip items then the "gameplay state" would need to know so it can display these new items on the player.

 

I dont know where this data should be stored and how it should be shared. If anyone knows a solution i would realy appreciate it.smile.png

 

0

Share this post


Link to post
Share on other sites

the Model-View-Controller pattern

 

This.

 

The state is only a view/controller of the model, not the model itself. To answer the examples in your question, the player's data and position, etc is stored in a separate object. The active state works by presenting all or part of that dataset to the user and by allowing the user/game-logic to alter that dataset. So when you open the map state the position information is already available in the shared dataset. When you leave the map state the information necessary to restart the gameplay state is sill available in the same dataset. When you open the menu the player stats are all in the shared dataset. The state simply renders that data in a user-readable format and reacts to the player's controls to navigate the menu options, etc.

 

An added advantage of this is that when it comes time to save or load the game, all the persistent data is in one place and can simply be serialized and dumped or loaded and deserialized.

Edited by Khatharr
2

Share this post


Link to post
Share on other sites

Thanks for the help guys. So if i understand, the data should be stored in, and read from, a "Model". The state then acts as the View/Controller to alter and display the data?

 

So going with ppodsiadly's layout, say i have an Application state "Game" which has three substates. Would the "Game" state class act as the Model and store all the data to be accessed by each substate? Or should the Model be a seperate class entirely?

Edited by Musikai
0

Share this post


Link to post
Share on other sites

So going with ppodsiadly's layout, say i have an Application state "Game" which has three substates. Would the "Game" state class act as the Model and store all the data to be accessed by each substate? Or should the Model be a seperate class entirely?

 

No, the game state wouldn't be that model, it is the view and, depending on your implementation, probably also the controller. For starting, choose what fits best. I'm using a seperate controller class that is based on my gui, but you should start easy, MVC is something that could be a little hard to get right the first time. 

 

"Model" should rather not be a seperate class eigther. MVC is a pattern, there does not need to explicitely exist a "model", "view", and "controller" class. For example, in my implementation, the "model" is an entity-component system. Each game state defines which entity systems it is going to use, therefore defining the "view". The entities themselfs is the "model", and they are shared between gamestates via an entity manager, thats allocated outside of the state system, with a reference being passed on to each new state.

0

Share this post


Link to post
Share on other sites

Thanks Juliean. Might be a stupid question but what would an entity manager look like, and how do the states interact with it?

 

Maybe i'm just slow but im really struggling to get this. I'm still very much a begginer, the only game i've written is a 2d game of pong. I just want to get away from the messy switch statements i've been using for game states. It feels like this is the only thing stopping me from writing more complex games, but every time i ask a question, the answer creates ten more questions. Wish i could have a programer sit next to me so i could bore them to tears with my lack of understanding.

0

Share this post


Link to post
Share on other sites

Read this article as it explains what a statemachine is: http://www.gamedev.net/page/resources/_/technical/game-programming/state-machines-in-games-r2982

Read: http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller to brush up on the MVS pattern.

 

Generally the MVC is implemented as three separate components(classes, systems, or whatever) that take to each other in the manner outlined in the wikipedia article. I implemented one for a space invader project in which the view controlled what the player saw, so the screens and stuff, the controller handled input for the player and the collision detection and send messages to the objects to update themselves with the collision response, the model(implemented as invader, player and laser/missile).

0

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