Grand Comment Blog
|
So this will be one long blog with all of my comments on other students blog posts. Blog1 – Cai https://caiart.wordpress.com/2018/02/08/development-blog-1perspective-and-boat/ Your blog gives very good insight into the design aspect of your game. The design decisions your team took and why they took them is mostly explained. Since the post focuses mostly on the decisions you made as a group it would however be interesting to read a bit about how you reached these decisions. The ideas behind your usage of colours is interesting and it will be fun to see how it turns out. You mention how “this decision is subjected to changes in the future”, could you maybe expand a bit on that? How do you think it might change? Overall your post has a good sense of clarity and transfers a clear sense of value of the project. There are however certain parts where some reasoning as to why a decision was taken Other than that, the only thing the that would preferably be improved are the various grammar mistakes.
Blog 2 – Marcus Ford https://boxparadoxgames.wordpress.com/2018/02/16/week-2-alpha/ Your blog is easy to read and well structured. Your breakdown of what you have done this week and the last week helps to convey the size and progress of the game as a whole and finishing with a summary section and an expectations section helps to ease the reader out of the blog as well. However,4 this might be improved by having some sort of conclusion after the summary, similar to your section “Am I happy with my work so far” but a bit more fleshed out. As for the main meat of the blog, it is written in a simple way so that even people with little to no knowledge about coding can understand it. I also like how you reflect on which parts of the code that could be improved or shortened as well as what and how future assets and functions could affect the current ones. Additionally, while it is not necessary it would be interesting if you had a section where you went a bit more in depth about one of the more difficult features to program. However, it seems in the instructions that we are supposed to focus mostly on a single artefact to write about. So while I greatly enjoyed reading this you might want to think about that for the next blog.
Blog 3 – Mikael Ferroukhi https://gamedesignbugbear998722415.wordpress.com/2018/02/22/game-design-journal-3/ I like how you get to the point very quickly in your blog. You also focus more in the beginning on how you were affected by scrum instead of only looking at what the team did to enforce Scrum. I also like how you reflect on what scrum has done outside of just improving the workflow and I agree that the Scrum methodology forces all of the participants to work more closely to each other. As for the sprint planning you go over the basics of sprint planning and do a good job of explaining it. However, you don’t mention the backlog or sprint reviews at all and it would help if you also brought up the sprint reviews, at least briefly. As for the backlog I would be very interested in how you wrote it and would have liked to read a segment around; How the backlog was organised? How often it was updated? If most of the features you planed originally looked the same during the first week of Beta? To improve I would probably include a bit about the backlog and sprint reviews, but all in all your post has a good structure and is easy to read.
Blog 4 – Alexander Sinn https://shirovfx.wordpress.com/2018/03/02/ink/ Your blog is mostly well structured and easy to read, it also looks really nice. While the big headings and lines break up the different sections quite heavily, your usage of pictures makes sure that the flow of reading isn’t disrupted too much. As for the content itself you go very much in depth on what style you were aiming for and what goal you had with it. I also like that you provide some of the references you were working on. It makes it easier for the reader to understand your working process. You also show of some work in progress as well as how it looked in-engine which also help the reader to understand the working process. It would have been nice to read more about how you created the ink shader in Unity since it sounds like it took a lot of time and that section of the blog is very short. As it is now it almost looks like an introduction to a larger feature, and it is mentioned again later, but it doesn’t contain any of the juicy details
Blog 5 – Carl Leong https://carlgraphicscourse.wordpress.com/2018/03/08/to-test-or-detest-that-is-the-question/ I understand that it would be difficult to write about the playtest since for a lot of groups the test didn’t emphasise the graphical spectrum of the game, however you have managed to clearly point out and explain three assets that in some way were improved by the playtesting sessions. It was very interesting reading about how you fixed the problems. Since it seems like these things were done pretty quickly and cleanly I don’t feel like I have much to comment on here. The blog itself was a bit on the short side, maybe you could have showed of a bit more precisely what the feedback you got regarding these assets were? It helps a lot that you show a before/after scenario of the powerup and background, but maybe you could have done it for the laser too. I do really like the updated laser tho.
Blog 6 – Benjamin Harbakk Your blog is well structured and easy to read, the use of pictures also helps as they for the most part fit well with the text and space it out so the reader doesn’t feel overwhelmed. While it is much easier to explain what to improve amongst the things that were not so successful, it would be interesting to read some more about the things that went well. Why did they go well? You went very in depth about how you could have improved the game and do well in presenting the flaws in a way that they can easily be understood and you also give them a bit of context. It was also interesting to read your reflection on the level design and how not changing certain early aspects and it sounds like you even designed the checkpoints around the difficulty instead of changing any values to lower the difficulty.
 |