HackVT 2015

Posted by vincentloignon

This last weekend, the yearly hackathon took place in burlington. I have been going to HackVT since freshman year when a friend convinced me to go and I in a way fell in love with it. This year in particular was different for me than previous years. In the past, I would go to the hackathon, program for a good chunk of the event and then go home without presenting. This year, since it would potentially be my last (due to graduating and getting a job somewhere), I decided to go all the way and do the presentation. I wasn’t alone though as I had one of my best friends, Kyle, who also has been going since freshman year with me.

Going to this years hackathon was also different in another way. In previous years, they released the data sets roughly a week or so in advance and we spent time preparing a basic idea of what we wanted to do before going to the event. This year was different because for some reason the data sets weren’t available until the day of the event and being the busy person I am, I had very little time to prepare due to this. Kyle and I started forming our “idea” while walking to the building roughly an hour before it officially kicked off.

So what did I do this year? This year, the theme was “Hack the Climate” and was focused around what you can do in regards to climate change. What Kyle and I decided to do was to create a management game where the goal is to teach people the things they can do to help mitigate the effects of climate change. Our game, Eco Builders, was created in roughly 22 hours and it was definitely quite the experience having roughly 3 hours of sleep after being up for 48 hours. Here are a few of the things our game featured:

  • 5 categories the player could improve on
  • Natural Events
  • Performance Reviews
  • Things you can do to mitigate the effects of natural events
  • A budget & deficit
  • A timeline

I’ll break these down one by one to explain them as well as having some pictures to go along with it.

The game had 5 different categories of things they could improve on. These were essentially the numbers running in the background of the game which would judge how well or poorly the player was doing based on an average of the 5. These categories were Soil Erosion, Nutrient Pollution, Maintaining of the Wetlands, Management of Culverts and Invasion of Non-Native Species. The average of these scores (on a 100 point scale) would determine how well the player is doing since there wasn’t time to do it on an individual basis.

Natural events were our primary form of creating chaos in the game that the player would then have to “fix”. The numbers were definitely not balanced and the system was by no means perfect, but its job was to present the player with a challenge and see if they can find the correct solution. Our game featured 6 different natural events each with their own effect on the environment. They were Ballast Spill, Influx of Exotic Species, Upstream Flood, Construction, Forest Fire and a Storm. More details on them can be seen below in the images. All of this content was created during the event.

[tribulant_slideshow gallery_id=”7″]

 

Performance reviews were in the game to achieve three goals. The first was to tell the player how they were doing. If they were doing terrible, they would know from the yearly performance review. If they did well, they would also know from the review. The second goal was to provide a lose state for the game. If the player has three bad performance reviews, they would lose. The third goal was to give the player some form of reward for doing well in the game. The reward being a larger budget to do things. More details can be seen below in the images.

[tribulant_slideshow gallery_id=”8″]

 

The player had many things they could do to mitigate the effects of natural events. Some of them were short term fixes such as restricting ballast water spilling or creating trash blankets, but there were also long term fixes that would be more beneficial. These included teaching and other things such as restoring native species and so forth. You can see more details from the images below.

[tribulant_slideshow gallery_id=”9″]

 

The budget and deficit is a money system which we used to help make the player make some more difficult decisions while playing the game. They were designed with the idea that they can’t do everything they need all at once and have to prioritize based on the upcoming natural event/s. The deficit specifically is there because you can’t spend more than you have and we wanted to avoid that. It is meant as a way to show what they are currently spending each month versus how much money they currently have available.

The timeline was a basic system we created to handle events on a month by month basis. We picked this timescale because it made more sense than days and years and we needed something to just show that things time. This system provided us with an easy way to create events where things happen each month (such as a budget/deficit) and things that happen only once after waiting a certain amount of time (such as the natural events). The important things can be seen in the top right with the time until it arrives.

