Blog Comment 6

Hi Anna!

Im glad to hear that the course went well despite all the obstacles and hinderences you seem to have encountered as an individual/group. Your post explains in detail the different aspects and questions regarding the development process with the project and look very well structured. I can see how the thought-process behind the post has been neatly planned in a concise and interesting way as it was far from booring to read through it. Even though it is a personal blog, it looks professional in the way that it would indeed be a blog that I could read for valuable and enetertaining purposes.

There isn’t much I have to critique since I think that you answered all my questions through the content you provided. As I said, it was not short but far from too much, but just about right to fill out any room for questions from my part.

Great ending for the blog, hope you will have even fewer problems when going into the Arcade Project, good luck and have a good one!

/Hampus Serrestam

End of Project

This past course has been incredibly insightful and giving regarding the development process and execution regarding Game Design and today we concluded the work with the last playtesting session.

In the end the game turned out good. It was playable and delivered on time where we met all the criterias for a viable product and almost all of the teams expectations. The playtest gave us a great deal of answers to how well we had done over the weeks and how well we had remedied the past misstakes brought up on earlier occasions. The data gathered from the latest playtest was the source of information on how well we had constructed the game, we would not have been able to do it without the input from the playtests.

Allthough it went close to as we had imiagined it to go, there were inevitable setbacks. From the beginning of the project there were a few things that was pretty much set in stone as soon as we had established the basic rules and assets for our game. The main point of our game was to make the player feel chased, which was conveyed to a certain degree, acceptable at least. We got a very important critique regarding the gameplay and the aesthetic feeling we wished to achieve, that mentioned the recurring problems with the player dying over and over again, from everything but the Creature (The main enemy that chased the player).

The point with this critique was that we had created a level where everything killed you, and not just the main enemy, making it a war on two fronts all the time. This made the players attention drift away from the main enemy mechanic we had designed.

To put it in context, our game was supposed to be a horror flick. The main character of the movie never gets killed by his surroundings or obstacles on the way when running from the antagonist. The only thing that can damage him severely or kill him is the murdurer/killer/creature, whereas the terrain exists to slow him down, creating suspension for the viewer. In our case the Creature was the antagonist and the Submarine was our main character, where we failed to properly deliver the messege of chase. This was the biggest part that we as a group failed to see, as I mentioned ealier we did not notice this viewpoint as we had already firmly decided on some basic standpoints. This meant that instead of reworking the basics we made everything else to work with the basics, which was the biggest mistake we made in terms of presenting our goals.

In the end we mananged to produce a functioning game withing a designated time frame using workmethods, we combined the individual strength and expertise each of us had and used it as a team. I learned a great deal from others, teachers and students alike and even though if  there were setbacks, I will cherrish them dearly, for they have been nothing but useful for me as a Game Designer.

It has been a pleasure having you as my reader and I wish you a great day, have a good one!

/Hampus Serrestam

 

Blog Comment 5

Hi there Jad!

I think that your post conveys, describes and explains whatpurpose the playtesting sessions meant for you and your team, very precisely and detailed. You bring up all the relevant problems you encountered and the solutions to them. The text is very concise and informative, doing necessary elaborations on your points and not wasting words. The graphs you incorporated in the post is not much, but just enough to get the messege delivered, keeping a good structure on the content.

If I am to be picky I’d love to hear a little more about how the actual development process was affected by the fact that we had these play testing sessions. Did it improve your planning with having these “milestones” set that were in correlation with the Alpha and Beta playtests etc.

Except from some input on how the playtesting affected your work as a whole I think that you managed to answer all the questions that occured from me as a reader or the ones you mentioned yourself.

Keep up the good work, have a good one!

/Hampus Serrestam

The Effects of Playtesting

Hi there people, playtesting is a great tool for improving the development process when making a game and I am here to tell you why.

Playtesting has bee very important for me and my group during the course of this project as it has given us invaluable information that can only be gathered through this kind of testing, namely the opinions of the end-users. As a part of the playtest we incorporated a survey for the players to fill out, rating their experience with the game and commenting on certain question we had tailored regarding assets we wanted to be tested.

