Well, I left for a trip to Glasgow for a job interview, got back and spent all night and most of the next day getting intimate with the toilet bowl. I've just now had my first solid food in 36 hours (a slice of dry bread) and I'm in no particular hurry to try another.
So. Not a lot happened to report in that respect.
Meanwhile, if you don't know already, there's an alpha release of Otherworld going. Buggy as hell, but we're working on getting it into shape. I think that's mostly what I'll be doing between now and Friday.
Wednesday, 27 July 2011
Saturday, 23 July 2011
Otherworld and ... other stuff
OK, so that was waaaay too long in between posts. I've been working on Otherworld, and for some reason wasn't comfortable posting about it in this blog. Don't ask me why, it makes no sense at all in retrospect.
So, I'l probably post a bit about some of the stuff I'm doing for that. No reason I can't meditate on Actionscript as well as C++.
Probably Inform7 as well. I've been looking at some of the adult based interactive text adventures out there: Valente and Fenoxo in particular. The whole transgender doesn't do anything for me I'm afraid, but they way they've been using Inform is a bit of an eye opener. So I've been playing around with something similar that plays more to my own particular interests. So expect a bit of that to show up as well.
(I know, I know ... another new project that'll last just long enough to look interesting and then get dropped in favour of the next shiny language. What can I say? It's how I learn things).
So, I'l probably post a bit about some of the stuff I'm doing for that. No reason I can't meditate on Actionscript as well as C++.
Probably Inform7 as well. I've been looking at some of the adult based interactive text adventures out there: Valente and Fenoxo in particular. The whole transgender doesn't do anything for me I'm afraid, but they way they've been using Inform is a bit of an eye opener. So I've been playing around with something similar that plays more to my own particular interests. So expect a bit of that to show up as well.
(I know, I know ... another new project that'll last just long enough to look interesting and then get dropped in favour of the next shiny language. What can I say? It's how I learn things).
Monday, 31 January 2011
Loading issues fixed
well, so far as loading chapter headings and background images goes, anyway. Still a lot of cases need adding.
Next I want to do the shuffle code. there's two parts to this: shuffling the narratives in a scene (or items in a narrative, or options in a choice, etc, etc, etc) and then there's re-arranging the treeview to reflect the change.
Let's get test cases for the Scene, Narrative and the rest, first.
Next I want to do the shuffle code. there's two parts to this: shuffling the narratives in a scene (or items in a narrative, or options in a choice, etc, etc, etc) and then there's re-arranging the treeview to reflect the change.
Let's get test cases for the Scene, Narrative and the rest, first.
Saturday, 29 January 2011
A Test Case
SceneEdit, Boo. Test Case. Why isn't the image tag loading from XML?
[Test]
def load_background2():
source = detab("""
<scene name="GameStart" default="" desc="wibble wibble">
<narrative name="waking_up" desc="In which our hero ...">
<image path="data/images/foo.png" />
<image path="data/images/bar.png" />
</narrative>
</scene>
""")
sr = StringReader(source)
r = XmlReader.Create(sr)
scene = Scene()
scene.load(r)
/*
* make sure we have a narrative
*/
Assert.AreEqual(1, scene.narratives.Count)
/*
* get the narrative, check the name
*/
n as Narrative
n = scene.narratives[0]
Assert.AreEqual("waking_up", n.name)
/*
* now - it should have two narrative items attached
*/
Assert.AreEqual(2, n.items.Count)
And that fails: there are zero items in the narrative. Also of interest is an error message in the test output saying "name image not handled". I missed that in the general output chatter when running the app itself.
A bit of grepping tracks that down to the Narrative class:
def load(r as XmlReader):
_name = gatt(r, "name")
_desc = gatt(r, "desc")
while r.Read():
if r.NodeType == XmlNodeType.Whitespace:
continue
if r.NodeType == XmlNodeType.EndElement:
if r.Name == "narrative":
break
continue
if r.NodeType != XmlNodeType.Element:
print "unexpected node type: ${r.NodeType}"
break
if r.Name == "narrative":
break
if r.Name == "snippet":
sn = Snippet()
sn.load(r)
_items.Add(sn)
continue
print "name ${r.Name} not handled"
So I need to add a case to that loop for every tag I intend to read. Tedious, but at least I found it.
Incidentally, that's lousy O-O methodology. One of the basic ideas behind OO is that you have subclasses so you don't need to have ifs or switches like this. The trouble is that this kind of breaks down when you're reading text data.
The OO way to do it would be to have a factory method, typed as NarrativeItem that took the class name as a string and returned the appropriate item. You'd have a reader class specific to each tag and register them with the factory so it knew what objects mapped to what strings.
Really though, life's too short. Getting all that working and debugged is a task in its own right, and for something as minor as this, it just isn't worth it.
Of course, all that may change as the code evolves. For now though, we'll go with the old-fashioned approach.
[Test]
def load_background2():
source = detab("""
<scene name="GameStart" default="" desc="wibble wibble">
<narrative name="waking_up" desc="In which our hero ...">
<image path="data/images/foo.png" />
<image path="data/images/bar.png" />
</narrative>
</scene>
""")
sr = StringReader(source)
r = XmlReader.Create(sr)
scene = Scene()
scene.load(r)
/*
* make sure we have a narrative
*/
Assert.AreEqual(1, scene.narratives.Count)
/*
* get the narrative, check the name
*/
n as Narrative
n = scene.narratives[0]
Assert.AreEqual("waking_up", n.name)
/*
* now - it should have two narrative items attached
*/
Assert.AreEqual(2, n.items.Count)
And that fails: there are zero items in the narrative. Also of interest is an error message in the test output saying "name image not handled". I missed that in the general output chatter when running the app itself.
A bit of grepping tracks that down to the Narrative class:
def load(r as XmlReader):
_name = gatt(r, "name")
_desc = gatt(r, "desc")
while r.Read():
if r.NodeType == XmlNodeType.Whitespace:
continue
if r.NodeType == XmlNodeType.EndElement:
if r.Name == "narrative":
break
continue
if r.NodeType != XmlNodeType.Element:
print "unexpected node type: ${r.NodeType}"
break
if r.Name == "narrative":
break
if r.Name == "snippet":
sn = Snippet()
sn.load(r)
_items.Add(sn)
continue
print "name ${r.Name} not handled"
So I need to add a case to that loop for every tag I intend to read. Tedious, but at least I found it.
Incidentally, that's lousy O-O methodology. One of the basic ideas behind OO is that you have subclasses so you don't need to have ifs or switches like this. The trouble is that this kind of breaks down when you're reading text data.
The OO way to do it would be to have a factory method, typed as NarrativeItem that took the class name as a string and returned the appropriate item. You'd have a reader class specific to each tag and register them with the factory so it knew what objects mapped to what strings.
Really though, life's too short. Getting all that working and debugged is a task in its own right, and for something as minor as this, it just isn't worth it.
Of course, all that may change as the code evolves. For now though, we'll go with the old-fashioned approach.
Friday, 28 January 2011
Shuffling Along
OK, time to look at the shuffle problem. First of all the verb needs to change to "move", if only on the buttons. "Shuffle" takes up too much space. (That said, I'm going to need another row of buttons before I'm done, but that for later).
The thing that stops this being trivial is that we need to be able to shuffle anything from menu choices to narratives.
I think I need some more test cases...
The thing that stops this being trivial is that we need to be able to shuffle anything from menu choices to narratives.
I think I need some more test cases...
Thursday, 27 January 2011
Shallow Bugs and Whoremaster
Well, there are that many bugs in this editing tool, if I hadn't doucmented the test suite as I went, I'd wonder if I ever tested it.
The thing is, short of some complicated and expensive software, there isn't a good way to repeatably test GUIs. (OK, it should be possible to do some tricks with NUnit and reflection, but I've never quite got that to work in practice).
Anyway, the theory is to put the application logic into a dll and test the hell out of that. The GUI code is to be as thin a wrapper around the dll as possible. But the GUI still needs testing - which is what I'm belatedly doing now, I suppose.
On the bright side, the bugs have generally been pretty superficial - which should be one payoff of the TDD phase. There shouldn't be any deep errors in the application logic, because I have tested the hell out of that.
On another note, I'm quite enjoying playing Whoremaster again. One of the drawbacks of developing a game is that somehow you never get to play it. You make changes and you test them, but somehow you stop playing for fun. Having had a break from the dev process, I'm starting to enjoy the game, and in doing so I#m starting to think about what I'd like to do to the source code.
I'm not about to break my sabbatical just yet but ... I'm starting to look forward to doing some work on the program again.
The thing is, short of some complicated and expensive software, there isn't a good way to repeatably test GUIs. (OK, it should be possible to do some tricks with NUnit and reflection, but I've never quite got that to work in practice).
Anyway, the theory is to put the application logic into a dll and test the hell out of that. The GUI code is to be as thin a wrapper around the dll as possible. But the GUI still needs testing - which is what I'm belatedly doing now, I suppose.
On the bright side, the bugs have generally been pretty superficial - which should be one payoff of the TDD phase. There shouldn't be any deep errors in the application logic, because I have tested the hell out of that.
On another note, I'm quite enjoying playing Whoremaster again. One of the drawbacks of developing a game is that somehow you never get to play it. You make changes and you test them, but somehow you stop playing for fun. Having had a break from the dev process, I'm starting to enjoy the game, and in doing so I#m starting to think about what I'd like to do to the source code.
I'm not about to break my sabbatical just yet but ... I'm starting to look forward to doing some work on the program again.
First Or Second Person
I keep alternating between wanting to write scenes in first and second person. So I thought I'd throw the question to the audience, as it were, and see what people think.
Both styles can be effective. The old Infocom style text adventures generally used second person narratives:
And that generally worked. The style was very much based on the pencil-and-paper role-playing games of the time, but you can tell a tale and get the player to identify with the protagonist. Of course you probably need to be a bit careful what words you put in the player's mouth, (and what thoughts you put in the players head!). Even then, games like Curses and Trinity play from the perspective of someone who definitely is not the player, and they still work very well.
Japanese style ADV games on the other hand tend to use first person, at least from the examples I can bring to mind. The dialog tends to be stream of consciousness from the MQ.
Anyway, opinions anyone?
Both styles can be effective. The old Infocom style text adventures generally used second person narratives:
You are in a round room.
> PISS IN THE CORNER
Sorry, I don't understand "corner".You are in a round room.
And that generally worked. The style was very much based on the pencil-and-paper role-playing games of the time, but you can tell a tale and get the player to identify with the protagonist. Of course you probably need to be a bit careful what words you put in the player's mouth, (and what thoughts you put in the players head!). Even then, games like Curses and Trinity play from the perspective of someone who definitely is not the player, and they still work very well.
Japanese style ADV games on the other hand tend to use first person, at least from the examples I can bring to mind. The dialog tends to be stream of consciousness from the MQ.
This is a very strange room I find myself in. It appears to be completely round.I think this possibly works better for ADV text. Second person seems a bit like constantly telling the player what to do. It's all right for descriptive text, as in Zork you have to say what happens to the player as the result of his choices. But then you get a lot more choice per text passage in Zork than you do in any ADV game.
It's all a bit confusing to me. They told me to take a piss in the corner, but there are no corners to piss in.
Maybe I could do it in the middle and claim the piss drained there. Maybe that would work. Or maybe they would see through my ruse and be angry with me.
It is a conundrum.
Anyway, opinions anyone?
Subscribe to:
Posts (Atom)