This more or less describes the game and all of its features. It really is quite impressive how much can be done in a 24 hour time period and whats even more amazing is how much Kyle and I were capable of doing during that period having already spent all day doing classes and work on friday. As for the result of our efforts, we didn’t win anything but it was nice being able to show off what we did for the event, even if all we took from it was a sleepless night and some free food. Lastly, I would like to thank my friend Kyle Strader for joining me for HackVT once again and helping my push through the event. It was fun and hopefully we can do something like it again.

EDIT:
I have recently uploaded the game and you can play it here.

Refactor and Replace

Posted by vincentloignon

Senior Production

Post VI

 

This week for me was focused primarily on refactoring the code base and preparing to be scaleable. This has been a task i’ve avoided mostly because the existing code was pretty gross to begin with but having too much work was a pretty good excuse not to do it either. This week’s post will also be fairly short as nothing has particularly changed code wise besides a lot of stuff being redone in C++ instead of blueprints. However, I do have a few things to talk about in regards to the prototype. Lets start real quick with the code.

So the original project was purely done in blueprints and I had not even touched it at all. I was busy working on BBR (rest in peace…) and my designer and artist worked on this prototype. They did a fantastic job of putting the prototype together, but the code base and the organization were not scaleable and would be problematic moving forward. This is where I come in to help. I don’t think I quite understood what I was getting myself into at first but the further I dug through the blueprint code, the more I realized how badly it needed to be redone. It felt a lot like the kind of code I would write in a game jam when there just wasn’t enough time to do anything fancy or good. So what have i done? I’ll break it down into a few things.

I started by refactoring the project files itself. If you saw them, you would understand how bad it really was. We had no organization and for some reason there was a folder in the root content folder that acted as its own content folder. Not to mention the world outliner being a total mess. After several tries of refactoring the project files (and failing spectacularly because of the dependencies on each of those files), I finally succeed in making it reasonable.

Next step was to rewrite the item system. Our item “system” was kind of thrown together and was a bunch BS which pretended it was a system. It didn’t make a lot of sense and there was tons of duplicated code and parts. I created a system that would allow us to do a lot of cool things down the road with both items and interactable objects. I started with an InteractableObject class which is an AActor and defines functionality for subclasses to implement as needed. It also provides a volume for them to specify which represents the box in which the player’s vision needs to overlap in order to show their interactable functionality whatever that may be.

12

This class is what I based the HoldableItem class off of which defined more functionality specific to the items. I then recreated our existing items in the system and they functioned more less the same but in a more scaleable system.

I also worked a bit on the character class we were using. Since the prototype was originally based off the first person shooter template, it had some blueprint code and assets from that. It also meant that our character class was based off the template’s character class which was all in blueprint. I then had the pleasure of rewriting all of that in C++ so it could be less messy and so that I could work on it down the road with less problems. This is still a work in the progress, but all the base functionality from the first person template is working (besides the shooting because that was removed).

Now that the more technical stuff is out of the way, I can also briefly talk about the direction our prototype is heading. The group and I talked a bit about it and decided to scrap the level we had already created. This is partially because it was incredibly messy and more a less a proof of concept but also because it didn’t fit what the designer had in mind for the beginning of the game. Our new level puts you at the exit of a subway next to the entrance of the mall. This is all underground if that wasn’t clear previously. The level in the prototype is still in progress so it’ll be best to show the image our designer has created for it. The main point of this level is to introduce the player to flares and a basic puzzle like opening a powered gate.

13

Now before I end this post, I have one last anoucement to make regarding the team. For a while, we have called ourselves Mind Tree Games. And while I had not previously posted this, it has been so for several weeks now. But what kind of team would we be if we didn’t have a logo? Our artist nick gave us a beautiful new logo to go with our team name which is below. It really is a remarkable piece of art and I hope we can one day make it a poster because it would look pretty awesome.

MTG

TL;DR:

  • I have the ‘joy’ of refactoring our code
  • We made a new level
  • We have a logo!

Research

Posted by vincentloignon

Senior Production

Post V

 

