A reflection on “Postmortem” blog, by Vidar Grönros

sasadzigurski · Just now

Hi Vidar,
I’m glad that you are very satisfied with your game. I have played it and it is among the best versions of the Umibozu concept. Well, maybe a little “too realistic” moving mechanic, but still challenging and interesting.
I like that you had a retrospective meeting after the project’s closure. Something that not much of our colleagues did with their own groups. I did it as well. We do need to have this ending or dismissing the team phase/step which sets all of us free, closing one circle and letting us go into another, richer with some experience and filled with the thrill of a new project to work on.
I also like the work-in-group day. Again, something I had with my team as well. It really helps and contributes to the goal of the project. Of, course it would be much better if we could have worked every day of the week, but…
I’m glad that you had a good communication in your team. Something that majority of us managers didn’t manage or not enough. One note, you have said that each of you has learned from your minors, maybe you could write a thing or two, what concrete you have learned as a project manager.
As of downsides of the project, I agree that a lack of paper prototyping and user stories is something that surely decreases the success of a project, in a way that the goals might be less clear to all.
Anyway, I’m glad that you have learned a lot during this project, and wish you a lot more knowledge absorbed in the future.

Blog url:

https://greenrosegamedesign.wordpress.com/2018/03/25/blog-6-postmortem/comment-page-1/#comment-4

Postmortem

Hi!

My final blog for this course is going to be about summoning all experience I have got through our “Game design 2” course, and my group’s project – “You may kiss the bride” game.

The end result

After nearly eight weeks of development, our game is finished. On last Thursday, the 15th of March we had a final gameplay presentation and we got the pass. It had an avatar, two enemies types (melee and range), a few obstacles (holes, benches and fire), a power-up (holy cross) and a finish (doors). It had an introduction slides (the avatar at the altar with the bride, deciding not to marry, bride turning into a demon which then continues into the tutorial start of the level) and an ending sprite (avatar waking up from a nightmare and hugging his lover).

Our aesthetic goal was – a threat. And by the response of 90% of players, it was stressful ( on the scale from 1-10 they choose 8+)

How did we do it?

As all of the groups did. By using Scrum. An agile framework. Which I described in my previous blogs, so I will not go into it, now.

But, what have I learned from it?

First of all – a group dynamics. Even though we never passed the stage 2 of it, I had a feeling that we would be able to pass the conflict stage without too much turbulence, had we had enough time. Apart from one member being distanced from the group, all the others were pretty compact.

Second of all, I have seen my flaws as a manager/scrum master. In the beginning, I was not aware of the importance of kick-off meeting and preparation of the user stories. My designer had made a backlog with all the features and I didn’t check it thoroughly (not that it was wrong or missing anything, but still..)

Further on, I could have been more successful in relating the sprint goal with the time points within the sprint (taking care of priority of the features) and better coordinating the workflow (not allowing one group’s discipline to wait for another, if possible).

And finally, improving the communication! We talk about it all the time, yet we manage to forget it too often.

And that would be all from me on this blog. Stay good and I’ll catch you next time!

 

 

Second playtesting – pre Beta

Hi!

In my previous blog, I was writing about a sprint between Alpha presentation and pre-Beta playtesting, and how we decided to freeze some features, and what was implemented and improved during it.

And then came the playtest prior to Beta. It was Monday, the 26th of February this year.  The teams occupied the tables and set up their games. I had a feeling, that this time it was much more relaxed than the first time. Probably, because of more experience of the groups and the latter stage of the project, having more and improved features and simply, more reason to be satisfied or proud. In our case, there were sounds, the bride movement, improved level.

 

The playtesting

Everything went smooth. Setting two laptops for a play and two for the feedback. And a lot of players playing. Almost thirty. And again, good response and a lot of suggestions.

So, what was the feedback like?

For the sake of the length of this article, I’m going to focus more on the feedback related to the aesthetic goal of our game, which is – stress.

Att question, “How difficult did you find the game to be?” only 17% of players answered that it was easy. ( on the scale of 1-10, they marked under 5).  Mostly, because they felt that it was possible to run far in the level without shooting or engaging the enemies. But then, further up there was a lot of enemies; too much to use that same tactic and then, they would die. In fact, only two players passed the level to the end.

The players who found the game too difficult (74 %) were stating that there were too many enemies and didn’t get used to the mechanics of reloading and limited bullets. Instructions were written on the paper beside the laptop, to which majority of the players didn’t pay attention.

