# data[].attributes.body
I made this difficulty curve when I didn't have my laptop. It's a little rough, but I used it as a reference for when I implemented the difficulty curve in the game.

# data[].attributes.body
Chris recorded the presentation, so it's available on whatever camera he used

# data[].attributes.body
Instead of screening it to classmates (most of my class had already played and given feedback on the game beforehand anyway), I decided to post my game to a forum on Reddit called /r/playmygame, a subreddit in which people submit their projects and people in the industry play them and give feedback. I ended up getting some extremely valuable feedback from people who work in the game industry professionally, which is fantastic.

https://www.reddit.com/r/playmygame/comments/4nrc06/bullethell_a_sloweddown_take_on_a_traditionally/

# data[].attributes.body
The game can be found here:

https://untitled.itch.io/bullethell

Note that it will only work on Windows computers.
Feel free to email me if something goes wrong.

# data[].attributes.body
Aaaaand we're done! At long last.

Today was mostly spent cleaning things up. I reordered my padlet, labelled everything etc., and then proceeded to write my evaluation for the rest of the day. All I have left to do is upload my mindmap to Padlet, which will be easy as it just involves scanning it in and uploading it when I get home. Chris said that he could sign me off on the condition that I do this, so I'll definitely be uploading it as soon as possible.

I believe that's everything. Unit 8 is over. Year one is over. I guess that's it until September...

Suppose I better start thinking about my next FMP. God knows it shouldn't be another game - too much stress. Maybe a video project... Who knows - we'll see.

# data[].attributes.body
It's the final week! I cannot wait to be done with this unit. Enjoyable as parts of it have been, I'd be lying if I said it wasn't extremely stressful.

Unfortunately there's not all that much to report for today. I spent the day working on my evaluation, and am around 1000 words into it so far, so about half way there. One thing of note is that I was chosen to be interviewed on C.A.S.T. about my game, which was really cool. I went to do it in the afternoon and it went really smoothly, can't wait to see how it turns out in the final edit.

Right now the plan is to finish and get signed off on Wednesday, assuming I can get my padlet organised and my evaluation finished quickly enough. Again, sorry for not being able to be too detailed in this entry, but the day mostly consisted of just getting our heads down and grinding out the rest of the work.

# data[].attributes.body
It's out! After all this development hell my game is finally complete and has been published on itch.io! 10 people have already downloaded it, according to the analytics!

This is ridiculously exciting, and I'm tremendously proud that I was able to get this finished even with the colossal setback of my laptop throwing in the towel.

Today was mostly spent prepping the game for publishing. I took away all of the debugging tools, changed the version number from "Alpha 2.0" to just "Version 1.0", wrote up the description, took some screenshots of the game, created a banner, uploaded everything and clicked publish. And just like that, there goes this entire term's work into the wild.

At the end of the day I also printed out several QR codes (which is the image attached to this entry) and put them up around the open plan. I doubt this will draw in much traffic, but still it felt good to finally be doing some promotion for the game.

Moving forward, all that remains to do is clean up my padlet a little and finish my evaluation. I'm also going to ask some friends and family to give feedback on the project, to see if I can get some thoughts from people that don't really have a direct involvement in the development. I think I'll also post a thread about it to a forum on Reddit by the name of /r/playmygame, which is a subreddit dedicated to giving feedback to this sort of thing. I don't know if anyone will respond, but it's worth a shot at least

# data[].attributes.body
Not as much to report today, I'm afraid, as there haven't been many changes made to the game between now and my previous entry. I decided that yesterday would be my day off - something which I don't think is unreasonable considering how hard I've worked on the game non-stop over the past week. Today, though I decided to refine what I had a little bit more. The first order of business was pretty simple: I decided to slightly alter how the tutorial worked. In playtests, I found that players would often get stuck on certain areas of the tutorial, as the "Press ENTER to continue" sign was not big enough. To fix this, I decided to just add a big sign to the middle of the screen prompting the player to press enter, rather than just having it be a small line of text in the corner. Sure enough, the problem completely disappeared when I did this, and the playtesters no longer got stuck wondering what to do when they encountered particular screens of the tutorial.

