First, there’s an exploit: After using your daily activity, exit to the menu, save the game, then load it. When you return, you will be told ‘Time to sleep’ but it will allow you to do another activity. Using this, with lots and lots of saves and reloads, seems to accelerate the problem detailed below, but I do not know if it is THE reason.
So at first, I believed that it was my cruddy desktop machine that I use at work which was causing the slow degradation of Kudos’s performance. At first, it’s perfect. Slowly, it begins to get a bit choppy during the description of the day’s events. It begins to miss clicks. Dragging faces becomes difficult. Finally, clicking Rest/Sleep causes the game to freeze for 20+ seconds while it thinks hard about what it’s doing. Saving and loading the game begins to take an extraordinarily long time, sometimes as much as two or three minutes.
Now, this machine is slow, but it’s not THAT slow. Process Explorer from sysinternals indicates that there’s a slow memory leak somewhere, but it doesn’t seem to correlate.
Quitting and reloading your save game doesn’t help. But starting a new avatar- without closing the program at all- does.
This gets me thinking, ok, it must be something about the avatar/save game. So I start poking around. First place I hit is the debugdata folder in Kudos’s program files, which has a debug.txt file that has swollen to 26mb. Ouch. If you’re rewriting the entire file rather than using file system api to append to it, that’s going to cause the huge delays I’m seeing.
So I find the save file, one that loads fast, one that loads (and thereafter, runs) slowly. The slow one has an obvious problem- it’s 7MB of xml. Parsing 7MB of xml is bound to cause a bit of a delay.
It seems there’s a bug with the saving/loading of games which is causing your list of previously performed activities to expand exponentially. The list of activities performed has several thousand duplicate entries- 8200 my editor estimates- of the same activity.
It seems that in each interaction, one activity’s count increments- in this case, jogging:
2413,10,63,9,4,15,1,5,10,2,10,5,14, 90.00,30.84,0.74,0.74,97.61,16500.00, 2880523.000 Have a bath! 19 Go jogging 18 Wine And Cheese Evening 2 Clean your home! 6 Do a cryptic crossword 3 Go shopping 5 Play Chess 1 Tennis 1 Museum 2 Play sudoku 11 Trip to the movies 1 Visit Casino 1 Have a bath! 11 Go jogging 4 Wine And Cheese Evening 2 Clean your home! 4 Do a cryptic crossword 3 Go shopping 4 Play Chess 1 Tennis 1 Museum 2 Play sudoku 11 Trip to the movies 1 Visit Casino 1 Have a bath! 11 Go jogging 5While this could be merely a symptom of the exploit, it may also have to do with the slow degradation of performance while not using it- the autosave feature could be instigating it.
On a completely separate note, several benchmarks were done on XML parsing, and it was discovered that using attributes rather than subelements can significantly reduce your load times. Ie, rather than:
Go shopping 4You would use instead:
I hope this information helps.
Cliff, please IM or email me if you have a few minutes.
.