Over 70% of players felt stressed ( on a scale of 1-10, they rated 6+). The bride mechanics sadly didn’t contribute to it ( it was significantly improved after the testing, implementing the rubber- banding). The progress bar also didn’t contribute to the stress; on contrary the omission of it did raise the stress because the players couldn’t know how far they went and how much longer they have to “suffer”.

All in all, we were pretty satisfied with the playtest and there was not much things left to implement for the final version. But, that is another topic to cover in the next blog. Stay good and I’ll catch you next time. 😉

 

Group Hastur “Base”

The groups setting up their games

Reflection on Game design blog, by Karl Lindkvist

sasadzigurski

4 mars, 2018 kl. 18:16

Hey Karl,
I have to say that this blog was one truly interesting, fluid article; easy to read and follow. It introduced me to some basics of level designing (interesting correlation with the music composing).
I like the slow introduction/tutorial way of teaching the player basics of mechanics and controls; rather than writing them on a paper or having them in written form on the screen, which then has to be memorised mostly unsuccessfully. Simply, because I don’t like much distractions until I get comfortable with the commands.
I feel like balancing the level is one of the most interesting parts of a design; feeling like some kind of god, introducing and spawning creatures on your vill, how will they behave, deciding how much pressure the avatar will have, thus influencing the player and forming him by your own philosophy, incepting your own logic in his brain (as in an Inception movie). Marvellous.
I don’t have any objections to your article. It was grammatically correct and easy to understand.
Maybe, one suggestion about the enemies; since you have mentioned a Fly as a first and easiest enemy, wouldn’t be bad to mention other types of enemies; their names or how do they attack. Otherwise, nice blog. Keep it going and good luck.
Saša Džigurski

Karl’s blog: https://karldesigncom.wordpress.com/2018/03/01/5sd064-game-design-blog-01-03/comment-page-1/#comment-6

Just another scrum week

Hi,

Today I am going to write about a week between Alpha presentation and last playtesting prior to Beta presentation. Or, shortly – the 5th sprint.

Long Monday

A week before, we just end up with first testing and Alpha presentation, which gave us a lot of feedback from the test players. That Friday was a bit busy, so we skipped a sprint 4 review on that day and decided to move it to upcoming Monday. And there it came – the longest Monday ever, regarding our group meetings.

Sprint 4 review, retrospective, setting the next sprint goal, discussion about it, preparing for the feature freeze and discussion about it, and finally the sprint 5 planning. It took over five hours of brainstorming and it was exhausting.

A lot of features went on freeze from our backlog. Only, this type of freezing meant something else. A no-go.

Instead of having three different types of enemies, we decided to stuck with the only one we had. The long-range attacker. It was a Tar-lady who shoots her vomits at a long distance. After a bit of discussion, we thought we could use that single enemy and change it a little bit, in order to get a melee attacker. So, we just took away it’s vomiting capability, gave it little longer hands with attacking movement, painted it a different colour and, et voila – we had a second enemy unit. A melee Tar-lady.

The list of frozen features goes on; a little girl with the flowers  (“No flowers for you at this time of the year …”) [from the concept document, she would throw flowers as range attack]. The gut-eye monster (“Er, it’s going to be as hot as in hell, your eyes might explode too early…”)[from the concept document, his eyes would explode as a ranged attack and then he would keep melee attacking]. The boss from the concept document [a priest] (“Sorry, next time, maybe. We don’t even know how to deal with the bride chasing us all the time”). And so on, and so forth. Of course, to put jokes aside, the real reason behind this was – lack of time. Instead of all these features taking us a time we didn’t have, turning into half-done, we have decided to put more effort into existing ones, and get the best results in our mechanics.

And, it started to show up. From the first playtesting until that moment, we have improved our game tremendously. More colours, sounds implemented for the first time, mechanics improved, etc. But, that will be more explained in my next blog. Until then, stay well and I’ll catch you next time.

 

 

Reflection on “Cut my life into…”, by Juste Eriksson

sasadzigurski

February 25, 2018 at 5:08 pm

