Game Design journal 6 – 2nd attempt

Mikael Ferroukhi

Date: 22/05/18

Throughout this entire course there has been quite a lot of work and emotions that I have been through with my team, and this come both from the excitement and the fear of producing our first game: will it be good enough? will it look like what we want it to? will it be fun???

All of these questions that can’t really be answered until the final moment when the game is released which make the pressure add up during the making of the game itself. This pressure is what I think changed me and the relation we have with each other in my group.

During the 10 weeks of the course, I’ve learned quite a few things about myself, team working, and how to provide my team with what it needs. All of that has been for the best since today I feel more confident than ever in the potential that I with the rest of my team have in terms of game production: the reason for that is that we successfully managed to produce a working game!

Working in a team like this was something that I had never really done, and just as I expected, I really struggled with it at first. The reason for that is that I really like to have my own workspace with all of my items, this way I can keep on a routine while working and it makes me more efficient.

Of course when working with my team I couldn’t just stay at home, and because we would never book any room I would have to move to a different location every day in order to work. So the combination of both working with new people and in an environment that is not often optimal for it (small space, not enough room for the tablet, etc..), made me feel extremely inefficient, feeling that I think was shared among the team at first for the same reasons.

Eventually after some time working together, the team and I managed to find our own pace. Although we struggled a lot during the beginning of the course to plan correctly our workload for the week and to be present for our daily stand up meetings, we learned with time to listen more to each other’s and most importantly to understand how much we were able to produce in a week!

In fact, part of my feeling of “inefficiency” was because I was not very proficient with Photoshop (as I had just changed my minor from programming to graphics), but by working on the art of the game, doing animation, GUI, backgrounds and everything that the game needed, I slowly learned how to use it properly and working became a pleasure instead of a hassle. It took me some time but I could finally draw some clean lines and art!

So with time passing, I was no longer working with strangers and I was actually capable of working with them: this was an upgrade in terms of meeting and communication, but also workload and share. Once you get use to this environment, everything become so much easier because you can ask for help or check anything instantly with the team, which is a great boost in term of work efficiency.

We kept working this way, with some ups and downs, and eventually we managed to produced a fully playable game that actually looks a lot like what we wanted it to be! So I think that this course was a success for all of us in the team.

Our game called “Umibozu” was about a mystical sea creature of the same name that destroyed the boats of the poor souls that crossed its path. You played as a sailor that wanted to discover if it truly existed and you set sail to discover the truth, but during your journey at sea, you get attacked by the sea monsters hiding in the mist.

The aesthetic of the game was about discovery, mystery and living a journey. In order to convey them to the player, we used the mechanics of him controlling the sailor’s boat and with the help of its flashlight and harpoon, discover what is hiding through the thick mist covering the water, and shoot the creatures that might appear. There is this tension where the player could shoot any shape lurking out but it could in fact be a power up or ammunition! So every shot taken must be wisely considered because there isn’t an unlimited supply of harpoons on board.. This aspect of the game worked pretty well since most players died really quickly while testing the game for the first time, only to be better the second time when they tried to be more meticulous about their shooting.

you lost screen mockup

The art style was black, white and grey, by having all of the elements on screen being low on saturation except for the GUI and other important elements.

powerups

So what is the end result? What have I learned? The finality of this course is that we managed not only to produce a game that we are proud of but also that we learned how to work together as a team and to listen to the needs of each other. I feel like the most valuable thing that I got from this course is actually learning how to work with a team and to feel what it is to share a common objective with other people and to try to our best to reach it through our common work.

Critique 6: Johan Fallberg

https://fallberggraphics.wordpress.com/2018/03/20/blog-6-first-game-project/comment-page-1/#comment-18

Very interesting post! I like how it is turned around your thoughts and feelings concerning how you experienced this course. It gives the reader your very personal point of view on that matter and it is always interesting to compare how different people approached the production of their first game (for the most part!).

I feel like you have really well answered the question for this blog post: “what’s the end result and what have you learned?”, because of the way you structured your text.

You start by explaining the way you feel about how a team should work together and approach the task of creating a game: knowing how you feel about that allows the reader to understand your mindset and why you write this or this..

From there you switch to how it actually happened in your case and what went right or could have been made better, to finally see what are the actual outcomes of that project for you: having a game, being better at Photoshop and Audacity, etc..

Now the paragraphs are aerated, the text flows well, the post is illustrated with videos, pictures and this all makes that it is always “refreshing”. So it was definitely a good post to read!

