Chronicles of a Sofa Ninja

I wanted to talk a little about how I think that I have experienced this module, what I have learned about the technologies and just as importantly, about myself and how I engage with the course and my personal projects. I would like to explore what I did, why and what I would now do differently. I learned a lot, and not in the areas that I expected to.

I was too scared to start in C++

When we were given the task of creating an app for the Jam, I was too scared to do the project in C++. There, I said it. I was worried that I would not be able to finish the project to a good standard in the allotted 48 hours and I felt that having something the show for it at the end was worth more than the experience I would have got from coding the prototype in C++. So, I used Blueprint, exactly the tool that I am trying to move away from. In retrospect, I think that was the wrong move and this was pointed out by staff, although frankly, I didn’t want to hear it at the time. I was wrong about that. At that time, I was not so far along with learning C++ and have a lot more confidence with it now, but I think that it would have gained more from the project had I just struggled through and learned as I went along. Having said that, I think that there was also benefit in learning about raw C++ before jumping into Unreal’s version of it, but I now think that it would not have been as painful as I first thought to just have a go. Having completed the Battery Collector tutorial, I am really looking forward to a pure C++ project, which will begin soon.

I should have started the project again when it crashed

I cannot say that the Game Jam project was a failure, not at all. The fact that it crashed and I lost the entire project file lead me to a strong desire to embrace industry standard techniques for protecting project against just this sort of thing. I learned about version control quite quickly and have used it on every project that I have worked on since that time. The other lessons that came from that experience was the problem of circular referencing, which I am surely guilty of. I came from the direction that it would be more convenient for the ‘weapon’ to know about the ‘projectile’ and the ‘projectile’ to know about the ‘weapon’ but, it turns out that there is danger in this. Particularly in how objects are created and destroyed. If the objects need each other, its very risky to manage the start and end of their lives and they lean on each other in undesirable ways. I also found out that there are established Object Oriented Design Patterns and frankly, that has been a huge relief and I am now aware that there is a tool kit that I can learn that will help me plan and visualise the structures that I need to build for the games I make. However, although I learned a lot from the failure of the project, I feel that I missed out on being about to link the rest of the course material to that project. By the time that I realised that the rest of the cohort were carrying their projects forward, I felt that it was too late for me to do the same as I would have to rebuild mine from the beginning. I regret that decision and have decided, as detailed in my CPD report, to recommence the project applying the lessons that I learned along the way. I will be working on this during the three week break between modules.

First Class Blues

Here’s one that I was not expecting at all but actually hit me quite hard. When I came off the BA and having received 78%, I expected to take to the MA easily and knowing that I work hard and put a lot of hours in, thought that I would replicate that sort of performance. The realisation that the MA is a much greater challenge and very different to the course I studied before was slow to dawn on me and I feel that I responded quite negatively to the first set of marking comments at the time, despite receiving a respectable score for a first mark. I am pleased that my concerns were taken seriously and care was extended in explaining in more detail how I may have done better, but I didn’t expect my reaction to be so strong. I think that my confidence was bound a little more than I thought to my recent success with the Degree and perhaps I needed that to continue. That’s an error. I feel much better about things now and realise that I am receiving a tremendous benefit in having the think differently and in being held to a higher standard. It’s ironic as when I was exploring my options with regard to taking on an MA, I talked with staff at Falmouth about how I wanted to be surrounded by people smarter and further along than me, but when I experienced that reality, it took longer than I thought it would to adapt. I am grateful for the opportunity to be here and to learn from a variety of people, staff and students alike.

Impostor!