Hi Juste!
I had a pleasure to read this blog. It was really clear and interesting description of spring subject as well as daily stand-up meetings. I agree that sprints are a bit too short, but that is how it is. Maybe, the only solution is to reduce features for each sprint to a minimum. I agree that it means also, freezing features from the product backlog.
About daily stand-ups, I could agree, regarding the same place and time every day sounded a bit hard to achieve. Maybe, one of the solutions could be meeting at the beginning of the lunch break (12:00), when all courses finish their lectures before lunch. And the place could simply be the cafeteria or somewhere around reception. It is a little crowdy but not impossible.
What I found a bit funny was your comment about moving stand-ups from 8:45 to later because of starting lectures at 09:00. Since they should last no longer than 10-15 minutes couldn’t they be moved 5-10 minutes earlier? But, I know that everything earlier than 09:00 is too early for our beloved fellow students/gamers.
The only thing you could add to your stand-up paragraph was, maybe a short definition of what they are, and what questions do we have to answer (by definition). Otherwise, it was all clear and grammatically correct. Thank you and keep good work. And good luck with the project.
Best regards, Saša Džigurski

URL to Juste’s blog:

https://justeerikssonblog.wordpress.com/2018/02/22/cut-my-life-into-stand-ups-this-is-my-scrum-approach-correlation-no-waterfall-dont-give-a-truck-if-you-click-this-post-reading/

Reflection on “Sprint 4 – Alpha” blog, by Niklas Ericsson

sasadzigurski skriver:

16 februari, 2018 kl. 16:57

Hey Niklas,
I have read your blog and I can say it was an interesting one. You have thoroughly described what improvements did you do with your game mechanics and aesthetics. First one, of different colours, was an easy and effective solution. I hope that change will result in a better response from the future players/ testers ( although it is a little bit harder to distinguish the spaceships and their projectiles from the background on this picture).
Another solution to avatar’s shooting mechanism is also interesting because it comes closer in line with the project requirements of having a basic shooting and power-up. And, who needs power-up if the primary weapon is of the same power as the secondary one (i.e. the power-up), right?
You have clearly covered all three questions of ”what”, ”how” and ”why” of those aspects.
One thing, however, I did not understand is- about this Alpha presentation. At the beginning of your third paragraph, you mentioned that you have covered it but I do not see any Alpha presentation described (except giving the date and time).
In the first paragraph, you have said that you as a team have been preparing for the alpha and I presume it was done via playtesting?
In the second paragraph, you said you yourself have been preparing for the Alpha and stated that you will present the concept of the game, and what have you had done so far. Maybe if you had given us a short description of the concept would have been nice (for those who don’t know that) and one or two concrete things you have done during your preparation and how have you done them (as a manager).
But, in overall, it was an interesting blog to read. I hope you will have a lot of good blogs in the future.
Best regards, Saša Džigurski

URL to Niklas’ blog:

https://niklasericssonblog.wordpress.com/2018/02/14/sprint-4-alpha/

 

Reflection on Ithaqua group blog, by Alexander Ebbesson

sasadzigurski

February 11, 2018 at 3:42 pm

Hey Alex,
you have picked an interesting topic to write about. A group contract. Something that not all groups did in this course. You have written some basics about it and that is pretty clear. However, had you put some definition of a group contract and add some of those ground rules that you have mentioned (give some concrete examples) it would be more close to the readers. The readers which are not that much in familiar to the topic. I really liked your suggestion about penalties for the ones that come late at meetings and I hope you will implement it successfully. Something that I would have to do as well.
About the form of this article; I fell like you started to talk about the concept of the game in the first few sentences, then touched a little bit group dynamics and after that started with the actual topic of this article – group contract. Something to pay attention to in your future articles. You have covered all the questions and the article could introduce the basics to someone unfamiliar to the topic. It was interesting to read it. Good luck in your future blogging.

URL to Alexander’s blog:

https://uugroupithaquablog.wordpress.com/2018/02/09/ithaqua-group-blogg/

Scrum-ing the project

Hi,

writing about scrum from a perspective of a first year management student, who will learn about scrum in the second year of study, sounds a little awkward. The more funny thing about it is, that a literature for a scrum has been given to us by game design course and not by management with agile methods course. However, we started our shoot ’em up game project in full scrum way.

What is scrum?

It is one of the agile approaches to management, which characterise an iterative way of developing the product. What does iterative mean? It means that a product is built piece by piece in short two-four weeks intervals called – sprints. After each piece (increment) of a product, a developing team focuses on the next one and so on and so forth.

Kick-off

Before the start of our project, we had one week to prepare for it. We had had a kick-off meeting on which we have decided about team’s roles and responsibilities, potential blockers and risks, a definition of done and a sprint plan. We had been given the requirements from our course directors. Those requirements made our user stories backlog. From them, we have developed features which we have put in our product backlog. Those features will be our increments to work on during our project, sprint by sprint. Each feature being prioritised by MoSCoW system meaning Must have, Should have, Could have and Won’t have in a particular sprint.

