Experimental Games, Game Dev Adventures!

Making “To Save or NOT to Save…”

Play this game! Instructions on the portfolio page.

GameCapture_Achievement

To Save or NOT to Save is an ethical dilemma game where player decisions create game-world consequences which the avatar is forced to experience. Careful your decisions! They are not free!

Inspiration

This was an experimental game made in a week based on a theme from the board game mechanic of push-your-luck. 

I’m not a fan of push-your-luck games (though admittedly there are a few I enjoy). I came up with a few ideas, but they were even duller than the versions of push-your-luck games I didn’t like. None of the ideas excited me or seemed thrilling. As the game was for an assignment, and I could “free pass” once in the class I thought about using that up for this one where I felt so dispassionate about the theme. But I wanted to challenge myself. I thought about an experimental game made by a previous experimenter, Sydney, in which she combined two genres she didn’t like either (idle clicker and match three) which turned out fairly interesting. I thought then, “What would a cross between push-your-luck and a runner look like?”

What I Did: Lucky Running

My first thought was, “What if you were a runner and had to pick up a bunch of somethings as you ran, but as you picked them up they obscured your screen? How about that something was bunnies (because they’re cute!) you need to save, and if you don’t pick them up it kills them?” When I pitched the idea to a friend she said she’d just kill the bunnies. So I thought, “Fine. Kill the bunnies, but blood splatter is going to obscure your screen anyway!”

Either way, you end up with a covered screen the longer you play. The only difference is that the bunnies don’t go away after you’ve picked them up, but the blood splatter does go away slowly over time. If you want your screen to be full of blood you have to keep killing. So evil!

To add depth to the ethical choice presented to players to save or kill the bunnies: I added judgments based on their behavior.

 

As far as camera and perspective went: I found the 3D avatar in the standard assets of Unity and was a bit enamored by him. I liked moving side to side and even backward with the basic camera I made for him and knew that a basic runner wouldn’t fit this movement. So to give the sense of urgency (which also plays into the narrative of impending danger) that comes with a true runner, I added a timer. If you fall off the edge or when your timer runs out, you get passed judgment. Then the game restarts.

I spent more time on this 7-day game than previous 7-day development games because I stepped out of my comfort zone to try something different and experiment with styles of games I haven’t really made before. I’m happy with the end result, though it’s not my personal favorite of the games I’ve created. But it does get immediate laughs, which at the end of the day was what I was going for, and I enjoyed working on the project.

What I Learned

Something unexpected was just how fun it was to play with an obscured screen that doesn’t clear up but only gets messier the longer you play. I think the bloodiest juiciest part of the game was the obstruction to the screen.

However, the re-playability increased when I added the judgments based on the player’s behavior. In playtesting: the obstruction of the screen and killing of bunnies got quick laughs, but people kept re-playing to see what judgments befell them based on their choices.

“I love designing games that are ‘Pick up and play!'”

I originally planned on making the game a 1st person game, but after seeing this cool looking dude I was intrigued and made it a 3rd person game. Other playtesters were also intrigued by this character who clearly doesn’t fit in this world. He’s gray and colorless, while the world around him is full of color, including the effects of “his” decisions.

With concern to the perspective, I don’t believe 1st/3rd really made a difference in gameplay, but I do believe the simple camera I made did. Though the camera moved in all directions, unlike a typical 1st/3rd person camera, it didn’t follow the player in the rotation. This added to the obscurity of the world as you couldn’t rotate the camera around to achieve different viewpoints from different angles, but could only move side-to-side to possibly see between the cracks. Moving backward is particularly difficult, and it adds to the fun. Camera controls are also one of, if not the hardest mechanic for new, and even more experienced players, to master even in well-designed games. Thus a natural consequence to the player not being able to control camera angles is that it actually makes the game easier to pick up and play, which is my thing: I love designing games that are “Pick up and play!” But that doesn’t make the game any easier to master, nor does it detract from the experience. In my opinion, simple cameras add to the experience by removing a layer of complexity in controls from the player. It’s why I think side scrollers, 2.5D, and other fixed rotation cameras are so popular: it’s not about the camera! It’s about game experience.

Ideas for further development

“The level I created was very basic and meant to merely communicate a basic idea: obstruction and an ethical choice.”

Game Level Design: Adding Life

Though I think this game works as an endless “runner,” I think it would work best as a procedural level based game. With a few crafted game level pieces (and by a few I mean probably 20), and a creative procedural level creation algorithm, I think interesting levels could be made at every reload thus increasing the re-playability of the game.

Adding to the depth of the world by creating an environment for bunnies to live and hide in (more on that below) by creating a space for the bunnies to be unaware of the danger that the player is trying to save from, or add to, would immerse the player more in the world.

And of course, adding to the life of the bunnies by making them move, breathe, eat, (poop?), and react to the player based on the player’s decision. Giving them a voice through audio and reaction would make them so much more real and make the decision the player makes have that much more weight. In games like Skyrim — which presents you with ethical decisions — when you see the consequences of your decisions you feel more connected to those things: it becomes an ethical consequence and although in a virtual world, it still shapes the way you feel about the decision and even yourself.