Finally, I also implemented the options menu that allows the user to toggle certain sounds that they might find annoying. This was a technical nightmare, so I won't put you through the same pain and frustration I experienced by explaining every aspect of implementing it, but rest assured it involved a lot of trial, error, and fiddling with the code. In the end, it works perfectly, which means my game is ready to publish - which I'll be doing tomorrow.

# data[].attributes.body
I may be exhausted, but this is the most fun I've had in a production period all year. Everything's done, more or less, save for some slight polishing that will be implemented based on the feedback of my respondents today.

First I'd like to give a bit of an update about what has changed in the game between the previous diary entry and this one (I have a full changelog in the .zip file, though).

I decided to change the dimensions of the playfield. While before, it was 512x512 pixels, is it now 544x512 pixels. A slight difference that doesn't really affect gameplay, but I figured I'd mention it since it renders the playfield size described in the game design document to be inaccurate. I did this because when making the tutorial and implementing the pause screen, I noticed that it was basically impossible to centre the text windows without directly editing their sprites (and with GameMaker's less-than-ideal sprite editor, just the thought of doing that was too tedious for words). For this reason I just decided to expand the width of the playfield by 32 pixels, allowing me to centre everything without adversely affecting gameplay. Obviously this meant that I needed to tweak the wall code somewhat, and edit the code that spawns the coins, but overall the end user won't notice it.

In terms of other changes: the difficulty curve has been added, though in a slightly refined form compared to my in-the-dark calculations that I drew up last week. Being able to actively test it makes all the difference with this sort of thing, so I was able to get it done and to quite a high standard relatively quickly. Either way, if I do need to change something I intentionally made the code quite adaptable, meaning that if need be I can very easily make a revision to it without breaking everything.

I also changed the way Smartbombs work - now, instead of the player having to click it with the mouse (which was just painfully awkward because you'd have to take your hands off of the keyboard to do so), the player can now just press Space to use a smartbomb. This brought up a few technical issues but in the interest of time and also not boring you to tears, dear reader, we're going to skip that part.

The final update of note is the sound effects. I'm actually really proud of this one, so I'm going to briefly explain how it works:

When the player moves, a random note in a scale is played. It's quite a simple system but it makes for quite a nice effect - during playtests the respondents would often start pressing buttons to a beat trying to make a song out of the random tones. The scale from which the notes are played are random, and chosen at the start of every game. There are currently three possible scales: A Minor Pentatonic, C Major, and C Sharp Major Melodic. These were all carefully selected to make sure they were in tune with the sound of the coin pickup (which is in C Major and just consists of the notes C and E).

Some players found this annoying though, so I will definitely be adding an options page to allow them to toggle certain sounds.

Generally, though, the reception to the game in playtests has been overwhelmingly positive. Some constructive criticism here and there, but no one has outright said that the game is bad. Several of my tutors referred to it as addictive - and while this is certainly positive for me, I do hope that my project doesn't put too much of a dent in their productivity.

So, moving forwards, I guess I just need to iron out some more stuff, and then I'll finally be able to publish to itch.io. I've already created an account, so it should just be as easy as writing the description and such and hitting publish!

# data[].attributes.body
Wow. I don't know how to say it but it seems as though my issue is fixed. A friend of my mother's agreed to let me borrow her laptop in order for me to finish my work. I thought the project was completely over due to this complication but now it seems that I'll be able to complete it to the extent that I had originally intended to.

The situation is still not ideal, though it's far from irreparable. I'm a week behind on work, as I wasn't able to develop any of the game without my laptop. Today, though, I'm tackling the simplest things first. During my downtime, I drew up plans for both the difficulty curve and the tutorial, so I implemented (a slightly revised version of) the difficulty curve last night and completed most of the tutorial today. This is still tedious, but it's much better than doing nothing at all. And I suppose that doing the planning for these tasks prior to developing them definitely softened the blow when it came time to implement them.

For now, the plan is to work all through the weekend. I intend to finish up the tutorial tomorrow (Friday), then work on polishing stuff up (adding a highscore system, shifting some controls around etc) on Saturday, then adding sound design + other polish work on Sunday. It's going to be tough but if I get everything done on time I should be set for my second playtest by Monday!

Hopefully I'll be reporting back with a wealth of updates and survey results in the next diary entry.

# data[].attributes.body
Yep, the project is more or less dead - or at least frozen in its current state for the time being. The college cannot install GameMaker: Studio on the network, as it costs a minimum of £300 to get the relevant license. I was able to use the trial version for free as an individual, but as a company/organisation they cannot do the same.

This isn't the only bad news: my father took the laptop to be assessed by a computer repair company, and they said that only Dell themselves can fix the issue. The best they can do is extract the files from the hard drive and put it onto an external hard drive, but this doesn't include applications like Game Maker.

In short, there's nothing I can do other than send it back to Dell at this point. This will be free, as the computer is still under warranty, but I have absolutely no idea how long it will take, and it could potentially only be back after the deadline.

I just don't know what to do, the only solution I can think of is to just use the demo I currently have as my final project and leave it at that; there's nothing else I can do. I suppose I can write a short press pack and present it as a proof of concept, but that's far from ideal.

I dunno, I guess we'll just have to see how it plays out.

# data[].attributes.body
The laptop situation is getting progressively worse. There's currently nothing else I can do other than just wait while Delta and the IT department. This is painfully frustrating: I spent so long getting through the preproduction paperwork looking forward to finally being able to enter production, and now the moment I'm able to enter production the worst possible thing that could have happened happened. Again, I've been making an effort to stay as productive as possible during this downtime, but it's an uphill battle. I started writing my evaluation and played around a bit with Scratch (another, more simplified game development tool designed by MIT for teaching children the basics of coding), but that wasn't particularly fruitful.

Not much else to say,  unfortunately. Currently my options are super limited: I either spend money on getting the laptop repaired, or I send it back to Dell and potentially get it back post-deadline. Neither of these are preferable at all, but I'm going to look into whatever I can do. Since it's bank holiday on Monday, my next diary entry will be this coming Wednesday - here's hoping something is sorted by then.

# data[].attributes.body
Well, the worst has happened. Yesterday, my laptop powered down, and due to the broken power button I cannot turn it on again. I managed to back up the project files to my USB stick before I lost the laptop, but without a laptop with GameMaker: Studio installed, those project files are useless.

So first thing this morning I went to see the IT help desk and asked if they could install GM:S on the college network, so that I could at least proceed with development when I'm in college. They said that they needed Delta's approval, and to check various things about the software (such as licensing etc) before they could do anything about it. I emailed Delta about this, and she seems to have set the ball rolling, but I don't know how long it's going to take - assuming that they do manage to install it on the college network, which is far from guaranteed.

This is especially frustrating because I was supposed to start production today. Everything was going really well, so I suppose I was due a roadblock at some point, but this one is especially debilitating.

Instead of sitting around twiddling my thumbs, I made an effort to be productive today, and I ended up producing the plans for the game's tutorial (which was on my to-do list anyway) and cleared my backlog of unwritten diary entries. I don't think I can keep this up for long though, as the majority of my work at this point depends on being able to code for the game. Hopefully we find some sort of compromise or resolution soon, otherwise I'm not sure what the fate of this project will be.

I can only hope that more light will be shed on the situation tomorrow.

# data[].attributes.body
Today was interesting. I brought my laptop in so that I could get screenshots and such for my experiments. In the morning, I noticed that my laptop's power button was broken. This is worrying, because it means that when my laptop powers down there's going to be no way of turning it back on, and by extension no way of continuing development on the game.

For the time being, my strategy is just to not turn it off, but I don't know how long I can keep that up. Just to be safe, I backed up the project files to my USB stick, so that if my laptop does end up dying, I won't lose all of my work.

Anyway, the rest of the day was spent pitching to Hannah and completing my experiments. Hannah seemed really pleased with my preproduction documents, and didn't really have anything bad to say about them, which was very relieving.

In terms of experiments, these were a little boring. I felt like I was repeating a lot of what I was saying in my game design document, but i managed to get through it in the end, and ended up with a document of over 500 words, which is absolutely fine.

So, on Wednesday, I should be able to begin production, if all goes to plan.

# data[].attributes.body
Today was pretty uneventful, and was mostly spent finishing up unfinished documents. I cleaned up my research analysis a little, and did some referencing and proofreading on the Game Design Document.

Then, I completed my production schedule. Since I'm making a game, and also have most of the game completed at this point, this was pretty difficult. Most of the production schedule has been left intentionally vague, as at this point I have no idea of the sort of problems I'm going to face. I'm looking at it more as a general, rough timeline than a set-in-stone production schedule. Structured enough to keep me on track, but also not detailed to the nth degree. I think this is good because it means I don't have to spend an age detailing every single point of production ahead of time, and as such I can spend more time on production. Production schedules as intended for short films and the like don't really mesh all to well with game development, anyway.

All that's left is to do my experiments, which I intend to get done on Monday.

# data[].attributes.body
It's honestly surprising just how easy it is to write about a subject that interests you.

Today I managed to produce both my Pillars and my Game Design Document more or less to completion in one sitting.

The Pillars were easy enough, they're just a small document consisting of four immutable one-sentence principles on which the game is built. It's basically just a general layout of the philosophy of the game design, and while this may seem unnecessary it really isn't - it serves to keep the game designer focused on what they want to achieve by producing the game.

The Game Design Document is the main deal. It's a massive document explaining literally every aspect of the game, from code, to structure, to visuals - everything is picked apart here. Because this document is going to be read and marked by people who likely don't have any experience in game design, I made an effort to make it as accessible and understandable as possible. Thankfully, when I showed this to Hannah, she said she understood it fine - which is a sign that I succeeded.

What I'm most proud of is that I managed to produce it pretty much completely today, writing around 1700 words of it. All that remains is to do the referencing, which I can get done in about 10 minutes tomorrow morning.

The last preproduction document I need to produce is my production schedule, but again that should be relatively easy to complete.

# data[].attributes.body
Today was spent finishing up our big research analysis document. I was honestly dreading producing this thing, as it needs to be around 1800 words. In the end, though I found it relatively easy to type it up, and ended up getting the word count over 2000.

I think the reason that it was so easy to type up was because I'm very interested in the subject matter. For this reason, I was able to get most of it done relatively quickly. This is why I think it's important to include one's hobby's and interests in one's college work; it works wonders for motivation. I also think that this is the reason why units like Unit 3 were so difficult to go through - there wasn't a lot of interest in the subject matter at all, so it ended up just feeling like a grind.

Also, I didn't have to conduct a great deal of new research in order to produce the document, as I was able to recycle most of the research I did for Unit 2 (which was our research unit, in which I researched and designed a gaming magazine), so that also made things much easier.

Now that this is done, I need to move on to my preproduction documents, which are the Game Design Document, the Pillars, and the Production Schedule.

In conclusion, things are going really well so far.

# data[].attributes.body
Oh wow, a lot went down today.

I started out by just finishing off all those research documents in the morning. The rest of the day was spent conducting research.

On Tuesday, I spent some time putting together a prototype for my game. I managed to get it into a playable state with all the features I wanted, and took it into college with me today. I then printed out a sheet and collected a few email addresses of people that wanted to take part in the playtest. Then, using wetransfer (a service that allows you to email large files), I sent the game and the survey to the respondents.

Whilst waiting for the responses, I had a conversation with Hannah and she said that I needed to have some sort of evidence of experimentation to go along with my work in order to achieve the higher grades. With this in mind (and with time to kill while I waited for my survey results) I typed up a document detailing my process of creating the game up until this point. For all versions after this, I'll type up a more traditional changelog. This just served to lay out all the work I've done on the game prior to actually starting Unit 8.

And finally, I started the research analysis. I'm a little bit concerned about this, as it's a 1800 word essay that we need to have done by Monday, and I have quite a busy weekend ahead of me. I'm hoping that since I'm so far ahead on the production I can shift the timetable a little bit, but there's still a lot of work to do and not a lot of time to do it. Here's hoping it all goes well.

# data[].attributes.body
Today we continued with the completion of our research documents. There isn't really much more to say on this matter. I still had some trouble filling them out due to having an unconventional final major project, but in the end I managed to get them all done. What I intend to do is have a playtest tomorrow with members of the class, and then give them a survey. After that, all that's left to do is go back and put my results into the research documents, and then write the research summary afterwards (a hefty document of 1800 words. Not sure how I'm going to manage it, to be perfectly honest).

So yeah - there isn't really much else to say at this point. I'm sure tomorrow is going to be a little bit more eventful, so you'll get more out of me in the next entry.

# data[].attributes.body
Today, we started our research documents. Because I'm making a game, I found this to be a little bit challenging. All of the documentation on Qube is designed for more traditional media productions: short films, photography etc. For this reason I had to adapt the documentation to be more relevant to my project.

Unfortunately, however, some of the documentation still ended up being a little lacking, as I simply did not have enough to say on the matter. Take for instance the Production Requirements document - there really aren't that much requirements for me beyond "access to a computer with GameMaker:Studio". I managed to add more to it in the end, but I think that were I to make a short film or photography series I would have a lot more to say in this document.

All in all things are going pretty well so far. The other research documents have been actually kind of interesting, as I'm writing about and picking apart the techniques of game developers I admire. The plan is to finish these this week, and then move on to preproduction next week.

# data[].attributes.body
When my laptop broke, the only thing I was really able to do was plan the tutorial for the game. The following images were all made in photoshop and were used as a reference when implementing the proper, playable tutorial in the game.

# data[].attributes.body
The Game Design Document is the big one. This details literally every aspect of the game (in this case simplified so as to not give whatever pour soul that has to trawl through it for assessment purposes an aneurysm). This is my main preproduction document - I, at least, consider it to be about as detailed as a production schedule, storyboard, and most film preproduction documents should be, but I suppose that's for you to decide. My point is, this should be a reasonable alternative.

# data[].attributes.body
This was originally meant to be edited with whether or not I completed my objective but since my laptop broke this basically got thrown out the window and wasn't usable. I suppose it still serves to be an indicator of how organised I would have been, had I not had such a terrible roadblock.

# data[].attributes.body
The pillars are a small game design preproduction document consisting of four sentence-long phrases that act as a philosophy for the game to stick to. Hardly a vital piece of preproduction but it definitely helps to have some clear boundaries set so that you know not to cross them.

# data[].attributes.headline
Task 3a) Second Playtest Questionnaire + Answers

# data[].attributes.subject
Task 3a) Second Playtest Questionnaire + Answers

# data[].attributes.body
https://www.surveymonkey.com/results/SM-BZQRY8VT/

# data[].attributes.body
These are the files for the second playtest. This was conducted near the end of the process.

# data[].attributes.headline
Task 3a) First Playtest Questionnaire + Answers

# data[].attributes.subject
Task 3a) First Playtest Questionnaire + Answers

# data[].attributes.body
https://www.surveymonkey.com/results/SM-C32L97QR/

# data[].attributes.body
This was the changelog that accompanied the first playtest of the game. It's abnormally long, as I felt the need to detail the process of creating the game up until that point, just to give some more context.

# data[].attributes.body
This was the version of the game that was played in the first playtest. This was conducted at the start of the process

# data[].attributes.body
I created my moodboard on Padlet. It can be found here:
https://padlet.com/theuntitled154/91l53kdzbwp5