Hot Off The Stack

We are a collective of College Students doing game design and development in our free time. Herein lies both work for the card game EC, and the personal work of PancakeMisery. Occasionally there will be posts detailing various game design and game programming techniques, so stay tuned for some educational material.

[hotoffthestack]

Building Bosses is really fun

[hotoffthestack]

On Building an API - The Dependancy

Switching the core philosophy for how we develop the core gameplay systems halfway through a project is a risky decision, especially if the project only lasts around 6 months. But sometimes you have to weigh the potential outcomes, and those are as follows

The work put into the replacement system is wasted and we revert to the old method

The new system ends up gaining no extra progress due to the short time frame of the project

We build it well enough that it rapidly speeds up our development cycle and the design team is able to take over some of our responsibility and implement more content than we would have been able to with the old method

In order these range from bad to neutral to good. We discussed the possible alternatives and to what extent the rework could be done. And after due diligence we reached the conclusion of doing a complete system strip and rework using the existing code base to develop a new solution. This consisted of a breaking down all puzzles into several variations. And finding ways to make it generic enough to be reused in any puzzle we design but also not too generic that the mechanics don’t feel unique between puzzles.  And we accomplished this, but not without set back from the rest of the team. The sheer amount of time needed for this meant that other times got put on the back burner that we really wanted to make happen. Those things are now being worked on with the Puzzle API no longer the main focus, The time we lost getting it working has been well worth it as we now have a much more streamlined and iterable puzzle architecture, that allows puzzles to be built without programmer oversight. So in all, it was a worthwhile decision, tho it wouldn’t be for all projects, but taking the risk may have saved this game from lacking sufficient amounts of content.

[hotoffthestack]

On Being a Discipline Lead - The Responsibility

For the first time ever on a team I have been designated as a discipline lead. For me this means I am the programmer in charge of the programming team and all programming decisions. As an unprecedented role in a game development environment, I had to spend some time finding out what it would entail and how we would proceed. The most important thing is that with me taking up a minor managerial role I would not be spending all my time solely on just pumping out code for the project, I would have to spend time on keeping everything organized.

That meant the following things

Keeping tasks assigned to the right people was key

Keeping a list of systems that needed to be worked on and their related dependencies and estimates for time and workload would be vital

Keeping in communication with the other two leads would be a lot more vital as there are more links in the communication chain and that means more ways for things to go  wrong.

I have to be more hands off and let people just get things done without me stepping in to micromanage

But also at the same time I have to keep tabs on how things are going so that we can make sure things get done on time.

So with all these things in mind I developed a rather nice spreadsheet with auto formatting and keying based on the info in it so we can keep on top of what tasks are our current priorities. And in addition to this we have a good hierarchy of communication. There are the three leads and each of us is in charge of our field, and we each have two people we work with and watch over and we [the leads] facilitate cross-discipline communication and task management based on each others needs.

All in all these things are making it a much smoother experience than previous experiences with larger teams, and we hope it turns out to be a successful team management practice.

[hotoffthestack]

Dissonance Postmortem - First Semester

Ok, so going forward, especially since our project is continuing and now with an expanded team, I need to mark out what happened and which were good and which were bad.

Positives:

Team Responsibility - for the most part, as a team we held each other and our selves accountable for our work. We were not prone to blaming other factors for things that were our fault.We followed through often, and when we did not, we were able to communicate a plan to fix the issue and then stuck to it and showed results

Game Concept - the big thing here was all our excitement in the project. We had genuine hope in it being a unique and show worthy concept, and while difficult to execute, our passion kept us on the right path. In the end finding a project were excited to work on enabled us to put out work above and beyond what we might have on other projects.

Communication - we kept a pretty open line of communication. We had no issues with not be able to reach people at reasonable hours, and as a whole we were confident in being able to voice our thoughts with the knowledge it would be honestly listened to.

 Negatives:

Schedule - There were issues getting a work schedule that could accommodate everyone’s time appropiately. A good part of this was due to me having issues with having too much I needed to do because of financial limitations. But going forward, finding a way to not have 60 hrs of work a week is highly recommended as it would allow us to work without constant pressure of things maybe not getting done.

Tensions - Near the end of the project, tensions were high and there were a few cases where people snapped at each other. While these didn’t cause issues as they were resolved. There are still ways to avoid them in the future, and one of those being the above. And not having team members snap at each other is a good idea.

Personal Organization - While the team was overall very organized as a unit, there were issues with team members struggling with managing their personal responsibilities. This luckily did not impact the quality of the end product, but it def put pressure on us being able to finish key milestones. Because if you have other projects breathing down your neck that you are behind on, its gonna eat up time that shoulda been dedicated to this.

[hotoffthestack]

On Why Experimental Tech Can be Your Savior or Your Downfall - The Cutting Edge Continued

