Hey yall, this is our devlog for this quarter. I'm Robin, and JC will be posting on here as well. We threw around a bunch of ideas about the self, feelings, the ego, and the viewpoint of both the player and the creator.
Both of us feel like there's a lot of exploration to be done with the point of view of player characters, and how they interact with the world, whether in a positive or negative light, and one of our most prevalent ideas at the moment is a game based around a mouse in a massive mech - we're talking like, 10 times bigger than a tree massive. Evangelion massive. I've assembled here a sort of mood-board with the references we were thinking of when we were drilling deeper into this idea, but we're actually still pretty open to other ideas, just this one is the most developed so far.

In addition to talking about the mouse in the mech as a standalone concept, we also dipped into the idea of solitude and morality in the context of this game. What happens when you are forced to live your life in isolation, only coming into contact with beings that you can never touch, life outside your own that must be taken to survive? How do you grapple with that moral decision, not knowing whether those people could be reasoned with, or even if they were there at all? Who are you when you're alone, and whose decisions are you making? We thought a lot about who we are as people, and what that means both in and out of context of social life, and how to take that to its extreme in an interesting way. The mouse game also came about through the idea of "Games that make a player feel small" - and we decided that the symbolism of being a mouse accomplishes this. We also thought about the mix of (hyper)realism and mixing that with a super cartoon-ish character and the aesthetic decisions of that.

Lastly, heres the list of the other base concepts that we had throughout our brainstorming sessions:

-Beauty and Sublimity in the mundane
-Finding Magic at 50
-Self-Sabatoging Character
-Townscaper Tactical Game
-Space Strategy Game
-Electric Football (as a base)

Thanks for reading, and we hope to stay with yall throughout the development process.

In terms of whats required from the class: 

1. We mostly engaged with brainstorming and writing things down as we went along - yes-anding each other, and setting a timelimit for 'blue-sky' thinking. We pushed for weird and out there ideas, and drilled into what we found interesting, and then drilled back out when we felt we were going too deep. 

2. Constraints discovered:

- Scope: we end up really big a lot of the time, with grandiose ideas that might not be possible within the timeframe of capabilities or the abilities we have at the current moment

- - We did our priority assessment as a way of assessing whats possible: again, as we go along, we often don't think about scope as a constraint, just thinking about what we want out of a game, in terms of feelings, mechanics, what-have-you. When we go through processes like the spreadsheeting we do, we're forced to think through things a little more analytically, and allows us to say what is and what isn't possible. 

3. We're fundamentally interested in a lot of different things - I tend to go more fantasy based, and JC grounds his in reality and sci-fi. However, our differences tend to compliment each other and our passion for game-making ends up intertwining extremely well. We both end up with more interesting and more complete ideas than we could make alone, even if what we make isn't what the other had in terms of "grand vision" - we end up with something that's more realized.

Hey all!

Week 3 for the quarter, Robin and I set to work looking for materials to enact our in-class play prototypes. We tried to center around different ideas involving agency, alienation, and responsibility - specifically how we might be able to complement or amplify the experience of our end product. Our materials involve a DM with play ideas, paper poppers, hot glue guns, pipe cleaners, playdoh, battleships, and a ttrpg called emotional machine diagnostics.

The core questions behind our prototypes (without spoiling too much) are as follows: How will a player react if they are forced by the constraints of the game to inflict discomfort/pain on someone else indirectly? How does a player tend to deal with a system which demands a decisive decision, but without knowing the full implication of their action, or what the result will actually be? And lastly, what works when players try to indirectly affect something?

I think over the course of this week we were very interested in provocative concepts - whether our prototypes will live up to that momentum, we'll have to see. I believe a classroom environment and friendly atmosphere may lead some of our prototyping intentions askew - but also feel that adversity to the idea could make it more robust or evolve into something entirely new from what we were expecting. Overall, we're both excited and curious to see what happens and to try other prototypes as well!

Making a Mech for a Mouse: Prototypes Part Primero

Prototype 1:

In this prototype, we required a couple materials, but most of them can be found at a craft store. Namely, we’re using a set of pipe cleaners (the multicolored ones), and a hot glue gun. Things in this prototype that can’t be bought at a craft store: 2 sets of music, one upbeat and one tense (we’re using Music for your dog (3 hours) and the music from “Who wants to be a millionaire, $640,000 question.”), and 2 volunteers, and if you want, 2 facilitators to change the music.

In this prototype, both volunteers should be told this:

One of you should sit on the ground, and the other stand or sit at a table. The one on the ground is able to talk, while the other is highly encouraged not to. The one sitting on the ground is to give directions to the volunteer at the table on what to build with the pipe cleaner and the hot glue gun.

Unbeknownst to the two volunteers. The two facilitators on either side should have access to being able to play the 2 types of music respectively. Whenever the building volunteer is constructing with pipe cleaners, the upbeat music should be played, and whenever the hot glue gun is even touched, they should switch to the tenser music.

The time limit is anywhere from 3-7 minutes, or however long either volunteer wants to stick around and see the product of their attempted collaboration.

So what’s the point of this? Well, we reasoned that first of all, even the most experienced hot-gluer is going to burn themselves, or get tied up in the little glue strings from time to time, and you might ask, what’s your point there? And our point is thus: What if your actions, your decisions and directions could cause bodily harm or discomfort to not you, but explicitly the bodily harm or discomfort of another person? Are you comfortable with the idea that your actions are enacting direct consequences on another person: especially a person who is very much encouraged to not be able to communicate back, express their discomfort or pain? The power dynamic here is clear, but in this power dynamic, how does that make you feel? Those are the important questions that we’re seeking to answer in this prototype.

Prototype 2:

This one’s a bit simpler. Have a DM/Facilitator narrate the sounds of a mech battle, represented in colorful language, and played out through a game of battleships between two non-talking except for shot callouts (and optionally non-seeing) participants (in the case of non-seeing use a facilitator with access to both boards). Hits or misses shouldn’t be narrated simply as such, they should be done through the story of what one might hear inside a mech, with a battle between two of them.

The point of this one is more about making narratives where the “main character(s)” are more disconnected from the goings-on: they have direct control but they are unable to see the direct results of what happens around them.

Prototype 3:

Have 2 people sit down with eachother. One of them uses the ttrpg framework of “Emotional Machine Diagnostics” and the other, silently, enacts the musings of the other person.

If we can’t take care of ourselves, but we can take care of other things, who are we? Why for some is it easier to take care of others than ourselves?

Here's a bunch of our first prototypes and what questions they ask.
If you get a chance to play with them, feel free to reply here and tell us what you found!

Week 4 for the quarter! This week was very busy for our team; We clarified our project goals, built around 4 prototypes all varying in style and focus. We took a special interest in a work called '24 game poems', which consisted of 24 guided role-playing scenarios all ranging in strangeness and discomfort. 3 of our 4 prototypes involved a focus on social interaction, and 1 of the 4 involved a rough implementation of how we might want the mouse and the mech concept to function.

I think we've generated a lot of good and interesting prototypes. We have set our sights on an integration between digital and physical design goals. This will play into the game thematically by having a day/night cycle where during the day, you play as a mouse controlling a mech; during the night, the mouse goes to a computer and this instantiates a real-life tabletop game which will include a variety of ‘game poems’. We think this mix of mediums and the use of game poems to incite social confrontation play with ideas of role play in a clever way (by inverting the traditional conception of role-playing into a character to role-playing from a mouse into a very much real social confrontation with other players) can front as an interesting provocation, and hopefully an interesting gameplay concept.

Overall we're very excited to have people try our prompts!

Hey all!

This week Robin and I took time to discuss what kind of mechanism would best integrate our vision for combining digital and physical game formats. We resolved on using QR codes to link together physical and digital elements to keep a more authentic track of points. We also flushed out more ideas about how we want the mech/mouse game to function. We are still undecided on the precise formatting, but we are certain we want a mix of balancing meters required to make the mech run, while also getting it to do what you want.

These are some screenshots showing visual prototypes of gameplay. The player must navigate the internals of the mech (shown externally) as a platformer, and execute minor tasks in different parts of the mech to make it move or relieve the mech from overheating.

Similarly, we expanded some of the cards for a social meta-game we made. We continue to juggle multiple elements of the project, but we enjoy the challenge!

Hey everyone! It's been a while since I've posted on the devlog, so here's an update

Throughout the week, we've been working on building and playtesting various parts of the game - attempting to bifurcate the process if you will. On Friday of last week, we managed to playtest the social meta-game that JC's been building, and that went pretty dang well! We gained a lot of interesting feedback, some of it pertaining to the tone of the messages that people would say, and how people reacted within the game to form social interactions that were either uncomfortable or hilarious. 

While JC's been working on that and the 3d unity build (which we're still editing the concept of), I've been working on a particular unity build that's all centered around how to manage a mech, mostly via numbers and different ways of pressing a subset of keys. 

