About this blog
My first actual complete game.
Entries in this blog
As the title suggests, I've been working on the event handling and user interface. They are tied together so they are updates/upgraded together. This has added a lot of complexity to the project but I believe it will be worth its troubles.
Originally, I had processed all the user input with the main window's event procedure using global variables. This worked pretty good as I could define the "actions" as variables. The variable, representing the action, would be either "true" or "false". This was pretty basic and old-school. So I rewrote, or wrote an entire event-engine.
I narrowed my choices down between two patterns: Observer and Visitor. Eventually, I choose the observer pattern. I figured it's features in abstraction would do nicely. I made the "Event" the subject that "EventHandlers" would subscribe to. I've not added a priority system yet, so all subscribers are currently handled in a FIFO manner. While each subscriber(EventHandler) is notified about the subject(Event) via Event::Notify(). In this method, each subscriber's event handling procedure is called. The procedure can return "true" for processed or "false" for pass.
It seams kind of redundant to subscribe to events, but it makes for cleaner code. I have two major events currently implemented: KeyedEvent and MouseEvent. Each define their own values and provide access to them via get/set accessory. Events are never queued. This may become a problem later, so I've been considering adding that feature when I add priorities.
I rewrote the user interface(UI). The base of all operation is the Widget. The widget defines most of what a UI component would be. From Widget, I have wrote several sub-classes that I felt I would use most often and leave the ones I would not use that often, only implementing them on a "as needed" basis. So far I have: Button, CheckButton, RadioButton, Slider and TextField. The first three are grouped together. CheckButton and RadioButton both derive from Button. Slider, is just that, a sliding control. It's something you would use to display volume. It's similar to a scroll bar, but doesn't have the end buttons.
All Widgets subscribe to events when enabled and render them selves with a global Theme. I felt using a global theme was a nice way of abstracting the rendering part from the components. In a way, they are all like builders, rendering custom images using themed parts provided by a global theme. They also use some of the image attributes, so if I change images they should adapt. I don't have a container Widget yet, nor have I implemented any layout scheme. I figured I would utilize the state machine I already use to act as a container for UI widgets. That only leaves a layout of some kind to manage how and where widgets would be and what might their tab-order be.
I've manage to stabilize the state machine more. While out of focus, the application will not go into a "Halt" state until it regains focus and resumes from a "HaltResume" state. When the application resumes from a "Halt" state, or just before actually, the current time is recorded. This eliminates continued processing while in the background and time jumps when re-focusing. I personally feel this has been my biggest hurtle. Making a stable system with reliable timing across multiple platforms.
The rest is cheddar. Ya know everyone just loves cheddar ;-)
Several bugs exist in this game and it is not entirely complete yet. Complete in the sense that it is a functional game. But it is not yet the game I originally had in mind. I've decided to start/continue development of it. Officially put it into what one may suggest a "time to polish" stage. I've listed a few problems I've notices so far that I plan on addressing:
I've noticed the game crashes under several, "easy to achieve" conditions. For example, task-switching. While in the background, the game continues to run. Music continues to play and logic continues to update without any interaction. Also, while re-obtaining focus, the game glitches out. This is an obvious bug in the state engine. Sadly, the OpenAL framework suffers too because the music continues to play because the state of the application was not handled as gracefully as it should have been. Timing is also an issue, mainly with accuracy.
2. User Interface (UI)
The user interface is currently "ultra-simplistic". I think better features are required to make a more "well-rounded" or "polished" user interface. While developing the interface, certain decisions were made that lead me to over simplify it. Mainly, the systems(OpenGL and OpenAL) and how they are implemented.
I think I could add features to this game, what they are and when they will become is still undecided.
The goal in this game is to basically get the highest score possible. You are given three chances to do so. You gain score points by destroying meteors. Depending on the size of meteor that's destroyed, smaller(usually faster) meteors will break apart. The scoring is as fallows: large meteors are 20 points, medium meteors are 50 points and small meteors are 100 points.
When I wrote this application I chose to write it from the ground up. No pre-packaged software, no source code apart from my own. I used OpenGL for the graphics and OpenAL for the sound. All the graphics are drawn using OpenGL's immediate mode. I never really had a design document or anything like that, I just went off what I had in my head.