{ "version": "https://jsonfeed.org/version/1.1", "title": "Syscall Studios Dev Log", "home_page_url": "https://syscallstudios.com/devlog/", "feed_url": "https://syscallstudios.com/feed.json", "description": "Syscall Studios is an independent game studio making systems-driven games about discovery, atmosphere, and the feeling of finally figuring out how something works.", "language": "en", "icon": "https://syscallstudios.com/icon-512.png", "favicon": "https://syscallstudios.com/favicon.ico", "authors": [ { "name": "Syscall Studios", "url": "https://syscallstudios.com/", "avatar": "https://syscallstudios.com/icon-512.png" } ], "items": [ { "id": "https://syscallstudios.com/devlog/project-01-changed/", "url": "https://syscallstudios.com/devlog/project-01-changed/", "title": "Project 01 Changed", "summary": "After eight months of development, we're changing which game will become Syscall Studios' first release. On understanding scope, sunk cost, old projects, and choosing the right first game.", "content_text": "Project 01 changed.\n\nNot a mechanic.\n\nNot the art style.\n\nNot the UI.\n\nThe game.\n\nCompletely.\n\nSo that's fun.\n\n## This wasn't the plan\n\nFor roughly eight months, we've been seriously working on the game we've referred to publicly as Project 01.\n\nDesigning it.\n\nProgramming it.\n\nMaking art for it.\n\nBreaking it.\n\nFixing it.\n\nBreaking it in more sophisticated ways.\n\nWriting enough documentation about it that Future Us will either be extremely grateful or deeply concerned.\n\nIt was the game.\n\nThe first Syscall Studios game.\n\nAnd now it isn't.\n\nWe're changing direction.\n\n## Nothing exploded\n\nThis would probably be easier to explain if something had gone catastrophically wrong.\n\nIt didn't.\n\nThe game works.\n\nWe still like the idea.\n\nWe still want to make it.\n\nThere wasn't some dramatic moment where we stared at the screen and realized:\n\n> Oh.\n\n> This is terrible.\n\nAnd this wasn't really a case of runaway scope creep either.\n\nWe didn't spend eight months continuously adding features until Project 01 somehow became our attempt to simulate the entire known universe.\n\nWe are not making GTA 6.\n\nNobody added a fully functioning municipal tax system.\n\nYet.\n\nWhat changed was our understanding of the scope that was already there.\n\nThere's a big difference between designing a game on paper and actually building enough of it to understand what making the whole thing properly will require.\n\nA feature that sounds relatively straightforward in a design document eventually becomes:\n\nArt.\n\nAnimation.\n\nInterface.\n\nAudio.\n\nEdge cases.\n\nSave data.\n\nContent.\n\nTesting.\n\nMore content.\n\nAnd then all the little pieces connecting it to everything else.\n\nThe design didn't necessarily get larger.\n\nOur estimate of what that design actually costs got more honest.\n\nThat's an important distinction.\n\nAfter eight months, we simply understand the project much better than we did when we started it.\n\nAnd the version of the game we want to make (not some dramatically expanded version, just the game we've been trying to make all along) asks quite a lot from a very small studio.\n\nA lot of environments.\n\nA lot of bespoke visual content.\n\nA lot of animation.\n\nA significant amount of audio.\n\nSeveral areas where quality depends heavily on having enough authored content surrounding the underlying systems.\n\nNone of that makes the project unreasonable.\n\nIt doesn't make it some impossible mega-game.\n\nWith enough time, experience, people, and resources, it's completely achievable. Frankly, very achievable as our second or third game. \n\nBut that's not quite the question we're trying to answer.\n\nThe question is:\n\n> Is this actually the right *first* game for us to make?\n\nNot:\n\n> Do we like it?\n\nNot:\n\n> Can this game exist?\n\nBut:\n\n> Given the studio we are today, is this the smartest project to build first?\n\nThose are very different questions.\n\nAnd eventually they stopped having the same answer.\n\n## The other project\n\nThe funny part is that we're not moving to something new.\n\nWe're moving back to something old.\n\nBefore the current Project 01, there was another project.\n\nWe worked on it for around six months.\n\nThere was code.\n\nThere were systems.\n\nThere were designs.\n\nThere were experiments.\n\nThere were, naturally, several things held together through methods we will generously describe as:\n\n> Prototype engineering.\n\nEventually we put it aside.\n\nNot because we hated it.\n\nNot because it fundamentally didn't work.\n\nWe just moved on to something else.\n\nFor a while, that was that.\n\nExcept apparently six months of working on something leaves a fairly persistent little process running in the background of your brain.\n\nBecause we kept coming back to it.\n\nNot necessarily to work on it.\n\nJust to talk about it.\n\nA design problem in Project 01 would remind us of something from the old project.\n\nA system we'd build would make us think about how differently it could be used there.\n\nAn idea would come up.\n\nThen another.\n\nEvery so often we'd open an old document.\n\nVery normal behavior for a project we've definitely moved on from.\n\n## Then we made the mistake of looking at it seriously\n\nAt some point, we stopped treating the old project as an interesting thing from the past and started evaluating it like an actual production again.\n\nWhat would it take to finish?\n\nWhat were the expensive parts?\n\nWhat could be systemic?\n\nWhat needed bespoke content?\n\nWhat had we learned since the last time we touched it?\n\nWhat would we do differently now?\n\nAnd, somewhat inconveniently, the answers were good.\n\nReally good.\n\nA lot of the things we've learned over the last eight months actually make us better equipped to build it now than we were when we stopped.\n\nWe've learned more about architecture.\n\nMore about scope.\n\nMore about art production.\n\nMore about what needs to be data-driven.\n\nMore about which systems are worth making flexible.\n\nAnd significantly more about the difference between:\n\n> This would be cool.\n\nand:\n\n> We can actually make this.\n\nThat second category has become much more interesting lately.\n\n## Practical is not a dirty word\n\nThere's a version of creative decision-making where \"practical\" sounds depressing.\n\nLike choosing a project because it's practical means choosing the less interesting one.\n\nWe don't think that's true.\n\nThis isn't really about making a smaller game.\n\nAnd it definitely isn't about making a less ambitious one.\n\nIt's about where that ambition lives.\n\nEvery game has a production shape.\n\nOne game might depend heavily on hundreds of bespoke environments.\n\nAnother might need enormous amounts of animation.\n\nAnother might live or die based on authored narrative.\n\nAnother can put a much larger percentage of its complexity into reusable systems interacting with each other.\n\nNone of those approaches is inherently better.\n\nBut they require very different studios to make efficiently.\n\nAnd we're starting to understand what kind of studio Syscall actually is.\n\nWe like systems.\n\nSimulation.\n\nReusable rules.\n\nThings interacting.\n\nBuilding something once and then discovering ten interesting situations that fall out of it.\n\nUnfortunately, this appears to be a recurring condition.\n\nThe project we're returning to leans much harder into those strengths.\n\nThat doesn't mean it's tiny.\n\nIt doesn't mean it's easy.\n\nIt doesn't mean we're suddenly making Pong because we became frightened by a production schedule.\n\nIt means more of its difficulty exists in areas where a small, technically focused team can get a lot of leverage from the work it does.\n\nThat's a very different thing.\n\nThe current Project 01 could absolutely be made.\n\nWe just think we'll be better at making it after we've shipped something else first.\n\n## Eight months is a lot of work\n\nThere is, obviously, one slightly uncomfortable part of this.\n\nWe've spent eight months on the current Project 01.\n\nThat's not nothing.\n\nThere is code that may never ship.\n\nArt that may never ship.\n\nDesign work that now belongs to a game we're no longer actively building.\n\nSystems we spent days getting right.\n\nProblems we solved that we didn't technically need to solve yet.\n\nThe tiny sunk-cost goblin living in every project manager's brain has opinions about this.\n\nIt says:\n\n> But look how much work we've already done.\n\nWhich is true.\n\nVery observant goblin.\n\nThe problem is that another eight months doesn't make the previous eight more valuable.\n\nIf we're going to make this decision eventually, doing it later mostly means spending more time before making it.\n\nAnd we'd much rather put the current Project 01 aside while we still like it than grind it down until we resent the thing.\n\nIt deserves better than becoming:\n\n> The game we had to finish because we started it first.\n\n## The work wasn't wasted\n\nThis is the part that sounds suspiciously like something people say to make themselves feel better.\n\nBut it's also true.\n\nThe studio that started Project 01 eight months ago and the studio making this decision now are not quite the same.\n\nWe know more.\n\nWe've built things.\n\nWe've thrown things away.\n\nWe've learned which abstractions actually help.\n\nWe've learned which abstractions are just programmers discovering a more academically interesting way to avoid making the game.\n\nWe've developed an art direction.\n\nWe've thought much harder about production.\n\nWe've gotten better at recognizing when temporary code is becoming permanent architecture.\n\nWe've developed stronger opinions about what we want a Syscall Studios game to feel like.\n\nThe old Project 01 caused a lot of that.\n\nThose lessons don't disappear because the executable changes.\n\nSome of them are already finding their way into what comes next.\n\nAnd the six months we spent on the project we're returning to weren't wasted either.\n\nWe're not starting from a blank Unity project and a paragraph in a notes app.\n\nThere are ideas there that have already been tested.\n\nSystems we've already thought through once.\n\nProblems we've already encountered.\n\nThings we know we want to keep.\n\nThings we now know we absolutely do not.\n\nWe're getting to approach an old project with a much better understanding of how we actually want to build games.\n\nThat's a pretty useful place to start.\n\n## So what happens now?\n\nFor the moment?\n\nWe're still not announcing the game.\n\nSorry.\n\nWe know.\n\nThis is becoming a bit.\n\nBut Project 01 now refers to a different project internally.\n\nA project we've actually known for quite a while.\n\nOne that already has history here.\n\nOne we're approaching very differently the second time around.\n\nAnd one that, after spending a lot of time looking at what it would actually take to build both games properly, makes much more sense as our first release.\n\nThe game we've been working on for the last eight months isn't cancelled.\n\nIt's going back on the shelf.\n\nWe'll come back to it.\n\nHopefully with more experience, more resources, and a shipped game behind us.\n\nFor now, we're returning to something familiar.\n\nfor the first time in a while, we're reopening old systems instead of starting from an empty project.\n\na lot of what was there still makes sense, although six months away from something gives you a pretty good list of things you'd do differently.\n\nit also happens to be the kind of game where an ordinary place can look very different once the sun goes down.\n\nright now, that's probably as specific as we're going to get.\n\nbut there are plenty of old systems to revisit.\n\nold assumptions to question.\n\nunderneath all of it is a project we're genuinely excited to come back to.\n\nnot everything from six months ago is going to survive the trip.\n\ndeveloping it again is going to be interesting.\n\nA frankly irresponsible number of design documents still need updating.\n\nAnd quite a lot of work lies ahead.\n\nProject 01 changed.\n\nSyscall Studios didn't.\n\nMore soon.", "image": "https://syscallstudios.com/og/devlog/project-01-changed.png", "date_published": "2026-10-02T22:00:00.000Z", "date_modified": "2026-10-02T22:00:00.000Z", "tags": [ "Studio", "Development", "Process", "Project 01" ], "authors": [ { "name": "Syscall Studios", "url": "https://syscallstudios.com/", "avatar": "https://syscallstudios.com/icon-512.png" } ] }, { "id": "https://syscallstudios.com/devlog/placeholder-art-is-lying-to-you/", "url": "https://syscallstudios.com/devlog/placeholder-art-is-lying-to-you/", "title": "Placeholder Art Is Lying to You", "summary": "Placeholder art is essential for prototyping. It's also great at making good mechanics feel terrible. What we're learning about game feel, polish, and fidelity.", "content_text": "Placeholder art is great.\n\nWe use it constantly.\n\nBoxes.\n\nCapsules.\n\nGray materials.\n\nIcons someone made in approximately twelve seconds.\n\nText labels that say things like:\n\n`THING`\n\nor:\n\n`TEMP`\n\nor, if we're feeling particularly organized:\n\n`TEMP_THING_02`\n\nIt's fast.\n\nIt's ugly.\n\nIt lets us test ideas before spending time making them look good.\n\nPerfect.\n\nThere's just one problem.\n\nPlaceholder art is a liar.\n\n## \"This feels terrible\"\n\nYou build a mechanic.\n\nTechnically, it works.\n\nBut something feels wrong.\n\nIt feels cheap.\n\nThe interaction feels flat.\n\nNothing has weight.\n\nNothing feels satisfying.\n\nYou start wondering if the whole idea is bad.\n\nMaybe the mechanic doesn't work.\n\nMaybe the design was wrong from the beginning.\n\nMaybe this entire feature needs to be cut.\n\nOr...\n\nMaybe you're interacting with a bright gray cube called:\n\n`TEST_OBJECT`\n\nthat teleports three feet to the left when you click it.\n\nPossibly not the fairest evaluation environment.\n\n## Presentation changes how mechanics feel\n\nThis sounds obvious when you write it down.\n\nOf course animation matters.\n\nOf course sound matters.\n\nOf course visual feedback matters.\n\nBut when you're actually developing something, it's surprisingly easy to mentally separate:\n\n> the mechanic\n\nfrom:\n\n> the presentation.\n\nAs if there's a clean line between them.\n\nThere often isn't.\n\nA button that responds instantly feels different from one that eases into position.\n\nAn object that snaps from Point A to Point B feels different from one that has weight and momentum.\n\nAn interaction with a little sound, motion, and feedback can suddenly feel obvious when the exact same interaction felt confusing five minutes earlier.\n\nThe underlying rules didn't change.\n\nThe player's experience of those rules did.\n\nThat's important.\n\n## But placeholder art is also doing its job\n\nNone of this means everything needs final art before we can test it.\n\nThat would be catastrophic.\n\nImagine needing a finished model, animation set, sound effects, particles, UI treatment, and polished environment every time you wanted to answer:\n\n> Would this mechanic be interesting?\n\nWe would release Project 01 sometime around 2047.\n\nPlaceholder assets exist for a reason.\n\nThey let you throw ideas at the wall quickly.\n\nAnd sometimes the gray cube is enough.\n\nIf moving the gray cube around isn't interesting at all, giving it a beautiful texture probably won't save it.\n\nProbably.\n\nBut there's a point where the lack of presentation starts contaminating the test.\n\nThat's the part we're learning to recognize.\n\n## The opposite problem exists too\n\nPresentation can also make a bad idea look much better than it actually is.\n\nThis may be more dangerous.\n\nGive something a satisfying animation.\n\nAdd a nice sound.\n\nPut some particles on it.\n\nMaybe give the screen a tiny shake.\n\nSuddenly:\n\n> Oh wow, this is great.\n\nIs it?\n\nOr did we just put enough juice on a mediocre mechanic that our monkey brains started applauding?\n\nThis is where things get annoying.\n\nBecause now placeholder art can make good things feel bad **and** polish can make bad things feel good.\n\nVery helpful.\n\nThank you, game development.\n\n## There are different questions\n\nWe're starting to think the useful approach is figuring out exactly what we're testing.\n\nIf the question is:\n\n> Does this system logically work?\n\nGray boxes are probably fine.\n\nIf the question is:\n\n> Is this interaction satisfying?\n\nThe gray boxes may no longer be enough.\n\nIf the question is:\n\n> Does the player understand what happened?\n\nThen visual hierarchy, animation, sound, and interface feedback might actually be part of the mechanic we're testing.\n\nAnd if the question is:\n\n> Does this look good?\n\nWell.\n\nProbably stop using the gray cube.\n\nDifferent tests need different levels of fidelity.\n\nWhich sounds incredibly obvious.\n\nWe have still gotten this wrong.\n\nRepeatedly.\n\n## Art can change design\n\nThere's another interesting side effect.\n\nSometimes replacing placeholder assets doesn't just make an existing feature look better.\n\nIt changes how we think the feature should work.\n\nAn object gets its actual proportions and suddenly the interaction designed around the placeholder no longer makes sense.\n\nAn environment gains real scale and something that felt conveniently close is now annoyingly far away.\n\nA real animation takes longer than the instant placeholder transition, which changes the pacing.\n\nAn interface gets actual typography and suddenly the amount of information we thought would fit comfortably absolutely does not.\n\nWho could have possibly foreseen that `Lorem ipsum` was not a representative final UI element?\n\nCertainly not us.\n\nSo art isn't always the layer you add after design.\n\nSometimes it feeds back into design.\n\nThe two are constantly arguing with each other.\n\nUsually that's a good thing.\n\n## The challenge is knowing when to care\n\nWe don't want to polish things too early.\n\nPolished garbage is still garbage, except now you've spent significantly more time on it.\n\nBut we also don't want to throw away an idea because the temporary version was incapable of communicating what made the idea interesting in the first place.\n\nSo the question becomes:\n\n> Is the placeholder showing us the mechanic clearly enough to judge it?\n\nIf yes, great.\n\nKeep moving.\n\nIf no, maybe it needs just enough animation, sound, art, or feedback to make the test honest.\n\nNot final.\n\nNot beautiful.\n\nJust honest.\n\n## The current collection of nonsense\n\nProject 01 currently contains plenty of things that are somewhere between:\n\n> prototype\n\nand:\n\n> please don't let anyone outside the studio see this.\n\nThere are assets that exist purely to answer questions.\n\nThere are objects whose appearance is not remotely representative of where they're headed.\n\nThere are things that will absolutely be replaced.\n\nProbably.\n\nSee our [previous post](/devlog/the-danger-of-temporary/) regarding the word \"temporary.\"\n\nBut we're slowly getting better at knowing when something can stay ugly and when the ugliness itself has become part of the problem.\n\nThat's a surprisingly useful distinction.\n\nPlaceholder art is supposed to lie about what the final game will **look** like.\n\nWe just have to make sure it isn't also lying about what the final game will **feel** like.", "image": "https://syscallstudios.com/og/devlog/placeholder-art-is-lying-to-you.png", "date_published": "2026-10-01T17:00:00.000Z", "date_modified": "2026-10-01T17:00:00.000Z", "tags": [ "Development", "Art", "Game Design", "Prototyping", "Game Feel" ], "authors": [ { "name": "Syscall Studios", "url": "https://syscallstudios.com/", "avatar": "https://syscallstudios.com/icon-512.png" } ] }, { "id": "https://syscallstudios.com/devlog/the-game-looks-exactly-the-same/", "url": "https://syscallstudios.com/devlog/the-game-looks-exactly-the-same/", "title": "The Game Looks Exactly the Same", "summary": "A week of game development, and the game looks exactly like it did on Monday. On refactoring, invisible work, and why screenshots are a bad measure of progress.", "content_text": "Sometimes you spend an entire week working on a game.\n\nYou write a bunch of code.\n\nYou tear apart a system that technically worked.\n\nYou rebuild half of it.\n\nYou fix six bugs.\n\nYou create three new ones.\n\nYou reorganize things.\n\nYou test everything.\n\nYou finally get to Friday, launch the game, look at the screen and think:\n\n> Huh.\n\nIt looks exactly the same.\n\nCool.\n\n## The invisible work\n\nThis is something we're running into more and more as Project 01 develops.\n\nEarly on, progress is really easy to see.\n\nYou add an object.\n\nThere is now an object.\n\nYou add a menu.\n\nThere is now a menu.\n\nYou make something move.\n\nIt moves.\n\nExcellent.\n\nProgress.\n\nBut eventually you reach a point where more and more development happens underneath everything the player actually sees.\n\nAnd that's where things get weird.\n\nYou can spend hours changing how two systems communicate with each other and, if you did your job correctly, the player will notice absolutely nothing.\n\nThat is the goal.\n\nYou worked all day so nothing would happen.\n\nGame development is a very normal profession.\n\n## \"What did you work on today?\"\n\nThis also makes answering that question surprisingly difficult sometimes.\n\nImagine someone asking what you accomplished today and the answer is:\n\n> Well, yesterday when this thing happened, System A directly told System B to do something, but System B shouldn't actually know that System A exists, so now System A tells System C that something happened and System C...\n\nTheir eyes are already glazing over.\n\nUnderstandably.\n\nSo you eventually just say:\n\n> Backend stuff.\n\nWhich makes it sound like you spent the day moving buttons around in an admin panel.\n\nBut a lot of game development is exactly that kind of invisible plumbing.\n\nThings need to know when other things happen.\n\nThings need to stop knowing about things they shouldn't know about.\n\nData needs to exist somewhere sensible.\n\nObjects need to survive being created, destroyed, loaded, unloaded, moved, saved, restored, and occasionally abused in ways you did not anticipate.\n\nNone of that necessarily changes a screenshot.\n\n## The screenshot problem\n\nScreenshots are a terrible way to measure progress.\n\nUseful for showing a game?\n\nAbsolutely.\n\nUseful for figuring out whether the project is healthier than it was last week?\n\nNot always.\n\nYou can make a screenshot dramatically prettier while making the project substantially worse.\n\nYou can also spend a week making the underlying game dramatically better while producing two screenshots that are pixel-for-pixel identical.\n\nThat makes development updates a little awkward sometimes.\n\nEspecially while we're still [keeping Project 01 quiet](/devlog/building-before-announcing/).\n\nWe can say:\n\n> We made a lot of progress this week.\n\nAnd technically that's true.\n\nBut if we showed you before and after images, you'd probably start playing spot-the-difference.\n\nThere may not be a difference.\n\nThat's the point.\n\n## Boring work has compounding returns\n\nThe nice thing about invisible work is that it usually isn't really about today.\n\nIt's about making tomorrow easier.\n\nMaybe we clean up a system now so adding the next feature takes two hours instead of two days.\n\nMaybe we separate two pieces of code so changing one doesn't mysteriously break the other.\n\nMaybe we make something data-driven instead of hardcoded so we don't have to manually repeat the same work fifty times later.\n\nNone of these things are particularly exciting in isolation.\n\nBut they compound.\n\nA project where every new feature is fighting everything that came before it eventually becomes miserable to work on.\n\nA project where the underlying systems are reasonably healthy gives you room to experiment.\n\nAnd experimentation is kind of important when you're still figuring out what the game wants to be.\n\n## Of course, there's a trap\n\nThis is also an excellent excuse for programmers to disappear into a cave for three weeks and emerge proudly announcing:\n\n> I rewrote the inventory system.\n\nWhy?\n\n> Architecture.\n\nWas anything actually wrong with it?\n\n> Architecture.\n\nDoes the player care?\n\n> **Architecture.**\n\nSo there is obviously a balance here.\n\nNot every ugly piece of code needs to become a beautiful abstraction.\n\nNot every system needs to be future-proofed against fourteen hypothetical games we may never make.\n\nAnd \"cleaning things up\" can very easily become a sophisticated form of procrastination.\n\nSometimes the ugly thing works.\n\nSometimes the correct architectural decision is:\n\n> Leave it alone and make the game.\n\nWe're getting better at figuring out which is which.\n\nMostly.\n\n## Progress doesn't always photograph well\n\nThe strange thing is that some of the work we're happiest with lately would make absolutely terrible social media posts.\n\nHere's the game before:\n\n`[ screenshot ]`\n\nHere's the game after:\n\n`[ the exact same screenshot ]`\n\nHuge week.\n\nBut underneath that screenshot, maybe something that used to be fragile isn't fragile anymore.\n\nMaybe a system we were afraid to touch is now easy to change.\n\nMaybe five future features just became significantly easier to build.\n\nMaybe [Future Us](/devlog/the-danger-of-temporary/) is going to open that code six months from now and, instead of saying:\n\n> What idiot wrote this?\n\nwe'll say:\n\n> Oh.\n\n> This actually makes sense.\n\nLet's not get too ambitious.\n\nBut that's the dream.\n\nProject 01 looks pretty similar today to how it looked yesterday.\n\nA surprising amount has changed anyway.", "image": "https://syscallstudios.com/og/devlog/the-game-looks-exactly-the-same.png", "date_published": "2026-09-25T17:00:00.000Z", "date_modified": "2026-09-25T17:00:00.000Z", "tags": [ "Development", "Programming", "Process", "Refactoring" ], "authors": [ { "name": "Syscall Studios", "url": "https://syscallstudios.com/", "avatar": "https://syscallstudios.com/icon-512.png" } ] }, { "id": "https://syscallstudios.com/devlog/the-danger-of-temporary/", "url": "https://syscallstudios.com/devlog/the-danger-of-temporary/", "title": "Temporary Is a Dangerous Word", "summary": "Nothing is more permanent than a temporary solution. How game prototypes quietly become architecture, and how we decide when technical debt is worth it.", "content_text": "There is a phrase that should probably trigger some kind of alarm in a game development project:\n\n> \"It's temporary.\"\n\nWe say it constantly.\n\nThis model is temporary.\n\nThis UI is temporary.\n\nThis script is temporary.\n\nThis entire system is temporary.\n\nWe'll clean it up later.\n\nAnd sometimes that's completely fine.\n\nYou need ugly prototypes.\n\nYou need placeholder art.\n\nYou need the button that is literally just a gray rectangle saying `TEST BUTTON`.\n\nIf every experiment had to be production-ready before you could use it, nothing would ever get built.\n\nThe problem is that temporary things have a remarkable ability to survive.\n\nThere's an old saying:\n\n\"Nothing is more permanent than a temporary solution.\"\n\nAnd it couldn't be more true.\n\n## The lifecycle of a temporary system\n\nIt usually goes something like this:\n\n1. We need to test an idea.\n2. We build the absolute minimum required to test it.\n3. It works.\n4. Great.\n5. We build something else that uses it.\n6. Then something else uses *that*.\n7. Then another system needs information from the first system.\n8. Three weeks pass.\n9. Someone opens the original code.\n10. Oh no.\n\nWhat started as:\n\n> \"Just make this work for now.\"\n\nhas quietly become:\n\n> \"Removing this would currently destroy approximately 40% of the game.\"\n\nVery cool.\n\nVery healthy.\n\nDefinitely not an [XKCD Comic](https://xkcd.com/2347/) that we have all seen...\n\n## Prototypes are supposed to be ugly\n\nTo be clear, we're not trying to avoid this entirely.\n\nThat would probably be worse.\n\nThere is a version of software development where you become so afraid of technical debt that every tiny feature gets designed like it's going to run a nuclear power plant for the next thirty years.\n\nWe're making a game.\n\nSometimes we genuinely just need to know:\n\n**Is this fun?**\n\nAnd spending three days designing the perfect architecture for something we're going to delete tomorrow would be ridiculous.\n\nSo we're trying to get better at recognizing two different kinds of temporary.\n\nThere's:\n\n> **Temporary because we're testing the idea.**\n\nAnd then there's:\n\n> **Temporary because we don't feel like solving the actual problem yet.**\n\nThose look suspiciously similar in the moment.\n\nThey are not the same thing.\n\n## \"We'll fix it later\"\n\nLater is a magical place.\n\nEverything gets fixed there.\n\nThe code gets cleaned up later.\n\nThe placeholder animations get replaced later.\n\nThe UI gets reorganized later.\n\nNaming conventions become consistent later.\n\nThat one weird interaction nobody understands?\n\nLater.\n\nUnfortunately, Future Us appears to already have a fairly substantial backlog.\n\nSo we're trying to be slightly nicer to them.\n\nNot by polishing everything immediately, but by stopping occasionally and asking:\n\n> If this survives longer than we're expecting, how painful is that going to be?\n\nSometimes the answer is:\n\nNot very.\n\nShip the ugly version.\n\nSometimes the answer is:\n\nThis will infect literally everything we build after it.\n\nMaybe deal with that now.\n\n## The boring stuff matters\n\nThis is one of the strange things about game development that isn't particularly visible from the outside.\n\nSometimes the most important work happening on a project produces absolutely nothing interesting to look at.\n\nYou can spend an entire day reorganizing how a few systems communicate with each other.\n\nAt the end of the day, [the game looks exactly the same](/devlog/the-game-looks-exactly-the-same/).\n\nMaybe it even runs exactly the same.\n\nBut now changing something six months from now won't require sacrificing a goat and rewriting half the project.\n\nHopefully.\n\nNo guarantees on the goat.\n\nThat work isn't exciting in a trailer.\n\nIt's very exciting when you're the person who has to maintain the project.\n\n## We're already guilty\n\nProject 01 is still early, and we've already had several moments where something built as a quick test started accumulating responsibilities it was never designed to have.\n\nWhich is probably unavoidable.\n\nWe're learning what the game actually needs while we're building it.\n\nYou can't perfectly architect a system around requirements you don't know yet.\n\nAnd we'd rather discover those requirements by making the game than spend six months designing an incredibly elegant architecture for the wrong game.\n\nSo the goal isn't:\n\n> Never create technical debt.\n\nIt's probably closer to:\n\n> Know when you're creating it.\n\nAnd maybe leave a note.\n\nA very apologetic note.\n\n## The current rule\n\nRight now, we've landed on something roughly like this:\n\nIf we're experimenting with whether something should exist at all, **build it fast**.\n\nIf we're confident it's going to become a foundation for other systems, **slow down and think about it**.\n\nAnd if something temporary suddenly has six other systems depending on it?\n\nCongratulations.\n\nIt is no longer temporary.\n\nPlease update the documentation accordingly.\n\nWe'll almost certainly violate this rule again.\n\nProbably this week.\n\nBut hey, now there's a Dev Log post we can link to while yelling at each other for doing it.", "image": "https://syscallstudios.com/og/devlog/the-danger-of-temporary.png", "date_published": "2026-09-21T18:00:00.000Z", "date_modified": "2026-09-21T18:00:00.000Z", "tags": [ "Development", "Programming", "Process", "Technical Debt", "Prototyping" ], "authors": [ { "name": "Syscall Studios", "url": "https://syscallstudios.com/", "avatar": "https://syscallstudios.com/icon-512.png" } ] }, { "id": "https://syscallstudios.com/devlog/simple-but-not-simplistic/", "url": "https://syscallstudios.com/devlog/simple-but-not-simplistic/", "title": "Simple, But Not Simplistic", "summary": "The game design principle behind our first game: make systems easy to understand without making them shallow, from Minecraft's Redstone to skill trees.", "content_text": "One phrase has started showing up repeatedly while we're working on Project 01:\n\n> **Simple, but not simplistic.**\n\nIt's become a useful shorthand for a surprisingly large number of design decisions.\n\n## Simplicity isn't the absence of depth\n\nThere's a temptation when designing a complicated system to communicate that depth by showing the player everything.\n\nMore buttons.\n\nMore statistics.\n\nMore menus.\n\nMore labels.\n\nMore information.\n\nSometimes that's necessary.\n\nSometimes it just means we've moved the complexity from the game into the interface.\n\nWe're much more interested in systems that become understandable through interaction.\n\nThe player shouldn't need a manual just to understand what the game is asking them to do.\n\nBut that doesn't mean the thing they're doing has to be shallow.\n\n## The difference between complicated and complex\n\nThose words sound similar, but we're starting to think about them very differently.\n\nA complicated system can have a lot of parts.\n\nA complex system can have relatively simple parts that interact in interesting ways.\n\n**Redstone in Minecraft is a great example.**\n\nAt its core, [Redstone](https://minecraft.wiki/w/Redstone_circuits) gives the player a relatively small collection of understandable building blocks: redstone dust, buttons, torches, repeaters, pistons, and a small selection of other components.\n\nNone of those pieces are especially complicated on their own.\n\nBut because they interact through a small set of consistent rules, people have used them to build everything from automatic doors to calculators, memory circuits, and literal functioning computers.\n\nThe depth doesn't come from Minecraft giving you a \"build computer\" block.\n\nIt comes from simple pieces being allowed to combine in ways the designers didn't have to individually prescribe.\n\nThat's the kind of complexity we find interesting.\n\nThe opposite is something you see in a lot of progression systems: dozens of upgrades, sprawling skill trees, multiple currencies, hundreds of percentage modifiers, and an intimidating number of apparent choices.\n\nYou can spend twenty minutes deciding whether to take one branch or another, only to discover that both paths ultimately amount to:\n\n> Your character now does a little more damage.\n\nThere may be a tremendous amount of *stuff* in the system, but if most of the decisions converge on roughly the same outcome, all of that complication hasn't necessarily created much depth.\n\nWe'd rather have a handful of meaningful rules that can produce unexpected situations than a hundred options that all eventually resolve to `+5% DPS`.\n\nThat philosophy affects more than mechanics.\n\nIt applies to interfaces.\n\nArt.\n\nAnimation.\n\nProgression.\n\nLevel design.\n\nEven sound.\n\n## Let the player understand things\n\nOne of our favorite kinds of progression has nothing to do with numbers.\n\nIt's when the player gets better because **they understand the game better**.\n\nMaybe they recognize a pattern faster.\n\nMaybe they realize two systems interact.\n\nMaybe something that originally seemed confusing becomes obvious because they now understand why it behaves the way it does.\n\nThe game didn't secretly add +10 to their Understanding stat.\n\nThe player learned something.\n\nThat's a powerful feeling.\n\nAnd we're interested in [building around it](/about/).\n\n## Visual simplicity matters too\n\nWe're taking a similar approach visually.\n\nMore detail does not automatically create a more believable world.\n\nSometimes the opposite happens.\n\nIf every surface, object, and interface element is screaming for attention, nothing feels important.\n\nWe're aiming for strong shapes, clear visual hierarchy, believable materials, and detail where the detail actually contributes something.\n\nThe goal isn't minimalism.\n\nThe goal is intentionality.\n\nWe want an object to contain enough information for your brain to understand what it is without having to reproduce every scratch, screw, seam, and manufacturing mark that exists on the real thing.\n\nSimple.\n\nNot simplistic.\n\n## The difficult part\n\nOf course, saying this is much easier than doing it.\n\nRemoving unnecessary complexity requires knowing which complexity is unnecessary.\n\nAnd sometimes the weird little detail that looks expendable ends up being the thing that makes an interaction satisfying.\n\nSo a lot of development currently looks like this:\n\n1. Build the thing.\n2. Realize the thing is too complicated.\n3. Simplify the thing.\n4. Realize we removed something important.\n5. Put part of the thing back.\n6. Somehow discover a completely unrelated problem.\n7. Repeat.\n\nScientific stuff.\n\n## A useful filter\n\nWe're starting to use a simple question when evaluating features:\n\n> Does this add depth, or does it just add work?\n\nSometimes the answer is both.\n\nBut asking the question has been useful.\n\nProject 01 still has a long way to go, and plenty of these ideas will continue evolving as we build it.\n\nBut \"simple, not simplistic\" is becoming one of the principles we keep coming back to.\n\nThat's usually a sign it's worth writing down.", "image": "https://syscallstudios.com/og/devlog/simple-but-not-simplistic.png", "date_published": "2026-09-15T16:00:00.000Z", "date_modified": "2026-09-15T16:00:00.000Z", "tags": [ "Game Design", "Development", "Philosophy" ], "authors": [ { "name": "Syscall Studios", "url": "https://syscallstudios.com/", "avatar": "https://syscallstudios.com/icon-512.png" } ] }, { "id": "https://syscallstudios.com/devlog/building-before-announcing/", "url": "https://syscallstudios.com/devlog/building-before-announcing/", "title": "Building Before Announcing", "summary": "Why we're keeping our first indie game, Project 01, under wraps, and what early game development looks like before there's anything to announce.", "content_text": "There's a slightly strange part of starting a game studio where you're doing a tremendous amount of work while publicly having almost nothing to show for it.\n\nThat's roughly where we are.\n\nProject 01 is real.\n\nIt's in active development.\n\nAnd we're deliberately not announcing it yet.\n\n## Why stay quiet?\n\nMostly because we want the game to have enough of an identity before we ask anyone else to care about it.\n\nEarly development changes constantly.\n\nYou can spend several days building a feature, play with it for ten minutes, and realize the entire approach was wrong.\n\nYou can build an environment that technically contains everything it needs and still discover that it doesn't *feel* right.\n\nYou can write systems that work perfectly in isolation and immediately fall apart once they have to interact with the rest of the game.\n\nThat's useful work.\n\nIt just isn't necessarily useful marketing material.\n\nWe'd rather make those decisions while we still have the freedom to make them.\n\n### Foundations first\n\nA lot of our current work isn't flashy.\n\nIt's the stuff everything else eventually depends on.\n\nWe're spending time thinking about questions like:\n\n- How should interacting with the world feel?\n- How much information should the game explain?\n- How much should the player discover themselves?\n- Which systems need to be flexible enough to support later ideas?\n- What should feel physical instead of abstract?\n- How do we keep complexity understandable?\n- What visual details actually matter?\n\nThose aren't features you can easily summarize with a flashy GIF.\n\nBut they affect almost everything that comes afterward.\n\n### The dangerous version of \"temporary\"\n\nOne thing we're trying to avoid is building too much around assumptions we already know are temporary.\n\nGame development produces a lot of:\n\n> We'll fix that later.\n\nSometimes that's completely reasonable.\n\nSometimes six months later you've built fourteen other systems on top of the thing you were definitely going to fix later.\n\nWe're trying to be deliberate about which shortcuts are [actually temporary](/devlog/the-danger-of-temporary/) and which ones quietly become architecture.\n\nThat doesn't mean we're attempting to engineer the perfect system before moving on.\n\nThat would be another great way to never finish anything.\n\nIt means trying to understand which decisions are cheap to change later and which ones aren't.\n\n## Finding the game\n\nThere's another reason we're staying quiet.\n\nWe're still learning things about the game ourselves.\n\nNot the broad idea.\n\nThe smaller things.\n\nThe things that determine whether interacting with it for an hour is actually enjoyable.\n\nHow fast should something happen?\n\nHow much control should the player have?\n\nWhen should the game assist you?\n\nWhen should it stay out of your way?\n\nHow much detail makes something interesting before that detail becomes noise?\n\nThose answers generally don't come from design documents.\n\nThey come from building something, using it, and noticing what feels wrong.\n\nThen doing it again.\n\n## When do we show it?\n\nWhen there's something worth showing.\n\nThat's the incredibly sophisticated marketing strategy.\n\nWe're not interested in announcing a logo for a game that barely exists, spending the next year explaining that we're \"still cooking,\" and then slowly discovering that half of what we originally announced no longer represents the game.\n\nAt the same time, we didn't want to disappear completely until reveal day.\n\nWe're building more than a game right now. We're also building **Syscall Studios**.\n\nSo while Project 01 stays under wraps, we still want to start putting ourselves out there. We want people to get to know how we think, how we work, what we care about, and what kind of studio we're trying to become.\n\nIdeally, by the time you get to know our first game, you'll already know a little bit about **us**.\n\nThat's part of what this Dev Log is for.\n\nEventually Project 01 will stop being `[ CLASSIFIED ]`.\n\nFor now, the work continues.", "image": "https://syscallstudios.com/og/devlog/building-before-announcing.png", "date_published": "2026-09-09T17:00:00.000Z", "date_modified": "2026-09-09T17:00:00.000Z", "tags": [ "Studio", "Development", "Process", "Marketing" ], "authors": [ { "name": "Syscall Studios", "url": "https://syscallstudios.com/", "avatar": "https://syscallstudios.com/icon-512.png" } ] }, { "id": "https://syscallstudios.com/devlog/hello-world/", "url": "https://syscallstudios.com/devlog/hello-world/", "title": "Hello, World", "summary": "Meet Syscall Studios, a new indie game studio building its first game. Why we're starting a dev log, and what's with the [0x80] in our logo.", "content_text": "Hello, world.\n\nWe're **Syscall Studios**, a small independent game studio currently building our first game.\n\nAnd, at least for now, that's about as much as we're going to tell you about the game itself.\n\nIt's called [Project 01](/games/) around here, it's in active development, and it will stay `[ CLASSIFIED ]` until we think there's something genuinely worth showing.\n\nBut the game isn't the only thing we're building.\n\nWe're also building a studio.\n\nAnd we figured that part didn't need to happen entirely behind closed doors.\n\n## So, hi.\n\nSyscall Studios is interested in games built around curiosity, systems, interaction, and the satisfaction of understanding how something works.\n\nWe like details that have a reason to exist.\n\nWe like worlds that feel believable because their pieces make sense together, not because every surface has four billion polygons.\n\nWe like mechanics that give players room to experiment instead of immediately explaining the correct answer.\n\nAnd we're especially interested in those moments where something that initially seemed complicated suddenly makes sense because **you learned how it works**.\n\nThose ideas are already shaping Project 01.\n\nThey'll probably shape whatever comes after it, too.\n\nAnd, just to get this on the record early:\n\nAll of that could change.\n\nWe're still a brand new studio making our first game. The way we design things, the kinds of games we want to make, even the things we think we're \"definitely\" sure about right now will probably evolve as we actually do this.\n\nFuture us may read this post and disagree with half of it.\n\nThat's probably healthy.\n\nWe're not trying to carve a permanent manifesto into stone. We're documenting what we believe **right now**, while leaving ourselves room to learn, change our minds, and occasionally realize that an idea we were very confident about was, in fact, terrible.\n\nConsider this less of a constitution and more of a commit message.\n\nWe reserve the right to `git revert` any of our deeply held design philosophies.\n\n## Why start talking now?\n\nThere's a slightly awkward period at the beginning of building a game where you're doing an enormous amount of work and have almost nothing you're ready to publicly show.\n\nThat's where we are.\n\nWe could disappear until Project 01 is ready for a reveal.\n\nBut we don't really want your first interaction with Syscall Studios to be a trailer suddenly appearing in your feed one day.\n\nWe'd rather you get to know **us** first.\n\nHow we approach problems.\n\nWhat we care about.\n\nWhy we make certain design decisions.\n\nWhat works.\n\nWhat doesn't.\n\nAnd occasionally, what went catastrophically wrong at 2:00 in the morning.\n\nBy the time you get to know our first game, hopefully you'll already know a little bit about the people and ideas behind it.\n\nThat's what this Dev Log is for.\n\n## What are we going to write about?\n\nWhatever seems worth writing down.\n\nSome posts will be about game design.\n\nSome will be technical.\n\nSome might be about art, tools, production, running a tiny studio, or the strange problems that appear when you're trying to turn an idea into an actual piece of software.\n\nWe'll talk about experiments that worked.\n\nWe'll probably talk even more about experiments that didn't.\n\nWhat we *won't* do is turn every post into a carefully sanitized marketing update where everything is always going perfectly.\n\nBecause that isn't game development.\n\nWe're figuring a lot of this out as we go.\n\nThat seems worth documenting.\n\n## What's with `[0x80]`?\n\nThe name **Syscall Studios** comes from system calls: the mechanism programs use to request services from an operating system.\n\nThe `[0x80]` in our logo is a reference to `int 0x80`, the classic system-call interrupt used on 32-bit x86 Linux.\n\nYes, it's nerdy.\n\nWe are aware.\n\nBut the idea behind it fits us surprisingly well.\n\nA system can look simple from the outside while an entire world of interconnected pieces is working underneath it.\n\nUnderstanding those pieces (and what happens when they interact) is interesting to us.\n\nIn software.\n\nIn games.\n\nProbably in far too many other things.\n\n## Starting from zero\n\nThere's something exciting about writing the first post when there's almost nothing here yet.\n\nNo back catalog.\n\nNo released games.\n\nNo giant team page.\n\nJust a studio, a game in development, and a lot of work ahead of us.\n\nEventually this site will look very different.\n\nThere will be games here.\n\nScreenshots.\n\nTrailers.\n\nOld development posts that we'll probably read back and wonder what we were thinking.\n\nBut right now?\n\nThis is where it starts.\n\nProject 01 is compiling.\n\nSyscall Studios is online.\n\nMore soon.", "image": "https://syscallstudios.com/og/devlog/hello-world.png", "date_published": "2026-09-04T12:00:00.000Z", "date_modified": "2026-09-04T12:00:00.000Z", "tags": [ "Studio", "Development", "Indie Games" ], "authors": [ { "name": "Syscall Studios", "url": "https://syscallstudios.com/", "avatar": "https://syscallstudios.com/icon-512.png" } ] } ] }