Great work!

-Mikael Ferroukhi

Game Design journal 6

Mikael Ferroukhi

Date 20/03/18

During these 10 weeks, I’ve learned quite a few things about myself, team working, and how to provide my team with what it needs. All of that has been for the best since today I feel more confident than ever in the potential that I with the rest of my team have in terms of game production.

At first it wasn’t that easy I had been through a Minor change from Programming to Graphic which totally changed my role in the team and what I can bring in terms of work. Luckily for me, all of my team members have been very kind concerning that change and made everything to make sure that we keep working just as fine as previously but with this new composition.

Working in team has always been something I struggled with, I like to have my own workspace where I know exactly where are all the items I need and it makes me more efficient this way. So having to actually move to some other place to work with other persons in an environment where I don’t have my references made me feel insanely un-effective in the first few weeks of the course. The feeling was such that I could see that in a week-end I would produce more than in a week. I think that is a feeling that we all shared at first among the members of the team to some different degree.

This is what un-motivated people look like:

photo chez alec

Now with the time, the team and I managed to find our own pace, both in terms of meeting and communication, but also in terms of workload and share. I felt that with time I became more eased when it came to working all together and it went to the point where I actually enjoyed it. Once you get use to this environment, everything become so much easier because you can ask for help or check anything instantly, which is a great boost in term of work efficiency.

So what is the end result? What have I learned? The finality of this course is that we managed not only to produce a game that we are proud of but also that we learned how to work together as a team and to listen to the needs of each other, while keeping a good pace in our work. I feel like the most valuable thing that I got from this course is actually learning how to work with a team and to feel what it is to share a common objective with other people and to try to our best to reach it through our common work.

Critique 5: Felix Rahm

https://felixrahmvideogameblog.wordpress.com/2018/03/08/player-feedback/comment-page-1/#comment-22

Very interesting post! I like how you start by giving a quick background and thoughts about playtesting and feedback in general as it helps to understand your point of view on that matter and as a reader to figure out where you are going with your post.

I agree with you on the fact that art is often looked over when it comes to critique as testers either don’t feel like they have the authority to comment on that topic (not graphics people) or just don’t want to hurt you. I find it interesting that you brought up that topic and that you give your personal opinion on it.

When it comes to the theme of the blog for this week: Playtesting (how has playtesting affected your development?), I feel like your blog is a little off topic as you mainly talk about the playtesting itself and your opinion on it but actually not on how it affected your work or the way you produce assets.

Now you said that: ”I don’t have that much to say about the playtesting – as I did not get much feedback that was aimed directly at my specific areas.”, by that I guess you mean that it did not really affect your development – which responds to my previous remark but I still feel like to some extent, even if it has nothing to see with art, playtesting has made you think again the way you work or see your game, and talking about that would have answered the problematic.

Concerning the grammar or the structure of the text, I have nothing to say, it is very well presented: clear and organized, making the reading flow very naturally.

All in all I will say that I found the post to be very professional and enjoyable to read. I’m looking forward to the next one!

Great work!

-Mikael Ferroukhi

Game Design journal 5

Mikael Ferroukhi

Date 08/03/18

During the production of my game Umibozu, me and my team has been through some heavy brainstorming sessions where we would decide what are the best ideas and solutions we can find to make our game the most enjoyable and close to his original aesthetic, all of this while keeping in mind our capacity and limitations to produce code and art.

The problem is that when you stay for too long with a group of 6 people and that neither you nor the other members get a breath of “fresh air” concerning the aspect of the game (gameplay, art style, etc..) from someone else that is completely out from the production process of the game, it is easy for us to all agree on the fact that the game works as it is right now and that everything is going just fine.

The problem is that right after the first playtesting session, we started to realize the potential of ideas that we never implemented and the weaknesses of certain mechanics of our game. People would try our game and say : “what do you use that for? I don’t see why this exist!”, and that is true! This really makes you realize how easy it is to become blind to the imperfection of your own game, as if because you made it, everybody should understand how it works, which is obviously not true.

Added to that being able to see what has been made by other teams, sometimes working on Umibozu as well, and to see what elegant solution they managed to find in order to make their game shine with as little amount of work as possible truly gets you wondering about if the way you have been working with your team was the most efficient one.

From there we understood that we needed to have a better retrospection on the work that will be made and that also we should stop trying to aim low, but rather aim as high as we can and try our best to get everything done properly.

