25-03-2018

This blog post will document my last work with group Rakshasa and the things I learned from that project.

So, what project? Well, in our group we have made three major projects: A boardgame adaptation of the popular online game Player Unknown Battlegrounds, a concept document for a shoot-‘em-up style game we called ”Trolling them softly” and lastly the creation of a working digital 2D shoot-‘em-up based on a concept document called ”Fear is in me”. Although, as previously specified, this post will only be about the last project, the digital game creation.

First of all, I would like to send a great big thank you to my team members Krzesimir Pszenny (our project manager), Shifat Ul Kabir (our lead artist) and Sofie Lindberg (our lead sound). It has been a real pleasure to work with them and I’ve learned so much during my brief time in this education. 

That being said, everything did not go as well as it could have. There are a couple of things that I would have changed with our approach had I known then what I know why. The most important part was that of our slow starting pace. Even though we were among the smaller groups member wise we really didn’t push ourselves enough during the first phase (pre-Alpha) in order to keep up with the larger groups. I know we weren’t expected to compete at the level of groups with more experience and more members but I do believe we could have challenged ourselves a bit more. Especially since the first weeks in a big way helped to form the group ambition and if you start up at a slow pace it is much harder to increase that pace later.

This in turn also led to the second major problem that I found and that was group motivation. I don’t want to say that our group wasn’t motivated because that wouldn’t be true. What I do have to say is that I personally felt some frustration when comparing our groups game to many other group’s games. This frustration didn’t exactly help with development either and I can admit that at times the work I put into the project felt a lot more like a tedious chore than something I was genuinely happy to work on. This frustration hit an all-time low during the announcement and subsequent build-up of the Arcade Game Development course. Since our project wasn’t turning out the way we really wanted it to and everybody was getting so hyped up about the upcoming project it seemed hard justifying putting the time and effort into working on the old project, which severely damaged the end product.

 

I think the main lesson to take away from this project is the importance of motivation, both individually but also in regards to your team members. I can think of few things more harmful to getting along than different motivation levels.

Oscar

 

 

13-03-2018

Feedback on the blog post ”The virgin alpha playtest vs. the chad beta playtest” by Guy Dimor.

Hello Guy, Oscar here from team Rakshasa! Really like the combination of describing yourself and actually showing wit pictures how your project evolved from alpha to beta. You also have an interesting writing style which helps your post feel more personal.

My main critique would be that you don’t really comment at all on what feedback you got. Even though you had a very primitive alpha build, surely you got some valuable feedback on how to improve it? You talk about how you used the feedback to maximize your game’s enjoyability, what feedback was this?

Anyhow, interesting read and hopefully I’ll get to try out your game this Thursday!

08-03-2018

Welcome back readers to a new week and of course a new post!

This week is supposed to be about playtesting and feedback but since I talked about that last week I’ll just skim it over quickly and then talk about something else.

If I would look back to all the feedback I’ve gotten during playtesting there are two main reasons to why I think it’s something very important during game-making. Firstly, you will never ever find all the bugs yourself! No matter if you test thing a hundred times, the playtesters are going to find something in your game that doesn’t work as intended. It’s a universal rule. Secondly, as much as you’ve heard it before and are probably sick of hearing it, it’s always nice with a fresh pair of eyes. Maybe the feature you’ve hyped all the way from the starts simply just isn’t fun for the player, and you’re to obsessed with it to realize that yourself. Or maybe there’s a really really simple solution to how you make your powerups feel rewarding while still not breaking the balance of the game. It happened to me, and it sure is going to happen to you.

That’s my final word on playtesting. The rest of this post will be dedicated to the subject of our games scrolling background. I’ve previously posted about how I implemented movement into our game and this is partially a follow-up on that post.

You see, we wanted a long level that our player needed to survive until the end, but we felt that making a long level completely by hand would take too long time for our graphic artist. It just wasn’t worth it, we had other more pressing matters that we needed our artists to work on. So in the end, we opted for a scrolling background. Our artist would make a short part of a level and then that short part would loop for a certain amount of time until the player cleared the level. Easy!