I could add other animals or environmental threats, but I think keeping it simple would play on the thing I want to push on the most better.

Pushing on Obstruction and Ethical Choice

The level I created was very basic and meant to merely communicate a basic idea: obstruction and an ethical choice. I think the combination of choice and obstruction played well together. It would be interesting to push on those ideas combined more.

“To play on ethical decisions in games it’s not enough to merely present the player with a decision. You must also provide a consequence to that decision. Their choice must not be without consequence.”

I think the combination of choice and obstruction played well together. It would be interesting to push on those ideas together more.

To push the on-screen obstruction

I had wanted to make the placement of the obstruction random but ran out of time, but that would be the first thing I’d add. Also, on the technical side, the size of the obstruction would need to be scaled properly with the screen resolution.

An interesting idea that was pitched was actually having the bunnies take up space around the character instead of on the screen. It would still obstruct the player’s view, but I think a more interesting and immersive way.

To add interesting gameplay ethical decisions…

To play on ethical decisions in games it’s not enough to merely present the player with a decision. You must also provide a consequence to that decision. Their choice must not be without consequence.

Good

I could add making it more difficult to pick up bunnies the more bunnies you’ve picked up (even adding the chance of accidentally dropping them and killing them that way), could even make player slower the more bunnies that are collected. But on the flip side I (with the basic game addition of slow-moving pace for the bunnies), to make it easier to save them the bunnies to come to the player. Screen obstruction could increase by making the screen could become lighter and brighter the more bunnies are saved. If you manage to save all the bunnies (Is that a challenge?) it could be a fun bright-out moment! The player could further witness what they’ve saved the bunnies from: or what they’ve left the bunnies they were unable, or unwilling, to save, were left to.

Evil

On the reverse, after adding a base slow-moving pace for the bunnies, I could make the bunnies faster and even attempt to avoid the player the more bunnies the player killed, especially when the player is clearly intentionally killing bunnies. As an additional threat, the murdered bunnies could come back to haunt the player. Player’s insanity could increase shown by a blurred screen, tinted red of course. The more insane, the blurrier the screen. If you manage to kill all the bunnies (Is that a challenge?) there could be a red-out moment with the player witnessing what they’ve done.

Conflicted

A lot of the game results are based on the difference of choice: a scale if you will, between these ethical choices. But what if the scale was basically equal? The bunnies become unsure to trust you or hide from you. Maybe some of the bunnies you managed to already save try to get away, maybe some you haven’t come to you. And your insanity is the highest because of the conflict. The screen could glitch with black and white and red. I mean, you got problems, so it could also become increasingly more difficult to control your avatar and his decisions as your insanity takes over!

Platform Porting

“I think… the biggest issue with mobile games [is] when the game designer/developer doesn’t design gameplay mechanic input specifically for the device they are targeting.”

I think this would play well on mobile devices, perhaps better than on the PC where players are looking for more immersive, longer gameplay. This game is more about a quick experience which most mobile players look for. But to play well on mobile the controls would need to be modified. I think that’s the biggest issue with mobile games: when the game designer/developer doesn’t design gameplay mechanic input specifically for the device they are targeting. But with a few purposefully designed tweaks to gameplay mechanic input, I think this game would work beautifully on a tablet or phone.

Possible mobile gameplay mechanics

  • Maybe a single tap rotates through the speed of the player (stop, walk, run), OR add a single speed uncontrolled by the player in the forward vector (for the direction the avatar is facing)
  • Drag to change the direction of avatar movement
  • Make the quick time event a quick double-tap (if using a single speed), or a swirl.
  • Jump (unnecessary in this very basic, experiment of concept level, but would work well in a platformer with either crafted or procedural levels) could be a quick swipe.

 

Experimental Games, Game Dev Adventures!

Making “Tech Escape: If You Can!”

Play this game! Instructions in the portfolio.

DankRoom

Inspiration

Theme: Feature a Keyboard

I was tasked with making a game featuring a keyboard. After several failed experiments I realized the game I wanted to make wasn’t so much about showing a keyboard in the game but having the avatar use a keyboard in the game. A gamebook was the perfect solution!

A few weeks back my boss suggested I make a game about trying to exit from Vim properly. The idea intrigued me so I filed it away. When I was tasked to make a game featuring a keyboard this idea came back to me.

Development Journey

I struggled a bit with making this game. I kept playing with 3D objects in Unity, but never really made a game. I thought about making different games, but I knew that I really wanted to make a game based on the Vim idea. It wasn’t until I realized that I didn’t need the player a keyboard in order to feature it that I finally came across the right game engine: Quest. Even then I ended up choosing the wrong game type (text adventure), but it was because I felt that a gamebook was too simple.

I had envisioned a game with open-ended input. But when I realized that that was really just making an infinite multiple choice, I realized that simplifying the choices didn’t break the idea of the game: to tell a story. And that was best suited in the gamebook type.

After that, the game came together rather quickly. I have always enjoyed writing (if you couldn’t tell by my blog), and was even a professional writer and editor for a while. It was nice to get back to something I enjoy in a creative way and be making a game at the same time.

