Week 6-8

Hello everyone!

This post will cover three weeks, and these in these three weeks we have finished the game for Gotland Game Conference (GGC), held a pitch for the jury and showcased our game at GGC. I also started on the final postmortem.

I will not go in great detail on the last week of production, but it was mostly adding a finishing touch on the level design, UI elements and the tutorial.
As we didn’t have that much time the tutorial was very short and it honestly did not explain the game very well, this resulted in us having to explain quite a lot for the players during GGC.

During GGC we got quite a bit feedback from both the jury and other players. The version of the game that we presented during GGC was very badly balanced as some parts of the level were almost impossible to get through. This difficult level was something that made some players turn away instantly but there were those who liked the challenge.

Most of the jury liked the concept that we had but they saw a bunch of flaws in the version that we had presented, some that we knew of and some that we had not noticed.

The week after GGC I started on the final postmortem for the course but I was not able to finish it before the first deadline, but I was still able to get some feedback during our public discussion session.

To finish of this series I can tell you that we even won an award at the GGC event!
The price that we won is called the Almedalen Award and is given out by the library of Visby, and we will also get to showcase our game at the library for a whole year! You can find the game at the library from October and on ( if I remember correctly).

Thanks for reading and I hope you have enjoyed this series of posts!

Ara Mohammad

Week 5 – One week from BETA

Hello again everyone!

This week has been very interesting. Five out of six members have been sick the entire week. So we all worked from home, which was something we really did not want to do as working together increased productivity. But we were sick so there was not much we could have done about that. This all resulted in a low productivity from all the members but we still tried as hard as we could.

We have now pasted the alpha and are getting very close to GGC. My role in the group will change a little bit as there is not as much that needs to be designed, instead it is more important for me to help out with the programming. Because of the fever and headaches I have not been able to code anything, instead I spent my time to read and plan how I am supposed to create a minimap for our game.

I have also been helping our graphical artists with further designing the UI elements. For example we have a function where the player can sacrifice a bit of their resources to gain more knowledge of the guard movement patterns and their vision range. To sum it up, I gave my thought on the UI design and gave examples of how I had imagined it.

This is all I have been able to do this week, but we are all feeling well now. The coming week we will be back and will continue to work hard and prepare for the upcoming BETA.

Until next week,

Ara Mohammad

Week 4 – Alpha

Hello again!

This week was crazy stressful, we had our alpha deadline on Thursday and there was so much to be done before that. On both Tuesday and Wednesday we worked from 10 am until midnight.

For the alpha we wanted a new and bigger level than the level we had for last weeks playtesting. So the first thing I did was to start working on a new level. At first it was difficult and I couldn’t get started on the level layout. Luckily one of my programmers helped me a little bit with the first draft of the layout.

After I had the first version of the level I things really picked up for me. I started redoing some of the corridors, broke down the really long ones and created several shorter corridors with more turns and rooms in between them. At this time it was easier to see what could and what could not work.

After I was finished with the layout I started mapping out the different routes that the player could guide the prisoners through to the exit room. After drawing up the routes from the prisoner rooms to the exit room I, together with one of our artists started working on different guard patrol routes.

When all the guards and prisoners had been placed I started working on the monitors, what we use to guide our prisoners. I started by placing out one monitor in each room, then in the corridors outside the rooms. After that I just filled in the empty spots.

On the day before the alpha I was working on implementing everything into the scene. I made sure all the prefabs were updated every time they had been changed. When I was done with the scene, one of my artists took over and started adding the necessary visual effects such as camera effects, the correct shaders, etc.

After a while there was not much I could do as I was waiting for the coders to finish their work and until the artists had added their artistic touch to the entire scene, so I took that time to help the coders when they needed it.