Well, not so easy as one would expect actually. Having the background to scroll actually messed up another key element of our initial design for the game, and that was the shadow chasing the player. The player needed to constantly move forward in order to evade the shadow.

In the end, I solved the problem by introducing a GLOBAL VARIABLE (gasp!) called backwardsSpeed that is set in the games Game Manager. This variable reduces the y-axis movement of every entity in the game, including the background. So if the player stands still they still move backwards, but it’s at the same speed as the background which gives the illusion of that it’s instead the camera, and most importantly, the shadow moving forwards.

 

Oscar

06-03-2018

Feedback on the blog post Game Design – Designing the enemy’s movement pattern and behaviour by Teddy Chavez

 

This week you’ll get two comments, Teddy! This is not only because you write so good posts but also because I couldn’t find the blogs of your teammates. Firstly I have to say, what a great post! Really interesting reading about how you got inspired by the enemies real-life counterparts when you designed their movement patterns. That you not only included pictures of the final product but also early concept art and even GIF:s (wow!) of the real creatures was a brilliant way of making the post much more readable and enjoyable. Great stuff!

But the best part is when you actually take your time to specify what certain behaviours you were aiming to recreate. Although a small comment on why you chose the different health and damage values for each creature would have been a nice finish. Looking forward to playing the finished product a lot!

01-03-2018

This Monday we had our first playtest since the Alpha preview. This blog post will be about lessons I learned from the feedback my group got from that testing.

At first, some of the feedback we got was quite confusing, and some downright offended me as the programmer. People were writing that the attacks didn’t work and that enemies were invincible. And I knew that just wasn’t true! But why were so many people saying the same thing? The answer came in a later comment.

”it was a little unclear that i was doing damage” – unknown tester

That was it! People assumed the enemies were a one-hit-kill because they couldn’t see that they were doing damage over time to them. So when the enemy died didn’t know that the enemies were taking damage and just assumed that the flashlight wasn’t hitting the enemies. The mechanic of enemies regenerating health while in the dark was also totally lost on the testers as they had absolutely no way of knowing this.

The more I thought about it the more stupid I felt. I had just assumed everybody knew the mechanics of the game just because I knew them. That’s what happens when you spend so much time on a project, I guess. Immediately after playtesting my group had a meeting and it was very clear what had to be done. Animations and sounds for when both enemies and player had to be implemented in order for people to understand what was going on. And scary to think about what would have happened if we wouldn’t have had that playtesting session…

And that is what I will bring with me from this week the most: the testers always know best, because after all, they are representing those who will actually play the game.

27-02-2018

Feedback on the blog post Agile Method – Scrum by Teddy Chavez

 

Hello Teddy! My name is Oscar Vines and I’m the programmer for team rakshasa.

It’s good that you start with explaining what Scrum actually is, as the whole post would otherwise be very confusing. I do feel that you could have added some more personal insights though, as right now you mainly just described how your group worked and not really what you think about the whole Scrum process. The point of the blog is to give your own opinion, which in this case is sadly lacking.

Although you make a good point with your self-criticism, the reason the stand-up meetings are done face to face is so people will be forced to be on time. It’s much easier to send a tet two hours late than be two hours late for a meeting with your team members.

That’s about it, have a great day!

22-02-2018

It’s that time of the week again, loyal followers!

This week everyone is expected to write about their experience with Scrum and yours truly is no exception. Now, where to start?

I guess it’s appropriate to start with my initial reaction to Scrum, which was… sceptical, to say the least. I’ve always expected these ”workflow enhancers” and whatnot to be a huge waste of time.I know it may sound narrow-minded but from personal experience they never live up to the hype, nobody wants them and they actually cause more harm than good. Why not put just the extra hours you spend on keeping everything up to par with some weird ruleset on, I don’t know, actually doing the work you’re supposed to do?