As far as narrative goes I was really aiming for the player to step into the shoes of a dumb character.

Cool Things I Learned

“…It’s important to use a game engine that is designed to support the type of game you are aiming to make.”

I think the biggest thing I learned is, don’t shove a game idea into a specific game engine/platform. That was what was holding me up the most. My game simply didn’t fit into Unity nor a text adventure. Which the first felt strange to me as I’ve never made a game before that I felt wouldn’t work in Unity. Now that’s not to say that I couldn’t have made the game in Unity, but I think it’s important to use a game engine that is designed to support the type of game you are aiming to make. Once I found the correct engine the game came together quickly and I got to play with what I really wanted to make!

“To feature something in a game you don’t have to actually see it!”

To feature something in a game you don’t have to actually see it! This stretched my mind! I got stuck on the idea of showing a keyboard in my game, but when I finally stepped back and let the avatar be the one to see and use the keyboard that’s when I hit gold.

“There’s a difference between a bad player and a dumb character.”

There’s a difference between a bad player and a dumb character. I think the hardest part of designing and writing this game was the balance between the player playing a dumb character (what I was aiming for) and the player feeling dumb (not what I wanted). I think in a couple spots this could have been improved. For instance, I could have allowed the player to select the correct choice, but the avatar still messes it up. Or instead of giving correct answers each time, I could have given just part of the answer, letting the player pick the part that is right, and allowing the character to mess it up. This was a fun challenge, and since the game is entirely text-based the game design had to come out in the narrative after the choices were made. That’s also where the narrator comes in.

I wanted the narrator to break the fourth wall, so to speak, to add humor, but also to show the player that they are different from the character they are controlling. I felt very quickly into making this gamebook that I was writing a story similar to the game The Stanley Parable. That was the feel I was going for in this experiment.

Ideas for Future Development

I like keeping this game in the text version. So I would fill it up with more narrative. The quest engine also allows for adding audio and images, even videos. I think it would be neat to add those in as well. I think the biggest design detail though would be to keep that distance between the player and the avatar while still allowing the player inside the character’s shoes.

If I made it graphical (which I would do after filling in more of the narrative to test out more ideas in an easier to develop and iterate environment), I would have physical things that the player could do (like pound on the keyboard), visual payoffs (like cool effects when answering correctly), and adding some eerie music, and of course some creepy critters…

Experimental Games, Game Dev Adventures!

Making “Prideful Eyes”

Game download and play instructions in the portfolio.

PridefulEyes_Splash

Inspiration

Theme: Pride

(as in the most deadly sin)

This is the first time that I was given a theme and couldn’t come up with a single idea! Literally! I could have spent the entire week just trying to come up with an idea! When I asked my Dad what kind of game with pride I should make, he suggested a game about lions. Thanks, Dad.

Luckily a game idea that my brother had pitched me last year came to mind, just like it does every week when my bro says, “Why haven’t you made my game yet?” Well, I still haven’t. But his game pitch got me going on this game.

Development Journey

I started with the main character. Since you were a shadow that means that light destroyed you. So light was the prideful enemy.

I also chose to go with a simple camera again. This was a slight variation of the camera from To Save or Not to Save. I did play with making the camera rotate, but I found It distracted from the lights, the theme (pride), and made me a little dizzy. That last one aside, I really liked the idea of thinking you only need to see what’s in front of you, but if you’re not careful the lights come from behind and get you! It made the gameplay more fun with this simple camera.

Initially, I had a bunch of blocks that you could move around to stay hidden from the light (being hit by light = death). But in the process of game development, and with my level design, I soon found that it was more fun to use the blocks to mutually destroy the light.

Next was the light. I wanted it to look dark without being dark so I made it red in a dark blue reality. I also wanted the player to see the light in effect searching for the shadow to destroy it. Originally I had it shooting out four spheres — one in each nautical direction. The plan was to have the main light rotate (you can’t tell, by it is rotating the entire time), and have it fire out these search spheres every 0.5-6.5 seconds. Then a happy accident happened: to track the search spheres I made them children them to my mother light. Since the mother light is rotating, once the search sphere shoots out it begins to rotate around the center on an ever-increasing outward projection: a circular movement outwards. The effect took me quite happily by surprise. If I had been intending this behavior I’m not sure I could have achieved it, but this happy accident gave life and interest to my enemy light in a way I could not have predicted.

I wanted the whole feel of the game to be dark. Not creepy, but strange to the player. Light, which normally gives us hope, and life, the enemy. As a shadow, your very existence depends on light, but too much light and you are nothing. So rather than use a nighttime sky to place my character in a world, I thought, “Why be in a world at all?” So I added a galaxy skybox to make the game feel unworldly.

Cool Things I Learned

On the scene reload my scene was very dark, unplayably so, and got darker each reload. This is because I had a lot of dark, baked lighting. Layer that all on top of each other and it keeps getting darker and darker. The solution is to turn off auto-generated lighting. This youtube video was helpful. https://www.youtube.com/watch?v=F-aUMLdIxRY