This is something that has only been identified very recently during a conversation with a member of staff but explains why I felt the way I did above. I think that I may have this ‘Impostor Syndrome’ regarding my ability to make games and in recognising how far I have come with in that goal. The thing is that this is in direct opposition to what I say a lot of the time. I find it easy to talk about the rate at which I have been able to learn how to do this work and the progress that I make all the time but actually, when I stop and recognise how I feel about it, I don’t yet feel that I belong and that at some point the gaps in my knowledge will identify me as a fraud. I think that was one of the motivations for Blueprinting the Game Jam project and for the the need to defend myself from the feedback that I received for the initial coursework in which I got a merit! I find that I continually remind myself of the things I have achieved as though they need to fuel the next challenge. I feel much better having had this realisation and am becoming much more aware that I do belong and that I can contribute and that it’s ok to get some things wrong and in fact, getting things wrong (combined with putting the effort in) shows that a person is learning and operating right at the edge of their current ability. I read somewhere, although I can’t seem to recall where, that the more specialised you knowledge becomes, the more obvious the gaps in it become. Also, the more you learn and achieve, the better your peers become. Both of these can fuel this problem if the are misinterpreted and yes, I think I may have done that.

The Direction of the Journal

While I was studying on the BA, we had to keep journals for each of the modules that we completed. The aim of that journal was to show the journey that each of us had and to show our ‘working out’ so to speak. I think that although I consumed the material from this course on reflective practice and writing, I didn’t fully appreciate the difference in the aim and style of this journal. On the BA, I wrote about everything that I did, what I thought about it, what was working and what was not, but it was missing the reflective side I think. I don’t remember committing much material that focused on how I had got to this level of skill, or why I had been encountering some problem or any real plans for solving those issues. It was all about the fix to the immediate problem, all about what I was learning to sort out the ‘line trace’ or the ‘overlap’ not registering, that sort of thing. I found it very useful, if a little too time consuming, although learning to type properly helped out a lot. I assume that we will need to keep journals for each of the modules that we complete and I will continue to practice what I have learned during this time. I bought one of the books that the course material recommended, ‘Search Inside Yourself’, and I will read it over the break between the modules.

Learning C++

I am very happy with the study that I have been able to complete on C++ and I feel much more prepared to tackle Unreal with it now. I do think that there are things I still don’t understand to a point where they could be effortlessly implemented (like I can in Blueprint now), but raw C++ certainly not alien to me anymore. I have almost completed the Udemy course I have been studying and its taken a long time as I have not left a single section without fully understanding the material, completing the quizzes and every programming challenge that the course sets, which are numerous.

In Conclusion

Now that the module is coming to an end, it’s clear what its purpose was. Who am I as a developer? Where do I want to go? What is stopping me and how do I deal with that? I did not expect so much reflection and I have struggled to come to grips with the academic writing, but I have received a huge benefit from the organised introspection. I now have a very clear aim, I know what I need to work on in order to get there and I have a structure in which to do that work. Over the break, I intend to execute the CPD plan I have created. First I will finish the C++ course that is nearly complete, then I will complete the design patterns examples and corresponding UML diagrams. After that, I will begin the Hostage Rescue project in C++ and set up a regular routine to learn and practice the math I need to learn in order to better understand the gameplay programming I want to do. At the bottom of the list, but still important to me, is the animation goal that I have as I think that starts the process of broadening my skill set as a developer. All the while I will split my time up so that Serial Link gets the attention that it needs also. I am confident that all of these topics are connected and that skill gained and work completed in one area will bolster my effectiveness in the other areas leading to overall progress.

As someone who has now worked on a few different project’s, although all academic in nature but one, I thought I should talk a little about my project management experience considering the nature of the material from week eleven. I will talk about how Agile was introduced to me, how I took to using it or not and how I think Kanban fits in to the mix for me.

Being introduced to Agile with Scrum

I was introduced to the Agile approach to software development and in particular, Scrum, early on in the BA top up course I took in 2017. As with most things on the course, the concepts were explained quickly and in a hurried fashion (our lecturer needed to be everywhere, all at once, but still managed to deliver a great course) and I don’t think that I understood what the benefit to the methodology was. I don’t think that I was alone in that either as although most of the other students present were on the course as a logical continuation of their study rather than coming in from the outside like me, they did not seem to have had to work in this way before. I was already vaguely aware of Kanban and had stumbled across Trello in reading around for better ways to manage my business tasks. We were informed that we needed to set up a Trello board and use the standard lists (To Do, Doing and Done) and although there was talk of Sprint’s, there was no mention of User Stories, the Scenario Testing to validate that they had been delivered or the idea of a Minimum Viable Product, at least not in those terms.

