|
Socoder -> Concept/Design -> The hard part |
|
| Wed, 11 Feb 2009, 20:49 | |
|
mindstorm8191 |
I'm building a simple-ish game, and I'm having quite a lot of trouble. The game code is basically done, but what's really troubling me is the front-end GUI. The game isn't really that far along, but this is drudge-work and I think its going to bring my project to its end. I'm starting to think that most peoples' projects hit this stage where the only next step is to build the front-end GUI. Does anyone else agree? -=-=- Vesuvius web game 
|
| Wed, 11 Feb 2009, 23:04 | |
JL235
|
Depends entirely on how you build it. For me it's been pretty trivial to build some buttons for my Sokoban game. Panels already exist due to how I've structured my middlewear. I start with an existing Actor class which by default knows how to update and paint itself, provides size and position, and can check for collisions against other Actors all by itself. I extend this with a ButtonActor class that adds the mouse tracking/checking code for switching between button state. It also adds three empty methods which it calls automatically: onPress, onHighlight and onRelease. Buttons are created by subclasses the ButtonActor and overriding those three methods with their button-specific code. Internally the ButtonActor uses the Blitz style of pinging the current state of the controls to tell when and which methods to call. Each subclass of ButtonActor (like the quit button) requires about 10 lines of boilerplate code (class definition, setting what images the button uses and the definition for overriding the appropriate methods). All the rest of the code is button-specific. This is typically either setup code (i.e. it's starting position or what layer it's drawn too) and the code to be executed when the button is pressed, highlighted or released. That is what I have today. In the future I plan to switch to an event based system for handling controls (i.e. onMousePress( runThisCode() )). It makes large amounts of control checking more efficient, aids with GUI's, can be used for in game elements and finally it also me to add synthetic events. These are control actions defined at the software level such as detecting double-clicks, if the mouse is dragges or if the mouse moves over a specific region on the screen. By also using existing, proven mainstream technology (i.e. Java, C#, VB.NET, C++) rather then a niche product (i.e. BB, BMax, Cobra) I also have lots and lots of resources to pick and chose from, all with tonnes of support. For example I have built my game in Java so for GUIs I can use Swing (which is cross-platform), SWT (which provides native components) and others including some OpenGL based GUI toolkits designed specifically with games and 3D applications in mind. The choice for niche products is typically far smaller, less mature, less documented, less supported and provide fewer updates/upgrades (if any). |
| Fri, 13 Feb 2009, 08:46 | |
|
mindstorm8191 |
JL, but see, all that is complicated. Me, I just want to get down to coding the game, and not worry about all the GUI elements. Right now I'm in the situation Tikihead is usually in. I don't have much of the game running yet, but I'm working on the interface.
-=-=- Vesuvius web game
|
| Fri, 13 Feb 2009, 13:53 | |
Stealth
|
 The game code is basically done, but what's really troubling me is the front-end GUI. I have the bad habit of building an elaborate GUI system before the actual game.The perfect team. Haha. -=-=- Quit posting and try Google.
|
| Fri, 13 Feb 2009, 23:39 | |
|
JL235
|
mindstorm In total, as a whole, yeah I'd agree. But I didn't build it as one piece. It's built from lots of little ideas, little bits of code with little changes and additions made over time. Each of those on their own is pretty simple.JL, but see, all that is complicated.The only important bit is that they are built as a library with code re-use in mind. |
|
|
| |||
|
| ||||