Week 6

This week we discussed data structures further, and considered the data flow of the system - for instance, to be able to move characters we need to know their path type, their (x, y) tuple, whether the destination contains an item (as this may change animations or mechanics), etc.

We also had some fervent discussions about sizing of our boards - I argued for consistency in size, while my partner thought the size should be variable dependent on the board size. These ideas could be balanced by maintaining a constant board size, which I am hoping we can implement in our level design.

The welcome screen design was also up to debate - we have one or two options which are similar, but different enough that they were up to contention. We will decide on one soon.

We decided officially to nest lists to design our levels. The levels will be lists of rows, which are lists of squares; each square will consist of a path type at [0], character or guard at [1] and button or goal at [2], with blanks …

Week 5

This week my partner (Liam) and I began implementation by discussing the types of data structures we'll be using in our program, as well as data flow throughout. We came up with a basic structure which goes thus:
- Assigning numbers to elements
- Partial definition of certain mechanics
- Level definition as triple nested lists
- Grouping of levels in ordered and indexable data type (list)
- Game initialisation: Main menu, level selection
- Levels: characters, then items, then guards in order of priority.

We started writing basic code which gives us a bit of an idea of what sort of basic methods we can use to implement mechanics, and came up with the following mix of python and a python version of pseudocode:

This basic programming requires little knowledge of pygame, as it is all about the mechanics of our game. This is ideal, as it gives us more time to learn to use pygame while still making progress on our designs. We will continue to develop this over the coming weeks. I also w…

Weeks 3-4

These last few weeks we did very little, which is why I compounded everything into a single post. We wrote an official project proposal and planned the Gantt chart which we will follow to the best of our abilities when creating our game. We hoped to get feedback on it soon, so submitted it on Wednesday last week; we received feedback and changed our proposal appropriately. We included particular detail in regards to our game's scope and aim, and included level designs we already have, with more additional detail.

Apart from that we did more pygame programming and Project Euler exercises for practise. I programmed several functioning 'games', such as an image of a ball which would move around at the touch of the arrow keys, a line which followed the user's cursor around a screen and changed colour according to input, and modifications to the program I have already shown Mrs Bennett of the square which moves around and changes colour when input is given by the user. We w…

Week 2

This week consisted of finalising general plans as to our game's premise and controls. We decided on including the following elements, with several basic behaviour definitions:

- A character, who can use power-ups and is controlled by the user. It will die if is ever on the same square as a guard. Its starting square is marked specially for the sake of later elements.
- Paths are the basis of the game; they are all at right angles and of equal length, and all elements must remain on them.
- Guards, initially stationary, will become alerted if the character crosses their line of vision. They will then follow the character: if the character leaves the line of vision, the guard will follow that same path. Guards will become un-alerted and stop moving if they kill a character.
- Pauses: these items will cause all figures except the one that picked the pause up to be frozen in place for a single turn. If a guard's line of sight is crossed or left while the guard is frozen, they wil…

Week 1

This is a blog throughout which I will summarise my progress in a group pygame project. This week consisted of the creation of an overall plan for the next term and a half. Here's a summary:

1. Gameplay:
    - Game genre (character-based y/n)
    - Fundamental concept / premise
    - A basic outline of items/obstacles to success

2. Theme
    - Graphics theme
    - Basic story appropriate to the theme
    - Adjustment of items/obstacles to fit the theme

3. Implementation
    - Design levels
    - Programming:
        - Mechanics
        - Graphics

4. Testing
   - Documentation
   - Desk checking
   - Appropriate adjustments
   - Repeat until final result is satisfactory

We have decided on quite a lot of aspects when it comes to the first section. Our game genre is set as a character-focused turn-based puzzler. The basic premise of the game is that in each level the character is trying to reach a final objective by traversing a square grid without being caught by guards on the way; …