Comment Week 6 (Amanda Cohen)

https://amandacohen58776528.wordpress.com/2018/03/20/blog-post-6-post-mortem/comment-page-1/#comment-14

”Hello Amanda!

Your friendly neighborhood programmer peeking in. First off: I want to say, great post. You explained very well why you think that your game turned out great and since I also played your game I would have to agree with you, it was great! I can see why you say that you had great management in your game so that you could focus more on polishing, it made your game very stable and reliable which a notable achievement as a first project.

I do also agree with you that working on a project that motivates you makes a big difference in the end result of the project and it can also be somewhat hard sometimes. But sticking with your project, especially since it’s a school project and you can’t really switch groups when things aren’t working out is probably the best attitude to have. It might even result in feeling increased motivation over time.

I am glad to hear that you had such an efficient workflow and that you are proud of it. I think you really should be proud of the game, it was one of my favorites as well. I do however think that asking yourself “would a professional do this?” before making decisions or speaking up might be very harmful practice. I think that there is a probability that you might never feel like a professional, I sincerely doubt that I will anyway, and I think it’s quite common to feel like you haven’t really reached that goal yet because no one is ever done with improving or changing.

At least, in my opinion, I think that you should always try to surround yourself with people that you can say anything around without having to worry about if they perceive you as being worth being there. Any unspoken thought is a wasted one in group-work, even the stupid ones. They might not be as stupid as you think.

However, I might have completely misunderstood what you meant by that statement and I’m sorry if I made the comment weird.

In conclusion: great game, and good job! Looking forward to seeing what you can make in the future!

//Fredrik Henriksen Lövlie

(frhe6405)”

Post Mortem Shoot ‘em Up

Greetings once again!

This week I will discuss the overall result of the 10 weeks of production that went into our Shoot ‘em Up game ”Beelonging”. My role in the project was Lead Programmer.

The game was a ”Side-Scrolling” shooter in which you played as a Bee and was hindered on your way to the beehive by enemies such as Flies, Spiders, Wasps, and Dragonflies. The game included a scoring system and a power-up mechanic in the form of a formation as well as a very rudimentary AI-System for your bee-friends. It also included a parallax background that was continuously scrolling, animation, sound effects, background music and a spawner that could conditionally spawn waves depending on if you had killed the previous wave.

The list of things that I have gotten out of this project is very long, but I will try to focus on the essential parts. First off, this was the first time I have worked with other people to create a video game of any sorts which introduced a lot of new challenges. For instance, I now realize exactly how hard it is to communicate well while designing games. Especially since most of the group are doing entirely different things, have entirely different areas of expertise but still rely heavily on the work of each other. I do however think that we did decently in this aspect since we are a quite closely-knitted group and tend to be able to communicate pretty well most of the time, but there are always off-days or unforeseen circumstances which can impact the development profoundly. The part that was particularly hard for me personally was the fact that I was lead programmer for the first time ever and I think that we programmers failed in some aspect of staying on the same page, but more on that later.

What went well:

Choosing a concept
Working and designing as a group
The art and sound design

I think that we chose well when we decided our game concept, it was not Umibozo which was a plus, and the game concept had a very well designed core mechanic that was somewhat easy to execute. I did, however, have a small problem with it and that was that I was worried that we would have problems with designing that AI which turned out to be very true.

Overall I would say that working with the group has been successful and I credit that mostly to the fact that we function quite well with each other, within meetings and outside of them as well. I think this is partly because we got lucky with the people in the group but mostly I think that it is because of good management of the group.

I can’t speak for the artists that much about why the art and sound design turned out well in my opinion since I do not have the expertise to define the key factors. I will just say that I feel blessed to have such talented people that I get to work with.

What could have gone better:

Preparation of Code Standard with clear naming conventions for the artists
Communication between programmers + QA
Version Control

All of the things that are on this list are things that are my responsibility as Lead Programmer, which paints a clear picture of who I believe holds the blame of the shortcomings of the group. That person is of course none other than myself and I will now go through the things that I think I failed at.

Even though the Code Standard was prepared by me before the start of the project, we quickly moved away from it and created completely new guidelines that were not written down and just changed on the fly. The main reason for this is because the Code Standard was written without any prior knowledge of the language that it was written for. Another problem was the fact that I did not acknowledge the problems when they occurred and steer the group towards better habits. I will, however, say that I do not believe I made a mistake in not updating our code standard in the middle of the project since that would only have subtracted development time, but I could have done more research prior to writing it.

For the next project, I already know more about C# so writing a Code Standard will not be as big of a problem, but I will also try to focus on including clear guidelines for naming art and sound assets.