Thursday, the dreaded alpha day. We had almost everything, we just needed the last part from our AI coder. This is when things fell apart. Bugs after bugs after bugs. They all decided to show their faced when there was only a few hours left until the alpha. We spent those last hours, last minutes on trying to debug and solve the bugs. But for each we solved two more showed up. In the end we did not have a playable alpha. It was very unfortunate, but the alpha testers understood and still did their best to give us feedback on what they could see and from what we explained. In the end we still received good feedback and have now a bunch of new and different ideas to discuss.

I now end this crazy week with a Sunday of doing absolutely nothing.

Until next week!

Ara

Week 3 – Playtesting

Welcome back everyone!

This week all the first and second year students had the opportunity to have a bunch of people to test their game. The playtesting was on Friday so we spent the whole week trying to prepare so we could test as many aspects as possible. The feedback we got from everyone was amazing and we also got to test some of the other games, least to say we were impressed.

To prepare for the playtesting I spent most of the week on creating a short level so we could test our input, graphics and the most basic gameplay.

For the level design I aimed to create a first draft of the introduction level that will be built in the level we will be presenting in GGC. When I created this level there were a few things I tried to keep in mind. Firstly it had to contain the all the basic elements which were to guide the prisoner, distract guards and be able to plan a route.
Secondly I wanted to give the player more than one option when they tried to rescue the prisoner.

Note: Still a few placeholder assets in the level.

The room to the bottom left is the prisoners cell, the green character is the prisoner that the player has to rescue and the exit room is the room with a sphere in the middle of the room, all the other rooms are either break rooms or laboratory rooms. In each laboratory room there is one object that the player can interact with to distract the guards.

From the playtesting we got really good feedback, the most important was that we needed to change the controls in someway. To guide to prisoners through the facility the player has to click on the monitor (red box in the level) that the prisoner is standing by and then on the monitor that they want the prisoner to move to. This kind of input really confused some players and combined with a few bugs it really annoyed some people.

The second most important feedback we got was that there was no indication of what the player can interact with. We expected to get this feedback as we have yet not implemented any kind of visual indication for the interactable objects.

After the playtesting we all sat down and discussed all the feedback we got, some of the feedback we decided to dismiss and some we decided were important for us to consider.

Thanks to the playtesting session we now know what we have to change and a slight idea of how as well. The entire next week we will continue on this level and prepare for the alpha which is next week. With the help of the feedback from the playtesting we will create a much better introduction level.

Other than the level design I continued on the design as there are still a bunch of stuff that is yet not defined. I had a meeting with one of our teachers and talked about the different options and the consequences of each option and by the end of the two hour meeting I came out even more confused than before. What my teacher said gave me many more ideas for the game and so the cycle of confusion continued. Of each aspect I changed more options opened up. But in the end I was able to decide on a few things at least. I will not go into further detail for now, but they will come up in future posts.

As I mentioned before, next week we have our alpha deadline so this week will be very stressful but hopefully we will be able to showcase much more than this weeks version of the game.

Week 2 – Redesigned the visual style

Welcome to yet another chaotic week. This week I joked about changing the visual style to a style that was way more computerized than what we had earlier. I showed one of the artists the following picture.

“What if the game had a completely computerized look!” I instantly regretted those words as the artist went crazy with the idea and started working on it. After a few hours of playing around he showed me this.What started as a joke became something that I was now seriously considering. We talked to the rest of the team and explained our vision of the new visual style and everyone liked the idea so we redesigned the visual style.

The goal with the new visual style was to really show that what the player is seeing on the screen is a simulation of everything in the facility. As the AI does not have an overview of the entire facility, instead has overviews of separate parts. So this overview of the entire facility is just what the AI simulated from piecing those separate parts together.

As we want the visual style to completely convince the player that they are an AI we wanted to have details such as seeing flowing data and electricity in the air and between computers and other objects. We also wanted to show the characters in a different way. The original inspiration was the Matrix style and combining that with the style of a game called Shadowrun we came up with something like this.

Now, this is still in an early stage but the characters turned out quite like we had imagined it.

