Brain*Mart: Instantiating UI and Berserking Zombies

So last time I discussed a few goals I would like to reach for the project:
1. Clean up the code.
2. Add some art.
3. Create a demo.
4. click-able (mouse) controls.
5. Audio.
6. Transition zombie thought clouds to the UI instead of game-space.

I was not insanely productive.

Possibly because I expected it to be the most challenging, I focused on number 6, Turn the world-space thought cloud UI into actual UI elements on Canvas. This would solve a few issues--such as the thought clouds rotating with the zombie as it changed directions, as well as, looking kind of odd floating feet above the rest of the world.

Before I get into the details of the latest updates, here's a quick video showing off a few of the accomplishments since the last update:

So I needed a UI element that translated world-space coordinates to 2D coordinates on the canvas. Within five minutes of searching, I found a great video on Youtube that showed a simple way to achieve this:

https://www.youtube.com/watch?v=0bvDmqqMXcA.

Following along, I was able to get a text object to follow the player, and later a zombie. I was super excited and imagined I had achieved an early success.

BUT, because my zombies are instantiated, that means I have to instantiate the UI elements too. Not only do they need to be instantiated, but I have to be able to turn them on and off, as well as adjust colors. And since they were on the UI canvas, and not children of the zombie--I had to find them, reference them, and get access to their scripts. Because I wasn't using childed objects, I had to rewrite almost every script to gain access to the UI elements in the canvas. I feel like my GetComponent references resemble that of an old telephone switchboard being operated by a chimpanzee.

It took me the whole week of working a few hours a night. And it had the wonderful result of setting me back on my first objective (cleaning up the code). It's been a real joy figuring this all out.

Once I succeeded, it was a wonderful feeling. Though I did create some annoying bugs in several other scripts.

But the more exciting news for me was figuring out the Berserk UI feature. This has been my largest worry. I knew since I originally conceived this idea, years ago, I wanted zombies to get so hungry that they went Berserk and tried to eat the people in the store. And I knew I wanted to illustrate that timer with a thought cloud that slowly filled up with a color (red in my case). But I didn't have a clue how to incorporate it. Luckily, I found another helpful video:

https://www.youtube.com/watch?v=4fYd6-RFp_M.

The script looked really simple, so I skipped to copying and trying to make it work myself. FAIL. Only by watching the video did I realize that Unity had handy sprite fill options in the image component. It's almost too easy to use, but I quickly got my Berserk Visual Timer up and running, making the project feel like it's really coming along.

After that, I needed a break--finally beating Halo 3 and getting pretty far into Fable. Xbox Game Pass is a very dangerous distractor--but playing great games is also really inspiring.

I've since created a functioning Berserk Mode that causes the zombie to flash red and chase the player at an increased speed. If the player doesn't feed the zombie before the berserk mode is over, the zombie simply leaves.

Brain*Mart: On the Road to Playable Demo

Didn't make huge progress this week. I may, or may not, have been a little distracted by playing a Vanilla World of Warcraft server. I find the game really inspiring--while it also steals my free time, thus preventing me from acting on the inspiration. Point is--I didn't make the leaps and bounds I had accomplished on the first week.

I did do a few things:

1. Level Building: I put together an environment. It's about three screen-sizes squared--not so big that you get lost, but does require some work moving around and getting to the zombies. The level also includes a sidewalk. It's inaccessible to the player through MathF.Clamp. Anyway, the zombies come in off the street and then leave the same way. Speaking of...

2. Sliding Door: To create an entrance for the zombies, I decided to make a sliding door with four panels. Just for funsies. But it turned out more challenging than I expected. I think it's because the whole time I was writing the code, I kept thinking up future problems. So I spent a lot of time trying to solve problems that didn't exist yet. 20 lines of code later and I was so lost I didn't know what to do. So I started from scratch and it works.

3. Zombie Spawner -- This was essential. I needed a way to "design" the game without having to code every level. So the zombie spawner does more than just instantiate zombies. I have a max amount of zombies that can spawn ever, which can be overridden by clicking the "Unlimited" bool to true. I also have a limit on how many zombies can be in the scene at one time, as well as, how much time must pass before the next zombie can spawn.

I'm still contemplating on ways to mix it up. Should I create waves? Should I designate which brain each zombie should have? Should I set different berserk time lengths? Should it be random and influenced by chosen difficulty?

Definitely worth testing.