Childing objects is an easy way to get cool effects. Since my child lights were ever moving forward in their forward direction, and the parent is always rotating, it gave a fascinating, yet simple to implement effect with very little effort, and no math involved.

Ideas for Future Development

There is no winning with pride.

Once you destroy all the lights you have destroyed yourself. I would add a blackout. There is no winning with pride.

My brother suggested particle effect moving in towards the center light so the player has a feeling that they can move into the light – I wonder if these effects are instead shadows that only get destroyed when they touch the light.

He also wanted a way to pick up and throw objects to make it easier to destroy things. That is also a good idea, but I’d be sure to keep the free form physics too. Most games like this one limit your physics capability to grabbing the object and then moving, but I really liked the free form feel of these blocks. But it would also be fun to pick them up and throw them.

My friend suggested that the blocks could be important statues or books that the player is destroying. I like that idea. Especially the statue idea. In the game world, they don’t even have to be anyone the player recognizes as important. But statues are difficult and expensive to make. Which means they are only made for/of “important” people. Destroying statues is disrespectful to religions, cultures, nations, and your mom. It’s prideful. That’s why I like the idea: giving the shadow his own deadly pride. In pride no one wins: so I’d be careful to carry on the theme of mutual destruction.

Experimental Games

Making “The Dangerous Unknown”

Go here to download and play the dangerous unknown. 

The dangerous unknown is an experimental twist on hidden object games. I made this game concept in less than hour.

Inspiration

Theme: Hidden Object with a Twist

I literally only had about an hour to make this game, but previously I had brainstormed some simple ideas. A common theme arose: what if the object you are locating bites back? It’s almost like the game doesn’t want the player to play: because the player gets punished for doing the only thing they can: find objects.

Development Journey

I knew the game would only play with player feedback, so I set out to implement the simplest of mechanics (tapping on an object to “find” it) and then implemented audio and visual feedback.

The entire game concept is a simple 2D orthographic camera, some UI elements, and I had the concept made: a flat map with the objects on top, which switch to a “found” texture, apply blood splatter to the screen momentarily, and plays one of two pain sounds.

Cool Things I Learned

“Code doesn’t always have to pretty, but it always has to get the job done.”

-Nancy Newren, Experimental Gameplay Engineer

The first thing I learned is that I have gotten a lot faster at prototyping. It’s certainly not my best work or my best concept, but knowing I had an hour I made deterministic engineering decisions to not architect a game that I could build on, but rather chose engineering design that would enable me to make the game work. I cut decisions like modularity and optimization, and opted for simplicity. I think it’s important in development to be cognizant of best practices and to know how optimize and make code modular, but to also be aware of deadlines and all important feature richness. Code doesn’t always have to pretty, but it always has to get the job done.

As I mention frequently I love designing games that can be played without explanation. So I had a friend in front of a class play my game. From the first “bite” the entire class jumped. I think that was the most enjoyable part to me. A feeling of being pranked prevailed. It was fun. And not just for me. It was also interesting to tap on these objects and see and listen to the feedback.

But even though the game was simple, I still learned some simple things. First: it didn’t read like the player was being hurt, it felt more like the pain sound was coming from the squished spiders. To resolve this I think a squish sound that is layered with the pain sound would help. Also, it would be good if the player didn’t necessarily get hurt each time. That way the player associates the squish sound with the spider, so the pain audio must be coming from a different source. Finally, I would also stagger the audio so they don’t play at the same time, though they could still overlap. This would increase the ability of the player to separate the meaning of the different audio.

To make it clearer that it is the player that is taking on pain is a border located blood splatter: instead of having the blood splatter cover the center of the screen, have red along the borders. The intensity and amount of red then can reflect the amount of pain the avatar is feeling. This plays well in other games this way and I think would translate well.

Also, I had to google blood splatter again as the stuff I had wasn’t a good fit for this game. If you don’t have a strong stomach, don’t google “blood splatter.” Just saying.

Ideas for Future Development

Found object games are typically played as static images and you located images within the image, but I think they would be more interesting if they were almost 3D: A “static” image with moving objects that you are searching for on the screen. This would add life to the game and make for more interesting gameplay as not all the objects may be visible all the time. This could potentially add to frustration as well. But adding things like timers, or find X when there are Y (where X is of course < Y), could dissipate expectations of finding all the objects.

I would really play on the jump scare, but keep it fun. I’m not personally a huge fan or horror, but I like a good scare and Half Life will forever be one of my all-time favorites. But I think the buildup of the scare and the buildup of a joke are similar. I spoke with Jose Zagal about wanting to keep the jump scare fun and he mentioned these similarities and how it’s a buildup: you build up to the punch-line or the scare. You do it again. And then sometimes you have a relief instead: in terms of horror this would be the audience thinking that a monster is about to attack but it turns out to be a cute cuddly kitten. The buildup of anticipation is what creates the pay-off of the scare/punch-line.