So during the whole week I was defining how everything should look and also writing our new visual style guide.

At the end of the week we had a meeting with a specialist in shaders and particle effects in Unity. He helped us figure out how we where supposed to achieve the style we were looking for. So next week we hope to fully achieve the style we want and I am also going to play test with people outside our team so we can get some feedback from people who have yet not seen the game.

 

Start of Big Game Project

Hello everyone! It has been a very long time since my last post, but it is time to start again!

So, the 10 week-long course Big Game Project has started and it is time to produce a game. The idea behind BGP is to write a concept for a full game and then create a vertical slice of that game.

So for the next eight weeks, including this past week, me and my team will be quite busy with F.R.A.U.S, a stealth and heist game where the player plays as a AI virus created to infiltrate the computer systems of corrupt companies and facilities. In the vertical slice the player has hacked into the computer mainframe of an underground research facility which experiments on human beings, most likely killing them in the process.

The game has an isometric view and the visual style is designed to make the player feel as if they are looking through the computers eyes. Having control of anything digital and electronic they have the power to rescue the prisoners of the facility.

Now, lets take a look at the team. As we are following the agile software development framework Scrum, we have three different roles in the team. The first being the product owner, which I hold; this person is the owner of the game and holds the vision of the game. The game will be created the way the product owner envisions it, this makes it natural for the product owner to also be the designer, and this is the reason why I hold the product owner title, as we decided in the pre-production phase that I would be most appropriate person to hold this role. The next role is the scrum master, the person who stands between the product owner and the team members. The scrum master makes sure that everyone follows the Scrum rules and does their job; the scrum master also “protects” the team members from any unrealistic demands from the product owner and is the one that the product owner goes to when they want something to be done. The last role the Scrum framework is the team members, the most important role. The team members are anyone in the production who actually work on the game, whether that is design, programming, 2D or 3D assets.

The process of Scrum is quite simple, everyone in the Scrum team have a meeting at the beginning of each sprint, a basic unit of development, and decide what should be done in this sprint period (which is usually one week-long, but can we longer if required). The product owner gives the team members one or more user stories of what the owners wants to be done this week, and the team members decide what is most important and what can be done within that sprint period and then start to break down those user stories into as small tasks as possible.

Now that I have introduced the most basic parts, I will explain what I have done the past week.

As the lead designer I have written user stories, user cases and continued to define and develop the design of the game. User stories are what the player feels, expects and experiences when playing the game. One example of a user story would be “I feel like I am looking through the eyes of a computer”. This user story is what the player expects to feel from the visuals of the game when playing a game where they play as an AI virus who exists in computer mainframes that has access to all things digital. User cases explains in detail how elements of the game works, for example how a guard behaves when that guard encounter an escaping prisoner.

As this is my first time being the lead designer many things are new to me, especially user stories and cases. So I booked several meetings with my teacher to ask about these and I am still confused about some parts but that is something I will hopefully learn with time. During this first week I have written nine user stories and user cases for guards, prisoners, scientists and a few interactable objects in the game. By writing these user stories and cases I have noticed that certain elements had not been clearly defined so I defined most of them alone, but sometimes I had to talk to my team to get some of their ideas when I was either uncertain or completely clueless.

The next step after writing some of the first user stories was to create a paper prototype to test the most basic elements of our game, the core loop, which was to guide a prisoner to the exit area and dodging the guards who stood in the way. This has always been one of my weakest point, paper prototype has always been something that I was clueless towards. I then booked a meeting with one of my teachers that has taught us in this area before and asked some questions and got some points clarified to me. I then tried to do some basic level design to test our core loop on. In my opinion this did not go very well, but it is something I will continue to work on.

The last element I worked on this week was the visual style of the game. In the last meeting I had with my teacher about paper prototyping I also got some tips about other games that had certain visual elements that could fit in our game. So I looked through them and then sat down with my two artists and our technical artist and went through the games and told them how i envisioned the visuals for our game. They came with some ideas and we all now have a better idea of how the game will look by the end of the course.