4. Nav Route Selector -- Gave me a little trouble. I have game objects I call "Routes". Each route has a list of "Nav Points". I fill the nav points with trigger boxes that serve to both be a target vector as well as set the zombie on a new target when it's reached.

Here's a video of a quick playthrough:

My next goals:

1. Clean up my code. I've been listening to Unity scripting tutorials at work and they advise keeping scripts short and focused. I agree--as my scripts have become a bit unruly. That's mostly from discovering what I need the script to do as I write it. Since I see how everything is working as a whole, I can hopefully streamline a lot of it.

2. Stand-in art. I want to get some 2D art for the player and zombies in the game. I feel as I start testing, that will make the experience more enjoyable for players. I think the environment can be more abstract, but seeing pills from Dr. Mario walk around is probably off-putting.

3. Create a demo. I want to get people playing this game asap. It's essentially playable--but I would like to have: a. A Menu. B. Tutorial--playable--to explain the mechanics. C. End screen with player score.

4. Click Controls. I ultimately see this being on mobile, so I need to start creating a control scheme that translates easily into touch. Hopefully I could do that before finishing a demo.

5. Stretch goal--some audio.

6. OH, and I almost forgot. I feel the floating brain cards and zombie clouds are little--weird. having them float about in 3D space isn't quite working for me. I'm considering making them UI elements on the 2D canvas. I found a video on how to accomplish that, so I want to play around with how that affects the experience.

Brain*Mart: Collecting Brains and Feeding Zombies

I had really intended to do a post with the Brain*Mart's Game Design Document.

That didn't happen.

Maybe later.

But the reasoning is because of how quickly I've made progress on the prototype. Unlike with FP$, where I spent much of my time learning different components to Unity that would allow me to achieve my project--while also making sure it was structured to work properly, I've been able to push through quickly, easily adding each feature with minimal hiccup.

Though I do wonder if there's more efficient ways to handle a few things.

Here's a video of how it's coming along:

 
1. I got the player controller up and running. No problem, given that I just steal the script from Unity's Tutorial. (Is that considered poor form?)

2. I created a Brain Asset and can change its color based on a Switch Statement. The colors will need to match in order for the player to feed a zombie a brain.

3. I have "Cards" that hide which brain they contain. When the player nears the card, it reveals the brain (color) it's hiding. By pressing space, the player picks up the brain in their inventory--which is shown in the upper right corner. This creates a "memory match" aspect to the game.

4. The zombie has a thought cloud that is blank. When the player nears it, the zombie's desired brain (color) appears--and disappears when the player leaves the vicinity. This adds to the memory match aspect.  Pressing space, if the player has the matching brain color, removes the brain from the player's inventory and satisfies the zombie's hunger--causing it to vacate the premises.

So far, the project is running well. I want to create a zombie generator that will create zombies for the player to serve. I want to include zombie amount limitations and a random timer to space out the zombies.

My hope is to have a good look project within about three months. Given the progress within the first week--I don't think that's too out of scope.

Moving On to Something New

I've decided to move on from FP$. For over five months I have been working on this project in my spare time. The process has taught me a ton about C# and Unity. Every new thing learned inspires 100 ideas. But this project is taking a long to complete and the end result...well I don't want to say it's not worth it, but it's not fully representative of the games I want to make. By that, I mean narrative driven games.

I say this, but I'm about to pitch my next project--which is minimal narrative value.

Maybe.

So RIP FP$.

...Wait. No.

I'm not killing it. Just putting it on ice for now.

Soooo, sweet dreams FP$. Until we play again.

Now, onto my next idea.

Brain*Mart!

BrainMart is an idea I developed when I first started working at Best Buy years ago. It’s based around meeting customers, discovering their wants, and then providing that want. But to be silly, it features zombies and brains.

As a stretch goal, I would like to explore relationships with Co-workers. But we’ll see.

My hope is to create a project that is Android Store Ready within about three months. To achieve that:

The first month will be devoted to building the systems. I want a fully playable prototype by the end of the first month.. The second month will be about adding in assets and making the project presentable. The third month will be about cleaning up the project--finding areas for improvement. I hope it works. See you at the grand opening! (That was some weak retail humor for you.)

FP$ is Playable (Via Web Browser)

Please try the game!!

Play FP$

Menus, Audio, and Transitions--nearly a complete playthrough!

Two whole months since an update on here. I'd feel lazy if I hadn't made so much progress on the project.