I don’t have much to show for visuals this week, just some text so feel free to just read the TL;DR if it isn’t interesting. I also don’t have too much to talk about this week. I spent a large portion of my time working on a few other projects and so there just isn’t much to say. However, some research has been done and the good news is that my team did in fact pass the Stage 1 Challenge I talked about last week.

The research and discussion has been focused around a few important topics for our game. When we passed the first stage, we were posed a question which we were not really capable of answering. This question being “What is your gameplay?”. Sure, we had some ideas for mechanics and we had created an atmosphere for our game in our previous prototype but what was the point of it all? Seeing as the point of this stage is to do a “Deep Dive” and the research will more than definitely help us, we’ve begun exploring what are game can and will be. One of the important things we want to use is a story. This can be a powerful tool to help drive the game and as a means to keep the player playing down the road as the game progresses. But a story isn’t enough, we need gameplay. So we decided to see how the mechanics we’ve talked about can be integrated into the story and become part of the game. This means the end result is that our game is more than a survival game with horror elements. Maybe it is too soon to tell, but It is helping.

As a team, we also began researching various psychological topics and other subjects useful to our game. We even watched a horror movie which had a similar premise to our story. Turns out the movie was terrible for more reasons than i’d care to say (Go see its wikipedia page here) but we did learn a few things. One of the things the movie did terribly besides the way they told their story was their inconsistency. They constantly did things that didn’t make sense in the context of their story. They also left too many questions un-answered and while in some cases, having un-answered questions is a good thing, this was quite awful. The list goes on, but the point being is that we can learn from their mistakes. To put it simply, don’t do what they did because clearly it wasn’t successful.

Lastly, I spent a small amount of time researching lighting in Unreal Engine 4. Having no experience with the lighting in the engine and since the prototype was created by our artist and designer, I wasn’t sure what to expect. I was told that stationary lights were limited in quantity due to how the light maps are baked but it turns out this is wrong. In a short amount of time I was able to figure out how to solve our problem and now its just a matter of making some minor tweaks to the level to fix the lighting. Nothing particularly special in the end, but seeing as lighting is important to the game, it was an important thing to look into.

This concludes this weeks post. This was a slow week on the production front, but it is very likely this coming week will be more eventful in one way or another.

TL;DR

  • What is our gameplay?
    • Working on story
    • Integrating mechanics into story
    • Maybe redefining the game?
  • Watch a bad movie
    • Learned what not to do
  • Found solution to current lighting problem

Stage 1 Challenge

Posted by vincentloignon

Senior Production

Post IV

This week has been a bit of a crunch for the team and there is definitely a lot on our minds right now. With the challenge of the first stage in our not so distant future, we are scrambling to get all the requirements done in time to be able to actually move forward. While we could definitely spend a bit more time on this very prototype heavy phase of development, we are pretty sure we know what we want to do and what to move forward with. Before I reveal what we’ve decided to move forward with, I have more updates on what i’ve worked on this week!

BBR has gotten a little bit of a facelift and has progressed nicely into a game (albeit a pretty awful game). It needs a lot of work still, but that is to be expected as its an initial prototype. In this past week i’ve managed to get a scrolling texture on the floor, enemy spawning, basic enemy AI, shooting and killing. I also updated the 2D aspect which now has assets and has a slight camera improvement. This is kind of a long list of features so I think it would be best to show it with a quick video demonstration! This is the video we will be using to present gameplay of BBR this Wednesday when we challenge the first stage.

So now that brings me to the topic of our choice. The team and I had a long conversation on Monday, we weighed the pluses and minuses of each game. We talked about potential problems such as a light or heavy workload (for the game), needing certain resources down the road, potential technical problems, etc. It was pretty thorough and we were able to eliminate at least 1 game, leaving the decision down to two games instead of three. Our conversation continued for a little bit longer and we started to consider how other people (outside of the team) felt about the two remaining games and with that we came to a unanimous decision. We are making a survival game.