Even though thus far I have alluded to the fact that the communication between the programmers wasn’t great during this project I will now go deeper into that fact. We barely worked together on code, this was mostly due to both of us working better alone, especially when it comes to coding. I also did not really see the benefits of working together on the same scripts seeing as you can only write the scripts once anyway so I thought that it would just be a huge waste of time. I did not think about the problems that my approach would cause, such as us eventually not even being able to read each others code at times. I also thought that we were somewhat on the same page about the approach we would take when making scripts but I was clearly mistaken, this was partly caused by not having a clearly defined Code Standard. Another problem that we had because of poor communication was the fact that around 2 weeks were wasted for one of the programmers because he felt that he could continue making an asset but was clearly not making any progress, a problem which is the responsibility of the Lead Programmer.

If my group decided to make me Lead Code again then I will try to talk more with the other programmer about how we should approach the issues that are in front of us and try to have well-defined responsibilities within the engine that make sense. I will also try to be more strict with QA and try to read and give feedback on everything the other programmer creates to have better quality code that is more expressive and less volatile.

The problems that we had with Version Control are mostly due to the fact that the group had little to no experience with it, to begin with. We did in the middle of the project realize that we should define clear responsibilities for who does what within unity so that we do not touch the same scripts or scenes. This worked for the most part but I am still unhappy about the fact that the artists and our designer did not work that much within engine rather than me implementing their assets, this was of course not their fault since it was part of my responsibility to make version control work for the group.

Again, if I were to be the lead coder for the next project, I would try to help the rest of the group out with understanding how Git works and also do more research on my own so that we are spared unnecessary issues but have improved productivity.

I will say that I am happy with the overall result of the project as well as the functionality of the coding done, I am however not satisfied with the overall quality and reliability of the code. Nonetheless, I think we did a decent job even though we had problems with illness and lack of experience and I think we improved a lot as a team over the duration of the project.

Looking forward to easier times and less merging errors.

//Fredrik Henriksen Lövlie

Comment Week 5 (Oscar Vines)

https://oscargamegotlandblog.wordpress.com/2018/03/08/08-03-2018/comment-page-1/#comment-8

”Hello Oscar, Fredrik here.

Your post was very interesting, and I can relate to not wanting to reiterate the importance of playtesting as I also talked about it in a previous week. I can also agree that having fresh eyes can really help the improvement of the game. As you mentioned, even if there’s a part of the game that you as the developer think is really cool, in the end It doesn’t mean anything unless the player feels the same, so it’s good that you have a positive outlook on the feedback given.

The part about the scrolling background was also very enjoyable and an unconventional solution to the background scrolling that I didn’t think about, it’s also very well explained why that approach was needed for your particular project.

I am however confused about your comment about making the level by hand would take too much time, do you mean that you have procedurally generated levels right now, or is it just about the background scrolling?

Other than that I think you have made a very good post explaining your design decisions and the reasoning behind them.

Keep up the good work, can’t wait to see the game that you guys end up with!

//Fredrik Henriksen Lövlie

(frhe6405)”

The Importance of Playtesting

Hello once again!

Fredrik here and today I will talk about the importance of good playtesting. It’s something that has been said again and again but the real significance isn’t really felt until it’s tried. It’s just one of those things that you have to experience for yourself. As for our game, we have gotten a lot of very good feedback from both of the playtests that we held, some of those things that related a lot to my work were as I mentioned in a previous blog post the movement of the player, way back in the alpha the movement of the player was very static and did not feel at all like a bee flying, this was very great feedback because I think we kind of forgot that we hadn’t moved away from that placeholder movement since the start of the graybox testing.

Another great idea that we got from the playtesters was the fact that you could hold down the shoot button without any repercussions and that in that case, you might as well not have a firing button at all, something that we had not thought about at all. We ended up deciding that we wanted a slowdown while firing so you would be penalized for holding it down all the time.

A third example is the fact that you could quickly press the formation button and then immediately fire and still be able to fire with all of the bees at once without draining that much honey, even if this was not said by the testers it was one of the most dominant strategies that they used. This was reduced in effectiveness by adding a flat cost to activating the formation at the start so that if you repeatedly click the formation key you will rapidly run out of honey.

In conclusion, playtesting is always necessary but it has to be done with the right mindset- You have to do it with an open mind to the ideas of the testers, but still keep in mind that they are not always correct. It is a difficult balance that has to be struck but the results are much more noteworthy that way, it is really the only way of getting something valid out of it.

