I’m still not able to use the “debug” feature correctly. I mean the possibility to replay the code step by step using the step line below the code on the right.
First strange behavior, often I saw multiple green arrows on different line of code. If the green arrow on the left of the code represent the current step, it should be only one, no ? (Or maybe it represent something else, but what ? )
But most annoying, each time I request to advance one step in the code (button step forward), the display scroll directly to the begining of the code. For the first steps, it’s ok, but when it executes code below the first page…It continues to display the first page. If I scroll down the code to view the execution point, It will scroll up again as soon as I press step forward. Grrrrrr.
Am I the only one the have this problem ?
Yes it is. Thanks, I can use it now.
I still see multiple green arrows, but that’s not big trouble.
Maybe a missing feature is the ability to go one call ahead. We can advance statement by statement, but not call by call.
And the time line is not precise enough.
Hmm. We have keyboard shortcuts to go back and forward by one statement, and ones to to back and forward by 5% of the level duration. Do you think extending the next statement shortcut/button to go to the beginning of the next call would be helpful? Should we add another shortcut?
Extending the feature of the next statement shortcut/button seems great.
When you reach the end of the current call, it goes to the beginning of the next call…
And it seems the most simple to implement (without knowing the code below
This way, we could really explore all the code. Problem, that could be long if we have a lot of statement.
But If we’re allowed to propose more complex ideas :
My real interest is to know what my code decide in each call, and to advance from one call to the next.
So I would like to see at the end of each call, what was the action selected.
But that’s not always the same line of code,
and I don’t really care of the 100 first statements that try to find the ennemies, or try to analyse my forces.
I could add in my code a final statement like : FinalAction =…;
And the best could be the possibility to mark this line (like a breakpoint) with a red point on the left, and with two arrows, so we could stop on this line for each call.
I understand it’s more complex to implement, but that could be great
For the action tracking, it seems like the HUD view action timeline is pretty good at that, no? Do you want that to be available for more units? Or is it missing something?
That’s true that this is a great help to get an overview of the strategy and what happened.
But a link with the calls is missing when you want to go to debug. Same problem as with the timeline.
Maybe with a feature to advance from call to call, we can more easily find the call that generate the “terrify” for example.
If I well undestand the way the game is running, during each call we can define the action of the hero, And we can say something to our troups. This last point is not visible on the Action timeline.
The action timeline is not available for troups. Does it could help ? Maybe, or maybe it’s too much information…
(one day, I was able to view the action timeline of the opponent hero, it was very interesting. Was it bug ? because I’m able to do that anymore).
If I continue on the missing points, it could be great to know the code running in our troups. Not to modify it, but just to know what they really will do when we ask to, for example, “defend”.
I thought I’ve seen somewhere an example of troups code, but, or I dreamed, or it’s well hidden somewhere, or it was removed…because I can’t find it anymore. If it’s not available at debug devel (read only mode), it could be placed in the help. The same for the spells. I found it difficult to know what they really do : action, range, duration. Some information are available, but not all.
Because we didn’t notice many people using the action timeline in our UX testing, we decided to hide it in some cases to make room for other HUD properties, like attackRange and maxSpeed, since we can only fit five properties in one column and the action timeline replaces the second column. Thanks for letting me know that you find it useful. Maybe we’ll try to use it a bit more often.
If you check out the level editor, you can see the troops’ code: http://codecombat.com/editor/level/dungeon-arena – most of their logic is in the AI Components. In Brawlwood, you get to control all the troops, too. (But as a result, the level is harder and runs slower.) We are trying to strike a balance between exposing useful information and overloading the player, but you can check out all of the code in the level editor.
