next »

[William Chyr]

DevLog Update #45 - 04/22/2014

PAX East Indie MINIBOOTH Post-Mortem

I exhibited Relativity in the Indie MEGABOOTH earlier this month at PAX East. I was part of the Indie MINIBOOTH, and it was my first time at PAX.  As I've benefitted greatly from post-mortems by other studios, such as this one from The Men Who Wear Many Hats, I decided to write up a post about my experience and share what I learned.

Background

I am a one-man developer based in Chicago, currently working on my first game, Relativity, a first-person exploration-puzzle game set in an Escher-esque world. I’ve been working on the game for about 16 months now. Prior to PAX East, I had shown the game briefly during a 2 hour show-and-tell session at IndieCade East in February, and also attended GDC in March. I wasn’t exhibiting at GDC, but I did meet with several developers and designers who I respect a lot, and got them to playtest the game and give me feedback

Indie MINIBOOTH

I learned about the Indie MEGABOOTH through twitter and submitted my game on December 2013. I had requested 3 days in the Indie MINIBOOTH as my first choice, and a 10x10 booth as my second choice. The reason why I chose 3 days was that I figured, if I’m going to go all the way to Boston to show the game, I might as well maximize my time at the convention.

On January 2014, I got an email from the organizers saying that my game had been accepted for the 3-day slot of the Indie MINIBOOTH.

So, what is the Indie MINIBOOTH? Unlike the other MEGABOOTH spaces, the smallest of which starts at 10x10, the MINIBOOTH is a shared area with kiosk stations showing multiple games. You can choose to show your game for 1, 2, or all 3 days of the convention.

Here’s the layout of the MINIBOOTH:


 
The blue part is the actual kiosk itself, and the black outlines show you where the monitors are. The 4 kiosks on the left each hold 3 monitors, while the 2 kioks on the right hold 4 monitors. The 4-monitor kiosks were mostly for games that were showing for only 1 or 2 days, while the others were mostly games exhibiting for the full 3 days.

Here’s the layout of the entire Indie MEGABOOTH area. The Indie MINIBOOTH is the orange area (booth 53).



