With the third thesis presentation, I felt delighted with the results of the day. After struggling for the earlier part of the semester, I finally found myself having refined my idea and its presentation. However, I’ve continuously faced with residual problems that came from the original scale of the project. I’ve also been dealing with issues that arose from Unity itself, and with the quality of life changes that I had placed on the back burner due to said issues.

In regards to the game, it’s now as close as I as I can get it to my original vision. There have been some downscaling, but it’s not too far from the basic premise I had in mind. One thing I’m glad I was able to do to improve the presentation of the project is the appearance of the fighters the players use. The appearance of the characters in the game has been something that I have been unsure about since very early on. I don’t consider myself a lousy artist in any respect, but I realized three points in regards that told me it wasn’t going be a viable option for this project. The First point: Even If I was able to improve my drawing skills to a level I would have been satisfied with, I didn’t have the time to do so, far from it. The Second Point: If I tried doing something draw that could fit the timeline I had; It would have looked out of place with the rest of the presentation. Finally, if I made something that with drawings, it would have looked the same as any other card game, thus making my game blend with other games of the genre.

I first tried made some prototypes regarding this using Vector Art and Pixel Art. My main inspiration for the approach I was aiming regarding the character design came from some art from artist Tato (https://tomatatoro.tumblr.com/). I remembered seeing in some videos about character design mentions of his work doing redesigns of Overwatch characters. I took not his points regarding character palettes and thought that it would be a good idea to choose colors for both players to differentiate them better. The primary purpose idea would be to use a basic template of white, black, and orange or blue, depending on what side of the fight summoned the fighter.

The tests on both methods didn’t pan out. Pixel art, while I have good experience with, didn’t fit the rest of the game. Not only that, for them to be cohesive, I would need to make it big enough to the point it was like drawing, so it would have been a time sink. I wasn’t satisfied at the time with the Vector Art either, but that had more to do with the fact it felt flat with the character design I was making for it. Finally, I considered the idea of using 3D Models to represent the characters, but that obviously wouldn’t work. Until I had the idea to use blender shapes, for which the process is rather straightforward. It just took making exciting, recognizable profiles on Quads with Unity and then using Vertex Morphing to animate them. This allowed me to quickly and efficiently be able to make different characters, and also be able to give them the motion to help them stand out.

Finally, I also finished a gameplay element that I hadn’t had the time to make fully functional, and that is the functionality of the Arrows found on cards. The arrows were made to visualize and simplify the function of card effects, making it easier to understand by just needing to see the specific card to see what their arrows do. However, another element that I did to streamline was making it that to use the effect of a card; you have to attack with said card. This gave me an excellent way to balance cards by their attack power. Cards with 0 attack could have a substantial effect, but it would make the player have to give up attacks.

With all of this, and the final presentation coming, it’s becoming harder to juggle all the work I have to do with everything else. I’m on the last legs of the project, and the only hurdle I’ve been facing has been bugs found in Unity 2017 (specifically a bug messing with the function of Multi-Displays). I have finally managed to do an admittedly risky fix for it, and that will hopefully be the last of my problems with the software. The only thing left is to finish the project and all the documentation needed.

At this point in development, I’ve managed to go through a rough patch, and things have been getting better. I’m at the stage in which the game is working on a functional level, but it’s not in a state in which its presentation correctly conveys how it works. Currently, I’m facing the problem of fixing how the presentation of the game and how I will do the setup of the game. I need to find a way for me to convey the mechanics of the game properly.

The stage of the game for the second presentation was one in which most of the mechanical aspects of the game were working correctly. The game’s flow is going as intended, but I am looking into speeding things up after more testing. The more significant problems were the presentation of the game in general and some technical issues. In regards to the technical side, one of the significant changes I had to do what the shift from online to local multiplayer. I underestimated the difficulty I would find trying to make Unity Networking work for the game. That said, the game wouldn’t work on one screen since players need to be able to keep information from one another. The most straightforward solution was to use an external monitor, that way both players would be able to have their screen without worrying about any networking issues. The only problem I’ve found with external monitors is that the function used in Unity to use another monitor, so I will need to use a computer using Windows for the show.

The other big problem for my project is the game’s presentation. This is mostly about two points, the aesthetic of the game itself and conveyance to the player. To address the first point, let’s talk about the type of aesthetic I’m going for. As I have stated previously, a lot of the inspiration for this project has been from trading card games. Those games usually possess a fantasy/medieval style for their characters and presentation. I wanted to do something different, so I chose to go the opposite route. I decided to make the game take place in a world in which network technology has advanced to the point that is has become a world all of its own. This cyberspace, however, has brought chaos, as governments struggle to keep up with technological advancements.

This gives me a good opportunity to talk more specifically about the rules of the game and how they work. The idea is that players are hackers, hunting down viruses and other, more malicious, hackers to keep the network safe. To do that, players use creatures called Avatars to fight. A match of Waraira works like this:

• Players create a team composed of 10 Avatars. They can use up to 3 copies of a specific Avatar.
• Players start the match with three random Avatars from their team, which will compose their hand.
• Each turn in Waraira is divided into three stages: Setup, Assault, and Battle. Players engage in these stages at the same time, so you’ll be able to see their actions, and they will be able to see yours.
• During Setup, players bring out Avatars from their hand into the field, choosing where to position them (Left, Middle, Right), and if they’ll be in the front or back.
• During Assault, players choose from their Avatars on the field who will attack the opponent’s forces. You can only attack up to the number of avatars on your field, and you can attack your opponents left, right, or middle. If one of your opponent’s side is empty, you can attack them directly to deal damage to them.
• During Battle, the actions both players chose in Assault will play out at the same time. An Avatars is destroyed if their HP drops to 0, they. If a player’s HP is dropped to zero, they lose the match.

The Basics of this have already been built in the game, but I still have work to do on how they are presented. Attacks from cards happen without any impact, and the UI isn’t clear enough and needs a bigger font size. But the core idea of a more focused card battle game is there. The main thing I need to do is to polish the experience and to experiment ways to convey better what the player can and must do.

With my goal of making a game that makes the Card Battle genre of games more accessible, the question came of how to approach it. While part of me thought of doing the project with paper and cardboard, I chose to approach this game as a digital game made in Unity. I made this choice because to my vision of the game along with some assistance that I wanted to provide to players.

In regards to it helping newer players, from experience, a lot of Card Battle games that I have played require the player to keep track of many elements at once. To put an example of this, here is a Hearthstone card.

During play, you have to keep track of its Health (the number on the bottom right) and Attack (the number on the bottom left), so that one card means two variables they have to remember as a minimum. By every card at play, we get two more variables to keep track of, and they can change during gameplay, so they are not static. In a physical game, it creates a situation where newer players would get overwhelmed with all the elements they have to keep track. With a digital game, it provides me with the ability to make information about the game more digestible, streamlining the experience.

The other reason I chose to do my game as a digital one was in regards to availability. Some of my most important memories with card games revolve around one in particular named Chaotic. I didn’t have anyone back home that played the game, but I was able to stay engaged with the game because the game had the option for online play. I’ve stayed in touch with many of my old friend from Venezuela because of online gaming, and I want my game to become one people can enjoy with people anywhere.

Portfolio Reflection Project

My name is Luis Gerardo Huiza; I am a student that comes from Caracas, Venezuela. I am part of Parsons The New School’s Design and Technology course as an undergraduate. My main focus in regards to what I want to do is game development, with a focus on game design.

When it comes to my work, the main focus of it is all about videogames. That is because I find their defining feature amazing; they are an interactive medium. My games mainly focus on gameplay-focused experiences that challenge the player’s skill in multiple ways. While I have high goals for what I want to accomplish with the medium, I have focused on smaller, simpler experiences that can be approached by anyone. I also have made small projects around ideas such as energy conservation, or a twitter account that posts puns. My projects like to focus on bringing joy to people.

When it comes to visual aesthetics, I normally go for simplistic imagery that is appealing to the eye. I also like to play with pixel art from time to time, as time consuming as it can be. My visuals normally come from a fondness I have for old school pixel art, as well as the necessity to make art that is time efficient for my projects. One of my proudest examples, FireWall, the player character’s sprites took a weekend to make. There are many inspirations from old school NES games in its animation.

When it comes to my work, I start by trying to think of a concept to wrap my head around. Normally I like having some paper on hand to sketch out my ideas. From that, I get a general idea of what can be done with it, and assess if it fits with what I’m looking for. After that, comes some testing to check how things pan out. I like to use Unity3D for most of my projects, although they sometimes are done in Javascript, in which case I like using Sublime Text. Finally, my trinity is completed with the good old Photoshop, for my visuals. That isn’t all of what I use, but they consistently show up in my projects.

Well, when it comes to why I make games, its because I really enjoy the work that goes into the craft. Through my life, gaming has been a hobby that always helps me with the struggle one faces in his life. Games helped me with my self esteem issues, and they also served as a tool to help me learn English. I want to make games because I know what they can do for people, and my dream is to make games that make people as happy as the ones I grew up with made me happy.

When it comes to my interests, they seem to overlap into one constant theme, creation. I’m the type of person that enjoys creating things of my own more than I do just getting them. Making something on my own has always been a very cathartic thing for me since I was a kid. It’s also one of the reasons that I wanted to study what I do. Another big point of my interests is that of

For the moment, I need to hone my craft; and for that I need industry experience. From there, I have multiple goals in mind; but the main one I would like to work on is education. I want to see if I could use game theory in order to help improve education in my country. People are more receptive of messages that give them a sense of agency, and gamification could provide that to students. As someone that didn’t excel in my studies, I want to use my skills to assist future students to improve their academic skills.

One of the main elements of H.A.C.K.E.D’s development from my perspective was the creation of its enemies and my foray into Enemy Pathing.

One thing that becomes immediately clear about the game’s stage is that it is filled with twisting turns and corners, so simple scripts to move them towards the players wouldn’t cut it, not alone anyway.

With was most of my time with the game’s development: Making the Enemy’s Pathfinding AI. At first I tried using Unity’s NavMesh Agent to guide the enemies to the player, but it presented some issues. Framerate would take a deep dive into the abyss of lag, and the movement wasn’t fulfilling my objectives for the game.

I then tried Astar Pathfinding, but the time constraints the game found itself prevented me from being able to learn the plugin to use it in a satisfying manner.

I finally decided to make a simple behaviour for the enemies with my own script. I used raycast that would work akin to how people use hands to figure out where to go when on a hallway in the dark. One would be in front, checking if there is a wall in the front, while 2 on the sides would check if there are any walls on the sides. When the player would reach a wall on the front, it would move depending on which walls were free: if there was one a wall on one side, it would go the the opposing direction; and if there were no walls, it would randomly choose a direction, adding randomness to its behaviour.

This game gave me a good challenge in terms of AI, but I wouldn’t say I’m too fond of it. To be fair, the development of the game was rather stressful. I still enjoyed coding what I did.

H.A.C.K.E.D was a multiplayer asymmetrical design between Griffin, Li, and I. We thought of this team based game in which players would work together to get to an escape point. At first we thought about making it about escorting a player to an extraction point, avoiding numerous zombies that would be between the players and freedom.

We then faced the problem that we were walking relatively near to a game made by another student.

Image of Don’t Bite Me Bro.

It was then that I suggested the transition into a game in which you have to save a system from hacking. The players would be tasked into going to multiple generators in order to get the server back up and running as it should.

We divided the working load into 3 part: Visuals, Player Controls, and Enemy AI; which were handled by Griffin, Li, and I respectively. I will go into detail about the process of making the Enemies in the next post.

Well, in the second entry for Stray Dogs, I will talk about level design of the game. In Glacial World, I talked about how I designed the interactive elements of the game to be given a safe space for the player to get used to how they worked. Here I went to the next level, making every level revolve around a new mechanic, and developing how the player may interact with them.

This design practice has become prominent in newer Mario games, where the levels revolve around one core mechanic, which they may then throw away, or reuse safe in the knowledge that you will understand the inner working of the mechanic.

This practice, called “Ki-sho-ten-ketsu”, was based after a format of japanese poems, following a structure of: Beginning, Development, Twist, and Conclusion.

But back to Stray Dogs, the 2nd level was the best point in regards to the use of the technique.

The first step was introducing the mechanic, in the case of this level, the lift platforms. They can carry both the player and object to higher altitudes.

We then add more blocks, which the player needs to use the lift to stack into a tower to move forward. Managing the lift’s timing is key to accomplish this smoothly.

And finally… THE LIFT BETRAYS YOU! jokes aside, now what was a boon to your quest for food as become an obstacle, you need to move the crates through the lifts, preventing them from taking box up, lest you have to start again if you fail.

The difficulty curve wasn’t exactly smooth, but I was happy with how I managed to apply this to the game.

Stray Dogs was probably one of the most enjoyable games I worked on this semester. I grew up exposed to 2D platformers, mainly Super Mario Bros. 3, so the assignment wasn’t something I was worried about in the design sense. I was more preoccupied about the main restriction of the assignment; that it had to be about something unrelated to media.

As someone who consumes a lot of media, that became a problem early on for me.

It was later that during work, I got a message from my mother. She mentioned that we would get a visit from Tracy. She is a pitbull that my sister rescues some years ago. We tried to take her back home to Venezuela, and while we succeeded, she wasn’t able to get along with our other dogs. We luckily managed to find a home for her, so while thing didn’t end as we hoped, we got her a happy home.

That was the inspiration for my game, I remembered all the street dogs that fill the cities in Caracas. I wondered how they manage to stay alive, especially in the food crisis that the country currently finds itself in.

In the next entry I will talk about the mainly way I focused on the game’s level design.

In this post, I’ll talk about the Second Build of Glacial World. After the playtest of the first build, I really wasn’t able to update much about the project. I prioritized the use of Maya assets for the game, as I wished to reduce the use of basic Unity shapes. My approach was making basic pieces that could connect with one another without much issue. This made it easy to build levels in a small time frame, which was important for the success of the project. I tried to also add music, but I found my attempts unsuccessful, and with the deadline approaching, had to leave that behind.

One thing I want to point out that was vital in regards to the development is my modular approach to level design, which I think was the best aspect in regards to my second build. I see building levels as something not unlike an exam, which requires a structure that checks the players knowledge of the game, and imbues new information as the game progresses. This can be taxing in terms of building a space to play in, specially when you find yourself as a one man army. Thus comes how mostly approach level design: I build the most basic building block I can see myself using for the project first, testing to make sure they work correctly, and then start building the levels, making sure to follow a simple system: Make sure players have a safe area in which they can experiment with a new element, while securing that they are conveyed clearly what it is that it does.

The room to the left in the center room of the Calm section demonstrates this in a nutshell. In order to activate the switch in the room, you have to deal with crumbling platforms. The platforms crumble after being stepped on, and likely the new player would end up falling to the bottom of the room. Then they would climb up and the path would respawn for them to try again. This is valuable, since in the  following scene, the player finds himself dealing with more of those platforms, and they can see what they have to do now that they are informed of how the platforms work.

Here is a link to get the Second Build of the game.

https://www.dropbox.com/home/Public/Glacial%20World?preview=index.html

I decided to approach this assignment with some relatively simple ideas. The objective was for us to make level that would present two different emotions. I decided to  use two opposites that compliment each other nicely: calm and stressed. Calm is a very simple, but effective emotion to convey through gameplay. Many people tend to play video games in order to relax from outside pressure. On the flip-side, stress is an emotion that is frequently seen in most high budget games. Action Set pieces, frenetic gameplay and action is the norm when it comes to a significant amount of the industry. While the two would seem to clash between each other at first glance, they actually complement each other perfectly. Calm can be a relaxing experience, but it can also lead to boredom or a lack of engagement, while Stress can be overwhelming, exhausting, or lose its impact if not given in measured amounts.

The main idea for the game itself was the exploration of a cavern. Even though I’m not exactly an outdoor person, I love exploring new places, and I decided to go with that for the setting. Players find themselves in a cavern that moves them into rooms with simple puzzles that rely on spacial knowledge. While perhaps not the best idea in an area with little variances in color, the size and number of blocks help give the player an idea of the space. After passing the first room, you find yourself in a cliffside, and the only path forward is a small, narrow walkway. Quickly, the platforms will start crumbling, so players will have to sprint through the path to reach the end.

Here is gameplay footage of the first build of the game. (for some reason my voices is rather squeaky).

In the next part I will talk about how I moved from this build to my delivered one and talking about my modular approach to level design.