I particularly had the idea of a two level puzzle for this game: you are using your finger to squish spiders, but that can back fire, so if you find a different object to squish them with you might have some better luck. This is where the buildup comes from. There’s quite a bit of tension in the game design for a game like this: as a designer you need to keep the game predictable enough that the player can play the game, but not so predictable that there isn’t any challenge or surprise to it. There is also the biggest source of frustration for a puzzle gamer: knowing what you need to do and not being able to do it. It’s why I rage-quit The Turing Test. With this kind of puzzle game though, which would be building up jump-scare tension, it adds an additional layer of tension: that is player expectations of what should happen and whether what does occur fits within the boundaries of what the player would accept. It’s not always easy to tune all of these variables, but if you do it right it can be a very enjoyable experience for the player, even while they’re screaming.

Cool Stuff!, Game Dev Adventures!

MY FAVORITE SEASON! (Ph.D. Year 1, Week 5)

TLDR:

I wrote a very rough draft for the AISL grant. Narrowed down research questions and aims for systematic review along with a pretty comprehensive list of keywords and databases to search. I need to get the AISL proposal written up and fast. The deadline is next week and I need to somehow fit that in with my course load. Where has September gone? On the bright side, it’s officially my favorite season and my husband and I just passed our half-year wedding anniversary.

The Full Story:

Accomplishments

It’s officially my favorite season! YEAH AUTUMN! Pumpkins, cute jackets and boots, and bring on the hot chocolate! My husband and I just passed our six-month anniversary. (We’re not very good at celebrating on specific days, but we do celebrate!). We started our marriage with his favorite season — we married on the spring equinox — and now we get to celebrate the rest of our first year kicking it off with my favorite season. I picked a good wedding day. 

Last week Rogelio made me aware of the NSF’s AISL program and potential funding. AISL is “Advancing Informal STEM Learning” which is right up my games ally! He asked me to write up a 1.5-page draft proposal. We first have to compete with others from the University of Utah (each university can only submit three proposals for AISL funding). It’s final is due next week on Wednesday, Oct 2nd! Wish us luck.

With the help of my advisor, Rogelio, I narrowed down my systematic review questions, created aims, and with the help of others from the QED lab, I now also have a pretty comprehensive list of databases to search and keywords to search on. (Thanks QED lab!)

What’s next

Write up a hero narrative for the AISL. Get all my notes from the systematic review all in one place (they are a bit of everywhere right now). Somehow fit in my coursework and study for my upcoming midterms.

Roadblocks

I somehow have to fit writing up the AISL and do my research amongst many large projects from my courses. I can see now why taking three courses, two seminars, and doing research is a bit much. I am definitely feeling burnout. Mostly because one of my courses workload (just one) ate my weekend. 😦

 

Game Dev Adventures!

Down to Brass Tacks (Ph.D. Year 1, Week 4)

TLDR:

This week I got down to brass tacks (which idiom no one knows the origin of): I began an application for outside funding, and started a list of research questions to use for a systematic review. I further refined my research interests which is almost ready to be shared on the QED lab page.

The Full Story:

Accomplishments

I officially changed my name! I am now Nancy N. Blackburn. Hooray!

I have a list of several systematic review questions.

I started a dreaded application for outside funding. (They are a lot of work!)

What’s next

Do a search in the current literature to see what literary reviews have already been compiled and use that data to select a research question to move forward on.

Continue to fill out my applications for grants.

Finish my QED bio and get it published.

Roadblocks

Feeling discouraged about my applications for outside funding. The competition is stiff and while I feel that I am deserving I am definitely wondering how I “prove” my value. 

Game Dev Adventures!, Ludology

The Plan and Burnout (Ph.D. Year 1, Week 2 & 3)

TLDR:

Finished semester plan. Main two research goals are to apply for outside funding and  write a systematic review.

This week I’ll create a set of research questions for a systematic review and begin applying for outside funding.

The Full Story:

Accomplishments

I have been reading meta papers and looking at different ways to read and write different kinds of research papers. I have decided this semester to focus on writing a systematic review in the educational games/intelligent tutoring systems area.

I also shared several of the games I made in 24-48 hours with my lab and discussed the design ideas and purpose behind each. It was a good review to me. My chosen area in games is for pedagogical reasons, however games have purpose far beyond just entertainment and education.

It’s one of the other things I did this past week was defending the rigor of games research. I have come across several researchers who use game terminology without actually understanding the field of games. It is particularly important to note that what many researchers have called “game design theory” is actually gamification. Without proper understanding of the difference of game design and gamification, the application of these principles can actually backfire and undermine the overall purpose of the application as a whole. 

Two books I am enjoying delving into are Dan Norman’s The Design of Everyday Things, and Level Up! The Guide to Great Video Game Design by Scott Rogers. Part of what I want to do as part of my Ph.D. is to define and further develop design principles for learning games.

Something I realized 2.5 weeks in is that if I don’t take time between research and coursework projects to work on personal & family goals then I don’t make progress my personal or family goals. The thing is research and school is that those things can balloon and take up all your time. It’s important to set appropriate boundaries for everything and not allow those things to consume your life unknowingly. With this in mind I was able to start making progress on personal and family goals as well which has made me feel better about my life overall since I am not ignoring important aspects of myself.