My First experiences with Agile

I think that considering the incomplete nature of the introduction to Agile combined with the sense of urgency that was being instilled due to the quality of the coursework needing to be very high, I saw Agile as a glorified to-do list. I thought that the bi-weekly catch up’s with the lecturer were just to make sure that the work was indeed moving forward. The idea of a ‘Sprint’ was not a lot more than ‘In two weeks I want to see where you are and I need to see that the project has moved on’ and not the heavily defined planning and tracking tool that I understand it to be now. Looking back, I would have benefited from understanding the link between the Sprints, the Backlog of User Stories and the fact that they combine to contribute to an MVP. I do think that the the idea of delivering something that worked as a whole was communicated and I do remember scrambling around to get assets that the team were working on into the main Unreal project file when each sprint was due. It’s fair to say that my memory of the process will be hazy as it was quite a while ago now and there was so much for me to learn and take in. I can say though that we did not create User Stories or Scenario Tests and in retrospect, that’s quite a large section of the Scrum methodology missing. In the teams we needed to choose a project leader and not a ‘Product Owner’, ‘Product Manager’ or ‘Scrum Master’, all important roles in the Scrum Agile approach. There were no Stand Ups, Retrospectives and work was frequently changed during the Sprint, which is forbidden until the Sprint ends and there is another Sprint Planning Meeting.

Despite a great many of Scrums implementation details missing, I did come away from the experience of the first two coursework projects with a better idea of why an approach like Agile should and does work. I liked the fact that there was no major upfront planning simply due to the fact that I had such little skill at that time, I would not have been able to create much of a plan past my ‘best guess’ at how something will go. I do appreciate that is the nature of most plans, but the clarity would have been very low and the probability that the content of the plan would need to change dramatically would have been high. That meant that Agile, even in its incomplete form, was quite a good fit for me and the team’s I worked with throughout the course as it was at least obvious that being flexible and responding to change was encouraged.

The mighty Kanban

When the need to complete a Gantt chart was thrown into the mix during one of the initial projects, I really felt that it was in direct opposition to all the benefits that had been communicated to us regarding Agile. Here was a document that was heavy in upfront definition and recording of tasks, dependencies and estimations of time and for me at least, seemed to be in direct opposition to the Agile methods. I think that it was intended that the Gantt chart be used in planning Sprints but I have since discovered that Scrum already caters for that kind of planning with the User Stories being broken down and prioritised and then being pulled forward by a team member willing to accept ownership of that task. Also, time is a tricky metric in software development, I know from my own experience, and so Story Points are used as a way to estimate the overall difficulty and complexity of a broken down User Story leading to a better estimate of how long the feature will take.

I did a little digging around at that time and stumbled across something that informs what I do even now. I found a presentation by a Microsoft project leader, Eric Brechner, and having watched that, was convinced that even Scrum, with the its limited planning and flexible nature, was still a little overly complicated. The way he spoke about Kanban really showed the simplicity of what he called Continuous Delivery. He calls the system an evolution from Scrum and talks about Scrum with respect. He does however say that he believes that the time spent Sprint Planning, tracking Sprint progress, holding daily stand-ups and the retrospective at the Sprints end would be better spent just, well, working. He talks about making sure that each of the Kanban board’s column’s are divided into two though, something that I had seen only in his presentation. The sub-column’s are the tasks that are to be completed and the ones that are complete. Sounds simple, but both of the sub-column’s contribute to the Work In Progress limit of the column that they combine to make. This makes it very easy to see what needs to be done from what is already done without the tasks having the move forward into the next column. The introduction of WIP limits in each of the columns keeps work coming at a steady pace so that developers don’t get overwhelmed and effort is tunnelled into one or two tasks (or however many tasks are appropriate for the team). But, having tasks that are complete still contribute to the the WIP limit does something very important. It act’s as a self imposed bottle neck that immediately shows problems with the work upstream and stops work being constantly pulled forward to that particular column, completed to that point and pooling there with no where else to go. This stops work being wasted on features that are not a priority and encourages the team to find out what the real problem is and band together to solve it.

