Using journals to test gameplay
by Daniel Buckmaster · in Torque 3D Professional · 08/01/2014 (5:36 pm) · 5 replies
I just read this blog post which had an interesting idea - to profile the game, record a journal of player input, then replay it in the profiler/debugger (since performance may degrade to the point where you can't actually play the game in realtime). They also mention that you can use these saved inputs to test changes you make - replay the same journal, and the game will desynchronise or have some unexpected outcome if you've broken any gameplay parts of the engine.
Doesn't Torque already have this kind of journaling built-in, or do I misunderstand the purpose of the journaling system? Could we use journals to make sure we don't introduce gameplay-breaking changes?
EDIT: And what about gameplay recordings? Do these still function in the engine? I'm going to start looking into these questions - starting by porting the journaling unit tests!
Doesn't Torque already have this kind of journaling built-in, or do I misunderstand the purpose of the journaling system? Could we use journals to make sure we don't introduce gameplay-breaking changes?
EDIT: And what about gameplay recordings? Do these still function in the engine? I'm going to start looking into these questions - starting by porting the journaling unit tests!
About the author
Studying mechatronic engineering and computer science at the University of Sydney. Game development is probably my most time-consuming hobby!
#2
08/07/2014 (9:30 am)
Well, I tried recording a demo. As soon as I try to play the demo, it just immediately crashes Torque. 
#3
Legions had this problem for years until one day I decided to just add a small 200ms delay before the recording starts.
If you look at the engine code its pretty picky about what the starting block is. That was my theory about why it worked anyways.
08/13/2014 (9:22 am)
Quote:Well, I tried recording a demo. As soon as I try to play the demo, it just immediately crashes Torque.
Legions had this problem for years until one day I decided to just add a small 200ms delay before the recording starts.
function GameConnection::onConnectionAccepted( %this )
{
Client::connectionAccepted();
UploadSkinsRuntime();
if (($IsADemoPlayback == false) && $Pref::Demos::Record)
schedule(200,0,"DemoRecording::startRecording");
}If you look at the engine code its pretty picky about what the starting block is. That was my theory about why it worked anyways.
#4
Good catch.
08/13/2014 (9:25 am)
You know, connections are finicky. The same applies to cycling levels - you have to add a little delay if you cycle levels using a trigger or other player action or it just hangs.Good catch.
#5
08/17/2014 (1:52 am)
The crash seems to happen because I was using HiFi networking. If I use standard move class, it plays fine. 
Associate James Urquhart
Gameplay recordings are slightly different - they are handled by the networking system.