Sprint planning

At the kick-off meeting, we have decided to have a sprint planning meeting every Monday. It is where we decide our sprint goal for current week as well as features we will be working on.

Daily stand up meetings

Twelve minutes of a standing meeting where we shortly brief what have each of us done the previous day, what are we going to do the current day and what were the obstacles or problems if any. This way we were up to date with problems if they occurred.

Sprint review

At the beginning of our project we had a sprint review meetings on Fridays, but lately, we have pushed them to Mondays, because of our schedule and lectures on Fridays. The bad side of it is, that Mondays have become fully occupied and long and exhausting. The good side is that we have a flow of testing the previous sprint results, discuss them and based on them set the goal and plan for current sprint, do the sprint retrospective and in the end, the sprint planning. After that, we are done for the day.

Satisfaction

I feel that working in scrum have good sides such as keeping the flow or the progress easily, working in groups (we have dedicated every Wednesday to work together), being motivated by the results that are visible and so on and so forth.

One of the bad sides of scrum we practise on this course is a length or duration of the sprint, which is only one week long. Having lectures and assignments apart from it were obstacles, which evidently slowed us down. But, that has changed from this week and hopefully, we will manage to meet our Beta requirements.

But, that is another topic for another blog. Stay well and catch you next blog. 😉

 

 

 

Pre-alpha story

Hi!

This time I am going to write a story about our pre-alpha meeting with our course representatives.

“It all started on cold, winter Monday, the 5th of February 2018. The day of pre-alpha. It was meant to be the day in which they would check and remind us that we are close to the alpha stage of our project. It also meant that we should have the results of previous two-three weeks. Even though I trusted my teammates, the excitement was felted. It filled the air. Will we meet the alpha minimum requirements?

Our group was scheduled at 15:00 hours. We went to F-building of our university. In Finn’s room, there was an unknown man sitting in his chair, looking in his laptop. His face didn’t reveal any emotion. He didn’t pay attention to anything going on around him. We were confused. Curious. We expected Mika. Only the presence of Finn, sitting behind his desk, filled us with little courage. Finn was quiet. But he was there.

The “stranger” raised his eyes and looked at us, as we were approaching the desk. He wished us a welcome, still being serious and mysterious. He introduced himself. So did we. Cautiously. He said he was just replacing Mika that afternoon. He was a teacher of art for the second- and third-year courses. We felt relieved. At least we were at the right place.

Not wasting his time, he started with first of his questions about our project. “Do you have an avatar?” Our programmer opened his laptop and started a unity application. After few moments, we could all see our avatar, moving in some church-like environment, left and right, up and down, responding to our programmer’s fingers on a keyboard. He did not make any sound. Moving between benches up, towards the top of the screen, he would run into some demonic creatures who would spit some strange, black mass on him. He would use his gun and simply take them down. That challenge seemed so easy for him, at the moment. And some numbers on the top of the screen would start changing every time he did it. It was a points counter. In other moments, he would bump into a funny little white box. That collision would make the other numbers to change. Those were his health.

And then, at some point, this little hero of ours could not get his way through those creatures. There were so many of them. Little by little in short time, his health numbers were dropping down. Soon, they came to zero. And so, he vanished.

The face of a mysterious guy did not change much. But it showed approval. He was, in his own mystical way, satisfied. And so, he thanked us and wished us good luck in further work. We did the same. And so we left…”

Reflective part

The purpose of this meeting was the showing of the alpha requirements being met, prior to an upcoming Alpha presentation. How did we present them? We have prepared a laptop with Unity application (which we use for developing our game). After launching our game, Johan (the teacher) could see our results by pressing the corresponding buttons on the keyboard. The basic movement was related to the WASD keys. The basic attack projectile was triggered by the left mouse click. Basic GUI was presented in form of numbers in the upper left corner of the screen. They were representing the health value of the avatar. One power-up was presented by the health box, placed on a tile of a level, which could have been activated by colliding the avatar with it. It would change the numerical value representing the avatar’s health, adding 25 points value. The losing condition was presented by reducing the numerical value of the avatar’s health to zero.

After the presentation, Johan asked us if we have any problems and obstacles during the development [there wasn’t any at that moment] and wished us good luck.