sushi4robots

[sushi4robots]

Current roadmap

[sushi4robots]

Working a bit on gamefeel

In longer projects, and especially when you're working alone, there are so many parts you want to improve at the same time. It can be a bit overwhelming. In the end, you just keep switching your focus. It's hard to fully finish something because everything relies on everything else.

Anyway, I decided to revisit the core gameplay and see what could be improved. I started with classic tweaks, like adding fast scale tweens and particles when players do something.

It's such a simple tweak.

And then I tried to tackle an issue that has been bothering me for a while (you might have heard about this already if you follow me on twitter).

In Sushi For Robots dishes get a destination and move there. Once every dish has reached its destination, they check the level state and choose a next action. It all looks very smooth, players don't realize it's actually a turn-based system.

But here's the thing, not every dish reaches its goal at the same time. There's usually a delay of a few frames. Which you don't really notice buuuuuuuuut it feels as if the game was stuttering. As if there was a frame drop even though that's not the case.

I spent some time trying to fix this. I'm sure a good programmer might find a good solution, my fixes were going to complicate the code way too much.

And then I saw another game that had a similar belt. I can't find it right now, it was a super cool puzzle game about cookies or cakes where you have to draw a path like in Cosmic Express. It was on a Steam Festival. Anyway, their belt stopped after each step. They weren't trying to hide it. And it looked really good.

And then it hit me, mine felt horrible because I was trying to cheat and cover my turn-based system. But that's creating a disruption. Your brain tells you it's supposed to be a smooth movement and your tells you there's something wrong in there.

So I stopped hiding that movement, in fact, I enhanced it.

Again, there are a lot of art placeholders in here. We need some animation for the belt that reinforces all this. But the prototype feels so much better after this. On top of that, I think it helps people realize it's grid-based and turn-based. People who have tried both versions really liked this small change.

And that's gamedev in a nutshell, sometimes you stress over tiny details that nobody will see. And sometimes you put lots of hours into a microscopic thing that actually matters a lot.

[sushi4robots]

First hub iteration

I've mentioned hubs here before and how I want them to feel a bit special (I'm not sure if I'll manage to achieve that). I'd just hate to have a boring menu with all the levels lined up. It's a small puzzle game, it's not like I'm building Breath of the Wild 2 but, maybe I can have some sort of exploration feeling? (hopefully)

So here's their first iteration (with placeholder art) following the style of abstract museum maps. As players complete levels they unlock new rooms and icons. Icons can be puzzles, narrative scenes or things like elevators which go to different floors/worlds.

You see these buttons, click on one, go do something and come back to discover new elements. It's a simple loop but it's probably going to save me from plenty of headaches. I have a small sprite that marks completed pieces of content and I'm thinking I might need one for new things? Just to highlight parts that just got unlocked.

I'm still not sure how many levels I should have on each floor. And I'd like to make them more interesting and a bit interactive. Like finding a level or a lift that's blocked and you have to do something else to activate it. But right now it's mostly questions. I need to keep working on the other pieces of the game a bit more.

[sushi4robots]

Drafting a visual identity

As explained in the last post, I decided to hire 3 artists from Monsterspit to find a visual direction for the game. We had a meeting where I showed them the prototype and went over the documentation. After that, each of them would work on one mockup.

The mockup wouldn't take much time to make, but we gave them a whole month for this. It's always nice to have some time to think about these things instead of just rushing.

The three mockups were quite different from each other (which was the ideal scenario) and we tried to encourage everyone to go wild. We discarded one of the mockups early on (and for a reason I wasn't expecting at all). One of the artists (who had tons of experience working in animated movies/shows) went for a style like the one in many F2P games (something I'd like to stay away from). The mockup was beautiful, but people used to playing games didn't find it very eye-catching.

From the other two, this one was my favorite.

I really liked the palette and the robot design. Those small pieces I could swap to create many variations. I was a bit worried about how this would translate to game assets (since robots need to be around 128x128px). And, as much as I loved this concept, the final mockup wasn't clicking with me. Art needed to be a bit more simplified given my screen limitations.

And that brings us to the third mockup (and the one I decided to go with).

Needless to say, there are a million things that need to be tweaked here. It's just a very early mockup. But they sent me this image and I was like "Hey, we can totally work with this, the foundations are strong". I think it's eye-catching and has a unique personality.

After choosing a final mockup, Monsterpit sent me a rough simplified tiled version of this to implement it and test it a bit.