Well...not as much as I wanted. I've been a little distracted by another idea--but it's not time for that.

I'm going to go over a few things I've added and then provide a playthrough video.

1.  The project can now be played from beginning to end. I have a main menu with a clickable button that takes you to the opening (doom level/apartment). Once objectives are completed, you are then taken to shopping level.

2.  There are sound effects and background music. It's royalty free stand-in, but I wanted some basic audio in-place.

3.  You will see some fade-in and fade-out transitions as well as some "cinematic" elements as the game switches between the "doom level" and the apartment. This required me using the "Animator" in Unity--which is kinda awesome, and would have solved plenty of issues I suffered through in other projects. I want to learn much more about its effective use.

4.  The apartment level has been updated, hopefully to feel more like an apartment layout. But I have also added some "objectives" and directions to guide the player. It's all stand-in for the moment.

5. I created a list of boolens to confirm whether the player had collected the required products. Once all have been collected, the game will allow the player to check out. Right now, it just logs to the console "You Win", but I hope to implement a simple animation of the player's gun disappearing, just as it appeared.

I'd like to create the ending and then post the game online (hopefully) to allow for playtesting and feedback. I also want to redesign the shopping level to create more challenge variety. Then ultimately, update the graphics.  Of course, by update I simply mean change. I'm considering going for a PS1 Parappa the Rapper look. Or, at the very least, low-poly and bright colors.

Hope to have more soon!

FP$: Sparks, Tracers, and Proxy Art...

I just realized it's been a whole month since I've posted. But that doesn't mean I haven't been working.

...It does imply it though...

Honestly, I've had so few obstacles with some of the tasks I've attempted, it just didn't feel important to update. It wasn't a lot of work though--especially since I had a family vacation last week.

First, I added three more bad guys to chase me around my "Doom Level". They zip off to different corners of the map when shot three times, just like they should.

Second, I added a particle effect for the "bullet" striking an object. Just some sparks. It took some time making sense of the particle system, but it works.

 
I also included a tracer bullet.

I'm going to expand on that a little...

I originally conceived the tracer bullet as a solid yellow capsule the size of...well, a bullet. But with the frame rate, the bullet traveled too fast to be seen. Slowing the bullet so that it was more visible desynchronized it too much with the sparks and "hit" from the raycast. So the bullet was landing several frames after the sparks had emitted.

I decided that it wasn't really important and moved on. But while driving to New York, it hit me: tracers are so visible because they leave a long trail of light. DOH! I immediately made the bullet longer and it was instantly visible!

Of course, shooting the tracer bullet required attaching a rigidbody and my "shot mover" script to send it flying. It also needed a collider so that I could apply the "destroy on impact" script.

And that's when it got weird.

The tracer stopped appearing. Since the "center" of the object defines it's point in 3D space, it was already colliding with my player as soon as it instantiated; essentially destroying itself right as it appeared.

I tried moving the spawn location, but that looked odd. So I experimented with shortening the tracer bullet. I found a healthy length that was both visible but not hitting the player as soon as it instantiated. It worked great while stationary.

While. Stationary.

As soon as I started moving forward, the tracers stopped appearing again. Frustrated, I came up with a solution! I will make a smaller bullet and child the longer tracer to it! This worked!

Until it hit a wall.

Every now and then, the tracer bullets would launch at a funny angle or hit a wall weird, and suddenly they would begin to spin in space, like cheap fire works in slow motion. For about five minutes I considered if this was an acceptable glitch.

I decided it wasn't.

My ultimate solution, I removed the collision. But this means it cannot destroy itself when it makes contact with an object. Luckily, the tracer moves fast enough that it's hard to tell (impossible, really) that it continues to move through objects and walls that I'm shooting. There's a short life-span on it anyway.

I'm satisfied.

So, third, I feel like I'm very close to having a full experience--from beginning to end, though very rough. So I've decided to focus on creating that full experience:

1. Main Menu to Doom Level--
2. Doom Level zooms out to House--
3. Collecting shopping list and exit to Shopping Level--
4. "Check out" and complete the level when everything is collected.

As my next step in that process, I began designing a basic layout for the House.

Nothing fancy yet, just a functional space.

Fourth--and finally, I started working on the TV that will render the Doom Level Camera as we zoom out, revealing the living room. I just finished sizing the render plane and adjusting the tiling; now I need to set a timer, switch between cameras, and create a smooth tracking shot.

Observe how the "Doom Level" is being played on a TV within the house level:

I'm really excited about getting this to work!

FP$: Menus and Nav Mesh

It's been a while...

I joined a Game Developer Group. As part of the group, we're supposed to perform "assignments." It's a neat idea, and fun. But with as little time as I have to work on projects, our current assignment has distracted me.

Also, my wife got me Hyrule Warriors for Switch with a shiny new Pro Controller...so that was also distracting.

No regrets...

But I am making progress with FP$! Since the core of the game is playable and functional, I wanted to start building the structure of the experience, from beginning to end. It's not The Last of Us, but I do consider it a story driven game.

I started with a main menu. I've never made one before, but got pretty far messing around with canvas. Still, I wasn't sure how to get my button to send me to the first level. I tried looking up a quick fix on Unity Answers...but it wasn't super helpful. I eventually watched 30 minutes of an hour long menu tutorial to find the 30 seconds I needed.

Now it works.

It's not beautiful, but it was only meant to be a functioning stand-in.

After pressing start, the player is supposed to be playing a classic Doom-styled game. So I made a simple, square level for the occasion.

I even downloaded classic Doom textures for my walls, floor, and ceiling--just for proxy art.

The idea is that the player will be roaming the halls, killing an endless wave of beasts while the camera tracks backward to reveal the Doom game being played on a TV screen.  I had to look up how I would project the player's real-time activity of playing the Doom-Clone while tracking backward to reveal a TV.

The answer was quite simple. Unity has a Render Texture that's simple to use. So simple, I started to play with it and found a 3D option on the renderer. I don't know what it means, nor could I get it to work. So for now it's a mystery. I don't need 3D projection for this project, but it would have been cool to figure out.

Next--I needed baddies to kill. That means Nav Mesh. I've worked with it before while making Rundead, but the work was mostly performed by another team member. I quickly baked a mesh and placed a Nav Mesh Agent in the project. It took me a few minutes and some Googling to get the Agent to chase the player, but sadly--it was walking through walls

I finally found a video by Brackeys that detailed my needs, and it was under 12 minutes long! But his process required me to use a special Nav Mesh Surface component. When I tried to apply it--there was no such component available. That's when I learned it has to be downloaded as an extra. So I spent some time doing that...

But even after following the tutorial, the agent was still walking through walls. As my kids crawled on me and my keyboard, I messed around in the Nav Mesh menus. Turns out I had to tell Nav Mesh not to navigate on non-walkable layers. Odd thing to not be a default...

Anyway--it works now.

I then used a tutorial to add health to the Agent, but instead of turning off the object--I just have it reappear at a "spawn" location. This way, each time the player "kills" an enemy, it simply reappears somewhere in the level. I do want to add in some death effects eventually.

The project is moving along and I'm learning new stuff each day!

FP$: A Playthrough -- Completing the Shopping List!

So here's a playthrough video of me collecting all items on the shopping list.

It's a bit long so I included a little music to help the time pass.

Let me know what you think!

FP$ -- Clean up on Aisle 7

Look at this mess! Who's going to clean it up? The employees of course!

But uh...I don't have any employees. Really not sure how to make any. But I know if I want to start testing this game I need product on the shelves. And it doesn't take long to make a mess of this place.

Sooo, I decided to create a simple clean up script.

When the game starts, every product detects its current transform location in the game world. It then checks to see if its transform location changes. When that happens, it starts a timer (that can be set in editor) and once that timer is up, the product zips back to its original location.

But uh...I had trouble.

See, I'm comfortable with Transforms (x,y,z locations in 3D space), but rotation is another thing. I mean, they use terms in Unity like Quaternion and Euler to describe and change rotation. I've Wikipedia'd both those terms and came out more confused than when I didn't know anything.

So while products were returning to their initial location, they were also returning at really strange angles. One even returned to its spot while spinning in space. It was kinda cool, in a trippy way--just not what I needed.