So in a previous entry, I wrote about how we had to find workarounds for tech limitations in the engine. And in another, we talked about the needs of designing retro technology to work in modern frameworks and the challenges it posed. But there was one extra thing that got in the way of the cell phone, the nature of just how new the features we needed were that made that 3d in game menu possible because the cell phone is just a fancy UI system. The fundamental building block of the cell phone is a 3D Widget class that was brought into Unreal 4.13 as an experimental feature. It was not extensively tested and it was not guaranteed to work. Before this engine version, I would had to have written most of the code for making those things work by hand, which was actually my first attempt, and it did not work at all. I actually lost a good chunk of time to do that only to realize there was a better solution already built in.  However, during development, there were a lot of issues with the phone, and primarily with dealing with input. There was not a lot of documentation on how to use the class as it was too new for Epic to have written documentation on it. In the end we saved a lot of time since we lucked out with the release of this new tech. And even if some things were cut or redone due to issues with the limitations of the experimental tech, it ended up being a very good risk to have taken.

[hotoffthestack]

On Relearning Programming Techniques for VR - The Cutting Edge

Ok, so the biggest thing for VR is that all our rules of design that we knew no longer apply, and with it being a new tech, a lot of the tech solutions for programming the flow of a game have to be rethought. For us, the biggest issue was that level loading needs to fill a couple criteria

We can’t have it take too long because VR risks frame rate issues if it gets stuck loading a ton of new assets

We can’t actually change levels if we want the player to stay in the game

The big reasons for both these things have to do with the engine we built the game on, Unreal Engine 4.13. A lot of the VR support is new as of that version, and that version only released a couple days before we started the project. That version of the engine didn’t have a way to keep players in the game when switching levels. It would kick them back to the Steam VR waiting Room. So for a few seconds, you are kicked out of our game and are in a default white grid environment. This is bad for us as we want to craft a very particular mood and breaking immersion can kill hours of work in a second. The first thing is also a problem because that version of Unreal did not have ASYNC level loading, so the level couldn't load while other things ran, meaning the game just tanked until things loaded. Which meant that even if we tried to change levels secretly it would be so unsettling that the player would immediately want to leave the game. Given that the tech has no way to fix these issues, we found design solutions that I had to very carefully craft to make it as nice as possible. The solution was to utilize the Level Streaming features in the engine. The gist of it is that the game has a master level with sub-levels. The sub-levels are just instances of other levels we made, but the thing is they can be toggled on and off at will. They do not incur the load penalties of non-streamed levels as they are cached. So what we simply do is have the player step into a hallway, do some fancy teleportation that looks seemless, and just swap the streamed level to the next one. the player has no idea this happens beneath the surface and we solved the problem of having to rethink the tech for game flow.

[hotoffthestack]

On Reflecting on Personal Complications - Time Management

There have been a lot of things learned during this development process, and for me, there have been a lot of those relating to personal health issues. While I will not go into details here, I definitely struggled with a basic skill, Time Management. The reason for this is primarily due to me attempting to balance too many things at once. At the beginning of the project I was pulling at least 60hrs a week between school work and a job, and that left me with little personal time. The problem with that is that it left me no time to destress and get myself back to a good place. It was work non-stop for weeks on end, and it left me in a place of exhaustion and stress. And that's what this is about, the importance of taking care of yourself and letting yourself have time to step away for a while, especially if some of your work is not stuff you’re too keen on. Pouring yourself non-stop into a project will eventually hurt you, and will also cause your work to suffer. Constant overtime isn’t worth it, and if I had not freed up a lot of the things that were taking my time from my Capstone project, our project likely would not have succeeded, or I would have put myself in a very dangerous place as a result.

[hotoffthestack]

On Recreating Old Tech - The Nostalgia

One of the biggest things about our game is the aesthetic and setting. I have not talked about this before on this blog, but the quickest way to describe it would be as a twilight zone episode set in a late 90′s American suburbia.

Anyone who grew up in America in the late 90′s or early 2000′s is likely familiar with this piece of technology

and the particulars of the way you typed on it.

I spent several weeks of this project working on this phone, or well a version for the game. And the most difficult thing was to nail the particular feel of the hardware and software. There are a large number of limitations of these things and with a modern game engine a lot of these limitations have been removed from the way the engine both handles input and presentation. 

For the purposes of the phone I recreated the following

input delay/multi-push system

retro inspired display

[hotoffthestack]

On Developing for VR - The Initiation

There's a lot that goes into game development, and doubly so if said development is occurring with either fringe or emerging technologies. That being said, I am not someone who lacks experience with working in VR, but even my experience with it is limited. So with our team developing for the just recently released HTC Vive VR headset, there's a lot we are gonna learn and a lot we aren’t gonna be able to find simple solutions for.

In order to discuss the specifics of how VR is affecting the project and how it’s important I need to first describe the game. And while we are working on multiple prototypes, this past week was spent working exclusively on one in particular. The best way to describe it would be as an Escape the Room Puzzle, but in a 1:1 Scale VR Environment, including object interaction and puzzles that make explicit use of the headset’s room scale capabilities.

 The most important aspect for this game, from a technical standpoint, is to make the systems and the way they feel solely contribute to furthering the immersion of the player, and never pulling the player out of the scene and reminding them of the VR nature. 