The winner was chosen for a few reasons. For starters, it was something we had talked about the most amongst ourselves. Almost every conversation we’ve had since introducing the idea has involved the idea in some way. There is very clearly excitement around it and when presenting our survival game to the class and other people, they definitely tend to respond quite well to the idea. We also decided to pick this idea because it gave us a lot room to craft the experience we want the player to have. Everything from the look, the feel, the sound and more. I personally voted for it because of the chance to mess with an interesting AI (the darkness/shadows) that will be ever present in the game. From a marketing side as well, this game is fairly viable because it would fit into the survival and potentially horror markets. This tends to appeal to a larger audience than Tower Defenses and Bullet Hells which makes it a more favorable pick. Overall, i’m pretty happy with our choice and while i’m sad to see BBR and the Tower Defense go away, i’m certain we will memorialize it in some way.

With that, I bring this post to a conclusion with a video of the game which we will be moving forward with.

TL;DR:

  • BBR is a game now
  • We are challenging the first stage
  • We picked the survival game
  • I’m excited for the AI

Prototyping

Posted by vincentloignon

Senior Production

Post III

This week marked the end of an era, and the beginning of a new one. At the end of the week, moving into the early parts of the weekend, I reached a point in the tutorial I was following where I no longer needed to continue. Not because I had finished it (far from it, lots of cool polish related features were remaining), but I got to see enough of the engine and how to do things that I could leave the nest and fly on my own. Towards the later part of the weekend, during my untimely catching of a really nasty sickness and some of monday, I managed to scrunge together most of a prototype for one of our games, Balls Balls Revolution (BBR will be used from now on so I don’t have to keep typing it).

I mentioned BBR in my first blog post where I talked about some of our brainstorming ideas. If you want to go back and read it, the link is here: http://vincentloignon.com/blog/brainstorm/. If not, that’s fine, because i’m actually going to talk about it a bunch in this post and you can probably figure it out. I suppose this now makes “What did I get done?” the all important question. The short answer is a lot of important systems, but from the outside, it looks like a whole lot of nothing. Lets take a look at it a bit more in-depth to witness some of the neat things I got up and running.

 

3D

BBR1

 

2D

BBR2

 

This is a graphic representation of some of the things that have been achieved. Now, It is important to note that you can’t see roughly 95% of the work I did from this, but lets break it down and see the insides.

The first thing to look at is the environment. The player (gold orb) is on a platform (the ugly grey thing). The camera is static and doesn’t move and in the 3D space, it is angled slightly so you can see ahead (hence the perspective warping on the ground). The player can move around the platform, but is blocked by invisible barriers I have placed so they cannot falloff and so they can only move so far up the platform (like most bullet hells tend to do). The player is also able to Dimension Hop between 2D and 3D. However, 2D is currently incomplete visually.

We also have another important system which is shooting. In fact, the shooting system has been built in a way is very easy to extend and create all sorts of bullet spreads and projectile types. These will be very important for building a bullet hell. Now, I tried to make a video to show this off because that would be the easiest way to do that. The biggest problem was that I kept coughing due to my recent sickness and my mic has horrible static, so i’ve opted for a picture heavy post this time. I am looking towards fixing my mic problem for the future so that I might be able to show some of these things in video form. I will explain it all first then just put all of the images in a gallery of sorts to look through should you wish to.

  1. The first step is to create your bullet spread. You can create a blueprint class and extend a class i’ve created in code called Bullet Spread. What this class does is when told to fire a projectile, it will search all of its sub-components and find all of the Arrow Components. These represent where to spawn the projectile and how to orient it in 3D space. It then creates a projectile of the type specified for each arrow. This means it is easy to create bullet spreads because its all visual in the editor and the system just handles everything else.
  2. The second step is to create your projectile. The projectile is slightly more complex, but is also very simple. You create a blueprint class, extending yet another class i’ve created in code called Projectile (big surprise). This class contains a mesh component, sphere collision component, and projectile movement component. The collision is separate from the mesh on purpose so you can customize them separately. The process is fairly simple, you import a mesh into the mesh component, tweak it as needed (materials and other settings). You can adjust your sphere collider to fit within your mesh as best you can or what will make sense in a game context. You then adjust the movement to work in the fashion you want. In my example, I turned off gravity, gave it a slight Y velocity (so it fires at a 45 degree angle to the arrow component) and give it a velocity. The nice thing is that you can also add other components and customize it to your liking and the base systems will still work.
  3. Lastly you go into the player’s blueprint and change which spread and projectile to use, in this case the ones you just created. Also make sure that you compiled everything before running! You can now run it and see your cool new spread and projectile in game!
  4. Profit!

 