So I took my confusion onto Unity Answers and to my surprise, someone kindly answered. Their Username is Dolzen (not sure if it's polite to share). They gave me exactly what I needed to make the objects return to their spot, and at the right angle.

The Script:

And this is how it works:

Ultimately, I would like the items to return to shelves when the player isn't looking. I'm not 100% how that should work. But I would like an NPC Employee to be there to imply they put everything back. Maybe they can say something snarky to the player as well.

Now that I'm caught up on the progress of FP$, I need to start making more progress.

Changing Text Color and Updating the Shopping List

Yay! I had my collectables, my randomly generated shopping list, and my working raycast directed projectile. But I needed to keep track of items in the cart and compare them to the shopping list, then ultimately communicate that to the player through UI.

I thought it would be easy...

Ultimately, I would love the shopping list to be a piece of notebook paper with hand-written text. Each time you find something, it should "scratch" that item off the list. (Of course, my modern shopping experience is that I make shopping lists on my Phone and click a box to mark it off...hmmm...something to consider.) But for now, I just wanted the text to change color (to green) when the correct item fell into the cart.

Changing the font color was overly complicated. That's because I have two different scripts, one managing the shopping list and the other reading what items are in the cart. So I have to use .GetComponent<> quite often to reference lists, objects, properties, and call functions. Maybe I'll combine the two scripts to make things simpler.

But for now...

PSEUDO CODE!:

-When a GAME OBJECT enters the shopping cart box trigger:
   -Check if that GAME OBJECT is tagged as a "Product".
       -If yes:
               -Get items script with properties
               -Get item's "cost" property from that script.
               -Add that GAME OBJECT to the list "Items in the Cart"
               -Add that GAME OBJECT to the list "Items in Basket"
               -Update List
               -Update Cost
        
In actual code:

Update list is actually in another script. It's what I'm using to check whether or not the player has found an item on their shipping list. If what is in the cart matches what's on the list, it changes the font color to green. Because I was hopping between scripts so much, I got confused at first and was trying to change the font color of a GameObject instead of a UI Text Object. 

...I'm smarter now...

Here's the list updating in action!

 

I just want to say that this little demonstration, as simple and mundane as it may appear, was a rough week for me!

Firstly, I had a problem with the UI text disappearing. To make text change colors, I was creating a Public Color variable and setting the color in the editor. But when I ran the script, my text disappeared! All the code in Visual Studio showed no syntax errors and Unity showed no compiling errors...I just couldn't understand.

Then I found that all Color elements have an Alpha Layer Property (Transparency), and for some reason its default is 100% transparent. So when I turned it 100% opaque--guess what, there was my text!

But then I ran into another problem. My script was written so that when an object fell into the shopping cart, a function compared all items in the car to all items on the list. If a match was found, then the relevant UI element turned green (as demonstrated). But they wouldn't change back again once the object was removed.

I tried a few variations of if-else statements, but I kept running into the problem of turning all the text back to black.

I'll try to explain my mistake with pseudo code:

When Update List is Called--
   Cycle through each item on the shopping list
       For each item in the shopping cart, compare its Name to that of the current Shopping list item.
           If they match, turn its text to green.
           If they don't match, turn its text to black.

I was trying to turn the text black when an object fell out of the cart--but instead, it turned everything black. That's because when I checked for a Red item against a Red item, it turned the "Red" font green. But then it moved to the next object (let's say blue), and would check that blue object against the red. When it didn't match it would turn the "Red" font back to black.

After a few days and no immediately answers on Unity's forums, I ended up creating a Bool called "nowGreen". For each item in the list, I set the nowGreen to false. As the function checks each item, there's an else-if statement that only runs if nowGreen is false, which turns the text black. If the items match, it turns the font green and changes nowGreen to True--which prevents the line of code turning the font black from ever running.

So far it's worked well so far!

My next post should be a little shorter. It's about how we do a clean up on aisle 7. I'll explain how I finally received some amazing help on the Unity forums, as well as, realized my game is too easy!

If you made it this far, how about leaving a comment so I know you were here?

Generating a Shopping List

(Before I get started: there is some code from the game at the bottom, for those interested in reviewing and providing feedback!)

So with a my First-Person Controller and Projectile working...ahem...perfectly...hack (*sorry, fibbing dries out my throat), it was time to generate a shopping list for my FPS shopping simulator. It didn't go as smoothly as I anticipated.

A colleague is currently in school for video game development and wants to focus on UI. I asked if she would like to help on the shopping list element (which I would like to be much fancier than what I accomplished), until she can beef it up--I just wanted it working.

I decided to give the player 8 items to find.

...You know...because...

And I thought for replay, the items should be random. So I needed:
1. The Game needs to pick 8 items at random from a pool.
2. Generate a UI list on screen of those 8 randomly chosen items.
3. Calculate a budget for the player.
4. Keep tabs of the total cost of all items in the shopping cart and track whether we're staying in budget.

