Archive for dialogue

Returning to Work

Posted in graphics with tags , , , , on February 15, 2009 by Tau

Well,  I’ve said a few times over the past couple months that I would be working on this again after a hiatus, and I hope that this time it’s for real. I think the best place to start is to sum up what I’ve done so far (for my own benefit as much as anything else) and post some screenshots of all the features I’ve coded.

Below is how the program starts up after typing python nsf.py into the command line. Yeah, I know, extremely bland. I’m sure I’d feel better about myself if I added some grass or something.

Opening Screen as of 15/02/09

Opening Screen as of 15/02/09

And how the dialogue prints out. I think the 1st thing to do is make that ugly blue box, well, not. Something with a border I think.

Sample of dialogue printing as of 15/02/09

Sample of dialogue printing as of 15/02/09

The basic message printing. Actually looks better than the dialogue, but still needs a proper border. I’ll use the same one for both I think.

Message Printing as of 15/02/09

Message Printing as of 15/02/09

That’s about it that you can see. I should work on some sprites, for morale as much as anything.. hope I can find the time.

Advertisements

Screen Messages

Posted in code with tags , , , , , on December 21, 2008 by Tau

I’ve just finished the classes for printing messages onto the screen. It’s basically the same as the dialogue classes, but requiring fewer variables: the text is read in from a file given as the argument of the event type “message” and blitted to screen.

Coming back to the code after quite a while has made me realise how much I shouldve commented the first time around. I’m going to go through all the files and properly document them, drawing up a diagram of where all the classes and functions lead.

Dialogue – On the Screen

Posted in code with tags , , , , on August 18, 2008 by Tau

Well, kind of. That which used to print in the terminal now appears as ugly text in an ugly blue box on the screen, and disappears when the conversation finishes. I moved the construction of the screen window to an external class that as a Get Screen function, which can be called by any other class, and thus drawn onto by any other class. It means all sorts of goodies can now be drawn whilst the main loop is running, such as dialogue, messages and menus. That said, my code is still ugly as sin.

I just need to create an image for the dialogue box to make it a little prettier, and it’ll be done, aside from writing the code for conversations generating gamekeys, by which I mean, for example, speaking with a NPC and getting some information from them allows you to proceed to a new area or whatever.

Next I think a few more events, such as finding items and attribute changes, and then really get going with the sprites, at least in order to finish this village and work towards some form of simple, wander around demo.

Dialogue Update

Posted in code with tags , , , , on August 17, 2008 by Tau

So I’m trying to get the dialogue to print out on the screen rather than in the terminal. Currently I’m doing this by sending the background all the way through a few functions to the dialogue class, where what is usually just printed is made into a new surface and blitted onto the background. This works fine.

However, the display won’t redraw in the dialogue class, only in the mainloop, meaning you see nothing until the conversation is over, and it all appears at once. Marvellous, if you’re psychic.

I really can’t see why this is. If the dialogue class can get information from he keyboard via pygame, and blit onto an existing surface, why can’t it simply redraw the screen? What’s so special about the main game loop? Is it because this is where the screen is created?

I wish I had a Magic 8 Ball.

Making Plans

Posted in code with tags , on July 26, 2008 by Tau

I’m finished with the dialogue classes for the time being. Whilst I do want it to print to somewhere other than the terminal, I can live with it for a while. The speech options now contain additional members self.final – Which tells the game whether this speechoption is a final one, and self.key which returns a string to be used as a game key.

Now, my plans for the near future are:

  1. Read in Events from a file, rather than hard code them like present.
  2. Write a Change Map Event, for the going in and out of places
  3. Draw Sprites/Plan Story – real RPG stuff
  4. Come up with a plan for a battle system

With regards to the look of the game, although I’d stated that it’ll probably be in the older style, I do want to avoid this just looking like it was made with RPG Maker. One of the reasons for self-coding is to have the flexibility not granted by these generic programs.

Grid Reference l3,3t

Posted in code with tags , , , on July 24, 2008 by Tau

I’ve written a file reader class for the maps, so that, like the dialogue, map information is read in from an external file, put into mapobjects and stored in a map, which can then be looped over and drawn. The file simply contains the co-ordinates, image file and permeability of what is to be drawn.

Now I think I’ll start drawing things, make the text from the dialogue print somewhere other than the terminal, and we just have something whole, albeit embarrassingly small, given the number of hours I’ve put in.

What I’m Playing

Posted in code, games with tags , , , , on July 23, 2008 by Tau

I actually got this done late last night/this morning, but as I had to get up only a few hours later, I elected not to blog it. The dialogue classes have been integrated with the main loop and read in from a file, whose name is defined by an event, which is stored in a list of eventlists, which is compared to the current location of the character when they hit the action button (gasp). The dialogue prints what the NPC says, then your options which you chose with a keyboard entry, and so on. However, there are some bugs at present involved with returning to the main game loop, but I know how I’m going to fix that, which will also be how the conversation produces a gamekey (my initial idea on how the story progresses based on what you’ve done).

So dialogue.py consists of 3 classes: DialogueOption, ReadFile and Conversation. DialogueOption contains the out text of the NPC, your choices in response and the corresponding keys. ReadFile, well, reads the file, and for each occurance of “start” or whatever, has a new dialogueoption created from the following data, and fills it all into a conversation. Conversation has a list of all the dialogueoptions, plus a list of all the keys. So, you see the first line of NPC text, your options a, b, c. Then if you press b, the code looks for b’s key in the list of keys, and returns the corresponding DialogueOption and runs it. Repeat until fin. This way you can have an infinite number of options and an infinite number of exchanges, based on the speech that is simply written in a text file. It requires hardly more typing than the text to be printed on screen. That’s what I wanted.

I’m aware that this blog must be pretty dull for non-pygame users (and maybe even for them) what with the lack of images/story from the game. Alas, that is still in R&D in the dark corners of my mind, but I can talk about the games I’m playing to stoke the old creative fire.

So, currently, on the SNES: Chrono Trigger, on the GBA: FF6, DS:FF3, FF12, Animal Crossing (anyone wanna visit?) and on the Xbox360: Eternal Sonata and Oblivion. I’m planning to “acquire” the new FF4 and Tactics for the DS as well, if I can find the time. Can anyone suggest any other SNES or Xbox games to try? Or anything else? Oblivion isn’t the style I’m going for, but some friends of mine refused to sleep because of it, so I’m giving it a go.

Ok, just a little glimpse. The opening sequence is (will be?) part inspired by [voices of a distant star]…