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

What are good ways to implement a "game playback" feature?

8 posts in this topic

I'm writing a simulation program. I need a way to record and then play back the entire simulation, at any given point. Kind of like how games like Age of Empires 2 does it, not as in actual video recording of the player's screen. My simulation consists of a really large grid of moving/changing objects. I've already had to dump the core of the program and I'm in the process of replacing it with a messaging system, so that any information that is WRITTEN to the simulation is done in a mesage format (eg. pObject->sendMessage_setDirection()) and information that is READ from the simulation is done regularly (eg. pObject->getDirection()).

 

This is turning out to be very hard to maintain. Every time I add a new object or a new kind of message for an existing object I have to add new code snippets all around. Mostly because messages have to travel from the top of the simulation through 2-3 layers down to the actual object, and every layer needs to know how to handle or route each and every message.

 

So I'm wondering if there's some clever way to go about this besides my approach. My program is relatively young so I can afford to make large changes at this point, specially if it'll make developing the rest of it easier. Recording pixel-by-pixel (video) isn't an option because the grids are supposed to be able to get really large (for example 64,000x64,000 tiles). I also thought about reading through the entire simulation after every tick (a "tick" is the smallest unit I need to record) and saving it to a file but again, it can be really large, so doing this every tick would make the whole thing very slow.

 

Thanks in advance.

Edited by OpOpOpOp
0

Share this post


Link to post
Share on other sites

One way is to store user input and playback a recording of the input.

 

This requires that state is properly reset at the start of the playback. Random numbers must also be seeded the same so that AI makes the same decisions. Some thing that require randomness but aren't critical (e.g. particle systems etc.) can use a separate source of random numbers which you don't require to be repeated exactly.

 

It can be quite tricky to get that system right though, and if you make a change to logic you invalidate the replay data. Also you can't rewind except to the start unless you save checkpoints (i.e. all the data and state) at regular intervals.

 

Timing issues can mess it up too so you probably want to use a fixed timestep and playback at the same rate.

Edited by Paradigm Shifter
2

Share this post


Link to post
Share on other sites

some games have recorded things like demos and similar, mostly by recording internal events (generally those that represent what the user sees).

so, whenever something moves or happens in-game, it is recorded.

 

to playback the demo later, you replay the events, typically on a timer, so it is as-if these things were happening again, and all the events are seemingly recreated on-screen.

 

recording user input has also been done in various games, but tends to be a lot more problematic:

if there is any non-deterministic behavior in the system (such as timing behaviors due to variability in framerate, AI logic timers, etc...), or something subtly changes from one version to another, then these tend to be very prone to blow up and have everything go berserk, whereas recorded game events tend to be a lot more stable.

1

Share this post


Link to post
Share on other sites

Yes the event system is more robust. You can also store undo information in each event then you can also play the replay backwards (which is useful for games where you can rewind time).

 

The "command" pattern is worth having a look at if you want to do that it is designed for undo/redo functionality.

1

Share this post


Link to post
Share on other sites

In a game (or actually a simulation) I worked on, we abused the networking system for this. We made a special kind of 'client' that would not connect through the network, but ran on the server locally. It would store all the game state updates sent to the clients in a file. Periodically, the whole game state (say, your save game) would be stored as well, serving as a kind of keyframe.

Then, at a later time, that file could be used as a replay.

 

Is it ideal? No.

In a large game, you'd selectively send updates to clients. So if units are not near the player, you'd not (or more sparsely) send updates. Also, it requires you to have networking code in place, which not everybody does, of course.

But for us, it was the quickest way to get things working.

 

Oh, and a link I found interesting: http://gdcvault.com/play/1018138/Implementing-a-Rewindable-Instant-Replay

1

Share this post


Link to post
Share on other sites

I played Tiger Woods one day, and the replay missed the put,

maybe they all accept the risk of having a re-play instead of a replay ?, not that i had to try again here in Tiger Woods, i still won the game,

some games let you play again after the replay goes wrong, by using all the same variables from the game i guess.

The weirdness, i rather have no replay at all in my own games.

Edited by the incredible smoker
1

Share this post


Link to post
Share on other sites

One way is to store user input and playback a recording of the input.

 

This requires that state is properly reset at the start of the playback. Random numbers must also be seeded the same so that AI makes the same decisions. Some thing that require randomness but aren't critical (e.g. particle systems etc.) can use a separate source of random numbers which you don't require to be repeated exactly.

 

It can be quite tricky to get that system right though, and if you make a change to logic you invalidate the replay data. Also you can't rewind except to the start unless you save checkpoints (i.e. all the data and state) at regular intervals.

 

Timing issues can mess it up too so you probably want to use a fixed timestep and playback at the same rate.

That's actually what I had done before. Problem is the simulation sometimes takes too long on a tick so live playback of all the computations can be slow, and it cannot be rewinded, which is necessary here.

 

 

some games have recorded things like demos and similar, mostly by recording internal events (generally those that represent what the user sees).

so, whenever something moves or happens in-game, it is recorded.

 

to playback the demo later, you replay the events, typically on a timer, so it is as-if these things were happening again, and all the events are seemingly recreated on-screen.

 

recording user input has also been done in various games, but tends to be a lot more problematic:

if there is any non-deterministic behavior in the system (such as timing behaviors due to variability in framerate, AI logic timers, etc...), or something subtly changes from one version to another, then these tend to be very prone to blow up and have everything go berserk, whereas recorded game events tend to be a lot more stable.

That's what I'm doing right now, event/command recording. Apparently that's the best way even though it's complex.

 

Thanks everyone!

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