Comment Week 4 (Kaijun Wang)

https://kaijunqilin.wordpress.com/2018/03/01/add-a-new-enemy-type-shooting-enemy/comment-page-1/#comment-8

”Hello Kaijun,

Your blog-post was quite interesting as you showcased a lot of different aspects of the latest enemy in your game. Some of these aspects that were interesting to me were for instance, how you spawned the enemy and that you had several different spawn points that were randomized, how you designed the enemy to stop firing after it reached the other side of the player and the reason behind those aspects. In addition to this, I think it was also quite good that you alluded to the fact that the difficult parts of the programming for this particular feature lies within the perfecting it, as the last little effort and polish is what is mostly noticed.

It was however somewhat difficult to follow your train of thought at some points when you were really getting into it. To remedy this in the future I would suggest that you read your text to yourself or even better someone else to see if it flows well.

All in all, interesting blog post and your game looks really cool!

//Fredrik Henriksen Lövlie
(fr6405)”

Smoke and Mirrors

Welcome back!

Fredrik here again, and this time I will bring you a peek into the design process of the AI in my game. As the title suggests, AI is usually not what you’d think when you experience it as the player. For instance, in our game, we struggled a lot with the AI even though it’s part of the core mechanics of the game. The AI is supposed to be what achieves the aesthetic of belonging in our game. You are supposed to feel like you belong to a swarm and any individual is less important than the swarm as a whole. Based on the concept that is achieved through the use of a formation to control all of the swarm and having the bees behave individually when not in formation.

To achieve this individuality I decided that I wanted the bees to move around somewhat randomly while not in formation and decided upon having them find a random spot at a distance between a random interval and move towards it somewhat slowly and once it’s reached within a small distance of that target it would find a new one.

I even have some basic avoidance code in the game so they try to avoid each other and the player if they get too close. This is done through a child collider of the AI bees and through adding the inverse vector of the colliding bee before computing the final movement vector. In addition to this, the AI bees also detect enemies in front of them while not in the formation and fire based on a cooldown, this is done through the usage of raycasting.

The second part of the AI is the formation, this had to be done properly as it would be the main mechanic of the game. The way we have it set up right now, which is subject to change, is that the player has a list of child object around it that the bees constantly move towards at a quicker pace than while not in formation, those are given to the AI-Bees through the use of two arrays, one for the bees that is stepped through and one for the formation positions which is handed out to the bees. In addition to this they also during this formation fire as the player fires. This is done through a similar method, stepping through the array of bees and calling a function to shoot on all of them.

As you can see the formation is draining the honey at the bottom of the screen which is the main resource of the game. When the formation is inactivated the bees go back to the position they had before the formation was activated.

In conclusion, as I said at the start, creating AI is not necessarily what you would expect and most of the time it’s just fooling the game to making it look like it’s doing what it’s supposed to. The bees aren’t smart enough to know where to go or any will to do anything at all, it’s just randomly selected constantly to create the illusion that they behave somewhat organically.

But as long as it does what it’s supposed to then it’s good enough for now.

PS: Credit to Adam Olsson, the other programmer in the group as the bee AI was a joint effort, he did most of the groundwork.

Comment Week 3 (Natasha Bianca Mangan)

https://programminggamesafunworkload.wordpress.com/2018/02/22/the-effects-of-scrum-on-my-games-development/comment-page-1/#comment-5

”Wasup Tashie! Fredrik here,

Your post was very interesting and I could really relate the what you said about how it’s easy to get distracted as a programmer and never completely finishing assets. I am however a bit jealous of having an excellent memory to offset that. That would be so nice to have but sadly it’s not the case for poor old me.

I’m not sure that groups normally should have two Project Managers, but that might just have been a typo and it’s not that important overall.

It’s nice to hear that your group has very good chemistry but I would have liked to know in what way the chemistry in your group works well to improve your workflow.

I liked that you went more in depth into what Agile development means for the workflow in your group and even gave an example of how it can make development more flexible. The quote was also very fitting and helped to prove your point.

The comparison between Scrum and waterfall, as well as the reason Scrum is usually picked for game development, was also interesting, especially for people who might not be familiar with the definition for them or the difference between them.

Overall your post was at some points hard to follow, perhaps because of, like your bad programming habit, sometimes you don’t really finish your thought and start writing about something else. Just a slight structuring problem that would make it a tad bit easier to read. Other than that it was very interesting to hear your point of view and I really enjoyed reading it.

Keep up the good work and I’m looking forward to seeing your game develop!

//Fredrik Henriksen Lövlie (frhe6405)”

