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.

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.

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.

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.

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.