As you can clearly see, I wasn’t the most hopeful guy that all this would work out. But hey, I thought, It’s part of the education and it won’t get better just because I complain a whole bunch about it. So I went to the meetings, set up the backlog, made my first sprint plan and come Friday, sprint evaluation day, and big shocker: I hadn’t even done half. I had fallen into the classic newbie trap of underestimate work time. No problem, said my project manager, we’ll just move the stuff that didn’t get done to next weeks sprint.

Hopefully you can understand my confusion at this point. What was the point of all this if we didn’t even have to do the things we set out to do? It all just seemed like grandstanding to me. Nevertheless, I made a new sprint plan for next week, this time taking into account my previous failures. And lo and behold: I followed through! Now that’s what I call personal development. And the daily stand up meetings had started to make sense. It was actually super productive to feel up to speed with everyone in the group. It was less four individuals working on different parts and more a team.

Now writing that sentence I actually surprised myself by how accurate it sounds. Scrum has gone from a time-wasting annoyance to an actual helper. With this I’ve learned at least one thing: time wasted planning isn’t wasted at all if it’s actually helpful.

I still reserve my right to be sceptical towards new work methods though.

 

P.S: Unity Collab can die in a fire.

15-02-2018

Hello reader(s)! Let me start by telling you a short story about a boy who decided to work on a programming project together with some of his friends. They opted to use the Unity engine and creation tool, along with its handy feature called simply ”Collaborations”. What he thought would be a nice and stress-free learning experience soon turned into a nightmare…

Yea, I guess you already know where I’m heading with this, so I’ll cut to the chase: today’s blog post will be about the importance of researching the programs your working with. As me and the other one working with code in my group, my dear project manager, found out the hard way this week, Unity Collaboration is prone to some pretty unpractical behaviour.

Overall these few weeks have been pretty good for me as a programmer. I’ve learnt a whole lot, always delivered on time and I’ve never really been stressed. This week was on track to be just as timely delivered as always. I just fixed the last bugs with the powerups (something for a later post, perhaps?) and I was dead set on implementing a nice UI just in time for the alpha presentation. Already my project manager had already started a bit and got an early prototype working. The goal was to display the player battery level in the bottom right corner so you could keep track of how much time you had left before your flashlight died. The problem was that the prototype was made with a GUI layer, a part of the Unity Legacy and no longer officially supported.

In order to not run into any troubles down the road, I decided it would be best to implement the UI with the updated tools, using a Canvas object and a Text object. And I set to work, everything going fine. I ran into a small problem with not being able to get my players battery level into my GameManager and instead of wasting some valuable time on what surely was a simple mistake I headed down to the code tutoring about 15:20 on Wednesday. The solution was simple, I just needed to change my public GameObject player to a more specified public Player player. Easy. Compile and play.

Spoilers: it still didn’t work. GameManager still didn’t get the right battery level. I spent a good hour testing it thoroughly to see that it wasn’t a dumb mistake I bothered the tutors with, in the meantime doing some much-needed cleanup of the project in general. After a while I checked my player.battery with Debug.Log() twice in the same file, Player. And to my big surprise, the console was giving me two different values for the same variable.

I can’t say I’ve seen much in my programming days but this was still among the top weird ones. I raised my arm and asked for help from the tutors. We checked all sorts of stuff and nothing worked. In the end, one of them asked me: ”Are you using Unity Collaboration?”. I told him that yes I was and all I got as an answer was a long drawn out sigh.

It turns out that the fellow who asked me had run into a similar problem in an earlier project when he was editing the same files with Collaboration. So I had to scrap what I’ve been working on and implement a (excuse my french) really shitty last minute UI with no updates what so ever just so we could pass Alpha.

In the end, I’m being overly dramatic for comic effect. But I’ve spent a bit to much time on problems I didn’t cause and caused serious stress to both me and my team members.

TL:DR: Read up on potential problems with Unity Collaboration now so you don’t have to do it later.

First update

This is my first update.