The nice thing about the MINIBOOTH is that you don’t have to worry about or bring anything. The computer, monitor, keyboard, mouse, and headset are all provided for. I arrived in Boston on Wednesday and spent Thursday at the convention center helping out with set up, and making the sure the game is working. Theoretically though, you could just show up on the day you’re exhibiting, with a build of your game on a flash drive, and you’d be good to go (I wouldn't recommend this though   ).

Also, you don’t have to worry about stuff like electricity, carpet, or vacuuming. From what I understand, all those things at a convention center are extra, and I think you’ll have to pay for them if doing your own booth.

Finally, if you’re doing something that involves a network, you should definitely bring your own server. One team wanted to have cable internet, and the convention center quoted them something like $1200 for 3 days. They ended up just bringing their own server and setting that up.


Numbers

Here's the breakdown of costs:

Item		Cost
Indie MINIBOOTH 3-Day Slot		$1,395.00
Flight (Roundtrip Chicago to Boston)		$186.99
Meals		$120.00
1000 Business Card		$80.58
7 Day unlimited MTA Pass		$18.00
TOTAL		$1,800.57

I stayed with a friend in the west part of Boston, so I didn’t spend any money with regards to accommodation. It took me about an hour to get to and from the Boston Exhibition and Convention Center via public transit (MBTA).

Kiosk Setup

Here’s a picture of the kiosk setup:



If you have an option between keyboard and controller for your game, definitely go with controller, especially if the player is going to be standing. With the stand, you can’t adjust the height of the keyboard, and it makes it really awkward for taller players. I had several people stop playing because their hands were getting cramped up. There are many reasons to stop playing a game. This shouldn’t have to be one of them.

Also, since the height of the keyboard is for standing position, it’s too high for players who are sitting, so this means that the setup won’t be accessible to players in wheelchairs. Again, using a controller would have solved this problem.

If you’re planning on getting a 10x10 booth or something larger, I highly recommend checking out IndieBoothcraft.com. It has tons of tips and advice with regards to building and setting up your booth.

Game Feedback
PAX is a really great venue to get a lot of playtesting done, as well as gauge players’ feedback on your game.  For me, I’m still 1-2 years away from release, so being at PAX East wasn’t so much about promotion as it was about seeing players’ reaction.

There is a lot of value in just watching people play the game, as well as looking at their facial expressions during certain parts. While I wouldn’t rely too much on analytics, some data collection can be helpful. For me, I wanted to get a sense of the average play length, and how long it took people to complete the different puzzles.

In an earlier version of the game, each puzzle was a separate level, and when players finished a puzzle, they would get teleported to the next one. This made it very easy to get the start time and end time of each level, and therefore figure out how long each puzzle took.

However, the current version of the game consists of a seamless world, with puzzles in different rooms that the player can enter and exit at will. This means it’s very difficult to track how much time players spend solving each puzzle, since they might leave and go explore for a while before coming back.

I tried to use the stopwatch on my phone to time players, but this didn’t work out really well. I’d often forget to reset the stopwatch, but also, a lot of times people would stop while playing to talk to you and ask questions. Also, sometimes, other players will take over in the middle of the game, so it’s unclear how to count the time for that.

One option is to screen record the game. The problem is that video files can become pretty large very quickly. Even a half hour video recorded with FRAPS can often be several gigabytes in size.

The guys from Octodad told me that their game would take regular screenshots while people are playing. This is really helpful, especially if you’re trying to get a sense of where players are getting stuck, and it also doesn’t take up as much space on the hard drive.

I would also recommend not adding anything new to your build right before going to PAX. I added an additional puzzle to the game, originally thinking it was a way to fix an issue with another puzzle later on, and pretty much everyone at PAX got stuck there.

Food

Food at the convention center is, not surprisingly, overpriced and crappy. So don’t eat there.

Lunch

Before PAX started, there was word that someone would go around and take orders for lunch, then go out and buy everyone’s meals. This never actually happened, or at least whoever it was never came by my booth.

In any case, even if it did happen, I personally wouldn’t rely on this. A lot of the volunteers are already overworked as it, and once the convention gets going, it’s pretty much non-stop craziness for 8 hours straight. I also wouldn’t recommend going out for lunch, unless you have someone on your team who can man the booth. On the first day, a few of the other devs in the Indie MINIBOOTH took a cab to Chipotle for lunch, but had a nearly impossible time trying to get back into the convention center due to all the traffic. They had expected lunch to take an hour, and I think it ended up taking two hours.

The way I did it, I would stop by the South Station cafeteria in the morning, and while getting breakfast, I’d just pick up an extra sandwich for lunch. There’s a Dunkin Donuts closer to the convention center, but I wouldn’t recommend going there. As you can expect, being the closest low-price food establishment to the convention center, the line is very very long.

Dinner

Also, often times, what happens when the day ends, is that people will form some kind of foot train and go to a restaurant to get dinner. Unless you have made reservations beforehand (which most likely you won’t have), I can guarantee you won’t get in anywhere. A day of PAX just ended, there are tens of thousands of hungry people in the area. It’s dinner time. You’re not going to find an empty table for 10+ people anywhere in the vicinity. Either go with a group of 3-4 people, or go to the cafeteria at South Station. Last thing you want to be doing is wandering around Boston with no definite plan and trying to come to a consensus with a large group of people, none of whom are familiar with the area.

Press

PAX sends out a list of about 600 press contacts who are expected to attend the event. If you want to meet with the press, I highly recommend scheduling a meeting in advance. .

How you go about contacting journalists is up to you. I was told that you shouldn’t mass-email people, so I sent out about 15 personalized emails, mostly to journalists who had covered or reviewed similar games. I only heard back from and scheduled meetings with journalists from two sites: Polygon and The Indie Game Magazine.

This was fine with me, as I’m still quite a bit ways away from release, and press exposure isn’t the most important thing for me at the moment. Mostly it was a way for me to get started talking to journalists, and also receive feedback from people who had written about and reviewed similar games.

Some teams sent out a generic press release, to lots of contacts, and just had line saying something like, “if you’re interested in meeting up, get in touch”. Despite what I was told, I think that actually had a better return. One team that did this told me they had 15 meetings scheduled, but they also had 2 days off from showing the game, so were able to meet with the journalists, and they are also much closer to release.

Again, it depends on what stage of development your game is, and what you want to get out of speaking with the press. Generally though, from my own experience, I would say PAX is not the best event for meeting with the press, at least for Indies. I found it much easier at GDC and IndieCade East.

Also, Press Hour is from 9-10 AM on Friday, one hour on the first day of PAX before it starts. However, during this time, most of the journalists go to check out the big booths, because once PAX begins, the lines get ridiculously long.

Finally, sometimes press will give out little badges of approval to put on your station. I got one from BigSushi.fm, and it totally made my day.



Networking

The best part about being in the Indie MEGABOOTH is that you get to meet a ton of cool people and developers.

You’ll meet people not only during set-up and take down, but the Indie MEGABOOTH also organizes several events to socialize and network. These are super cool, and I highly recommend attending them.

On Thursday evening, the night before PAX East opened, there was a party for all the developers in the Indie MEGABOOTH to meet one another. On Saturday evening, there was a mixer between people in the MEGABOOTH and reps from Sony, Microsoft, and Valve.

Both of these events had food and an open bar. The atmosphere is usually pretty informal, but just remember that at the end of the day, it’s still a professional event, so probably best not to get wasted. Also, when speaking with the platform reps, please be considerate of others and don’t hog the conversation. The ratio of developers to platform reps is something like 100 to 6. We’re all trying to get feedback and make connections with the platforms, so let the other developers have a chance to introduce themselves and ask questions.

Misc

Some things you’ll want to bring:

• Hand sanitizer
• Cough drops
• Gum
• Bottles of water (I recommend at least 4 a day)
• Snacks
• Power strips

Also, be sure to thank the volunteers! Both the Indie MEGABOOTH volunteers and the PAX Enforcers. These people work their butts off doing all the boring work to make the event happen. I had some volunteers stand in for me when I went to the bathroom, or fill up my water bottles, and it was super awesome. I really appreciated it

[William Chyr]

Bit of a setback today. Upgraded to Unity 4.3, and ProBuilder + ProGrids stopped working properly.

Ended up losing about a day of work 

[William Chyr]

DevLog Update #46 - 04/26/2014

Sky
One feedback I've gotten from a lot of developers I've shown the game to, especially with regards to Relativity's visual style, is that the sky is too empty.

A large part of this has been due to the game's mechanic. Because you can rotate onto different surfaces, and orientate yourself along any of the 3 main axes, there is no limit in terms of locomotion. In other words, pretty much everything that you can see, you can get to.

For me, in designing the game, I really want to embrace this. I've always hated games that prevent you from going somewhere by using invisible walls, or respawning you somewhere else when you step outside of the bounds. For example, in Bioshock Infinite, they've created a beautiful world, but you cannot stray from the path the designers intended you to go on. Everytime you try to do that, they've placed all thess invisible colliders to stop you. To me, this really irks me as it takes me out of the experience, and makes it not immersive at all.

So in Relativity, I wanted it to be such that, anything the player can see, the player can get to. This means that I can't really have a skybox showing mountains or other geometry in the distance, because either I would have to create all that geometry, in which case the game becomes too open, or I have to somehow prevent the player from getting there, which breaks the consistency of my logic.

Falling Off
Another design issue I had, once I made it so that the player could go outside and walk around in the exterior of the space, was, "What happens when the player falls off?"

Originally, I just made it so that if the player fell off, the screen would fade to black, and the player would respawn in the last place he was standing at.

You can see that here:



I implemented this mostly because that was how a lot of other games did it.

However, while watching Alexander Bruce's GDC Talk on the design of Antichamber, one thing really struck me. He talked about how he eliminated death because it made the experience non-immersive. He brings up the example of Portal, which goes to lengths to create an immersive experience, but then you get shot and die, and respawn at a previous checkpoint, which really breaks the immersion.

For me, an important design choice I've made has been to eliminate all unnecessary UI. In the game, there are no maps, no inventory, no splash screen, no loading scene. I've gone to lengths to create a entirely seamless world, so why am I now having the screen fade to black and have the player respawn? It just didn't make any sense.

Recursive Space
I thought about this, and realized I could get around having to respawn the player by simply having the world wrap around itself. This way, if the player fell off, they would eventually just fall back on the world itself. This meant also that I would solve the issue of having a blank sky, because I would just have repetitions of the world in the sky, like the way things look when you stand between two mirrors.

The way the actual recursive space would work is that I have a trigger below the space, so that when you fell off the world, you eventually hit the trigger, which just teleports you to being above the world.

This is what that looks like (it's sped up to make the fall faster for the gif):


At first, I started off by duplicating the entire world in the scene, and placing the clone around the space. I soon realized this wasn't going to work. The minimum number I would need is one along each direction of the axes (positive and negative), as well as in the corners. In other worlds, a 3x3x3 matrix of clones, or 26 (27 minus the one in the center, which is the actual world itself). Hand-placing these in position wasn't going to work, so I wrote a script to instantiate the clones and place them for me.



However, there was another problem - there was way too much geometry. I couldn't just simply duplicate the world. That was very inefficient. I had doors, triggers, buttons, colliders, that didn't need to be there. And everything was getting multiplied by 27. There was so much geometry, in fact, that Unity kept crashing as a result.

So what I did instead was that I deleted all the interactive elements, deleted all the colliders, and then merged the renderers together, so that all I had were 7 mesh renderers (I would have made it all one giant mesh renderer, but merging meshes that were too large would cause Unity to freeze).  

Here's what the clone world looked like after that process:


The different colors are because I colorcode different geometry when building the world, so I can more easily see when things are aligned, etc.

There was still way too much geometry, and Unity was still crashing way too often. And when Unity wasn't crashing, it was just running ridiculously slow.

I realized I didn't actually need all the details, and I also didn't need any of the glass components, since they pretty much weren't visible.

So what I did instead, was remodel the entire world, but this time, I would just place giant blocks where the rooms and tunnels are, eliminating anything unnecessary, like interiors.

Here's what the simplified version of the world looks like:



You can see that a lot of the details are removed. However, from a distance, it is barely noticeable. And by the time the player gets close enough to see anything, I've already teleported them to above the original world.  

Finally, here are some screenshots of what the sky looks like with the recursive space:

[William Chyr]

Got world-wrapping working in all six gravity directions!

Also, added terminal velocity so that the player can't keep increasing fall speed. Otherwise, if you're going too fast, you can end up falling right through floors.

[bsp]

dude, really nice improvement. it's great that it may potentially solve a big portion of your skybox problem while also fixing the weird respawn thing. good work.

[William Chyr]

dude, really nice improvement. it's great that it may potentially solve a big portion of your skybox problem while also fixing the weird respawn thing. good work.

Thanks, Cordell! It definitely still needs a lot of work w/ regards to optimization. The method I'm using right now is not really efficient.

But visually, and from a design perspective, it definitely feels like the right track.

[William Chyr]

DevLog Update #47 - 04/28/2014

Relativity has been getting some press coverage recently! Here are the different articles it has been featured in:

Relativity hands-on: walking on the ceiling - Polygon

PAX East 2014 Golden Sushi Awards - BigSushi.FM

DevLog Watch: Augen Der Welt, Heat Signature, Relativity - Rock, Paper, Shotgun

[William Chyr]

DevLog Update #48 - 05/02/2014

Several setbacks this week, so production has been a little slow.

The major issue was due to the Unity scene file sizes being way too big. This was because to get the recursive world geometry looking right, I was generating the duplicate worlds during editor mode. This meant that all the additional geometry was getting saved, and making the file really bloated. The scene file size was around 20 MB.

This caused 2 problems: 1) The file size was too big to push to github (maximum file size is 100 MB), and 2) it would cause Unity to crash and delete the file for whichever scene was open. After this happened the second time, and I lost several hours worth of work, I decided I needed a new approach.