[tribulant_slideshow gallery_id=”2″]

 

This brings my post for this week to an end, but there will be more in the coming weeks as I detail the progression of capstone from my eyes. Just keep in mind things I talk about may vary between things I’ve done and things my team has done.

TL;DR:

  • Finished Tutorial
  • Started BBR prototype
    • Dimension Hopping!
    • Bullet Spreads & Projectiles!
    • You can make your own bullet spreads and projectiles easily!

Learning Curve

Posted by vincentloignon

Senior Production

Post II

 

This week has been interesting in the world of unreal. The first step I needed to take moving forward with my team and our choice of using Unreal Engine 4 for our games is to learn it. Having never used it before (besides some basic tinkering previously), it was a daunting task. It still is to be frank. I knew there was going to be another learning curve, one that is a little more menacing than the one I usually need to deal with. Nevertheless, i’ve been pushing forward at a slow and steady pace, quickly gaining momentum.

Most of my hours outside of our weekly meeting schedule have been focused on using a tutorial to help guide me through some basics before I spread my wings and fly through uncharted skies. The tutorial series can be found on youtube (here) and is provided by Epic (go them!). While it does a few things i’m not particularly found of such as blue prints to do code, i’ve taken it as an extra challenge to figure out how I might setup things to do the same task but purely in C++. A bit more complicated at first when I didn’t have a clue what I was doing, but this has proved to be a very helpful challenge and continues to push me forward at an ever increasing rate.

My progress so far has been minimal though. It’s to be expected and as a result, this post will be short, but at the very least, there has been progress. Speaking of progress, it wouldn’t be official without a screenshot to go with it!

TwinStickTutorial1

The player can move and turn their character using either a controller or the keyboard. The enemy has very very very very basic AI which just follows the player and their classes are setup for the next part which involves some shooting and killing. Looking forward, I am anxious to get through the important parts of this tutorial so I can start looking towards the creation of our game’s prototype.

TL;DR

  • Twin Stick Shooter Tutorial
  • Some progress learning UE4 (slow but steady)
  • Can’t wait to program Balls Balls Revolution

Brainstorm

Posted by vincentloignon

Senior Production

Post I

One of the integral parts of my Capstone class is working with a team to create a game. Assuming we decide to challenge enough stages and make it through the cut this winter, this will become a 2 semester long project. This blog, beginning with this post, will try to elaborate on some of the things we will be working on, my thoughts on various things and just the process of making our game. In the future, it is likely I will be posting content such as images, videos or perhaps some code but for this first post, it will lie mainly in the realm of text. There is a TL;DR at the bottom for those who prefer it.

Like everything, this game will have to start somewhere and the first place for us to begin is with the ideas we have brainstormed. The class requires us to have at least 20 ideas (they don’t need to be thought out) and the idea behind this is to get us thinking and to explore our options before settling. I don’t have intentions of posting this list here, but I would like to talk about a few of the more notable ones and my thoughts on it.

The first thing we talked about and the thing we were originally excited for was a Tower Defense. Having talked briefly over the summer with my team, we knew our interests lay in a more strategy oriented game. We started brainstorming with a tower defense game and ended with 3 different takes on it. While we could theoretically take any of these aspects and apply it to each of the other ideas (or even merge it all into one game), they are fundamentally different. The idea I brought up was a casual competitive take on the traditional gameplay by turning it into a game that two players play against each other. Players would be playing in a round based system (where actions such as building towers could only be down between rounds) and the object was to get as many of your troops through the enemy defenses. Other mechanics such as abilities, wave organization and more would be in place to allow each player control over the process. Victory was also determined by who won the most rounds rather than who was last standing. This meant that each round could be wildly different since each round was like having a fresh start. Other interesting mechanics brought up by the other 2 variations were the use of environment (such as weather) to affect gameplay and a blend of 2D and 3D mechanics that would make it a battle in both a 2 dimensional and 3 dimensional plane at the same time.

