Comment #6

Hey Hampus, this is Guy from Wendigo, let’s get this last blog post over with!

Your summary of your developement process was very interesting to read, and the criticism you raise towards your group and yourself shows a high level of introspection and willingness to improve, which in turn shows great strength of character. I also really liked reading about your creative process and goals, describing the feel of your game as that of a horror film where the protagonist is being chased and nothing around them is friendly. It really fits what I remember from seeing and playing the game.

A point of criticism I do have, however, is that the many typos really took me out of the text, which is a real shame because the text itself is not badly written at all. Just try to watch out for these.

All things considered, you wrote a very good post about the whole ordeal of making a game, I hope that you’ll successfully improve on your points of criticism in the next project.

Final days and postmortem

Hello, this is once again the infamous Guy Dimor of Team Wendigo, and for the final blog post (yay!!!) I will talk about the final stages of developement of Umibozu and attempt to summarize the experience as a whole.

Going into the last week of production, I had very little left to actually add to the game, as most of everything was already complete. With my group’s agreement, I decided to focus mostly on bug-fixing, polishing and implementing the remaining assets. Aside from those, I needed to create an opening scene that explains the backstory, as well as change how the tutorial works. Fortunately, I only needed to do the code aspect of those and let the designer do the rest. The pace for that week was slower than usual for me, I mostly needed to wait for art assets and sounds to be completed and uploaded by my teammates, as well as for my team to report every bug they encounter so I could fix it. This resulted in many tiny updates on GitKraken, accompanied by a slight sanity slipage on my part which manifested as inane hebrew ramblings on Git. All in jest, of course.

By the end, the game had 2 distinct varieties of enemies, 2 obstacles, 4 abilities activated through power-ups, a narrative and some stellar visuals.

Now for the the game making process as a whole, I feel that my team did far more things right than wrong. We were constantly ahead of schedule, were not afraid to put in extra hours when necessary and had an all-around very pleasant working experience.

Things we did right:

• Communication: Slack and Trello proved very efficient at making sure everyone was updated.
• Personal chemistry: None of us are best friends when we go home, but we know how to have fun together while we’re working.
• Inclusivity: Anyone could suggest an idea for the game, all suggestions were fairly evaluated.

Things we did wrong-ish:

• Discipline: Some members were often late to meetings, I feel as though our manager could have handled it better, though it should be noted that it stopped eventually.
• Openness: Perhaps we should have tried reaching out to our quieter members more.

On the personal side of things, I feel like I learned to work withing a group in a non-leading role, something with which I had trouble in the past. I also learned to be able to stop thinking about my tasks at times when I shouldn’t, like on weekends, in order to avoid burnout. During my… previous occupation… I would often obsess over my work, which took a toll on my mental state.

As a whole, I feel we achieved our goal fairly well. I’m personally very proud of the game we had at the end. Our goal was to create the feel of exploration, which we accomplished not with an open world but with the illusion of movement. Using various visual tricks, like fog and darkness, we created the appearence of a long eerie journey into uncharted seas.  We finally got to see how well we work together when working on a real game and were very satisfied with the results. Although our manager elected to leave the group for the next project out of a desire to work with new people, the rest of us decided to stay as a group and bolster our ranks with new members.

-Guy “no seriously, why isn’t he in an asylum or something?” Dimor

Comment #1

Hey Adam, Guy from Team Wendigo, let’s take a look at your post.

The choice of a 45° top-down is fairly unique and your solution of having 8 sprites is creative and very reminiscent of old top-down games, as well as early first-person shooters like Doom and Wolfenstein. I also quite like the art itself, though that is probably more to your artist’s credit as I would be very surprised to find out you, a programmer, drew it.

That said, there doesn’t seem to be much programming involved here, and for that matter I have no idea what you did yourself. You described choices you made as a group that otherwise could have been made by your designer.

I’m not even sure what to write here, I’m not getting a lot to work with. I’m sorry if I’m coming off as mean, it really is not my intention, this just doesn’t have much to do with programming or anything you did yourself.

Comment #5

