Blog Comment #6

Hello!

So as a beginning statement, I would like to start by saying that the artifact which is the postmortem has been clearly stated throughout the blog. I also find it interesting to see the things that you consider disappointing about the game getting investigated and even showcasing parts where problems arising from other minors of the group is good criticism. Showcasing that you have learned from your mistakes and won’t be letting to happen again shows your motivation for the next project and even beyond. Which include squashing bugs, playtesting for new players a lot more and adjusting the gameplay time.

I would say that this blog has clearly showcased that it is reflecting the value of how a game developers feels after project is finished, not being totally satisfied with it and the willingness of improving it. But as for the blog improvements I would say that a better structure of paragraph would be desirable.

Blog Comment #5

Hello!

Firstly the artifact which is the playtesting was mostly stated but I feel like you didn’t have the need to add the Alpha presentation to the conversation as it just isn’t correlated to the theme. Whilst the process of playtesting is being told, I also feel it didn’t have a need to be stated where instead of it’s place more writing about the effects of play testing could have been available.

Other than that the process of understanding the faults thus showcasing the motivation, is clearly shown. But one problem I feel like is that the effect you is just too statistical, where as you could have shown a much more detailed version of the effect via gameplay improvements.

Even with it’s flaws the blog is good at reflecting it’s values, showcasing the player ideas being processed in their desire, for the developers to pursue it.

Blog Comment #4

Hello!

I would like to start with your structure being quite simple and understandable by any reader and clearly concentrates on the artifact which is the tutorial design. The process behind designing the tutorial is told in a way where motivation are included which is that players have a hard time understanding essential gameplay mechanics and tutorials. I would agree on this as the game you’re making Behemoth had the difficulty of multitasking, thus making it quite hard to understand for a newly starting player such as myself. The problems are addressed such as that it is unknown if the tutorials given will be enough, which needs playtesting as said.

The reflection gives out the value of a simple investigation of the difficulties of creating a tutorial for a game. As for improvements, making some tests to some people who doesn’t know about the game and showcasing the results here could be an interesting addition.

Blog Comment #3

Hello!

Firstly I would like to start with the comment of that your blog is clearly organized, well written and clearly investigates the viewed artifact which is the Scrum. This is seen with your 2^nd paragraph focusing on a general aspects of Scrum whilst your 3^rd paragraph clearly focusing on the sprint planning. By focusing on the sprint planning aspect you have achieved a better showcase of the process of the plan between the group. The motivation is clearly stated as with the dedication showcased on the team whether it is about pressuring the team a bit or making everyone take some part within the sprint planning.

I believe this reflection has given the value of how the scrum integrated with sprint planning works and how some aspects of the group has been improving. As for improvements I believe there is no needs except a picture showcasing a group discussion or perhaps a picture of a concluded Scrum sprint planning.

Blog Comment #2

Hello!

I would like to begin with the comment that I believe that you have successfully investigated your artifact on your blog by showcasing your entire process. The connections you made between the animations and the “Sky Ray” creature such as the tail problem where it didn’t feel right. The process of production is shown from the beginning to the end with visual intensity which helps the reader relate to it much better. Thoughts and failures are also showcased which makes readers that doesn’t know anything about animating, help understand the difficulties of the process. Opinions of teammates are also taken during the process, thus showcasing the group effort taking place.

I believe the reflection provides value as it does what it intends to deliver which is the process of animating in an orderly fashion. As improvements, a connection between animations and the MDA Framework would have been welcoming but as it is not requirement I would believe that this is just a minor setback.

Blog Comment #1

Hello!
So firstly I would like to start with the comment of that you have clearly stated and described your chosen artifact in a detailed manner. I would like to also add that focusing on something as simple as a line, yet showcasing that it isn’t as simple as it looks like, makes the investigation of the artifact much more interesting. While the production process description of the artifact doesn’t feel that detailed, which is understandable as there isn’t too much to say, it still goes over the essential parts. The motivation is well provided as you showcase change of your point of view about the lines with some questioning and working together with your teammates.
As a simple conclusion I would like to say that your reflection contains value as change about an idea have been viewed to the reader. Change of an idea and branching out of it, is a way to showcase a will to improve and experience new things, thus making this investigation of an artifact valuable. As improvements, maybe a more detailed process showcase would be interesting to see, thus making the viewer observe the different line changes of the avatar towards the end.

 

Game Design Blog #6

In this blog I shall be talking about my conclusion about this project and in which way it helped learn and develop. Firstly I would like to start with the aspect of working together with a group on a game and succeeding in doing something is quite something incredible. Thus I have learned so much in managing, deadlines and work psychology within my groups dynamics. The flow between the group members has been great as communication, motivation and willing to help each other has always been there.

I have learned and seen the possibilities of code used within unity and thus solved problems that I would have never thought I would able to solve. Which includes working a 3D world but using 2D sprites and mechanics, integrating animations made by the lead graphic to fit the movement of the enemy and  figuring out how to make a crosshair system whilst unity lacks an easy dynamic crosshair system.