Look at all those items on the shelves!

Public Variables -- AMAZING!

I started by first creating 16 items. Until art is available, I made them solid colored cereal box sized objects and named them after their individual colors.



I then created a simple script to hold properties for each object so that I could utilize them within scripts. I think the properties are pretty self explanatory, unless you've never worked retail--then Sku might be confusing. It's usually just a number (different from the UPC) that represents the product within the retailer's database.

Such shopping carts

I forgot to mention. I also made a shopping cart. It's just sprites and invisible collision boxes. I also put a trigger box inside the cart to keep track of what items where falling inside of it. So it's on this trigger box that I decided to create my list.




To Generate my shopping list I created a list and placed every single shopping item's prefab into it, and then I created another list that would eventually become my shopping list. I used a For Loop to randomly pick 8 elements from my product pool and added them to my shopping list. I had to use .remove to take the chosen items out of the first list so they would not be accidentally chosen twice. I then set each item chosen to a UI Text object. It worked pretty flawlessly!

 Here's a brief sample of the script I used to create the list. You'll also see that I calculate a budget for the player. After the objects are chosen, I cycle through them and get all their prices. I add those prices up and multiply them by 1.10 to make the budget 110% of the cost of all the required; which can be adjusted if needed.

FPS -- First-Person Controller and Raycasting Woes

So, this project is a first-person shooter/grocery shopping sim. The player must explore a store, seek out listed items, and then shoot them off the shelves into their shopping cart. Obviously, the first thing I needed was a FPS controller and a form of shooting.

Raycasting is the way I went.

I struggled with getting the racycast/shooting to work as I'd like it. Not 100% satisfied, but it's functional enough to keep moving.

Unity comes with its own First-Person controller, but, for the sake of learning and practicing, I followed an online tutorial on creating a FPS controller from scratch. It's not as robust as the Unity provided option, but it still does more than I need for this Project.

Pretty sure this is the video I used:

According to the many videos I watched, FPS games do not have traveling bullets. Instead, a line/ray is shot/cast out from the camera until it connects with an object/collider: raycasting. The point where the ray makes contact will receive bullet damage instantly. I know games like Battlefield somehow account for bullet travel and bullet drop, but I couldn't find a clear answer on how to get this to cooperate with raycasting.

I did want projectile travel time and not the instant contact that raycasting provides. I'm not 100% sure why I insist on this, but my gut says it's the right path to follow. If testing proves otherwise, I'll happily change it.