The system itself isn't super complicated, and the player interacts with the mech solely through Q, W, E, R and the numpad, but the complicated portion is making sure that you piloting the mech itself doesn't feel aimless. Feeling pointless would be interesting, as that's one of the major concept's we've been playing with in our own playtests, but in this case, I want there to be a solid goal for the player to work towards. Just as a note, the images that I'm using here are just some picrews that I happened to have saved on my computer for generating OC's for other tabletop games, or just messing around. The final images that I hope to use will be of mice that I drew, and ideally they would change with the state of the players. 

Players? Yeah! Once the project is minimally functional - in that a player can interact with the mech interface but not have it be so pretty that it makes it complicated - I'm going to be working on the central tenet of the base digital game: multiplayer! So far, I took one look at how unity used to handle multiplayer, said "That's not so bad" and then proceeded to figure out that they had completely abandoned that as of 2018-2019 (I'm pretty sure). Instead, they've shifted into a system that's called MLAPI, which was... so intimidating (and my part of the project so barebones and incomplete) that I just kind of, stopped. At least, I've stopped for now. Once I'm able to make this single player host version, making a client version should be relatively trivial, because I can just change some of the names and messages around. Then it's all MLAPI stuff, all the way till the end

The thing is, my build is actually just a giant test in the first place. We don't actually want this to be the game almost at all - managing meters, yes, but the idea that it would all happen through UI is somewhat of a personal project for me, almost completely separate from this project. The main thing that this is testing (which might seem like a question with an obvious answer) is "Is it fun to pilot a mech?" - our question is "Is it fun to pilot a mech in a way that's similar to this, but platforming?" The other concept this is testing is our ability to use MLAPI to make a multiplayer game in the first place - and would that game be fun. 

Anyways, that's all from me for today. We'll add some of our more interesting notes from playtesting in the future. 

As always, thanks for reading. Robin, signing out.

This week, Robin and I continued to refine our idea of how the game should come together and built out more details on the digital side of our game sequence. Robin has made more progress on the UI and systems side of the game, while I have clarified the techniques we will be using to display and manipulate the 3d elements of the game. By allowing two cameras to screen at the same time, different objects can be overlaid at different distances relative to each camera. This allows various moving objects on the screen to not interfere with each other or need to be parent/child with each other and to keep the physics of platforming isolated from other parts of the scene. The effect is that there is a cross-view of what's "inside" the mech, which is where the game is played and takes place. There are many affordances this technique allows, and though our time is limited I'm excited to see what we are able to do with it.

Throughout this week we have also discussed and revised project goals, set up our macro design, and continued to think about how all the sequences of our game come together. It's apparent that each sequence seeks to tell a specific story, but tethering them together in a meaningful way is the question that's been recurring. At the moment it's not obvious whether or not it's possible, but we continue to chunk out essential components, hoping some obvious pattern will emerge. So far, that I can tell, that pattern is exhaustion. We attack the player's stamina in many ways - organizational stamina, emotional stamina, problem-solving stamina; we are constantly trying to break the player down. We feel inclined not the belabor the theme so dramatically but to see where that takes us in playtests. This, also, I am excited to see the result of.

Those are the experiences and thoughts we've been having for the week - and I look forward to continuing the pre-production process.

Hey everyone! Just a quick devlog for this week. I've got some sketches that I've lined out and am in the process of scanning in to rig out the mouse character in full - for now, we've also made a level layout! JC's done a great job implementing the level so far, and all we gotta do is make sure we can actually interact with things in the level! For now, we've split the digital portion of the game into 2 parts - a host who navigates and does a lot of the "commander" work for the mech, and the two client players who do maintenance work on the ship throughout the day.

First things first though, here are the sketches and their lined version, which are going to be scanned in and colored so they match the mouse head thats serving as our "map indicator" icon (but will be put atop the body soon, and is also attached here)

I've also been working on editing my portion of the tabletop section of the game, a mini-tabletop game that I've dubbed "Elephant" - we've had a playtest for it in class, and I made the edits according to what I learned. 

Continuing onwards and upwards - I'm finally in the wrestling ring for MLAPI, and its already MLAPI 1 - Robin  0. I followed a tutorial to the letter and didnt manage to get it to work... sigh. Hopefully, In this next week I'll be able to make that score 1-1. 

Thats all from me for now, hopefully I'll remember to update this with any major updates that happen before next week instead of doing it day of. 

Robin, signing out.