For this a few key things became apparent:

The frame rate must be maintained as high as possible

The player’s interaction with objects must maintain as little input lag as possible

The method of interacting must as closely reflect real life interaction as possible

Any mitigations for the size of the room relative to the play space must not be nauseating or clunky

The risk of game breaking bugs becomes higher, as they will immediately break the immersion we are trying to craft

So with this is mind I spent the first week developing both basic object interaction (two forms) and a remixed version of the default Vive teleportation system that more closely matches the needs of our game.

The first interaction method is the built in ability to pick up and grab objects, and since these are already built into the default VR project I did not need to spend any time on implementing my own version. The second method of interaction is modeled after the need to hit switches and buttons. That would be using the finger on the player’s hand model to interact with these things and run their code. This was simple in concept, but many small idiosyncracies with both the way that UE4 handles component and actor collisions and the fact that the player does not have independent finger control over the model lead to lots of very tiny bugs. These bugs weren’t system breaking but definitely made it not feel as natural and as good as it should, so even early on, a lot of time was spent making it just feel good.

Oh and setting up the Vive is a lot of work and it really really really gets cranky with how your playspace is setup, so that was a good thing to learn.

For now thats all on Phantasmagoria, I’ll be keeping more posts on the process as production moves forward.

[hotoffthestack]

Rule Based Systems and Their Use for Interactive Fiction Games

WHAT IS A RULE-BASED SYSTEM?

A Rule-Based System is a tool used to allow an Artificial Intelligence (A.I.) to make sense of and develop relationships between objects in a world. Granted, this is almost exclusively one objective world, because to have the system try to relate several different methods of understanding would likely result in near infinite loops and becoming unable to function properly. This is why most uses of Rule-Based Systems are referred to as expert systems, as they only have a finite knowledge of a focused area of understanding.

There are three things that compose of a Rule-Based System:

A Knowledge Base

A Rule Set

An Inference Engine

The knowledge base is simply a set of Relationships that the A.I. can use to establish when rules should be used, as well as to infer connections between things (such as: a is b and b is c therefore a is c). One of the main functions of the inference engine is to use the knowledge base to generate more knowledge and apply rules.

Heres the source I used to build my Rule-Bases System: http://content.gpwiki.org/index.php/Rule-Based-AI

It covers all the basics and provides ways to improve upon the system if you wanted to, I didn’t because this is a simple proof of concept that is meant to get the ideas across. HOW DOES IT APPLY TO INTERACTIVE FICTION?

A very common use of Rule-Based systems is in interactive fiction, games such as Zork and Adventure. The draw here is in the fact that the game is composed of interacting with objects that have multiple uses. What you want to use this technique for is assigning rules for each objects used that can be called after parsing user commands. Another big draw would be in situations where you want adaptive conversations between the player and other characters.

As you can see here, the primary use as it comes to dynamic conversations comes from the ability for the A.I. to learn new Relationships and can then make new rules or modifying existing rules to accommodate new information. I used this for a rather simple command line program that allows an A.I. to parse information you are providing in order to determine the Fruit you are talking about. You provide information in a form that the rules system is familiar with (this case being A, Relation, B). Using the information about the fruit along with the information stored in the general rule database, the A.I. can decide what uses the fruit has, such as whether or not to eat it.

Here you’ll find the discussion on the evolution of Interactive Fiction, and where I got the basis for how this could be applied to conversations with A.I. in games: http://eblong.com/zarf/essays/rule-based-if/

WHICH PLATFORMS IS IT GOOD FOR?

               Because, at least in this example, Rule-Based Systems work within the confines of a text parser and user typed input. While technically possible and not beyond the realm of possibility, these kind of games tend to work best when not done on Consoles, they primarily are done on Computer and occasionally mobile. Depending on implementation, this technique could be applied to any platform and almost any genre of game. Though in the confines of a text based, you will primarily be doing this on a computer system because of access to a command line for text input and output.

here is just a good general overview of the topic: https://books.google.com/books?id=Sz-Sqvm-hSYC&pg=PA212&lpg=PA212&dq=rule+based+system+in+games&source=bl&ots=vNjw-g1EjG&sig=Ev3qbBGHoQg8iI1XqJ-7OFnKxlY&hl=en&sa=X&ved=0ahUKEwij9PaWjsDJAhVHVj4KHcPmA3EQ6AEIVzAH#v=onepage&q&f=false

Link to my project: https://www.dropbox.com/s/t0ll9e1hurpnvjq/RuleBasedSystem.exe?dl=0

Link to the readme:

[hotoffthestack]

The home of Hot Off The Stack Games

Hey, I finally got a website up and running. It’s not finished and a lot of areas are temporary, but you can go check it out and even hit the forums up if you want.

[hotoffthestack]

COMING SOON!

We plan to start launching updates on EC. Soon we hope to get our first round of intense testing done and hopefully by the end of the year we can get a starter set out.