I'm hoping to do a second "art push" in early October, iterate a few things that haven't been working, and polish all the assets. Other devs might prefer to just wait until the whole game is finished, I totally get that. It's "easier". Who knows if the artist I'm working with will be available once I'm ready for a new iteration? It's a risk. At the same, time, it's allowing me to slowly integrate the art style with the other parts of the game. And it's also giving the artist time to breathe and get a new perspective. I think the final result benefits a lot from this.

In this case, since I hired the studio and not the artist themselves, I trust they'll be able to suggest an alternative if the original artist isn't available. But one never knows for sure and a risk is always a risk. It's mostly a matter of deciding if that particular gamble works for you or not. It's the same with game design, to get something you're usually losing something else in return. You ponder the situation and pick the gamble that makes more sense at that point.

[sushi4robots]

Finding an artist to work on the game

As I said in a previous post, I wanted to start experimenting with art styles. As long as the game had my ugly placeholder art, I wouldn't be able to properly set up testing sessions or really polish the small details.

So I openned twitter and wrote a simple message.

Why go to social media for this? If you're a studio you'll probably want to post it on job boards and more traditional places, my time is more limited and I knew twitter would get me tons of great portfolios. Plus finding people who don't usually work in games was a priority for me.

They aren't familiarized with the usual production pipelines (and you need to spend some time there explaining things) but they can easily come up with styles and ideas that feel refreshing.

I tried to write a short message that explained the style I was looking for, pace/schedule and that tried to encourage people to get in touch ("if unsure, just get in touch", "don't need previous experience in games", etc).

So people started sending me their portfolios and, if I thought they could be a good fit, I'd send them a document detailing what I needed and asked them for their daily rate. My goal was to find an art style (even if the sprites were still quite rough) and my budget for this was around 1.200€. I didn't tell people that though, as a freelancer I'm not very comfortable when a client tells me I have to do X in Y days and for Z €. I just asked, "Hey, what's your daily rate? and how much time would you need to do this?". I was ready to be flexible with my budget if I liked their work.

I got over 60 messages and, though it took me some time, I reviewed and answered each of them. That was actually a bit exhausting. And if I felt their work didn't click with me, I tried to let them know as soon as possible.

I managed to find one that I really loved. And then something kinda unexpected happened, let me provide some context. I share the office with two more people, one of them(Igor) is a very experienced concept artist with a dark/mature style (so pretty much the opposite of what I was looking for), but he manages a group of freelancers (Monsterspit) that take new gigs when he is busy.

We were discussing all this and he said that if my goal was to try different art styles, I shouldn't work with just one artist. Even if they're experienced and can switch styles, I should let everyone do their thing, what they're really good at.

But somebody had to coordinate the artists. He voluntereed to help me with the project but he also suggested picking three artists from his team (which would be easier to coordinate). And my answer was "show me three portfolios that match what I'm looking for and we'll see".

And after seeing their picks, I decided to go with them. Though these choices are never easy.

[sushi4robots]

It's been a while

Hi there!

My last update here was about three months ago. I've been quite busy with cool projects, things for clients and Sushi for Robots. And since this isn't a promotional blog, I decided to wait a bit, avoid rushing and get back to it once I had time.

So my plan is to catch up with this blog over the next 1-2 weeks. Expect plenty of posts.

[sushi4robots]

March is over, let's review milestones

In March I implemented a working level editor, added debug hotkeys and fuctions, remade the (simple logic) from some of the stickers found in the original prototype.

I didn't fully achieve two of my original goals:

- Gamefeel: I tried working on this a bit, but it's quite hard to figure out the right game feel without having a definitive artstyle. I shouldn't have put this so early. So I'll be leaving this for later in production.

- Prototype hub: I haven't implemented any hub yet. Getting a first concept I could work with too me longer than expected.

Truth is I didn't feel super productive last month. I think it's partly due to the level editor. Coding semi-complex things (specially if they're backend) drains all my energy (hey, I'm a designer, not a programmer). Plus working on it made me lose perspective on the actual game. I was too focused on databases and not really on moment to moment gameplay.

I think it's important for me to:

- Schedule my tasks so I don't have to code a lot in a short period of time.

- Focus on getting something playable (hub, levels, etc) that looks and feels as final as possible. Getting that ready for the first testing should be my main priority.

With that in mind, I took a look at what I had originally planned for April and decided to make a few adjustments.

- I'm delaying prototyping new stickers. They aren't necessary for the goal I'm focused on (making something playable and polished).

- I'm switching "implement menu flow" for "game flow" (I'm not making a menu, but I want to have a full loop that includes hub, scenes and levels).