We all started to produce more content, I personally started to draw more and more asset for the team, and all of this has been made possible thanks to the playtesting sessions that opened our eyes.

Between the first playtesting session and the moment I am writing this blog, there has been a second playtesting session. This time again it has played a role of eye opener: even when we try our best to be objective about our game and to really think about if what we do make sense, nothing will ever be as effective as someone out of the group coming and testing the game, giving raw feedback and making you aware of the flaws of your game.

What is also interesting is trying the game of others, I’ve already talked about the fact that watching game can give you ideas but when playing them, you actually see what is good or wrong with them and this actually help you to understand what does or doesn’t work in games, making you more aware of the mistakes not to make, and prevent them in your game.

To conclude this all I will say that playtesting session helped both as a tool to understand better what isn’t working with my game, thanks to the comments of the testers, but also as a place where you can discover and analyze other game and try to find inspiration in their work while also experiencing what flaws they contain by playing them, making you aware of mistakes not to repeat in your own game.

Critique 1: Alexander Sinn

https://shirovfx.wordpress.com/2018/02/08/water/

Your article is well constructed and most importantly: concise. Easy to read, grammatically correct and allows the reader to get a clear understanding of what went through your mind when deciding upon how you want the game to actually look at his final state.

Nevertheless it would have been interesting to get at the beginning a quick explanation on what Omibozu actually is and why the folklore around it makes sense towards your design choice.

Also an image of your own work side to side with your style guide reference could have been a nice touch, because it is intriguing to see how you interpreted this „ink on paper“ technique even if it doesn’t necessarily worked out the way you expected.

Still it is a very good article, it clearly shows that you understood the MDA framework and how the chosen aesthetic/art style impact your game and helps to convey the desired feeling to the player.

Great job!

Critique 4: Yinsong Hong

https://yinsongflytrap.wordpress.com/2018/03/01/5sd064-the-making-of-fog-shape/comment-page-1/#comment-17

Very interesting post! I like how you first start by explaining what you have been working on, and why you did so. Getting a little bit of background concerning your game and how the fog needs to be implemented helps to understand the different aesthetics choices you go for.

While it is nice that you show different type of fog with an explanation added to them. I find it sad that there is at no point a picture of an in-game scene with one of your fog on top, to illustrate how they actually look in game: both for the “bad” ones and the “good” ones. This would have added much more to the post as a final result of your work.

Right now because I have never seen your game. I can only try to imagine you when you say stuff like:

-“Finally we implanted this fog shape to the game and used it for playing test day. Even I tried to be close to the background color, it turned out it’s much darker than the background in the actual game playing.”

-“In the end, another artist Marie from my group helped to adjust the lightness based on my fog shape which made it blended with other fog much better”.

which can make the reading very one sided as the reader can not relate to what you mean.

Outside of that, the content is good and interesting, the paragraphs are well ventilated which makes the reading fluid and enjoyable. Great work!

-Mikael Ferroukhi

Game Design journal 4

Mikael Ferroukhi date: 01/03/18

5SD064

During this week I have been working on a Level layout design. Up to now, me and my team had been working on our game Umibozu without any real structure concerning how the game actually take place. We knew the enemies, the character and its power ups, the obstacles, the boss and etc.. but we never explicitly said how all of this would be organized inside of the game.

At first the idea for our game was to have the level randomly generated, with a defined speed rate for the spawn of the enemies and obstacles, but we soon realized that this was actually not the right way to go for our game.

Our idea was that since Umibozu is a game about mystery and discovery, we should first of all implement the possibility for the player to move without any barriers on the side, using a scrolling background, in order to simulate this feeling of freedom and not being “trapped” inside of the camera view so to speak.

With that in mind we thought that the continuity of this idea was to have the “world” be randomly generated, so that the game feels really about discovery and mystery, since the player would never find any similitude between the formation of the terrain or the pattern of the enemy spawn.

Now what happens is that this last part was in fact a bad idea for a simple reason: even though randomly creating the world seems to be a big advantage to the game, it creates an issue: in our game, there is this mechanic of saving your ammo by lighting the “shadow shapes” with a floodlight so that you can distinguish if it is an enemy behind it or a power up, at the same time you also want to save your battery by not using it too much. The problem is that when altogether the enemies, power ups, batteries , and ammunitions spawns are randomly made (even with a good balancing), the player will very often find himself in a situation where he is unable to shoot or to differentiate the shadows, preventing him from experiencing the most important aesthetic of our game which is discovery, also discovery is brought both by having the time to discover but also by not being overwhelmed by enemies, in which case you don’t try to discover: you just shoot.