The opinions of the group that makes the game is relevant to some aspects, but far from sufficient in order to produce a satisfying product to ship out for potential customers. The group is getting used to the game and all its elements, which can make them ignore certain assets and mechanics. I.e. Me as a game designer spent alot of time playtesting the game in between changes, doing numbercrunching and itteration. I became very comfortable with the gameplay and the level, which eventually made me think it was “too easy”. As a fix to the problem I just changed the numbers until I thought the game was close to “hard” to beat. This turned out to be a major issue for the majority of the playtesters during the Alpha, as a common response from the survey was “it’s too hard”. It would be fine if the players were casual close to non-gamers, but in this case the play-testers were your avarage gamer, making it an issue. This would not have been spotted without the help from a non-group member. We need the voice of an outside party such as the end game user as it is for them that we create the game.

As an example, by looking at the results of the survey from our Alpha Playtest and by applying changes with the testers comments in mind, we managed to improve the outcome of our Beta playtest. We still got alot of constructive critisism, though it was not as “harsh” as the previous and there was a great difference in how people were commenting, as they seemed to enjoy the game overall alot more than they seemed to do during the Alpha playtest. The game had been improved between the Alpha and Beta so of course we got “friendlier” comments during the later session, however it was enhanced greatly because of the testers.

/Hampus Serrestam

Blog Comment 4

Greetings Mattias!

I think you communicate your artifact on an overall understandable level, with some aspects I just want to point out and talk about, such as how you answer the question “why” in this post. At the top of the blog you mention that your task has been to create a boss with interesting movement, with as little effort as possible from your artists and following that paragraph you talk about how you did that, since it seemes you managed to solve the problem (good on you!).

However there isn’t much communicated information regarded why you decided to prioritize this particiular task. On your forth paragraph there is some explanations for it as you say, quote: “This system made it easy to create the boss charge attack”. I felt like that gave some insight on what you had planned or could expand on to fill out the “why” in this post. Would love to know more about that since your post was easy to read, follow and intruiging.

Keep up the good work, have a good one!

/Hampus Serrestam

Time to make a Tutorial!

This week, my work has been dedicated towards creating a tutorial level for our game. It’s not part of our original level, but an optional level that the player can run if it’s the first time playing the game. All the instructions to controls, enemy behaviour, powerups and objectives isn’t necessarily restricted to only the tutorial, but it can help the player get a feeling for the actual gameplay.

The reason for me to choose this as my priority number one for the week, was that during the last play-test session (Beta), we recieved alot of comments saying that the controls were “hard”, or “clunky”,  but “fun when mastered”. This indicated that the players did enjoy the movement of the playable avatar, but it took some time getting used to it. How do we keep the controls as they are, but give players an option to learn them in a safe enviroment? Well a tutorial of course! The tutorial is not a part of the original level, rather a different, optional level for the player to try out if they want to get a hold of the basic gameplay before being put into the immediate action that the “real” level provides.

 

There had also been thoughts on creating a “intro” for our game, as you start off by being chased by this big nasy underwater creature. Just as it is, it may seem like the game has a very unfriendly and hectic start, but if we would implement the “intro” into the tutorial level, we would smash 2 birds with one stone.

 

 

I created a separeted level part from the game we have created thus far, and removed The Creature, which is the big thing chasing you throughout the main game to ease off the preassure, giving the player time to familiarize themselves with the game. In the tutorial level I implemented simple obstacles that will be encountered in the main level, in order to prepare the player for how they should tackle the challenges.

The basic enemies and powerups are also implemented, as I wanted the player to encounter everything there is, to learn all there is to learn, but in their own time. The player can still take damage and die in the tutorial, simply because it wouldn’t be fair to make them “invincible”, even if it was for learning purposes. The player would only get used to not taking damage and not see the real danger with colliding with terrain/enemies etc.

 

 

Upcoming work will be to finalize the tutorial and to create the “introduction” sections, where the player will get a glimpse of “The Creature”, which will be the main challenge to deal with in the main level.

Thanks for reading, have a good one!

/Hampus Serrestam

 

 

Blog Comment 3

Hi there Daniel.