- I'm bumping up "hiring artists" and starting with that this month. I checked a few doubts with my administrator and everything's ready. And I think it's very important for me to get a feel of the final artstyle. I originally planned it for May so it'd overlap the first testing (and I could use it as a poll). After rethinking it, I'm not comfortable with using a poll to decide the final artstyle. I'll go with my own preference (and the feedback from some close friends) instead.

I don't know if I'm trying to bite too much in April. I have a big sideproject this month and I'm also taking a few days off for a holiday. I fear I might have been too optimistic with my goals. We'll see in the next milestone review!

[sushi4robots]

Hubs and what happens between levels

This month I've spent some time thinking about that part of the game that I didn't really know how to approach, hubs (or what happens between levels).

I wanted to use them to add playful interactions, crack a few jokes and serve as a nice wrapping to the whole thing.

I know that this hub needs buttons that take players to levels. Plus space for text and interactive elements. And players must be able to navigate this hub somehow (because I can't fit all those elements in one single screen).

But how will I frame all this? It's not like these elements are just floating around. What's the narrative excuse holding this together?

I started toying with a simple (and kinda dull idea), players are sushi restaurant inspectors. They're going through files on their computers and checking/fixing all these restaurants. Yeah, it's not Shakespeare. It's a simple puzzle game and I just want a silly narrative excuse to tell jokes and explore concepts I'm interested in.

I kept jumping between similar ideas until I reached one that got my attention. Let's set all this in a museum. A museum about the history of sushi restaurants, why not? I actually prefer something silly like this.

I think museums are fascinating places and bring up lots of interesting topics. Plus their structure already resembles games a bit (exhibitons are like worlds, you usually follow a kinda linear path around them, etc).

(map from the British Museum)

And it'd probably be very fun to borrow that abstract representation from museum maps. I was picturing it as a big museum map and, when players tap on a room, the game loads a small scene with the level buttons, playful elements and all that.

This idea fills many of the blanks I have. It's giving me a way to navigate a big hub, a nice (but very simple) visualization for it and a context that should allow me to make a decent narrative. So I guess I have a starting point to work on.

[sushi4robots]

Aaaaand the level editor is done

I've finished the level editor! It's not super fancy, but I've already noticed how it's speeding up the design process. There are two features that I've skipped for now (since they were harder to implement), at this point the editor can't:

- Load a file from any folder on my PC. It can only load files found in the game folder. This isn't an issue at this point (though I'd like to include this if the editor was open to players).

- Rewrite an existing file. If I wanted to change a certain detail in a level I'd need to load it, change that thing, save it somewhere and drag it to the right folder again. This would save me a few seconds, but implementing it would be quite tricky.

So, how does it work? Well, I just take an array (which is basically a table) and write down the values there. Each cell can only host one value and sometimes I need it to contain more (like when a cell has a belt tile and a dish). You can create new code words to fix this (like belt_up_dish, belt_down_dish, etc) but this can grow exponentially and lead to lots of issues. In order to make things right, I need several tables (like layers), one for the belt and one for dishes/clients. I could save each table in a different json file, but I really want to keep things simple, so I just place both tablets in the same json file. And then I add there the level metadata (id, turns players have to solve it and the available stickers). If we could visualize the data in a table, it'd be something like this.

(this is just a quick example I doodled on excel)

Managing this data was a bit tricky. I had to write functions so both the editor and the game itself can read it. I'll need to make small adjustments as new features are implemented. But so far I'd say this was a positive choice. Let's hope I don't regret this in the future.

[sushi4robots]

Should I code a level editor?

"Should I code a level editor?" I booked some time in March to try to answer this question. I spent a few hours doing research before deciding the best way to consider this question was to start building it. So I gave myself a day and got this.

It's a working level editor. You can place tiles, hit "play" and test them. With a simple click it takes the array value and saves it as a json file. What is this version missing?

- It still can't load levels from files. Making it load project files should be quite fast, but I'm not sure if I'll be able to make it load any file from my computer (which would be a very nice feature).

- Right now it's saving a single value for each cell, but some cells contain more data (like a belt that has a dish on top of it) and I might want to expand this on the future. I implemented this feature in a very crappy way, but I really need to come up with a more elegant solution.

- It still can't handle sticker data (or timer length). This shouldn't take too much time.

Looking at this I'd say I could finish it in 2 more days. But, should I?

This is what makes me excited about having a custom level editor:

- Having shortcuts (I already implement a few) that allow me to work faster.

