Author Topic: Debugging and other helpful things  (Read 26239 times)

MorleyDev

  • Newcomer
  • Posts: 5
  • Karma: +0/-0
  • "It is not enough for code to work."
    • View Profile
    • http://www.morleydev.co.uk/
    • Email
Re: Debugging and other helpful things
« Reply #30 on: December 12, 2012, 10:08:12 PM »
I tried Google Test, but I like to do a "Given X When Y Then Z" structure with Test Fixtures, where most logic is in the SetUp ("Given X When Y") and the Tests themselves only contain the Assertions ("Then Z"). Well, sometimes the Given is alone and the When and Then get combined, but not often. Not strict BDD, but more inspired by BDD but without the strict requirements.

Google Tests' lack of Suite support made organising that layout tricky and kept me with UnitTest++. I did use Google Mock, but I like to have "Weak" setups of functions with strong verifications after the calls are made and Google Mock didn't support that.

I use C# at work, where we do TDD in this manner using Nunit and Moq which work very well. But C++ doesn't have the kind of reflection that lets Moq work.
« Last Edit: December 12, 2012, 10:10:07 PM by MorleyDev »
All code is guilty until proven innocent, unworthy until tested, and pointless without singular and well-defined purpose.

tuturto

  • Rogueliker
  • ***
  • Posts: 259
  • Karma: +0/-0
    • View Profile
    • pyherc
Re: Debugging and other helpful things
« Reply #31 on: December 13, 2012, 05:31:17 AM »
NUnit combined with Moq is a good toolset. Much nicer to specify mocks on the fly than to code them by hand. Do you happen to have any C++ code with tests online? I have zero experience with that stuff and it would be interesting to see how other languages do things. I might learn something new that way.

I was again playing with IPython and wrote rendering methods for my levels. Here's a console dump: http://tuturto.github.com/pyherc/sketch/ipython.html. I had to scale down the final image a bit in order it to fit better on screen.

I realised that since I have more or less the whole game running (save for UI currently), I can poke around the data and experiment with things. I can even add new monsters on the level and trigger their AI and make them to wander around and fight. Might be useful if I ever want to really tinker with AI.
Everyone you will ever meet knows something you don't.
 - Bill Nye

tuturto

  • Rogueliker
  • ***
  • Posts: 259
  • Karma: +0/-0
    • View Profile
    • pyherc
Re: Debugging and other helpful things
« Reply #32 on: January 01, 2013, 05:10:27 AM »
Since I can get the program up and running without UI, I started tinkering again with Sphinx and removing duplicate data. I have a page in manual that lists most of the weapons with their pictures. Same data is kept in the game too of course for the game to use. When I change the game, I have to change the manual, which I sometimes may forget.

So, I added two more directives that I can use while writing manual: itemimage and itemdescription. Those link directly back to game and pull some of the data from there, saving me from typing it.

If I type in manual's source:

Code: [Select]
Dagger
======
.. itemimage:: dagger

.. itemdescription:: dagger

I get

Code: [Select]
Dagger

XXX
Light and simple weapon that does not do much damage. Small size allows skilled wielder to do critical damage easily though.

Where XXX is a picture of dagger.

If I want to create a nice little table listing all the weapons that the manual mentions, it is as easy as typing:

Code: [Select]
Weapon tables
=============
.. itemtable::
   :type: weapon

That saves some typing and keeps the manual up to date regarding to items.

Full source of the items page of manual is here: source and resulting html-page is here:
result
Everyone you will ever meet knows something you don't.
 - Bill Nye