Finally, I finished my semester plan and have a clearly defined path to accomplish my goals this semester.

What’s next

Create a set of research questions for a systematic review.

Begin applying for outside funding.

Roadblocks

Adhering to my scheduled time blocks to accomplish different tasks. Issues here are: under/over estimating (mostly under) time it takes to accomplish tasks, unplanned activities (such as having to spend an extra hour getting somewhere, forgetting lunch, etc.), and burnout. The burnout bit is an issue for me when I’m working against a deadline and I’m sick of doing the task in front of me.

I think I have a solution, by switching up tasks, going for walks, taking time to eat, relaxing about perfectionism (which has been a big thing for me), but when you have to get something done and you need all the time you have been given to accomplish it burnout sets in…

This semester has also been a lot heavier on the reading/analysis then expected and not so much on math and programming. I have done little programming and not in any way that I truly enjoy, and I don’t have time to make games, which makes me sad. So yeah, burn out is an issue.

Game Dev Adventures!

Ph.D. Year 1, Week 1 – Starting a Journey, GBA Workshop

TLDR:

I survived my first week of my phd, read lots of papers, attended the first ever GBA workshop at which I met lots of interesting academics, industry professionals, and peers with similar research interests, and then slept a lot (#TravelWipesMeOut).

This week I will be writing up my Ph.D. overall goals and coming up with a semester research plan. (Plus of course my coursework, but that is implied.)

A roadblock would be the need for some read/want-to-read research paper organization system suggestions, and just waiting on research papers from my advisor and contact information for people at the GBA workshop.

The Full Story:

This past week, starting 2019-08-19, I began my long journey to doctorate at the University of Utah in the School of Computing. My Ph.D. is in Computing on the HCC, Human Centered Computing, track, with a research emphasis in educational games. I started the week by attending my courses and ended the week by attending the first of its kind, GBA conference at the University of Minnesota, which made for a great start to my professional academic career, and made me a little behind in my coursework. Aw, the life of a Ph.D. Student.

As first weeks go, it was very exciting, both on the new and exciting, and scary and near panic inducing ends. For instance, because of funding and for personal reasons I am taking a more course-heavy load than typical: in all I have five courses, with one being for my research and one a required seminar for all fellowship Ph.D.s in the school of computing. As a gameplay programmer enrolled in four cs courses I was a bit taken aback that only 1.5 of my courses will be requiring programming! For the most part I will be reading and analyzing research papers in my and related fields, studying from textbooks, a little bit of math, a little bit of programming, and adjusting as best I can to Ph.D. student life.

So far so good.

I have been warned repeatedly of the cycle of a Ph.D. journey, with all its highs and lows, and I believe I have gone through the cycle multiple times this week ending on a bit of a high note.

So far so good… 😉

GBA Workshop

The GBA Workshop was very well organized, especially considering it was the first one ever. There was research presented by people in academia (from the graduate to tenured professor positions) and industry, from different disciplines (from I/O psychology to cs), and different countries (mostly U.S. and European). It was great to mingle with people from so many different backgrounds.

My favorite presentation was by a Ph.D. student at Northeastern University, Chaima Jemmali, entitled “Insights on Debugging Processes of Beginner Programmers in an Educational Puzzle Game.” Her presentation was the only one that directly correlated to the kind of research and work I want to do with my background and degrees. Specifically, she designed and programmed the game by herself and then tested it, analyzed the results, refined her project, and presented her results: a validation for using games to teach programming. I spoke with her briefly after the conference (she didn’t speak until near the end) and I hope to get to speak with her more in the future.

Accomplishments

I didn’t give up! As an industry professional turned academic I didn’t believe my experience was valued in academia, but advise from my advisor was that I should wear my experience as a badge of honor, which I did. I found that at the workshop I attended my industry experience was highly valued. I had important experience to share that all could learn and benefit from.

My main goal at the GBA workshop was to network with my peers in multiple disciplines. The conference was very interdisciplinary. I met people from I/O psychology, game design, educational games, and the social sciences, as well as people from multiple different countries (majority representation from the U.S. and Europe from my limited sample pool). There were also industry and academic professionals as well as other graduate students, both MS and Ph.D.s. Again following the advice of my advisor, I never shied away from a conversation from my fellow students (my career-stage peers), nor from beginning or experienced career and academic professionals. It was a very good first experience networking in as an academic. I’d say I killed it. Perhaps in the future I’ll share some networking tips (both that I received and that I used from experience networking professionally).

I managed to stay afloat in course-work by waking up early in my second week to do catch-up.

I have read and listened to several research papers in my broader field of research interest.

What’s next

The major two goals I have this week are:

  • Write down my Ph.D. Goal – I can revisit/revise this idea each semester
  • Write down my semester plan.

The rest of these will be part of my semester plan, some to be accomplished this week

  • Create a list of 5-7 academic/professional conferences and workshops that are related to my field. Plan to attend 1-3 of them in the coming year.
  • Start organizing/recording the papers I have been reading so I can keep track of the important things I have read and ideas for future.
  • Discuss paper ideas with my advisor. Pick one of the paper ideas and begin background and supporting paper research.
  • Start preliminary process of applying for two grants that I qualify for.
  • Start reading papers directly related to my research interests.

Roadblocks

I have been directed to two different research paper managers – I would like some guidance on organization strategies so I can track important papers.

I am also waiting on some research papers from my adviser to begin reading research related to my areas of interest.

I am awaiting contact information for people at the GBA workshop. I brought my business cards, but some of the people I spoke with didn’t have one of their own and promised to contact me. I’ll follow up once I have their contact information from the workshop organizer.

EAE 6320-001 GameEngII Game Engine Project, Game Dev Adventures!

Final Project: Matching Game!

My FINAL game: simple one-click download below, unzip, play, enjoy!

NancyNewren_ExampleGame FinalProject!

What’s new
It’s a game!

Controls
Main object: Use arrow keys to move the 3D object to its matching card.

About the Game

Okay, so it’s not pretty, but sometimes you just need to get to proof of concept; beautifying the game can come later.

When I was making educational games for Waterford Research Institute I made a lot of mini games for preK curriculum: letter/word association, number recoginition, letter matching, and even an ethics game. I really enjoyed making these simple-to-play games for 4-5 year olds. They were fun enough that even my older play testers (20-year-olds) liked them. However I never got to make a shape matching game. But now I have!

This was fun to make, especially since it was in my engine, but slightly more complicated than I anticipated.

The first thing was paring down the game to its minimum essentials: for instance having animations wouldn’t matter if I didn’t have a game first. So what was essential? Well having four objects with four matching cards. Being able to detect a right and wrong guess, and upon such guesses having a response (moving onto the next object for the right guess, feedback to let you know it was wrong otherwise). Once that was determined I simply needed to set up the graphics objects and then create the basic right/wrong logic with a simple collision detection.

Everything we needed to draw to screen was done: but any game logic I had to write, though admittedly we had previously written the player controls and the essential game loop code (like the update functions in Unity) were already supplied previous to this final assignment.

I don’t think I had noticed previously how heavily a game relies on its graphics components though. Without those, regardless of any clever logic you may have written, you don’t have much of a game. And I think it took up a majority of my time to find, create, edit, and import into my engine all the assets.

Honestly I think the most difficult thing to do was just tracking all the different assets. In game engines such as Unreal and Unity it is easier to track them I think because there are prefabs and the editor to help you create your arrays of assets. However creating the c3DObjects class to manage all things for my 3D objects (mesh, effect, texture, transform, speed, and even id) made it much simpler to program the game. When I was trying to detect whether or not an object matched a card all I had to do was give them both the same id in their c3DObject instance. Which brings up something: the cards, though flat, were still meshes. As I didn’t want them drawn like UIElements, but to interact with the objects in world space, I had them as 3DObjects. The only thing I’d add to the engine would be a UIElement class (akin to the 3DObjects class, but fancier since I’d need to track scaling vs. anchoring, etc.), and the idea of prefabs. It’d really make things easier to track with those things in place. Well, I’d also add an animation project to make animations simpler too.

The only time that I wished I’d done something different in previous assignments was the way I stored graphics elements in my game logic. Before even started coding the game I did some refractoring in my game logic to make it easier to track my graphics elements.

I created two effects for right and wrong guesses that tint and make the cards transparent. Then it was a simple matter of just swapping out the regular effect (which everything 3D was drawn with) with a right/wrong effect. That decision also made it easy to animate the ending flash as I just swapped out right and regular effects. If I’d passed the color to the effect to draw right/wrong it would have affected all my objects, and not just the one I wanted to draw.

The other difficulty was randomizing the order of everything while keeping track of them! picking four (of seven) random objects to be the match objects, making sure the four card were the four matching ones, and then drawing the four matching cards in a random order on screen. Here’s how I chose my random objects:

The collision was interesting. I didn’t do what fancy game engines do: detect whether the bounding boxes have collided. What I did was much, much simpler! Knowing that my local meshes origins were all at the origin, this meant that their position were all in world space. And as I didn’t care when their boundaries collided, but rather when their local origins were within a certain range of each other, all I needed to do was check to see if a matching object was within a certain distance of the card. To further optimize, as square roots are inefficient, I only checked the distance squared, I only checked the player object against cards that hadn’t been matched, and didn’t check for collisions at any time when the player movemnet input was deactivated. I added the DistanceSquared method to the Math::sVector class.

float distSquared = eae6320::Math::DistanceSquared(i_pObj1->m_rigidBodyState.PredictFuturePosition(i_elapsedSecondCount_sinceLastUpdate), i_pObj2->m_rigidBodyState.PredictFuturePosition(i_elapsedSecondCount_sinceLastUpdate));

return distSquared <= m_distAmountSquared;

The last thing I did was add in the sprite images upon a correct solution. This had multiple purposes: 1) it hid the no longer drawn match object, 2) It hid the sudden movement of the next object to match to the starting player position, and 3) It gave some fun, and funny, feedback to the player that they are on the right track.