This is it for this week, I will now be taking the rest of the weekend of and continue my work on Monday.

Until next week,

Ara Mohammad

Weekly blog assignment #6

Hello people!

As it is getting closer to the final, we have worked on more tuning and polishing. We had a couple of meetings talking about all the things in the game that we had yet not decided. For example there was the defeat screen and the victory screen that we had not decided on how it would look like. What information that the victory screen should show and the same for the defeat screen.

I also worked on making the items to fly off the screen after they hit a monster. We had animations for the items that would show after they hit the monsters, but as we deleted them as soon as they hit the monsters, there was no time to show them. So now, after they hit the monsters, they bounce out of the screen while the hit animation for the item is played. It took me a lot longer than it should have, I was sick the whole week and it made it really hard for me to concentrate, but in the end I did get it done.

Below is a picture of when an item is bouncing out of the screen while playing the hit animation.

Other than that, I fixed a couple of bugs aswell as there were not so much left to add to the game. But there is still some things that have yet not been added to the game. For example most of the sound effects have yet not been added. But most of that will be added next week.

The whole group also went the sound studio to make our own sound effects for the game. Everyone contributed to make some sound effects that would fit the game. We made sounds for when the monsters got hit, when the player got hit by the monsters, when the wizard throws items and much more.

More than that I have started working on the project report for the design course, it has been really difficult to write some parts and also as we have to write two different project reports for the design course and one for the programming course. They also have to be very different so making sure that the one for the design course cannot have anything from the programming aspect.

This will probably be the last blog post for the project. I might continue blogging for the next course. Hope you enjoyed these past weeks and I hope you learned anything!

Hope you tune back in later!

Ara

Weekly blog assignment #5

Hi everyone!

I started out this week with finishing my bounce power-up, I did have some troubles with it as it had some bugs. After spending a considerable amount of time on it I asked for help from our lead code, after a few iterations we were able to solve it and now it works fine (most of the time).

The main thing I worked on this week was creating a instructions state, where the players can see two pictures that explains the rules and game mechanics.

As this was the first time I actually created a new state I was confused and did not know exactly were to start. So I spent some time on just reading the existing ones.

To my surprise, creating a state was not as hard as I thought it to be. It introduced me to some new ways of thinking that I had not earlier experienced when I just created monster classes or managers that just used things that already existed. It also helped me to understand the whole structure of all the aspects of the code we have. For example I had never used to GUI class that we have before and now that I have created the new state I had to use more parts of our code than before. All this really helped me with some things that I earlier had problems with and that is too understand how to connect all the dots in the code.

More than that, the state was not something especially difficult as it was a really simple state that had very few elements. First when the player clicks on the instructions button while in the menu, they first see the first out of two pictures that explains the game mechanics. At this time, when they are looking at the first picture, there is one button they can press that takes them to the next picture, there they have two options, either go back to the first picture or exit to main menu.

Here is what the two instructions pictures look like.

 

 

 

 

 

 

 

 

Also, I am the one that will hold our BETA presentation on Friday, so I have spent some time on practicing for the presentation. I prepared my speech by listening to music on my headset on a high volume so I could not hear myself speak. I find this a very good way to practice, as you can not hear yourself stopping between each sentence and saying “uhm…uhm”.

Just tonight I practiced one final time and also made a nice powerpoint presentation with our art as background as a final touch.

Wish me luck and tune in next week for more!

Ara

Weekly blog assignment #4

Hello everyone and welcome back!

This week has had so many ups and downs. First I had trouble with the structure, then when I figured out how I should write the code I had some problems with the syntax. When I finally figure that out, the game just crashes over and over again. It has not been an easy (or fun) week. But when I finally solved it all I got so happy, for a day, then the game started to crash again.