When we come to how our project came to be, my opinion suggests that it is a working game that has beginning, middle and an end. But perhaps my gripe could be that I am not 100% satisfied with it. I’ve thought about the reasoning behind it and came to the conclusion that more could have been done. For example a settings menu where volume could be adjusted, an infinite mode with a high score system instead of the game ending with a boss and perhaps more enemy types such as our turtle concept where immobile entities attacked with slow moving torpedo projectiles against the player. This makes me understand the time schedule process of game making more as the experience of building this game has thought me manage my time according to the time limitations.

As a conclusion I would like to say that game making is not a process that can be perfected, but as experience will build up, I hope it will become a more apparent process to me. I have learned a lot during the process of this ten week project which I hope bring out for the next project.

Game Design Blog #5

In this blog, I will be talking about how playtesting sessions have affected the development of our game. In the first playtest made for our game to be played by random people from our programs. It was observed that people after a shoot-em up game were kind of not satisfied with our main playable ship, is a slow moving(including slow turns) entity and even with a slow harpoon turret with a slower flashlight. But our reasoning behind this was to stay close to the aesthetic goal of the of the original design document of the game which is “being mysterious”. Thus caused by the aesthetic goal we had made an early decision that the gameplay would be slow, to make the player find roam around and look around the gameplay area to be able to understand and learn the situation rather than just going around fast and missing things. Thus this critique of the players didn’t make us change the slow gameplay but only made us make a slight increase in reverse speed.

The other complaint or critique was the turret turning speed, including the flashlight, where the player move the slow turning turret towards the enemy to aim at them, which meant that it was needed to concentrate on the turret as there were no crosshair available. Caused by the limitation of our knowledges of how it exactly worked and the frustration caused to the playtesters, the speed of the harpoon turn was increased to the real-time speed of the cursor. Yet we still kept the flashlight at the slow speed as said before said the game needed to be mysterious, so the flashlight needs to be slow to make the player guess and perhaps shoot before seeing either if they shot a powerup, an enemy or an artifact.

One of the more minor complaints would be that the game needs more tutorial for the player to at least understand the basics. Thus more tutorials hints were added making, most of them in the beginning and even when pausing the game in case of the player forgetting some controls.

Game Design Blog #4

In this blog, I shall be talking about how I managed to create the Menu beginning and tutorial hints. So firstly I would like to start with the fact that our brainstorming around the idea of the menu with the group ended up going towards a route where the menu isn’t a scene but instead, it is integrated within the game. The reasoning behind this was to make the player not wait for scenes to load, but rather just letting them see the surroundings as the menu and the tutorial hints and just let them play the game and make them consider the hints and not force them.

So when I started to work on the implementation of the menu, I made quick work at making it the beginning area of the game. As our games playable character is a boat, the beginning area is a dock. The menu created by the lead graphic, is a forward facing art, thus the player could just see the empty behind of it by just moving a bit to the left or the right. In order to fix I had to make the player unable to move left, right or reverse. So I made three collision rectangles making the player only able to move forward. With that addition, I also made sure the menu deleted itself (including the collision rectangles) right after the it was out of players sight.

By making the player need of moving forward in the beginning of the game, the opportunity rose of where the tutorial hints could be added next to the player to read and understand while moving forward. So I implemented the tutorial hints made by the lead game designer. I design them so when you press the hinted button, the button hint would delete itself. To make the tutorial hints appeal to the eye I made it fade in and out with code. Essentially when the game world starts the hint would fade in, but the second the hint button gets pressed the fade out process would start for them.

Game Design Blog #3

This week I’ll will be going over the managing tool we call “Scrum” and how it affected our development. I believe the usage of scrum has helped us tremendously in coordinating what we were supposed to do in sprint planning weeks. It has helped us organize our development by breaking it into parts in every level. This levels containing what every minor is going to do, what will be done before alpha and who will check the progress of that persons work. Yet there is one I thing I do not really about scrum which is the hours of work written in the beginning of the sprint week. I understand that we are not experienced enough to know how long a feature is going to be developed, but I still feel that we can never be sure if we can finish that feature within the necessary hours as problems will occur, making the hours spent more than usual. This also correlates with the risk factor written before any feature, making us again guess how much effort will be put and if it is even probable in the first place.

Another great aspect of scrum could be said that it is also used to write the possible things that can be done in the future. In the continuation of the development, these possibilities are assessed as if they are worth the effort of doing them.

But I believe the most important aspect of scrum is the deadline. Even thought not everyone, including me, weren’t able to reach all the deadlines, I believe we have improved on delivering them much better, as time has passed. The reason being scrum helping us improve our time management by quite a bit.

As an end note I would like to say that scrum has made the development a much more manageable. Making us less stressed and more on point on feature requirements, specifications and possibilities. My only minor gripe being the time and risk factors that we will learn to asses better in the future as experience will come along, is kind of difficult to investigate during this period.