That’s the major difference. Scrum focuses on using the product backlog to house the User Stories just like Kanban, but from that, the Product Owner must create a sprint. All attention is then on that Sprint and the content of that Sprint should not change until it is complete. In Kanban, there is no such structure and tasks are pulled across to board at a steady pace and completed. The Sprint seems to me to be the last area of rigidity. So is it useful? Well, business people would likely think so as It’s the closest thing that an Agile practising team can put forward as a forecast. If there are team members that are perhaps not as intrinsically motivated as they could be, they may benefit from the push of the external, intermediate deadline. But I think that if the team is motivated, and the ‘Done’ rules for the board are clear and being obeyed, the Sprint is just not needed. On of the other key arguments is that at the end of the Sprint, there should be a prototype of the software that is available for the Product Owner to test. With Kanban, its no different. The only component needed on the board is a done rule in a ‘Build’ column that collects a number of tasks defined by the WIP limit, and forces a build in order that they can move onto the next column.

I would go with Kanban all the way if I could, and I have with Serial Link, but it’s clear that Scrum is very established. That means that in order to fit into other studios and be able to collaborate, I also need to embrace Scrum and that’s fine. It’s not the difference between cars and motorbikes, it’s as if we were talking about how different petrol and diesel cars feel to drive. Different, but closely related.

Using Now

In my little studio and in making Serial Link, I am using Kanban. I have dedicated one of the walls and set up the following columns.

• Backlog
• Breakdown
• Development
• Implementation
• Build
• Validate
• Done

The Backlog is where I keep all the items that I want to work on although I currently don’t have this organised in User Stories or Epic’s. I think that given the chance to set it up again, I would do it that way as I feel that approach captures the emotional experience you want to player to have.

The Breakdown column is where large tasks get, you guessed it, broken down into smaller tasks. So, a large task like ‘Improve the Gore’ was broken down into several things like ‘Find better particles’, ‘Find out why the decals clip’, ‘Find a better way to draw blood, reducing the number of line traces’ and so on. I think that creating User stories would have been better here though and in my next project I will try using that approach.

The Development column is where the design and prototyping happens. This is where I get a bare bones ‘I could show this to other developers’ sort of feature done. It would have no UI and be printing feedback to the screen but all the pieces would be there before it is declared ‘Done’ and can move on. The WIP limit is quite high to accommodate the high number of smaller tasks that may be required to complete the main task from the Breakdown.

The next column is Implementation. This is where I take the feature from ‘developer ready’ to ‘playtest ready’. Items don’t leave this column until they I am happy to put them in front of a play tester with confidence that they will understand what it does and how to use it. The reason that the WIP limit is only one is that I am the only developer that touches the project file. Knowing more about version control now, I would change this in the future and allow other developers to check in there own assets and so on.

After that is the Build column. When the WIP limit is reached here, the project must be built and satisfy the frame rate criteria. This means that even though I am not using Sprint’s, I still have incremental builds being triggered in a systematic and predictable way. There are a couple of things that I will change in the future with regard to the done rule here. Replace ‘extended period of time’ with an actual number and ‘no bugs or crashes’ to something like ‘all bugs captured in kill list’. The presence of bugs should not mean that the build cannot go through to validation, the next step, as it could be that the feature needs heavy reworking anyway.

Coming toward the end of the board is the Validate column. This is where the features are tested by users and is critical for making sure that we do not develop in the dark, emerging one day with something that no-one wants. I need to make sure that we are creating things that people actually want to play with and testing is very important to me because of that.

The end of the board is the Done column and is just a place to collect the stickies that have travelled through the process. Its good to have them there as a reminder of whats gone into the project and allows better reflection in the future when planning new projects. Well, I suspect so, as this is the first one that I have managed this way!

Will that Change in the future?

In the immediate future I will be managing the Hostage Rescue project using the Trello board I have set up and using Scrum because I want to get the experience of doing that. I can see that in projects where I have the authority, I will be using Kanban only as I really do think that its the better way to go. But I have nothing against Scrum and I want to be able to contribute well to other studios using it.