Instead of having the geometry generate in edit mode, they are actually generated during gameplay. This brought the scene file size down to 70 MB, and also made it much more manageable in general.

Anyway, here's a shot of the second hub world with the recursive geometry working:

[Christian]

I was curious about something. Couldn't the player falling into the world from above have the potential to break the game? Like they could land somewhere and be able to get around some part of a puzzle

Or does the player land at the spot where they fell off?

[William Chyr]

I was curious about something. Couldn't the player falling into the world from above have the potential to break the game? Like they could land somewhere and be able to get around some part of a puzzle

Or does the player land at the spot where they fell off?

The player usually lands around the spot where they fell off, but not always. What I mean is, you fall vertically in a straight line (if you don't air control), so if there was a ledge above where you were standing before, you'll land on that.

Regarding breaking puzzles: no, this won't break the game. A lot of the puzzles that center around the block mechanics happen indoors, where the recursive world stuff won't apply. That's really only happening when you're in the exterior space, which is much more about navigation and exploration, so allowing the player to get around to different places is actually encouraged.

And as a matter of fact, I'm going to create several puzzles that utilize this very nature of the world

[Connor]

these levels have gotten pretty crazy. the screen wrap things kinda like a waste of time if its all gonna be indoors. if a few levels have puzzles that utilize that though, it might end up being cool. also, i forget. this game will be pay to play right? :L

[William Chyr]

these levels have gotten pretty crazy. the screen wrap things kinda like a waste of time if its all gonna be indoors. if a few levels have puzzles that utilize that though, it might end up being cool. also, i forget. this game will be pay to play right? :L

\

There's actually quite a lot of outdoor spaces that play a very significant role. I would say the outdoor to indoor ratio is around 1:1.

In a way, it's similar to the way Skyrim works - there are large exterior spaces that are very open, and then there are dungeons that you can go into, which are all very linear.

The screen wrapping is definitely not a waste of time. And yes, it will be old school pay to play. No in-app-purchases.

[Connor]

oh wow, cool! i didnt realize that it would be like that. thats handy to know. i have about 30$ now thanks to some money i saved doing some shopping for stuff today so i can use that.
now that i think about it, you have posted a lot of outdoor screenshots. didnt really think about it up until now.
sorry if i made you mad about the screen wrapping waste of time thing. i didnt mean it in a way that would offend anyone...

[William Chyr]

sorry if i made you mad about the screen wrapping waste of time thing. i didnt mean it in a way that would offend anyone...

Not at all. 

I haven't had too much time of late to write more in-depth posts, so it's just been snippets here and there.

I'm still trying to figure out the best way to do pacing in the game, to prevent puzzle fatigue and maintain player motivation. From what I've seen, the first 1.5 - 2 hours of the game is pretty solid, but I'm now moving into the middle third of the game, which feels very much like unexplored territory.





 

[William Chyr]

DevLog Update #49 - 05/09/2014

Been really busy working on new content for the game, and preparing for more playtest sessions, so haven't been able to post here as frequently.

I'm now working on the middle third of the game, and a brand new hub level. It's a real change of pace from what I had been doing for the past several months. Instead of tweaking lots of minor areas of the puzzles, I'm now building lots of new infrastructure from the ground up. Lots of new prefabs, lots of new scripts. To be honest, I'm finding it to be quite tedious.

I've also been working on some new design challenges. It looks like I will have an over-overworld in the game. In other words, a hub level that acts as a hub to other hubs.

I still haven't worked things out fully in my mind yet, but will try to find the time to write up a post on this topic sometime this month.

In the meantime, here are some screenshots of the new hub I'm working on:

[William Chyr]

Got Hub No.3 working with recursive worlds! Going to start playtesting this level this week. Expecting to tweak it a lot.

[William Chyr]

DevLog Update #50 - 05/11/2014

The past few few weeks after I got back home from PAX East have been quite busy for me.
Today, I finally have some free time on my hands, so have decided to write about a few topics that have been on my mind for quite some time now.

PAX East Feedback

While I did write up a post-mortem on my experience showing the game with the Indie MINIBOOTH at PAX East, that post focused primarily on the logistics side of things, and I didn’t talk too much about the feedback I received regarding game design.

The build of the game I presented at PAX contained the first two hub worlds, and also had the new edge-detection shader applied.

Art Style

Visually, the game was in a much better place. At GDC, a lot of the feedback I received was that the game looked too much like a generic first-person puzzle game. At PAX East, however, several people commented on the art style being very distinct.

A lot of people did say it reminded them of Antichamber, mostly due to the edge-detection and very geometrical architecture. And while I do intend for the look of Relativity to be much more different than Antichamber, this was a good sign for me – at least people had stopped comparing it to Portal, which was a problem I had for most of development up until then.

Design

The most useful feedback I received from PAX East was regarding the pacing of the game. Because there is so much going on at the convention, you really have to work extra hard to grab and maintain people’s attention.

Since there are so many people playtesting the game, any problems you have get amplified tenfold. You want people to see as much cool stuff of your game as quickly as possible, and walk away with a positive impression. This means that the pacing at the beginning is very important.

One thing I learned is I needed to vary the concepts of the puzzles at the beginning. For example, one of the skills in Relativity that is really important, and which I need the player to learn early on, is that they can lift up boxes and place them on platforms above their heads.

After players learns they can press triggers to open doors, and place boxes on appropriate squares to open doors, I immediately have a puzzle to teach players about lifting boxes. In the build at PAX, this puzzle required the player to perform this skill three times in a row. Right after this, I had another puzzle that required the player to perform this skill once.

The reasoning behind the second puzzle was that some players were not as perceptive, and would still manage to get through the first puzzle without realizing what they had done, so this served as a small re-enforcement of the concept.

However, at a setting like PAX East, where people form impressions about your game very quickly, people were like “oh, I see, all the puzzles are just about lifting boxes to higher platforms. I get it. Gonna go check out something else now” and proceed to walk away.

Of course, the game is not about lifting boxes to higher platforms. That was simply a technique I needed players to learn so that they could tackle the more interesting puzzles later on. But having two puzzles in a row utilizing the same technique, right at the beginning of the game, resulted in giving people the wrong impression.

What I should have done instead, was have a puzzle with another concept in between the two box-lifting puzzles. This way, players would see a range of different puzzle mechanics, but still get the re-enforcement of the box-lifting technique. There’s no reason why the ‘review-concept’ puzzle needs to happen right after the ‘concept-introduction’ puzzle.

Another area that was causing problems was a puzzle I had added a week before PAX East. Basically, one of the more advanced puzzles later in the game requires the player to stand on a box to accomplish something. During playtest sessions, I noticed that a lot of players would struggle with this puzzle because they didn’t know they could stand on boxes.

I decided therefore that I needed a puzzle which isolated the concept of standing on boxes. I added one into the game, thinking it had solved the problem with the other puzzle. However, at PAX East, a lot of people ended up struggling with this puzzle. I realized then that the puzzle should have been broken up into two parts.

And so, here’s a simplified version of the puzzle order in the build I showed at PAX East:

Box Lifting Puzzle #1 --> Box Lifting Puzzle #2 --> Multiple Gravity Interaction Puzzle #1 --> Multiple Gravity Interaction Puzzle #2 --> Standing on box Puzzle

And here’s the sequence of puzzles in the current version:

Box Lifting Puzzle #1 --> Standing on Box Puzzle #1 --> Box Lifting Puzzle #2 --> Multiple Gravity --> Interaction Puzzle #1 --> Multiple Gravity Interaction Puzzle #2 --> Standing on box Puzzle #2

I’ve only done a few playtest sessions since then, but already I can see that it’s much better. Of course, puzzle order isn’t the whole picture with regards to pacing. There’s also a lot of things like teasing the player (showing them something cool but currently inaccessible through a window), rewarding the player by opening new areas when a puzzle is solved, etc. All these play a significant role in getting the pacing right in a game.

A game that does this really well is Antichamber. For example, check out this

. Every moment is carefully planned to show you something new and unexpected. You start the game, it says jump, you jump, you fall. WTF? You walk forward, turn right, go down the stairs, and end up in the same hallway. Go up the stairs, end up at the same place. Turn around, and the world is different. It's hitting one beat right after another, without any lag time in between.

I spoke to Alexander Bruce about this while at PAX East, and he described Antichamber as a “convention-friendly unconventional game”. This doesn’t mean he catered to a convention audience. Instead, it means he used the convention environment to create really strong pacing for the game. Everything is designed carefully to engage the player right away, and to strike the right tone for what the game is.

If you’re making a weird, unconventional puzzle game, and you can grab the attention of players at a convention and keep them engaged, then you’re really onto something.

[William Chyr]

Spent an hour trying to work out the logic for teleportation triggers, only to realize the solution was super simple. 

[jeffrobot]

Those screenshots sure are purrty.

What are your thoughts on a narrative?

NPCs?

I'm working on a game that features crows very heavily. I could see some birds flying around your levels, perching on objects, quizzically eyeing the player.

[William Chyr]

Those screenshots sure are purrty.

What are your thoughts on a narrative?

NPCs?

I'm working on a game that features crows very heavily. I could see some birds flying around your levels, perching on objects, quizzically eyeing the player.

I'm not planning on having any NPCs in the game. This was a decision I made early on in development. As a one-man team, there's no way I'd be able to pull off good character modeling or animation, and so I've decided not to have any at all.

I haven't thought too much about narrative at this point. I do have ideas, but I want to focus on getting the puzzle pacing right before working on anything else.