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.

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

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

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.

 

Lighting effects in Unity

I’m Guy Dimor, lead coder for team Wendigo, and today I’ll write about my journey into the wonderful world of lighting, Unity, and the combination thereof.

After the alpha playtests, my group decided that our immediate priorities are the implementation of the ‘fog mechanic’, concealing the true nature of game objects, and lighting effects, to add to the atmosphere of the game and greatly enhance the player’s experience.

Once I was done with the aforementioned fog mechanic, which involved using sprite masks and was all around a blast to create (I mean that unironically, it was really fun), I knew it was time to start working on the lights. However, one thing stood in my way, and that was the fact that I had no idea how lighting in Unity works. Fortunately for me, it was wednesday, which meant there were code tutors who could help me.

They explained, to the best of their abilities, the different types of lighting available as well as the need to create a material that reacts to light and apply it to every relevant sprite. For those wondering about the specifics, you need to create a material with the ‘sprites/diffuse’ shader and set the color to white. I then started experimenting with different lighting shapes, trying to find out as much as I could about how lighting works. For example, while masks don’t allow gradients (areas only partially affected), lighting does, meaning I get artsy with the cookie (the sprite dictating the shape). I started making images for that purpose (technically giving me a spot in art credits of the game) until I created one that was just right, as seen here.
This image created a light as seen in the featured image. I then made the light a child of the rotating spotlight object in order to bind them together and added another small point light as a child of the player in order to have the small “aura” around the player. I made both lights pale yellow in color and I was done. I then encountered some strange bugs, which even the tutors couldn’t figure out, that caused some objects to be unaffected by light sources. The brute solution was to creat new objects from scratch with all the same components.

Another thing I did was make the darkness darker in order to conceal objects better. This can be done by going to Window > Lighting > Settings and changing the ambient color to something more to your liking.

And that’s about it. It took me a whole day, but I got it down eventually.

Object-spawning in a top-down shooter

My name is Guy Dimor, I’m the sole programmer (and therefore lead coder) for Team Wendigo, currently working on the game Umibozu.

The biggest challenge for me was finding the right way to spawn enemies. I needed them to come into the screen from all sides. My initial idea was for them to spawn randomly on an ellipse just outside of the game screen and then move in a straight line across the screen. A quick google search landed me an algorithm that produces a random point on a circle.
While I wanted an ellipse, I nontheless implamented the algorithm (and adapted it to C#, as it was originally in Java).
I’m somewhat ashamed to admit that it took me too long to figure out how to turn the circle into an ellipse. After a while of struggling with it, I finally realized all I had to do was divide the Y value of the dot by any number larger than 1 to get an ellipse. I made a function out of said algorithm and set the spawn-manager to instantiate enemies using the resulting points as positions. The ellipse can be seen in the featured image.

Once the spawn pattern was created, I need to make the enemies move across the screen. The enemies’ only “AI” is moving forward, so I needed I way to make them point towards the screen when instantiated. I initially had them point towards another random point on the same ellipse. However, too many either did not enter the screen or just barely grazed it. I then decided to have that point towards the player’s position at the time of their creation, which indeed caused all of them to enter the screen. However, this meant that the player had to constantly change position to avoid them, as staying static for long guaranteed taking damage. While that is not a bad feature in and of itself, it does go against the goal of having the player not feel stressed.

My final idea proved more accurate: Have the enemies move towards a random point inside a rectangle slightly smaller than the screen. This meant all enemies entered the screen, but were more evenly spread-out and did not overwhelm the player.