In our Production 2 class, we built 3 prototypes in 3 weeks. I was the programmer on a team of 3 including a designer and a producer. Since we had such a small team with no artist, we went for a very simple game our first week:
Screwing a lightbulb in while standing on a chair
I ended up building the entire prototype (minus the art) within the last 20 minutes of our meeting, where we were designing the game. I really only had to write 2 functions. One to simulate inertia for the chair which was calculated by taking the chair's "angular distance to being straight up" (pretend I wrote that with big boy adult words) and applying it to an animation curve in Unity's inspector, so that the designer could then go in and dictate exactly how much the force of the chair falling should increase based on it's angle. I then just subtract the "Horizontal" input axis multiplied by another variable in the inspector to allow for the player to try to counter the tilt.
The second function was used to control "screwing in the lightbulb" which involved the player hitting the arrow keys in a clockwise direction. For that, every time one of the arrows was pressed, I saved the keycode and made sure it was the correct next arrow from the last one saved, and incremented the bulb's "screw level" until it hit "m_bulbMaxHeight", which caused the bulb to change sprites.
Settings for the Designer:
Ship Game
The next game which went untitled, ended up being a bit more complicated. It was a side-scrolling game where you controlled the sails and cannon on a ship. When the player raises the sails the waves pushed you backwards and lowering them caused the wind push you forward. Periodically you would pass over rocks. To prevent damaging your ship, you would have to time passing the rocks, to when you are passing over a wave, so the wave lifts you over the rock. Also periodically, barrels would float on by which you could shoot with the cannon. We had plans for more obstacles like other ships and eventually trading at different islands and hiring a crew, but that was only if we wanted to go with this game.
As you can see, apparently our designer could do art. Although it wasn't exactly fair for him to do 2 jobs, so we were really hoping to get an artist on board if we made it through mid mortem cuts.
Honestly the most difficult or closest to being difficult part of this game, was just simulating all the movement. Obviously you weren't actually moving, I was just parallaxing the background, although water should also move even if you aren't. So I would offset their sprites based on a constant minus your simulated movement speed which would be different based on your sails. Next for the waves, I would offset it's collider at the same rate as it's texture. Then since rocks are supposed to be static objects, I would only "spawn" new ones in based on your the player's simulated distance from start, which could go up or down (since raising the sails, brings you backwards).
To simulate "health" I just created a health script that broadcasted a message every time it's m_health variable changed or went below zero. The message would either be "OnHeal", "OnHurt", or "OnDead" and would include the new health as a parameter. The message would be broadcasted to both it's own gameobject, and to every object "subscribed" to it (every object in a list assigned in the inspector). The one you see in the screenshot, is the healthbar "subscribed" to the health changes. That way it only will change the fill of the health bar when the health value changes instead of checking every frame.
Next I created a damage component which would just broadcast a message "OnDamage" with an amount to whatever it hit. The health script had an OnDamage function which would receive the message.
Lastly, for the rocks and barrels, I created an Obstacle generator script which had a queue of "deactive" objects and a list of "active objects" basically creating a dynamically sized object pool. When it came time to spawn a new object, it would check the queue to see if there were any available "deactive" objects. If there were, it would dequeue it, activate it, add it to the active objects list, and set its position to the spawn position. If not, it would create a new object from a prefab assigned in the inspector, and add it to the list. Next if the object went offscreen, it would be deactivated, removed from the list, and added to the queue. The barrels, had a health script, so when they received "OnDead", they would call the function in the ObstacleGenerator to deactivate themselves.
Lymantria Dispar
Our final prototype, made in our 3rd week was Lymantria Dispar. Lymantria Dispar was a bit more ambitious in that it was a first person, atmospheric, survival horror game. You are lost in the woods with an axe, a torch, and a bow. You can harvest wood for arrows, to refuel your fire, or to make new ones. There are 2 enemies in the forest;
Giant moths (modeled after the gypsy moth or "Lymantria Dispar"). The moths do not attack the player, instead they are attracted to the fires, and when they fly over them, their giant wings blow the fires out.
The next is giant larva. These do attack the player. They aren't too much of a threat on their own, but having to manage keeping the fire lit so you can see them, while also defending yourself from them, becomes a real challenge.
This is the game we ended up choosing to continue working on for mid mortem. We decided that it had the best chance of making it through cuts and if it did, we could get a much needed artist to replace the placeholder art (including my awesome axe and torch I made in blender in 5 minutes).
This prototype ended up being fairly simple to make. The AI pathfinding was handled by Unity's navmesh, and the player was controlled by a script I made which integrated with Unity's CharacterController. I reused the Health and Damage scripts from the last game, except I added a list to the health script "List of layers that can hurt me" because before I was using the the physics collision matrix to prevent collision between layers I didn't want to hurt each other, which worked fine for the ship game, but for this, I needed things to collide physically but not hurt each other (example, enemy shouldn't hurt the tree, but the axe should).
I also made a simple inventory system which was basically a list of structs called "ItemLoadouts" which included a left and right tool. The player can use the scroll wheel to change loadouts (currently just torch+axe or just bow). There is also a list of Hot-key loadouts which can be activated via a hot key.
I used the same object pool system as the last game, to periodically spawn in new enemies except with some added settings for the designer. I added a list of effectors to the script which could add, subtract, multiply, or divide the time between enemy spawns, by an animation curve with time since start, number of fires, and number of enemies as the input. It is a list, so the designer, could add as many of these effector animation curves as they want.
The AI as I mentioned is mostly handled by Unity's nav mesh. I gave the script a layermask variable so the designer can tell it which layers to chase. It basically just does an OverlapSphere using the layermask, and chases the nearest object within the sphere.
This is the game we ended up going with, and it made it through mid mortem without being cut. So now we have gained another designer and an artist! So now we can finally get the art more fleshed out (or replaced altogether). We have plans for a simple story and maybe some environmental assets, but other than that, and a lot of needed polish and balancing, most of the features we had planned have been implemented in some form.
Hopefully we can get this to a good spot, within the next couple weeks before the semester ends.