Within the tutorial (which I followed on Unity's website) they have a ray cast from the camera. This ensures a centered hit. Then, a second ray is cast form the gun-muzzle to the exact hit point. I'm not going to mess up my code to show the errors I ran into with this--but I will bore you with great detail in text :D.

Firstly, once I had followed all tutorials to perfection(ish), I began to play around--firing pink lasers (raycasts) from gun-muzzle to centered contact-point. But then, seemingly random, the laser would fire backwards. I couldn't understand it. I adjusted code so that the laser did not disappear once fired and discovered that it didn't just fire backwards, but it was firing at my player-avatar's head!

Since I didn't want instant hits from raycasting, but rather a traveling object, I decided I would disable the raycast to avoid shooting myself. But then I noticed another problem, my trageting was no longer centered, it was off-center. This is the obvious result of the muzzle being off-centered (per classic FPS style) and the projectile instantiating from that point. But sadly, it also meant I couldn't bypass the suicide-feature inherit in my raycasting.

After weeks of frustration and refusal to open the project, I found my answer. I don't know if this was mentioned in any of the tutorials I watched and I just didn't catch it (as I tend to work as I listen/watch), but you can actually set layers for objects to not receive raycasting hits. I simply put the player avatar on this layer and now I never shoot myself in the head!

It's not perfect for Battlefield but it'll work for an FPS Shopping Simulator.

*You'll see a red-sphere appear against the wall. This sphere is instantiated by the raycast. You will then see a grey sphere travel from the gun-muzzle to the location of the red sphere. This grey sphere is the projectile that actually interacts with objects in the project.

Working on my new FPS!

I've been working on a new project for a few months now. A variety of things, such as fatigue, children, vacation, depression, Sea of Thieves, and Jessica Jones Season 2 have interfered with my productivity--but I'm feeling particularly motivated now!

I will being make a series of rapid fire posts to catch up on the story behind this game's development, but that will likely slow to crawl as I try to work my way through scripting hell.

To start things off, I'd like to share the game document I made for the project. It's, uh...three pages. At FIEA, 10 pages was considered a good length, but considering that those assignments were limited by only our imaginations, it was easier to hit the 10 page mark. This project is much smaller, and thus, requires less explanation.

Besides, one of my other Professors proclaimed that Rapid Prototypes were better than game design documents--so that's what I've focused on!

OVERVIEW: FPS is a first-person shooter about a character so obsessed with shooting games that their light-gun melds to their hand and becomes an actual projectile weapon. Their mother then sends them on a mission to buy groceries from the local shop.  Only using their non-lethal gun, they must collect the required groceries without going over budget.

GOAL: Use the gun to shoot listed grocery items into a shopping cart then take those items to the checkout.

PROJECT GOAL: Create a quirky shooting experience that plays well on the mobile platform, entertains, and subtly inspires some thought about the simplicity of shooting games.

TONE/THEMES: FPS is quirky game of silliness. The intent (beyond just being fun) is to encourage the player to think about the limitations of shooting games and the narrow experiences they provide.

AUDIENCE: Casual gamers with a cell phone looking for a quick, quirky experience. Public playtesting will allow for better audience identification.

ART DIRECTION: The project will take inspiration from Playstation 1 classics, like Parappa the Rapper, with low resolution sprites and brightly colored environments. (Or something else if testers hate it.)

STORY

Pixelated graphics: A metal door opens, revealing a corridor with plain concrete walls.

We are in control.

On screen, we see a 2D hand holding a pistol, our pistol. We move forward and are confronted by monsters from hell. Very reminiscent of the original Doom.

We shoot the monsters as they come. They explode, but still more come. No matter where we go, there are more halls, more corners, more doors, and more monsters.

As we play, the camera begins to pull back. The graphics are now three dimensional and brightly colored, à la Parappa the Rapper. We are in a living room playing our game on a TV.

Pulling back all the way, we are now in the eyes of our Avatar, and the pixelated 2D hand holding a pistol is now substituted by a 3D hand holding a plastic light-gun in our screen view.

Suddenly, the gun begins to glow and after a quick flash of light, the gun is now melded with our arm. And it no longer just shoots light at the tv, but fires plasmatic orbs of force.

An irritated voice calls from upstairs--ordering us to fetch the grocery list from the kitchen and take the money along with it.

We rush to the kitchen, grab the list, and then leave the house.

At the grocery store, shoppers are irritated by our menacing presence. Store employees are constantly complaining about the mess we make as we try to shoot grocery items into our shopping cart.

After collecting our necessary items, we make our way to front register. There, our items are totalled and the clerk asks for the payment.

With a familiar flash, the gun suddenly morphs back into a toy and drops to the ground.

Fade to black.

GAMEPLAY:

MOVEMENT
Played like most FPS: the player controls movement with the left thumb while turning and aiming with the right. For mobile touchscreen devices, the left half of the screen will detect movement while the right half detects turning and tilting (*player may invert this in options).

SHOOTING
The player fires their gun by tapping the right side of the screen. This is also the side that controls aiming. To differentiate between aiming and shooting, we must detect how long the player’s thumb is held and whether or not it glides across the screen (implying turning/tilting).

THE GUN
The gun melded to the player’s hand is the player’s primary form of interacting with the world.  It shoots “plasma spheres” that strike objects with a physical force--about equal to that of a tennis ball launched from a CO2 cannon.  Smaller objects like a box of noodles can be launched into the air while larger objects like people will simply be annoyed.

GROCERY LIST
The player will be presented with a randomly generated shopping list at the beginning of the level.  Aesthetically, it should appear handwritten on notebook paper and each item should be crossed out once collected. At the bottom of the list is a total of items collected.

The list can be hidden and accessed by sliding it up and down with one’s finger like a cell-phone menu.

SHOPPING CART
To satisfy the grocery list, the player will need to shoot items into their designated shopping cart. The cart can be pushed around or shot.

CASH & COSTS
The player is given a set amount of cash at the beginning of the game and they must collect all the necessary items on their grocery list.  If the total cost of items collected is higher than the cash the player has--they cannot complete the level.

NPC INTERACTION
NPCs will be shopping as well.  If the player agitates them by shooting them, hitting them with items, or bumping into their carts--they may kick the player’s cart and eject the items.

SCORE
A scoring system could be introduced to give added replay and challenge.

Rundead Android Trailer