Hey Maya, this is Guy Dimor, lead code for team Wendigo, you may or may not have heard about me, I don’t believe we’ve spoken before. Kidding, of course.

You did a great job explaining the reasoning behind your various design decisions as well as detailing the thought process behind every wave of enemies in your game. I liked that your primary goal was to make sure the player used the full set of abilities given to them and that you managed to design the level accordingly.

I wish you would have taken pictures to illustrate your designs, especially considering they’re a requirement for each blog-post, as they would add a lot to the post. I mean, come on Maya, it really shouldn’t be difficult.

All in all, it was a very easy to read and well-written post which I enjoyed reading, and we’ll see where your game ends up.

 

Comment #2

This is Guy from team Wendigo

Your post seems to cover all the bases for implementing a health bar in a game and probably would prove useful to anyone looking to do the same thing in their own game, your use of masks was fairly creative and I liked the level of detail despite the fact that you didn’t show any code.

I feel as if I must comment on the grammar and spelling. I’d hate to come off as mean, but the mistakes really hurt the flow of text. It’s a shame, too, as this is otherwise a really good post.

I’d also like to suggest you look into Unity’s built-in sliders and how they function, as they could also be used as bars for various stats. Just a suggestion though, what you did probably works just as well.

All around, your post is very informative and I enjoyed reading it.

The virgin alpha playtest vs. the chad beta playtest

Ignore for a moment, if you will, the title that will probably be outdated by the time you read this, and listen to my small ditty about the playtests, the steps taken in both of them and the differences between the two.

For our alpha playtest, our build was rather minimal, we had 1 type of enemy, one type of power-up (which was later scrapped entirely) and randomly generated levels. It was also before we introduced the mechanics of the fog and darkness, the title-screen,  completely reworked the way the projectile is fired, and that’s before even mentioning all the art assets we didn’t have. All things considered, our alpha was fairly bare-bones. We did make one really good decision in our playtests, we set up shop on the stage in class, which we would discover boosted the number of playtesters. Below you can see the stark contrast between the two versions. We took our feedback in the form of recorded interviews, which allowed for a greater range of responses but was a figuritive bitch to transcript, so we decided that the beta playtest would have a standard survey.

We tried to fix things that were commented on during the alpha, such as the behavior of the pickups and how the projectiles were fired. We recieved praise for our use of sound effects and how well they were integrated into the flow of the game, so we continued working with those as we did before.

Before the beta playtests, there was a lot left to correct and fix, the most challenging was the level manager which, as noted in my previous post, took me a weekend to create just before the playtests, after which I negotiated a day-off with my teammates. This time we had four different power-ups, a menu to control them, a health-bar, a battery bar, new enemies and new obstacles and a metaphorical shit-ton of new features and mechanics. We once again chose the stage for our station, and we are very proud of the fact that we got 49 feedbacks and also very bummed because we didn’t get 50. One of the artists, in particular, had a hard time swallowing it, such an almost-perfect number. A new feature which I was particularly proud of was the spooky scenes between the levels, a piece of information I did not hide from our playtesters at all. Oh, how I watched them play, just waiting for the first level to rap-up so I could see how they react. I took immense pleasure in it. The responses were mostly positive, most criticisms said that the squids were overpowered, so they were quickly nerfed.

In conclusion, we tried to learn as much from our initial mistakes in both our game and the playtests themselves in order to maximize our game’s enjoyability as well as our efficiency in gathering information and making people aware of our game.

 

-Guy “did he really just say that?” Dimor

Comment #4

Hey Basil, it’s Guy, let’s analyze your post.

Firstly, I’d just like to say that your post was very easy to read, nothing seemed to drag on pointlessly and all of the points raised were good. That said, a lot of the English was kind-of off, which is understandable after all, but could be quite jarring when reading an otherwise well-written post and then suddenly stopping in my tracks when a mistake catches my eye. But again, it’s understandable.

Another interesting thing is the fact that while I have already used coroutines liberally in my code, you still managed to teach me some new things about them (mostly how they actually function) and also about other unity features, like fading text in and out. Also, it’s not specified in your post, but I assume you used triggers for the text events.