Your blog post was informative, concrete and structured in a way which was easy to read and to understand. You describe which parts of scrum that has been of use to you and your team mates, how it has been applied/carried out by the group and why you used the template when working with the current project.

I particularly enjoy the part when you talk about the milestones present in the schedule regarding the game development process. The usage of milestones in a scrum-enviroment doesen’t make sense as it represents the waterfall-method, which is an issue I havn’t really been giving much thought. With that you put forth the issue of not being able to focus on all the core assets, but instead trying to please criterias for the Alpha and Beta playtests.

Overall you give a clear description of what scrum meant for you and your team, in a detailed, easily read way, with focus on quality content.

Cheers, keep up the good work!

/Hampus Serrestam

Blog Comment 2

A good blogpost with clear enough information to understand what you wanted to show, however there are some things that made me read some of the paragraphs more than once to understand the context.

You explain almost everything you write, as the reader would be a non-gamer in the terms of how you talk about scrum and the Alpha-Presenatation. On one hand this can be helpful if the intended reader is one with little to no experience within the gaming industry or education. I personally don’t think it is needed to explain these terms in detail, since the people visiting your blog most likely are familiar with them.

Reading these expanations got me off track from what the post actually was all about, forcing me to backtrack to the parts before the explanations and read again, skipping the detailed parts to feel the flow of the text.

Besides from that I got a perfect understanding of what you had been doing, why it was necessary and how you had tackled the issue. An overall good read, keep up the good work!

/Hampus Serrestam

Blog Comment 1

I think it is explained to a highly comprehensive degree that the blogger has been working on the soundtrack of the game. The reasonings behind what and how is well-communicated, however there isn’t much reasoning behind the why of the picked artifact. The blog carries value, as it tells and demonstrates (with the soundtrack connected to it) the atmosphere of the game and describes two different zones planned for the game, a safe zone and a supposedly dangerous zone. There is alot of well-explained reasoning behind why the music sounds like it does. I would like some more pictures to give a good visual represenatation on the intricacy of the intrument tuning the blogger described. Add some reasoning the the reason of why the blogger did the work he described with such detail and thought. It would be easier to understand why he chose this particiular artifact since it isn’t often an early priority, as he mentions himself.

Room for improvement, as for the rest of us, keep up the good work!

/Hampus Serrestam

Developing Games with Scrum

Hi all! Today I will talk about Scrum, how it has affected our developing process and what it has done for my group over the period of time we have been using it.

Scrum has been an agile tool/method to use for me and my group, not to the extent that I would hope it would have been, but enough to notice that it has given us a clear structure on how a development process should look like. When I say it didn’t meet my expectations I say it in a sense that the fault is on me and my group and not Scrum itself. The whole system of logs regarding features, sprint reviews and meetings is an easy way of recording the progress/decisions we make along the way, however we have not been putting it to as much use as we would have liked.

Apart from our misstakes, Scrum has been working as a great guideline for how our meetings, reviews and plannings are supposed to look like in order for us to have an agile work-enviroment. Before we had been introduced to Scrum, the structure of how a development process was supposed to look like had been quite in a blurr.

In the beginning when we learned about how to use backlogs, sprint plannings/reviews there were some confusion. We didn’t know for sure why it was all needed and what for, such as the sprint planning and review section of the official Scrum Template we were provided with. During the first meeting with our Scrum master all of the previous issues were explained and clarified to a great extent. Thanks to the Scrum master the doubts we had regarding the different aspects of Scrum was all gone, which helped us a great deal to get started with the project and familiarize ourselves with Scrum as a way of working.

The usage of Scrum greatly increased our efficiency as a team, it enabled us to always stay up to date with the backlogs, keep a good concised sprint and have a overall great view on how the project was coming along. Compared to our earlier projects this felt alot more professional and structured. Even though we haven’t had a real game-developing process before such as this one, it still felt more structured now than it had felt before.

As an end note Scrum has been a very useful tool for us as a group to create an agile and well-functioning development process. There are things we as a group could have done better in order to use it to our advantage, but in the end we appreciated that we had been introduced to the method.

/Hampus