Unfortunately had to abandon sound code as other priorities cropped up, mainly getting the game to look right. After some photo-shopping today and general tinkering/commenting over the past 3 days, the demo is now finished to my satisfaction. One bug persisted but it is not a major problem at this stage.(it served a purpose in that it became a source for my testing report.) With the completion of this demo, I will now be focusing on my exams. During the summer, I’ll be moving on with the next phase of the game, starting by fixing the persistent bug, developing the plot further and then expanding the game accordingly.
Added some basic code for sound effects, simply passing loaded sfx into a static sfx class which has a method for playing it, which is currently called whenever the left or right mouse button is clicked. However, it repeats whenever the button is held down. Quite confident I can fix this, should have time but it’s not a priority.
At the minute I am mostly concerned with the game’s aesthetic. I added a bit more code optimization by removing redundant sprite-class properties (see last post, did same thing to npcs) but at this point the heavy coding is finished. I now want to make sure the game looks and sounds right. I had drawn the majority of art assets a few weeks ago and now I am editing and putting them into the game. I’ve been using photoshop to cut out un-wanted background pixels (which has aided the accuracy of the clicking mechanism, which will only detect an object if pixels are present. This will also help with an object layering error I’ve been having) and will be adding some shading, etc. It’s quite awesome to finally see my idea come together as I position the furniture and what not around my opening scene and watch my script pop up as objects are interacted with.
Very productive weekend. On Friday I made a class for npcs (inheriting from the same class as the one for my furniture as they are quite simple. The first instance of this is the receptionist in the first scene. On Saturday I made it so that clicking on the receptionist triggers a second video, which triggers the player going outside. This is the only way the player can leave, as clicking on the door tells the player they need to talk to the receptionist. In this way I have introduced the first class of puzzle in the game, whereby the player must trigger a specific event to continue. This was accomplished with a series of if statements found in the gamestate navigation portion of game1.cs which are triggered by a series of flags used to track what has been clicked, etc. Today I decided on all the objects that would be required for scene one and created them, giving them default positions on screen. I’ve also encountered and solved a series of bugs (particularly when trying to solve navigating from scene1 to the second video to scene2) which will form the basis of my testing report. I also optimized some code (got rid of some redundant properties in favor of a “this.(field-name) = (filed-name)” setup for my constructors in some of my classes, etc.)
Added a base class today. My pre-existing sprite class is now derived from it and it’s “update” and “draw” methods are now implementations of un-implemented abstract methods found in the base class. Now the game has inheritance and a loose form of polymorphism. When I add a human class (for handling npc sprites, actions etc.), it will also be derived from this base.
More progress has been made. A draft of the opening video for the game has been completed some stock art has been drawn up. This includes standard objects like chairs, a clock, a desk for the first game scene etc. The code for incorporating videos was a bit finicky at first but I got it working in the end. I also have game state switching working at this point, which coupled with some flag use and the object-clicking mechanic makes room navigation possible and switching from the opening video to the beginning of the game. I am now working on reverse engineering some polymorphism and inheritance into the game using an abstract class with a series of virtual methods, something that will be crucial to the later stages of the project which will grow in class size and require maintenance of a proper api.
Had to give over a lot of time to other assignments/tests int he past while. AS of now, game is working well, displaying different messages when different objects are clicked on using a series of flags(among other things) this enables room navigation. Currently working on some switch statement code I might consider using for dialogue options. Going to draft some dialogue for the first room and some of the art over the next day or so.
Really happy with this weekend, found a tutorial dealing with the tricky area of isolating mouse click-reactions to specific sprites on screen (essentially each item class now has code which detects the location of the mouse in relation to the location of a drawn sprite. It also detects if the mouse has been clicked. All these conditions are linked to flags.) Next up, I’ll be passing spritefonts into these classes, which will be drawn when all the flags are true. Also, I have been able to start removing a lot of static code by giving more responsibility to individual classes. I will still use some (for example my sound effect class) but my reliance on them is heavily reduced.
Here’s a simple activity diagram detailing the very first user actions in the game:
The last week went on changing the art for “Hero-Hunter” to make it acceptable for next week’s gamesfleadh. However, I was able to come up with an idea for some activity diagrams to help map out player interactions by a room to room basis. I will upload one over the weekend. I am hoping to load all the basic elements of the opening room and to solve my isolated clicking conundrum this weekend. Hopefully I’ll have time to import some new art and possible a rough cut of the opening cinematic. As part of a HCI lab this week (writing project proposals with given guidelines/requirements) , I was able to write a more detailed version of a project proposal, which helped me to visualize more elements of the game.
As of now, I have 4 builds of the game, each with slightly more functionality than the last. I want to keep these previous builds for documentation purposes and as fail safes for being able to rewind if I muck something up. The current build is very basic. I have loaded sprites through their own classes (furniture and such like). The player character is also loaded form it’s own class. I just added basic music code, which simply plays a background tune on a loop (really just so I can get an idea of what the whole package will be like). The mouse is visible on screen and by using two moue states, I can make certain sprites/spritefonts only draw to the screen when the right mouse button is held. The current player sprite is a hand drawn prototype I scanned in and altered with photoshop. Though not the final version, my subsequent re-designs have retained many of it’s features. Currently the game relies heavily on statics. This will be changed, but currently they are useful as a means for throw-away proto-typing. Basically, I want to build my first state as soon as possible, get my head around state changes, then go back and remove as much static code as I can. Once I have accomplished these two core concepts, the game will have its skeleton. I can already tell the final, complete version (that I would be happy to release online) will be sometime coming. The story concepts are coming along, supporting character art is developing and friends have been contacted about voice-acting. Progress is progress.