If I had had more time (I did this all in about about 15-20 hours), I would have added:

  1. Movement animations
    1. For instance: Locking the “match” object to the center of the card before checking for a match, then moving it back to the beginning
  2. Setting boundaries the player can’t move outside of
  3. Beautifying the game: better match object models and cards, a better background too
  4. Add fun audio
  5. I also really wanted to do lighting

I enjoyed how it turned out though, and so did my play testers. 🙂

What I learned this semester

What I think the goal of the assignments were

I think the most important goal of the assignments was to teach us what good interfaces can do for us. For instance once we set up our one interface which behind the scenes dealt with our different platforms, we didn’t write any platform dependent code. That is very cool! We didn’t have to think about what each platform might need, instead we only connected with our interfaces and let the interfaces do their job.

We learned about building good asset pipelines. At the beginning we only had shaders, but by the end we had textures, meshes, and shaders. We separated out our algorithms from the data. I really liked this (especially creating the binary files!). Doing this makes it much faster and easier to change our assets as data is easier to update than code, and doesn’t require a recompile! We only need the built asset and that can plug-in to our code.

Another big point was to write code that is human readable, understandable, and easy to debug. Ultimately, whether it is someone else or yourself, someone is going to have to read your code to understand how to code against/interface it. If the programmer can’t understand and debug your code (which is really sad when you’re the programmer in your own code and you can’t do this!)  they’re just going to have to either spend a long time to understand it or are going to have to rewrite it, which if it’s a large amount of code is going to take a lot of time. But if you make it human understandable then they should understand quickly what is being done in the code and should be able to code/interface with it quickly, which is very important!