Moving forward a bit, we also had an idea for a dungeon crawler. This also had slight variations, but the basic idea was the same. It was intended as a couch co-op game with multiple players playing together and working together to get through a dungeon of monsters. One of the ideas focused around having roles and the use of teamwork to survive while another focused around two or more players controlling a singular character. Either way, it was sure to be an interesting idea to see to fruition.

Since our session was open to any idea, one of the things that was brought up was a horror game. Now, I’m not usually a fan of this genre, but some of the ideas being thrown around really got me thinking. The biggest of these ideas was the use of sound to help the user find their way around a dark space. This as well as using light as a mechanic for gameplay (such as a monster which only moves in the shadows) would make for a really interesting game. We have come back several times to this idea since the initial brainstorming and the more we talk about it, the more interesting and appealing this idea becomes. I am, however, slightly concerned about the scope of this idea so this will need to be something we tackle early should we move forward with it.

One of the more innovative ideas we came up with was intended to use a peripheral (such as a phone) as the main controller for the game. The idea which sticks out the most is a Cooking Simulator. Rather than abstracting the process of cooking into little minigames like a lot of other cooking games have down, this was intended to be a simulation of cooking. The game would use the phone as a means of navigating the work stations and selecting tools. The hardware on the phone (such as accelerometer and gyroscope) would be used as input for the game which interpret the action based on the context. This game is also ambitious in a different way because the point was to get the user to create a dish and they would be rated on how they did. An example could be making a steak dinner and they would have to tenderize the meat, season it, cook it on the stove or BBQ to the desired temperature and prepare vegetables and other sides with it. Everything you would do in real life to prepare a meal would have to be done in the game. This game has a lot of potential walls to climb over should it go forward, but it is definitely something that would be fun to see to completion.

The last idea I will talk about is one that kind of sprung up out of the blue. Typically, our ideas would be a genre or a specific take on a genre (such as Cooking Sim or 2D/3D Tower Defense), but this one started off as a bad joke. We initially put up the words “Balls Revolution” with no idea what it actually would be. One can only assume we meant a ball rolling game, a classic amongst champlain game students. We later jokingly changed the name to Balls Balls Revolution as a playful stab at Dance Dance Revolution and how it is redundant in its name. But when I posed a question to my team asking what we think this game would be, a great idea was formed. On our list of ideas, we had bullet hell listed. This was meant to signify that we could make a generic bullet hell game. Then someone brought up the idea of combining the 2D/3D mix we liked from the tower defense idea and putting it in the bullet hell game. This would mean you would play in either a 2D or 3D space and that everything you did in either dimension would have an equivalent in the other dimension. So for example, fighting a boss in 3D could have a part which is impossible in that dimension, so you would swap to 2D mid fight and fight the equivalent boss at that particular time frame and this would be a important mechanic in the game. Lastly, we tried to figure out how to tie this idea to the name. One of us had the idea of putting a ball game spin to it where the player is a spherical object (perhaps a ship or something of the sort) that was fighting a race of sided objects. Perhaps even the number of sides on the enemy could signify its difficulty. This in particular is my favorite and I would love to see this through to completion.

Looking forward, i’m sure this will be an interesting semester and I have high hopes and aspirations for what my team and I can accomplish together.

 

TL;DR:

  • We brainstormed ideas
    • Tower Defenses! (Maybe 2D/3D twist on it?)
    • Co-Op Dungeon Crawler
    • Horror game
    • Cooking Sim 2015
    • Balls Balls Revolution
  • I like Balls Balls Revolution the most