Comment Week 2 (Kentaro Hayashida)

https://ouroboroshamtaro.wordpress.com/2018/02/15/water-like-no-other/

”Hey Kentaro!

Fredrik Here,
Very Impressive work. The game looks absolutely astonishing. It looks something that I’d expect from a released title, not from the first game project from school. Very well explained as well, especially how you allow the reader to follow your process as you went through the different iterations and encountered different problems. I also enjoyed the very nice usage of GIFs so the game could be appreciated in its full glory. The thing that matters most is after all how the game looks while running and you supplied a plethora of good GIFs to document how the game improved over time.

I am a little curious about how the things you have implemented affect the overall performance of the game even if the framerate looks baby-smooth from the GIFs shown. The only negative thing I can say is that I would personally have liked more in-game screenshots or GIFs of how the different layers move while in engine.

Overall, very well explained so even a plebeian like myself can understand what you are talking about.

Keep on rocking man, you’re making me jealous!

//Fredrik Henriksen Lövlie (fr6405)”

Agile Programming

Welcome back honored blog-reader,

Fredrik here again, and today I will discuss Scrum and how it has affected my personal workflow throughout this project. First off I would like to talk about the bad parts. For instance, the fact that there are now multiple additional obstacles in the way of me sitting down and actually coding. Which as a fairly lazy person is definitely a huge problem. Not only do I have to make a new task within HacknPlan (the Kanban board our group uses), I also have to start recording the time I use to study as well as to remember to redo it when I switch to another task.

In addition to this, I now constantly have to think about what I am working on. Before when I worked alone on projects in programming I always just did whatever I felt inspired to work on at that very moment. Of course, this has upsides, it’s probably even predominantly positive. Mainly because I usually get lost in my own code and forget what I should be working on because I see some shiny problem in the corner of my eye that I just have to hack away at. However, it is still something that I have to get used to and I’m still prone to going off-book when I’m short on time and patience and neglecting my responsibilities to follow the proper order.

Even if I have my minor gripes with Scrum and agile development I still think that it has been immensely beneficial to me and my team. The reason for this is mainly because of the improvement to our communication, something that in my opinion should be valued over everything else when it comes to game development. I say this because that there are so many different aspects to a game that needs to be thought about and that need to fit together perfectly to work. Not to mention that they are being made by people who most definitively have completely different workflow in addition to the normal personality clashes that are to be expected.

Because of having to do daily-standups, sprint-planning, and sprint-reviews you are constantly coaxed to talk about the game and how best to proceed with it which not only clears up misunderstandings, it also helps the different disciplines to understand each other and what they require to be effective.

In conclusion, I do have a lot of bad things to say about Scrum, but most of them are because I have still not gotten completely used to it, but even now the pros far outway the cons.

Flight of the Bees

Hello again!

Fredrik here again and this week I have mostly worked on how to make the movement in our game feel better. This is because, based on the feedback we got from the alpha testing, we decided during a sprint planning meeting that the current movement we had was very lackluster. From the testers we had some people saying that our player could have been anything else and it would still have made as much sense as a bee from a ”Game Feel” standpoint. This was very valid feedback since our movement had been a placeholder since the start of the project but we really never actually thought that much about it. The movement we had was just moving the player avatar with a set amount when the button was held down, so it felt pretty much like dragging a box across the floor, but it wasn’t something that we as a group thought that much about since we were so used to it.

BadMovement — This does not feel fun to play

Since the movement is something that is extremely important to the experience of the player we decided that I had to redesign it. I started out thinking that I would use the in-game tools that unity provides to simulate physics. I wanted to do this because in the sprint-planning we decided that I would try to implement a first iteration of the movement overhaul during the first half of the week so the group would be able to give me feedback on it. This was because we had yet to decide on the specifics of how the movement was going to work which made me want to cut corners to save time. After playing around with it I quickly realized though that I was not really happy with that system because there were too many things that were not that accessible to customize the movement the way that we wanted. Because of this, I decided to make my own system which is based on acceleration and max velocity and having the velocity be decreased constantly while there are no inputs. It didn’t take very long and is fairly rudimentary but the results are pretty positive if I dare say so myself. It’s not perfect by any means but it just goes to show that a simple solution can sometimes have a big impact.

BetterMovement — As you can see it is a lot more fluid

In conclusion, there are probably problems in your project that might not be seen by yourself if you are making it because you are so used to playtesting it yourself. The solution to this is, as many before I have said, to playtest with people outside the development group. It’s nothing revolutionary but the reason for it might be something that one has to discover for themselves, at least that was the case for me.