Week 1 + 2

Week 1

The previous week did not get a development post because of nothing particularly special occurring. We spent the week preparing a previous project to be developed on. This included refactoring certain pieces of code so that the overall design is better.

Although there is nothing particularly visual here, scenes in the past were quite a pain to change between. A scene is a screen, or a place where information is displayed to the user. For instance here is the wizard shop scene:

Here is a scene which shows the smith:

Ignore the code. In any case, changing between scenes was difficult because of the design of the code itself. We fixed this issue by giving each scene a method. This method takes in two parameters: The scene to change to, and the way the scene will make the transition. Then in the main game loop we hook onto an event which fires whenever this method is run. By doing so we can manage all our scenes from our main game loop instead of through scenes which may have other scenes embedded into them. Thus the organization of our code has improved greatly.

Week 2

Week 2 we fixed up a notorious bug that had been plaguing the game for some time. This is a label alignment issue. It’s probably better I show a picture. Pay close attention to the blade/trim/handle material names on the right:

There was an alignment issue with these labels (labels are simply text). The labels were offset by about half their width. Unfortunately it isn’t as easy as pushing them back half their width either, as this causes issues depending on when the player reaches this scene. This bug has been narrowed down to an issue in which the menu was not aligning the labels each time they were created and has been fixed this week. The proper alignment:

Also this week we documented more of our code and refactored a few issues. To go into better detail I will give an overview of the game:

So the game looks like this. This is the shopkeeper, he has no functionality he is simply a scene in the game. However the does exist weapons in the game (and in the future he will sell some). The weapons in the game are randomly generated from a settings object, the settings object generates a random weapon and then we pass it onto the player/enemy/whatever. The problem with the previous code was that all weapons had a copy of their settings object which generated them. Code-wise it was nice to have access to this information, however not all weapons will be randomly generated. Specifically weapons that may be loaded in the future are not randomly generated, but created from a save file. Though it would be possible to save the settings object alongside each weapon, this is not necessary. By removing the settings object from all weapons though, this causes a few problems and so we had to change the design up to accommodate this change.

Part of the refactoring done this week involved removing control mirrors. These are essentially objects that take a snapshot of the button/label/etc so that it does not need to be rendered each time. This does however use up RAM as it produces a texture from the snapshot and renders that texture instead. In the past we had been using these mirrors to display the weapons gained in an adventure or the information regarding the weapon. We have fixed a bug which meant we no longer needed to use this way of rendering things.