- Being able to doodle levels without opening the engine (maybe even from a phone or a tablet).

- Having all the level data as external files (this might not sound super important, but it might end up being super helpful).

- Making overall layout changes (like tweaking the UI) would be way easier.

- I might want to offer this as a feature for players (though I'd need to polish it waaaaaaaaaaay more).

Reasons why I think I shouldn't implement it...

- It'll take time to update it with every new mechanic.

- It's a huge part of the game that'll affect every mechanic. It could bring lots of issues in the future.

- It'll probably make debugging more troublesome. If there's a glitch it could be coming from the level editor/loader and not the core code itself.

- I've never coded my own level editor in a long project. It might end up leading to road blocks.

There are only a few cons, but they're pretty heavy because they're introducing large scale risks. I can't support both methods (it would be too expensive in terms of time) and switching in the middle of production sounds painful.

And my final conclusion is that... I'm going to go on with the level editor. My main motivation is that just the possibility of using the editor as a learning resource for design students is already worth the risk, on top of that, I'm lucky enough to have a grant that covers the expenses and acts as a safety net.

If the editor is a bad decision I hope I can see that early in production (when switching to the other method would only mean losing 2-3 weeks).

[sushi4robots]

Progress so far

I've finished the tasks I had planned for February. My current build already has the basic systems (belt, dishes, stickers, clients, timer, etc). It's full of placeholder art though.

I don't want to lose a lot of time making nice assets (at least right now) but I think I'll take a few hours to quickly adapt the assets from the original prototype (just because these sprites are hurting my eyes).

It's easy to look at this and think "wow, this looks way worse than the jam version and it took longer to make". And yeah, that's true, but the insides are much more robust.

The first difference is how dish movement works. Here the game is checking dish priority, calculating moves and waiting until every dish has arrived to its destination before moving them again. It's like having turns, this gives me a tighter control over the game (which prevents bugs that were found in the jam version) and brings lots of advantages. For example, I know how many turns (or tile movements) it'll take to solve a puzzle. So I just tell the timer to last "x turns", on the jam version I manually calculated (poorly, I just used a stopwatch) how many real seconds took to complete a puzzle and I feeded that data to the timer for each level.

Lots of things that I was tweaking for each level (the direction of eahc belt tile, client queues, etc) have been fully automated. The game calculates all that just from its initial placement.

Even though the current build is ugly as hell, I'm constantly polishing the interaction. I made sure stickers can't be moved while the belt is active. I spent a decent amount of time making sure objects fully reseted their state once the belt stops. Overall, I've been trying to get rid of lots of minor bugs/issues, not just progamming the core features.

My next task is quite daunting. I'm going to analyze if it makes sense to code a custom level editor. I've already been thinking about it and planning my project accordingly. But it's still a pretty big task, wish me luck!.

[sushi4robots]

The conveyor belt

The belt (as in conveyor belt) is already working. It was cool to remake it from scratch. I'm not reusing any code from the original prototype and I'm taking my time to ensure everything is as clean and ordered as possible. Since I already got a glimpse of the kind of challenges my code will be facing later on, I'm building it accordingly.

I'm also keeping (or trying to) my variables and functions under control with comments and descriptive names. Yeah, having short elegant names for them looks fancy, but I love when the name of my function already tells me what it's doing.

But let's get back to the belt. At its core, it's an ordered group of tiles. For the jam version each belt sprite had individual variables setting the available movement directions from that tile (that I wrote manually). It was hellish, but hey, it worked.

For this new version I used a sprite with an arrow painted on it. The game extracts the belt moving direction from the sprite angle (no further variables needed, the arrow points the way). And it allows me to see the level flow just by looking at it. As soon as a level is loaded a script goes over each belt sprite and saves within it the ID of the previous and next tiles in the chain.

When a dish spawns, it can check the variables of the belt it's standing on to find out the id of the belt where it'll be moving to the next turn.

So the basic logic is "when you're (the dish) asked to move, get the id of the belt you should move to and try to move there". It won't move there if there's already a dish standing on that belt sprite.

Even though you see dishes moving smoothly around the belt, the game logic isn't really tracking all the steps of that movement. As soon as a dish starts its journey to the next belt, its origin is marked as "free" (so other dishes can move there) and its destination is marked as busy (it's booked so other dishes can't get there). With puzzles games it tends to be pretty important to have very strict rules.

Each turn a function checks every dish and asks them to move. This is what happened.

A dish tries to move, but it can't because that belt is busy. Then the dish standing on that belt moves (freeing the space) but the first dish already tried to move (that's what's causing the gaps).

I added a new rule, each time a dish tries to move and can't, it's marked as "blocked". When a dish moves it checks every blocked dish again.

Here's the result.

There's one tiny thing I hated from the original prototype (though I'm sure nobody noticed) . Some subtle details of the system couldn't be predicted. Imagine two dishes moving in opposite directions separated by an odd amount of tiles (let's say 5). Both dishes will move forward for two tiles (until there's only one separating them) and then one of them will occupy that final tile. Which one will it be? Well, that depends on which dish tries to move first (this was chosen randomly).

I thought that was annoying, players should be able to foresee the outcome of a puzzle. On top of that, it was the cause of some odd bugs that happened when combined with other mechanics.

So I made a priority system. After all the dishes have moved, the game checks them and assigns each of them a priority score (based on things like the way they're moving). And now I have a system that allows me to control that subtle part of the game. For example, I gave a higher priority to dishes moving clockwise, so this situation will always have the same outcome (that players can predict and expect) on every level.

And that's pretty much it. Now I just need to add stickers and clients and I'll have completed all the tasks I set for February.

[sushi4robots]

Window and object size

So there I was, ready to start coding logic and then I bumped into one of the early decisions you need to make on every game.

How big should the native resolution be? And what’s the right size for the main game objects?

Regarding resolution, I’m going for 1920x1080 (the jam version was in 1280x720 by the way, lower resolutions tend to make development faster). It’s a standard one. Defining the size of game objects can be a bit trickier.

I like my puzzles to feature all the information in one single screen (without scrolling around). I think it makes them more intuitive and accessible. That means there are two important elements affecting this decision:

- Level design. How much space do I need to build interesting levels? It’s important to have limitations, but I’m always a bit worried small levels might make level design harder.

- UX. How is this affecting player interaction? Since I’d like this game to be playable on phones, I need to make sure interactive elements feel comfortable in a small touch screen.

I started with UX. I had been playing Trees and Tents on my phone lately. It’s a puzzle game that features levels of various sizes. So I messed a bit with it, paying attention to how the different sizes felt. I thought that was a very fast way of trying out several options.

Grids of 8x8 or bigger forced game objects to be quite small, I felt that it was easy to make a mistake and tap the wrong square. It wasn’t a comfortable interaction

So having a grid with a height of 7 tiles (that takes most of the vertical space in a 1920 x 1080 resolution) seemed to feel decent. I looked up some recent games like Grindstone which also happened to be limited to rows of 7 elements. The next question was, will that get in the way of level design?

I went back to the original prototype, turns out I was already working with that limitation most of the time. Keep in mind that I’m taking about how many objects I can fit in the Y axis (that includes both the belt and the robots). It’s not going to be a square grid though, it can be wider. Assuming it’s on landscape, the Y axis is my main limitation. Though I also need to use the space in the X axis to fit the menu button, stickers and the timer.

At this point I don’t think that size should be an issue but, who knows? I’m just trying to foresee issues that might arise in the future (given the experience I have from previous games) but you always end up bumping into those.

(small note here, could I spawn the menu and the stickers on the left side for left-handed players?)

I made a crappy mock up of how the interface would work. With a resolution of 1920x1080 I can have tiles with a 128x128 size (which should work well on mobile). My levels should be limited to a 10x7 tile grid, that will (hopefully) be enough. And I have some extra space on the side for up to 12 stickers plus the play and menu buttons. Will my levels need up to 12 stickers? I really don’t know yet, but that seems like a number that I don’t think I’ll be close to.

Once again, I’m just using my experience, small tests and research to try to prevent big issues. But most of the time feels like gambling. You definetely get better at it, but you’re never 100% sure.

[sushi4robots]

Repository and backups

I just checked another task on my monthly list. Sure, setting up a repository takes just a few minutes, but I’m usually extremely lazy when it comes to these. With most projects (that take days or weeks) I just keep a folder in my desktop until it’s done and then I upload the source to dropbox or drive (this is extremely dangerous, please, don’t do this).

Repositories are a must for any serious project. So I just set up mine AND created a monthly calendar reminder to save an extra backup. Doing my best to be a responsible adult and keep things organized.

And now it’s time to finally start the project. I have the rest of the month to code the basic mechanics.

[sushi4robots]

Reviewing the original prototype

I replayed the prototype I made during Ludum Dare, went through all the player feedback and watched some gameplay videos. The goal here is to see what worked, what didn’t and try to predict what might become an issue in the future.

The game was well-received. It has a 4.8/5 rating on itchio and it ranked 16th (overall) at the end of the jam.

Things that people seemed to like:

- Main mechanic and level design.

- Narrative.

- Overall mood (the feel created by art + text + music).

Things that people commented frequently:

- Pretty much everyone wanted a button to fast forward the game (which makes a lot of sense).

- Some levels could be completed without using all the stickers. Some people thought this was cool, and most weren’t sure if it was a bug (meaning it was confusing). I think it’d be almost impossible to avoid this situation in a larger game (plus these alternative solutions are quite cool) so I think it should be a feature. Completing a level with less stickers should give some kind of reward (though the game should tell players that not every level can be completed this way).

Things I considered while replaying it:

- The belt moves clockwise, but that’s not always intuitive. I’m the designer and sometimes I had trouble guessing the direction a dish would take (when you put together weird shapes, teleporters and all). If something isn’t fully intuitive to the person making the game, it’s safe to assume it needs more work. I’m not fully sure how to address this (while keeping visual language as clear as possible) but I’ll think about it.

- One person mentioned that it’d be great if the timer and the belt had something like a grid that allowed players to predict how long it takes to cover X distance. This is something I considered while making the game (but I didn’t have time to implement). I think I’m going to try adding it.

- I want this game to feature some kind of “Unlock all levels” button. I’m not sure how I’ll implement it (probably buried in some menu) but I want it to be there. I don’t like using them, but more and more puzzle games have been featuring this and I believe it makes it more enjoyable for many players.

- It doesn’t make a lot of sense to have the narrative right next to the puzzle (it’s just something I do on jams), they’re kinda fighting for attention. Narrative will now be in the hub. This will also allow me to center everything. I want to target mobile devices too and this will give me more screen space as well.

- Sushi should have different shapes linked to each of the different colors (for accessibility reasons).

[sushi4robots]

Early production schedules

Today I took some time to draft a production schedule. Plans rarely work out perfeclty, but it’s important to have them. Some of the reasons why I’ll probably need to update this plan constantly include: - I wasn’t able to predict how long a task would take me. - Something unexpected happened (random bugs, new opportunities like showcases, feeling sick, etc). - There’s a lot of place here for experimentation. Maybe some of my initial ideas don’t make sense. Maybe I find something better. Maybe finding a good answer to an issue takes longer, etc. That’s why the second half of the year is less specific, it relies on the first half. - I forgot to add some key things.

The first 2 months or so should be kinda close to my plan, but I’m sure things will deviate from it soon enough. (pic in higher resolution)

[sushi4robots]

Game values

Hi! The first posts on this blog are likely to be a bit more abstract and wordy (this will change soon) . I’ve already been going over design and production plans for this game and I’m mostly trying to verbalize all that here. Just so any reader can understand my situation and the reasons why I do certain things. The last post said one of my main goals with this game was to “create a good puzzle game“. That’s an abstract concept that doesn’t mean much, so I thought I’d make a list with the core ideas that come to my mind when I think about this project. Keep in mind that these aren’t universal truths, just things that are relevant to me for this specific project. - The core of the game is about exploring a decision space created by the game mechanics. I’m very interested in presenting levels in a way that can lead players to new ideas. I’m not that interested in offering an endless array of complex exercises that feel like a workbook.

- I don’t want the game to be just level after level. That always feels as a meal where you don’t have time to catch your breath between courses. My favorite puzzle games have hubs to explore, small story bits to discover or additional mechanics that allow my mind to take breaks and let concepts sink in. The focus here will always be puzzles, but I think a nice wrapping is very important as well.

- I want to publish Sushi for Robots and it’d be absolutely amazing if it made enough money to fund more games, but that’s not the main priority. The main priority is to make a good game within my production constraints and enjoy the process. When your game needs to make money you should ask yourself things like “can I make cool gifs out of this?”, “how well does this genre sell when compared to others?” (these aren’t going to guarentee your success but will improve your odds). I’m in a lucky situation where I can prioritize creative values.

- Given the resources at my disposal, it makes sense for me to work “alone” on this project. Just adding one more person to the core team would mean that we wouldn’t be getting a decent monthly income while working on the game. I think working along with others will make the game significantly better (specially since there are some fields where my skills are lacking), so my intention is to hire some external help as consultants during specific parts of the development.

- I can be very picky about some creative concepts, but playtesting and getting feedback are key when it comes to developing a game. I’ll schedule several testings during production. And that’s all for today. The next post will be a production sketch, setting tasks and defining milestones.