By taking notes of what the other teams managed to produce during the different play testing sessions, with my team we decided that pre-building the level was the way to go, first of all because there was not a lot of time left before the beta and that we thought it was the most effective way to get something “good” done before the deadline, with more control over what will be present in game etc.. But mostly because If you can control how the different parameters of the game (spawn rate, enemy rate, level layout), you can control how much and how the mechanics have to be used (shooting, moving, lighting, etc…), and therefore you can control what aesthetic is produced by the game.

This is utterly important for us as Umibozu is primarily a game about feeling an aesthetic, not a challenge.

At this point there was one thing missing: pre-building the level, which means creating a level layout design. After having done an heavy brainstorming session with the team and searching for the best way to develop our level layout, I decided to put in onto paper so that my team would have a one page reference to look at anytime they are unsure about what exactly will happen in the game (for the Beta), this way we can all follow the same direction and the programmers will now exactly what has to be done.

20180226_160251

This was the first draft I had done, the very same day as the brainstorming session. It was complete but I did not like it for the simple reason that there was some subtleties not apparent on it, which means that programmers could actually get stuck at some point and only rely on their memories from the meeting, and also because it was made in a short amount of time, without much caution about the lines etc… It basically could have been made better.

Umibozu level design

This was my second and last draft, it looks very similar to previous one, which is normal because the main content is the same, the only difference is that it “looks better” and also that this time it leaves no room for misunderstanding: every piece of information is there and every subsection of the level is detailed in term of content, camera movement, player character actions, etc…

With this done, my team has been able to work this week with a clear objective in mind and to produce to the best of our abilities the Beta version of our game.

Critique 3: Ellen Wetterholm

https://buriburifarm.wordpress.com/2018/02/22/post-3-scrum/comment-page-1/#comment-7

Very interesting post! I like how you start by giving a clear and concise explanation of what Scrum is and how it does work. Even though as Game Design students we all know what it means, some people tend to have different views or simply not understand how Scrum actually works, so by making clear from the beginning what it means to you, I know as a reader how to react to the rest of the blog.

The overall feeling that I have for your blog is the following:

In the first half of the text, everything seems perfect, but the deeper I get into your post, the more It seems to me that you get a little off from the topic of this 3rd blog which was: ”how has scrum affected your development?” to something like ”How my team tries (sometimes struggle) to follow the Scrum methodology and how we learn to adapt to it”.

There is a lot of personal opinions and thoughts but not that much explanation about HOW Scrum actually did help you (or not) while developing the game, examples of what I mean could have been:

-”The sprint planning helped me getting motivated to work as I tend to procrastinate”

-”Having these scrum review meetings helped me to understand how much I could work in a week and to find my flaws, which made me more efficient”.

-”Knowing exactly what had to be done during the week for both me and my teammates helped me to free my mind from the anxiety of not knowing what is being produced, which made more productive”.

Don’t get me wrong, this is actually interesting to have this very personal opinion of yours on that matter, and to see how different peoples react to this framework that has sort of been ”forced on us”. I sometimes myself feel the way you describe, which gives me another point of view over how Scrum affected your development but maybe more on a personal level than on a school level

Now because of this slight deviation from the topic (that’s how it felt to me), it accentuate at the end of the post this impression of : ”but anyways, let’s get back to the subject: Scrum is useful, THE END”, which is not a problem but sort of made me laugh when I noticed it.

All in all, it was a very enjoyable blog post to read and I’m looking forward for the next ones.

Great work!

-Mikael Ferroukhi

Critique 2: Carl Leong

https://carlgraphicscourse.wordpress.com/2018/02/15/the-background-as-tool-for-narrative-and-suspense/

Very interesting post! I feel like you divided your thoughts in a clean way using these different paragraphs, each having their own idea while still being related with the others. It makes the reading really pleasant and allows the reader to get a concise idea of what you are trying to tell through your post and your art.

Grammatically speaking there is no mistakes I could see and overall I feel like you really tried to explain every design decision behind the art that you are presenting. By doing so and showing the reasons for the changes that took place, it makes it really clear to understand what kind of aesthetic you are trying to create for each part of the game, and how this will impact the player experience.

All of that makes it clear that you have understood the MDA framework and that you try to apply it to the best of your ability into your game.

Great work!

-Mikael Ferroukhi