http://i.imgur.com/EINiN.png
I've done this exercise before, but I need to rehash old topics to get back in the swing of things. I convinced myself (and more or less verified in the documentation) that the container I'm packing the buttons into keeps track of them (the pointer to the button widgets) such that they can be individually "closed" when you click them and the callback function knows which button to remove from the view.
I never really had a firm grasp on g_signal_connect_swapped but it's a good shortcut to sending kill signals to widgets so I roll with it. The API and internet in general isn't any help here, but I never NEED to use it and I haven't run across anyone else's code that has much of it.
Up next in the book is some detail about the order the buttons are packed in (top to bottom, bottom to top, there are functions for both) and some info on resizing the main window and the consequences of the child widgets. THEN it starts into vertical and horizontal dividers and tables. This is especially important since the way I want to lay out the Wumpus UI will require both.
Wednesday, April 6, 2011
Wumpus planning 4
I got some good advice on how to divvy up the program responsibilities.
Let's say I started with the map data structure. Would I define it in a header file, or in a separate .c file? I rather imagine I'd put it in a header file. I don't have a particular preference, really.
I got some decent practice dealing with keeping functions in different .c files (really the trick is in the main .c file including the function prototype) and being able to see variables (extern) from .c file to .c file. I don't have all the trickier cases hashed out but I haven't had any real problems yet.
I'll try to stick to the Model/View/Controller paradigm that Matt tuned me into. I wonder how that would have helped me with the .plx reader? It certainly would have helped to keep the file reading functions away from the display functions. In fact the reader could have just done the right thing and dumped the data to allocated memory for whatever visualization function to deal with later.
I think this is a good plan, but the specifics of what goes where need to be nailed down. The map itself (static, non-moving parts anyways) will go in one function, and the player, bat, and Wumpus can go in another structure. A few posts ago I had them all in the same structure, but the map structure is going to get a bit more involved because I want it to contain pointers to the rooms it connects to (instead of assuming linearity). Saying "check if the room the player form this struct is has a swamp against the room in this struct" should be easy enough. I dunno - might think on that a bit more.
In the meantime I for real need to get banging on GTK a bit more so that I can get a UI going.
Let's say I started with the map data structure. Would I define it in a header file, or in a separate .c file? I rather imagine I'd put it in a header file. I don't have a particular preference, really.
I got some decent practice dealing with keeping functions in different .c files (really the trick is in the main .c file including the function prototype) and being able to see variables (extern) from .c file to .c file. I don't have all the trickier cases hashed out but I haven't had any real problems yet.
I'll try to stick to the Model/View/Controller paradigm that Matt tuned me into. I wonder how that would have helped me with the .plx reader? It certainly would have helped to keep the file reading functions away from the display functions. In fact the reader could have just done the right thing and dumped the data to allocated memory for whatever visualization function to deal with later.
I think this is a good plan, but the specifics of what goes where need to be nailed down. The map itself (static, non-moving parts anyways) will go in one function, and the player, bat, and Wumpus can go in another structure. A few posts ago I had them all in the same structure, but the map structure is going to get a bit more involved because I want it to contain pointers to the rooms it connects to (instead of assuming linearity). Saying "check if the room the player form this struct is has a swamp against the room in this struct" should be easy enough. I dunno - might think on that a bit more.
In the meantime I for real need to get banging on GTK a bit more so that I can get a UI going.
Tuesday, April 5, 2011
Wumpus planning 3
Ok, so I have a map structure.
The program would flow like this (very high level):
1) Initialize map data
2) Draw map
3) Give player feedback (unless 100% done graphically)
4) Wait for input (up/down/left/right/fire arrow/quit/restart)
5) Update map data structures (set player location flags, etc)
6) Re-run the Draw Map function
So, the data in the array drives what's drawn. It's easy for my naiveté to get in the way and want to drive it with the graphics itself (check for pixel colors or something) because that's what I used to do as a kid. Live in data-space so that the drawing method can be as agnostic as possible.
I would love to do this with GTK to handle the keyboard events and some kind of graphics element. Imagine a square grid of tiles and then below that a text box that updates the player on what's happening or gives instructions on what to do. If I wanted to get some widget practice I could even add in arrow buttons to drive the movement.
The program would flow like this (very high level):
1) Initialize map data
2) Draw map
3) Give player feedback (unless 100% done graphically)
4) Wait for input (up/down/left/right/fire arrow/quit/restart)
5) Update map data structures (set player location flags, etc)
6) Re-run the Draw Map function
So, the data in the array drives what's drawn. It's easy for my naiveté to get in the way and want to drive it with the graphics itself (check for pixel colors or something) because that's what I used to do as a kid. Live in data-space so that the drawing method can be as agnostic as possible.
I would love to do this with GTK to handle the keyboard events and some kind of graphics element. Imagine a square grid of tiles and then below that a text box that updates the player on what's happening or gives instructions on what to do. If I wanted to get some widget practice I could even add in arrow buttons to drive the movement.
Wumpus planning 2
It's easy to represent a grid with a 2d array. You can even use a 1d array as long as you know when the next row is supposed to be (assuming an 8x8 grid array[63], elements 0-7 are row 1, 8-15 row 2, etc).
I've been trying to think of how to dynamically generate the grids. The first iteration is going to be hard coded most likely.
Mleh. Some of my most productive coding has been in the early morning (around 5-8am) oddly enough. Ana is on spring break so I haven't been awake at that time in almost two weeks. Coding in the evenings is almost impossible right now because I'm too tired from work or I've taken work home with me.
The first thing I'm going to do is come up with a level storage concept. Lets keep with the 8x8 level size. Each of the 64 elements needs to have the following defined:
1) Does it have pit or Wumpus clues in it?
2) Does it have a Wumpus, pit, or bat?
3) Does the player start here?
This could be solved with a 64 element array of structs.
struct room {
int Wumpus;
int Bat;
int Pit;
int Moss; // the pit clue
int Blood; // the Wumpus clue
int Player; //tells the future graphics device to render the player here
}
The level setup would init all of those to 0 (for false) and then make another pass that places the Wumpus, bat, and pit (and the clues, too) and then puts the player start somewhere far enough away from each (or not).
If I was feeling sassy I'd make it even more complicated by adding variables to define which rooms each room connects to - that way I could have rooms with tunnels. For example - lets say I'm in a room with exits to the North, South, East, and West. In the Wumpus game I played it was common to have one exit connect to another, like the North exit would loop around to the East such that going North or East would put you right back in the same spot.
Here's a screenshot of that: http://www.giantbomb.com/hunt-the-wumpus/61-13729/
But for now I'm not feeling sassy. I'm feeling depressed because I don't have time to code and I can't find a sensible 2d graphics option.
The horrible irony is that we never had problems with graphics back in the QBasic/Pascal days! We were rendering sprites defined by text files back then!
My kingdom for a 486 with a VGA card.
I've been trying to think of how to dynamically generate the grids. The first iteration is going to be hard coded most likely.
Mleh. Some of my most productive coding has been in the early morning (around 5-8am) oddly enough. Ana is on spring break so I haven't been awake at that time in almost two weeks. Coding in the evenings is almost impossible right now because I'm too tired from work or I've taken work home with me.
The first thing I'm going to do is come up with a level storage concept. Lets keep with the 8x8 level size. Each of the 64 elements needs to have the following defined:
1) Does it have pit or Wumpus clues in it?
2) Does it have a Wumpus, pit, or bat?
3) Does the player start here?
This could be solved with a 64 element array of structs.
struct room {
int Wumpus;
int Bat;
int Pit;
int Moss; // the pit clue
int Blood; // the Wumpus clue
int Player; //tells the future graphics device to render the player here
}
The level setup would init all of those to 0 (for false) and then make another pass that places the Wumpus, bat, and pit (and the clues, too) and then puts the player start somewhere far enough away from each (or not).
If I was feeling sassy I'd make it even more complicated by adding variables to define which rooms each room connects to - that way I could have rooms with tunnels. For example - lets say I'm in a room with exits to the North, South, East, and West. In the Wumpus game I played it was common to have one exit connect to another, like the North exit would loop around to the East such that going North or East would put you right back in the same spot.
Here's a screenshot of that: http://www.giantbomb.com/hunt-the-wumpus/61-13729/
But for now I'm not feeling sassy. I'm feeling depressed because I don't have time to code and I can't find a sensible 2d graphics option.
The horrible irony is that we never had problems with graphics back in the QBasic/Pascal days! We were rendering sprites defined by text files back then!
My kingdom for a 486 with a VGA card.
Sunday, April 3, 2011
Wumpus planning
Since I'm struggling with the graphics element I've decided to work on the game logic part. I also spent the afternoon reviewing some old GTK stuff just to make sure I could pick it up again where I left off.
The game is played on a square grid. The player, the Wumpus, a pit, and a bat live on the grid. The player moves about the grid one space at a time. If he inhabits the same space as the Wumpus he gets eaten. If the player inhabits the same space as the bat he will be transported (by the bat) to a random space. If the player inhabits the same space as a pit he will die.
The Wumpus and the Pit leave clues. Spaces around the pit are "swampy" or colored green. Spaces around the Wumpus are "bloody" or colored red. The caveat (and this varies from implementation to implementation) is that not ALL the spaces surrounding the Wumpus/pit are specially colored.
To win the game you must kill the Wumpus with an arrow. Once you determine (via the clues) where the Wumpus is, you fire an arrow in the direction (up/down/left/right) that the Wumpus is relative to you. In the game I played I think that if you missed the Wumpus would move but the old clues would remain (and new clues would be added, making it more complex). Some games I think missing means the Wumpus knows where you are and eats you.
The game is played on a square grid. The player, the Wumpus, a pit, and a bat live on the grid. The player moves about the grid one space at a time. If he inhabits the same space as the Wumpus he gets eaten. If the player inhabits the same space as the bat he will be transported (by the bat) to a random space. If the player inhabits the same space as a pit he will die.
The Wumpus and the Pit leave clues. Spaces around the pit are "swampy" or colored green. Spaces around the Wumpus are "bloody" or colored red. The caveat (and this varies from implementation to implementation) is that not ALL the spaces surrounding the Wumpus/pit are specially colored.
To win the game you must kill the Wumpus with an arrow. Once you determine (via the clues) where the Wumpus is, you fire an arrow in the direction (up/down/left/right) that the Wumpus is relative to you. In the game I played I think that if you missed the Wumpus would move but the old clues would remain (and new clues would be added, making it more complex). Some games I think missing means the Wumpus knows where you are and eats you.
Friday, April 1, 2011
tag
I wish I could tag my posts. I can't find a post I made about GTK callback function prototypes that I need to check to make sure I'm not doing something dumb here.
2d
Man, I'm having a tough time convincing myself that Cairo is the way to go. There is a lower level "pixbuf" way of doing things in GTK, and Cairo seems to primarily do vector graphics (lines, curves, etc). I think it has some ability to load images but it doesn't seem to be what it's FOR.
Mleh.
Mleh.
Subscribe to:
Posts (Atom)