What I got out of this class

I learned so much this semester. I used to always be scared whenever I had to set up build dependencies and references, what the differences were, and why they mattered. I never felt like I could do it on my own. But I don’t feel afraid anymore! In fact, I learned it well enough that I was able to explain to someone else the differences and help him troubleshoot his code, and to recognize when another of my classmates had done it incorrectly in his own code. I say that not to point out that he did something wrong, as we all make mistakes, but that I know enough to know when it is done incorrectly now. And that is also not to say that it’s always easy, but I feel confident that I can figure it out, and to NOT PANIC when I get linker errors! J

I learned…

A lot about graphics for a non-graphics class (I actually understand, on a very high-level, what the graphics card does now).

A more-different way to essentially have shared pointers without the overhead of shared pointers through reference counting.

Oooh, after class one day I asked JP about how shaders do absolute value so quick and so I became aware of the intrinsic functions of the graphics card.

Also, D3D has different debug output in VS than OpenGL.

The difference between handles and pointers.

A side effect of all that we did in the code for me was using the c11 standard as I’ve never worked on projects before that used it (we were in the dark ages I suppose 😉 ).

The, unfortunately short, discussion we had about lighting was very interesting. I hadn’t thought about digital lighting as taking away light, but it made sense.

I also think I would enjoy doing graphics more than I thought I would. Every time we got into talking about graphics I got really excited. The math is pretty basic, but can also be really interesting. I really thought I would hate the discussion on lighting, but I found it fascinating.

My thoughts on good engineering architecture and design

I usually like to try to play the line between very structured and “design as you go”. However I knew there would be a lot of refractoring from assignment to assignment and there’s nothing I hate more than having to undo complicated architecture, and since I also didn’t know what the end goal was, I purposely chose to play on the side of “design as I go.” Otherwise I would have drawn out a more architectured structure. There was only one assignment that I wished I would have architected more in a previous assignment, but even in that case my friend who chose more architecture in the previous assignment only finished about an hour before me, and I know he spent more time making the architecture in the first place. So it was basically a wash.

I’ll say this about good architecture: while I was programming my game I made a decision early on to have a GetMatchObject(const unsigned int i_index) and GetCard(const unsigned int i_index) functions. This made it so that later on when I changed how I retrieved cards I only had to change it in one place: my “interface” function.

A good software architecture allows for flexibility in adding new items to the code, but isn’t so abstract and complicated that it is unclear what the interfaces are good for. I.E. it’s easy to read, understand, and debug, and allows for quick and easy iterations.

A good design will be platform independent: so that you only have to write code once! A bad design will have multiple files with only small changes in each for every platform (whether the platform is OSes, websites, or databases). A good design will allow for quick creation of new types that fit into the same interface. A bad design will require a new object or interface for each new type. A good design is faster to refractor. A bad design requires gutting of the interior for even small changes. On the other hand, a good design also isn’t over-architectured either. For instance, there is no need to create a reusable interface (no matter how neat) if you are only ever going to have one type that uses that interface. Good design is about being aware of the parts of code that need to be reusable, what needs to be able to be interfaced, and what can be done top-down as it were, because it’s not going to be used more than the once.

Acknowledgements

Thanks to Zeno for letting me bounce ideas off of him, and my Dad for proofing my write-up.

Many thanks also to my play testers who really just had fun playing: Zeno Saviour, Monika and Erik Tolman, my sister Deborah, and my brother Zeke (who tested it on linux with wine and it worked!).