The game of chess dates back to the 6th century in South-East Asia. Originally played with ceramic and resin, we thought it would be interesting to use modern tools to see if we could code it for the digital world using the Raspberry Pi.
2 Coordinating Our Work & Team Dynamics
We were aware from the inception of our idea that its success depended on having enough time, and consequently we decided to get the assembler and emulator nished as early as possible. Early on, we decided to use the games room inside our hall to work in, because it was usually empty, had a large HDMI screen to test on, and was geographically close to each of us. Our strategy for the compulsory part was simply working full time on the project, whilst thinking ahead about what equipment we needed for the extension. We tried to be resourceful in this respect. For example, we used the HDMI television screens inside our halls of residence to test our display, and we did not even need to purchase HDMI-HDMI cables since we found televisions that already had them attached. When we realised we needed extra parts (primarily buttons and extra wires and resistors) we did some research on prices and split our orders into the parts which could be found on RS and Maplin, and the parts that could only be found on Amazon (the buttons), before sending the former to Tristan and buying the latter ourselves. This meant we could minimize our spending on components.
Before we decided on our extension, we had been optimistic about our timing, and indulged in splitting to consider dierent ways of implementing emulate. From assemble onwards, we both gelled as a team and became more focused. We decided we needed to delegate our programming better, so our strategy shifted from allowing each person to consider dierent implementations of code, to deciding on the specication for the code beforehand, as a team, before delegating each other to write dierent sections of it. We found that merging the contributions from each team member into the nal result, as opposed to choosing one person's code and trying to bring everyone else's code into it, resulted in completing the code in much less time. We acknowledged our dierent backgrounds and tried to take advantage of our dierent skills - we were all procient in programming C for the assembler and emulator, but parts of the assembly chess were more suited to some than others. Gun had developed games before and had the most experience in assembly, so it was decided that he should work on the game logic. Xu, who liked debugging and tackling new ground, was chosen to focus on the display. Bora, who came up with our image compression scheme, was chosen to write the C program dcd_gen and became responsible for graphics, including the storage of the piece templates using assembly directives, and writing draw_square(), which is used to generate square images on the screen. Despite focusing on the areas which most appealed to each of us, we also made sure to go over each other's work and help with other sections of the code. Not only did this mean we would cross-check and pick up mistakes that had been missed, but also that we were each given the opportunity to learn about all aspects of game development in assembly. For example, we debugged Gun's game logic with our graphics, and Xu wrote the promote_pawn() method, which is called directly by the game logic.
We noticed that our teamwork started o relatively fragmented and became more cohesive as the code grew. This was partly out of necessity - having completed our separate parts we needed to make sure they came together - but mostly because as our game became more complex we increasingly had to consult each other's knowledge on design details and bugs. The three of us started coding on dierent laptops, since we were at our most productive when all three of us were actually coding and early on in the project producing functioning code was our...
Please join StudyMode to read the full document