Creating the PowerUpManager was harder than I thought it would be. So far I have done two out of three power-ups. Last week I finished the freeze power-up and this week I finished the Pierce power-up and I have done about 50% of the bounce power-up.

The pierce power-up was not that hard to structure but I did have some syntax problem, especially with all the pointers I had to use. It also required a lot of attention to detail. There were a lot of pointers that could be null and making sure the count them out was such a hassle. I did miss a few now and then and that made the game crash upon start and/or using the power-up but with some outside help I was able to clean it all up and got it to work almost flawlessly. So far I have not noticed any bugs with the pierce power-up.

Now, the bounce power-up. This one has been nothing like the other two power-ups I have worked on. This one needed so much planning beforehand. When I first started working on it, I just started writing some code but I understood quickly that just testing different ways until it worked was not gonna work out. So I sat down for quite a while and just constructed the structure in my head. But one of my biggest flaws in programming is that I do not have a lot of experience of structuring code so this step did take my a significant amout of time. I played around with some different ways in my head, talked to our lead coder and after a few hours I had planned ahead a bit. Some stuff was still changed as I went on but the fact that I put down time to plan ahead really helped and of course I still had some problems but that is just programming.

All I have left of the bounce power-up is to make sure it does not bounce on the same targets more than once and also make sure it only bounces once on a monster for each lane. So a maximum of five bounces and there are also a few buggs here and there but nothing that is a problem, so I will probably be finished with everything in the PowerUpManager tomorrow.

Below you can see how the bounce power-up has affected the snowball to bounce between the monsters.

That was my whole week, hope you enjoyed the read and have a wonderfull continued week!

Tune in next week for more code trouble!

Ara

Weekly blog assignment #3

Hi there and welcome back!

So, this week started a bit late for our group. Our scrum master was not here, so we had our weekly scrum meeting on Tuesday instead, which led to that no one in our group had anything special to do on Monday. So I spent Monday on just reading our code and trying to understand the whole structure better, as this has been and is my greatest flaw in programming. Mostly I read through our Animation and Animator class. As it was built in a very smart and easy-to-use way.

But then, finally, Tuesday came and we planned out our week.

So far I have worked on our power-ups. As I mentioned before, I am not good at code structure so I spent a lot of time on thinking through how to best implement them, if either to just write them in our GameState class or to make a manager class for all the power-ups. In the end, with a bit of outside help, I decided on making a manager class for the power-ups.

I first started out by redoing the freeze power-up which freezes all monsters in place because we already had the code for it which made it easier to test the new PowerUpManager class. After a ton of errors and iterations, I have now finished the freeze power-up.

I think that it will be somewhat easier to implement the other power-ups. The other power-ups that we have are firstly the pierce power-up. This one is supposed to make our items, that the player can throw, pierce all the enemies in one lane, meaning it does not disappear after hitting one enemy, it will still do the correct amount of damage to each monster, depending on their weakness and the items property. The last power-up we have is the bounce power-up. This one will make the thrown item jump between each monster. The item will only bounce on one monster per lane and also it will only jump on monster that are farther back than the one that was hit just before. This, like the pierce power-up, will also deal the correct amount of damage to each monster.

The biggest problem I have had so far is deciding whether the functions should be of void type or boolean type, as I did not have the final or best structure in head. So I just tested back and forth, adding new functions and removing the ones I had for quite a while. But in the end I ended up with the same functions I had in the beginning. I ended up with a activation function to activate the freeze power-up, a function to the remove the freeze after a set time and lastly a function that returns a boolean value that is sent back to the GameState class to make sure that the monsters stop moving and also that they stop spawning.

And now, to finish up, here is a picture of my end result.

It looks like the monsters are still moving if you look at the waves behind them, but that animation is not finished yet, I plan to make that animation stop as well as soon as possible.

That is all for me this week, I hope you enjoyed reading and tune in next week for more progress!

Have a swell week!

Ara