All around, a very good post covering a very important subject.

Creating a level manager, kinda…

Once again, I’m Guy Dimor from team Wendigo, and today I’ll write about how I created a maybe-sorta-kinda-not really level manager.

Before the beta playtests, there were some things still missing from our game, not the least of which being an actual series of levels. Instead we had a randomly generated endless mode, which didn’t have much replayability and did not have any progression. We knew this would pose a problem with the playtesters, as this was no longer alpha and we needed a way to keep them playing.

This resulted in me spending the better half of a weekend crunching code until my brain dripped out of my ears. My issue was my lack of knowledge when it comes to programming sequences of events, as all I’ve done up to that point was make loops that generate random enemies. Then I had an idea: Still have the levels be randomly generated, but have a series of them that progresses in difficulty, differentiated by an integer that keeps track of the levels. In addition, the circle of light around the player would slowly shrink over the course of the game, eventually lighting only the player.

This wasn’t enough, however. I wanted to add some cinematics (kind of) to add to the atmosphere of the game. The goal was to have the levels be seperated by a short scene each time, in which a giant shadow swims below the player and growls menacingly, growing in size, darkness and volume each time, serving to foreshadow the eponymous Umibozu. The group already discussed the idea beforehand so we already had the right sound effects for the job. I used one of the existing shadow sprites as a placeholder (later one of the artists made an original shadow just for this) and wrote coroutines for each scene. My personal goal was to spook the player while also piquing their curiousity to keep playing.

Finally, I decided to add a tutorial to help familiarize the player with all the mechanics of the game, as it could be daunting to take them in all at once. I did a few playtests to make sure everything was working properly and then I built the game for the beta playtests.

 

-Guy Dimor

Comment #3

This is Guy Dimor from group Wendigo, here we go…

First of all, this is surprisingly well-written and properly sourced for a blog post, which also made it a very easy read. In addition, you gave a complete and total rundown of about everything related to scrum, so now I don’t even know if I have anything more to say about it. Won’t stop me from trying, though.

I liked how each paragraph covered its own topic (as a paragraph should) and the whole post had a clear structure showing a solid thought-process. I also liked the fact that you explained how using scrum improved your work routine.

Personally, I could immensely relate to what you’ve written, as working with scrum has made my life much easier than I thought it would be.

And… yeah, I’ve got nothing more, sorry. Not a lot to criticize, so take that as compliment.

Working in scrum – daily sprint meetings

I’m Guy Dimor, lead code for team Wendigo, and today I’ll be writing about scrum, daily sprint meetings, getting used to said meetings and incorporating them into my daily schedule.

Going into this project, I had no idea what scrum is or how it works, nor did I have any particular interest in anything relating to project management. However, once I had scrum explained to me, most of it seemed rather intuitive.

While it wasn’t too challenging, I still needed to put in effort in order to get used to having the daily sprint meetings as part of my (well… daily) routine. At first it just felt like a hassle, having to be in school every day at the exact same time, having to present what I’ve done since the last meeting, being accountable, having thoughts along the line of “Who are you to question my methods?”,  “I don’t owe you anything!”, “You’re not my supervisor!”, “Get the hell out out of my room, mom!”, and “Only Linkin Park trully understands me”.
But it didn’t take too long for me to get into it and when I did, I found that my work schedule was really not as hellish as I thought it would be, and those meetings became mundaine very quickly.

Due to my background, I was already accustomed to living from weekend to weekend, which turned out to synergize well with how scrum works. As far as I was concerned, I could crunch all day, every day as long as I got the weekends off, an attitude which I’m sure I’ll come to regret eventually, but not quite yet.
As for the meetings themselves, once I realized I work better when I’m not at home, I simply used the sprint meetings as reason to get to school and continued working from there, on some occasions getting there earlier to do even more work.

As a group, we had the idea to work together every wednesday, which helps us improve our group dynamic. While we work, we also crack jokes, bring snacks and have fun. We even have our own custom emoji and Pepe on Slack. All of these combined with a workflow that’s busy but not overbearing resulted in a very good work environment.