DevBlog #04
Hey everyone!
I wanted to talk about art, art, and finally art.
As we’re getting closer to releasing the game/demo we’re really striving to get the art/UI to feel like it belongs together. Phill and I don’t enjoy the art process as much as we probably should as game developers.
That said, it doesn’t diminish our bar for quality. We both have a strong vision for how the game should look, so it makes it hard to get the “fast, good, cheap” tradeoffs right. We’re at the stage where the process is refining what we can and cannot fit into the game. It’s starting to not become a choice but a necessity.
I think this is part of the natural game development process. Especially for a two person team like us. There’s only so much we can do and only so much we can control. When we try and fit everything in and meet our deadlines, something has to get cut.
Phill sent me the above graph after one of our discussions about art and I keep going back and looking at it when making decisions. Having visual reminders really helps you process things when you have a lot of competing priorities. It reminds me to focus on the whole product and end goal and not just the task that I’m on currently.
Moving on to our next subject “art”. I’ve been working on implementing the UI elements, which has been fun, but also challenging because of the unique way we’ve built this project. We essentially have to write our own tools to implement our features into the game. Specifically what im referencing is our UI implementation. Most game engines have a way to edit or build menus and other UI elements. We have none, so we’ve written a tool to help us design/implement into the game. It’s kind of wild but cool at the same time. It means I can build the tools as we’re using them.
Creating those tools does slow down the process a bit for now, but hopefully will pay dividends later when our workflow is optimized. It should make future work easier, and if we build another game this way, we won’t be starting from scratch.
I’ve been enjoying the process, but I need to move faster. So my goal is to get this UI stuff into the game as “good enough,” and then take at least one more pass to make it feel polished. I want everything to look and feel good/natural, and again, we both have high standards but have the constraint of time.
For better or worse, that will speed up my process and hopefully be good enough to pass muster.
I didn’t have time to talk about my third topic “art” but maybe I’ll talk about it next time.
-Nate
DevBlog #03
Hi all,
I’ve been super stoked to keep working on the game. My tribulations from working through the netcode are finally coming to an end (I hope). I’ve been teasing talking about the netcode for a while. While it can be boring, I think it might be interesting to aspiring developers, so I wanted to talk about it.
Here’s some context for how we got here.
We were originally thinking of making a website like “https://awbw.amarriner.com/” where you log in to the website and it manages everything for you. We were using a JavaScript/TypeScript React frontend, and I was hosting some servers on a cheaper platform for us to use. As we got further and further down the game-building path, we started wanting things in a standalone client and a website. Facepalm.
So little old me rewrote the WORKING NETCODE to accommodate that as our idea morphed and pivoted. Hey, stay flexible, right? After a while, we realized what we really wanted was a standalone client that we could sell on Steam. So this led to the third (and final!) rewrite of the netcode so it could work through Steam and so we could fully move away from the old web-based setup.
I glossed over a ton of stuff and reasons why, but the big one was that we wanted to be able to sell our product on Steam. There were other reasons too, but that was probably the core one. We wanted to leverage the tools, marketing, and ecosystem that Steam offers.
So what did these rewrites look like?
Initially, the architecture was pretty straightforward: client/frontend talking to server/backend. We were using Postgres to handle the data side of things, along with some clever cookie manipulation to keep track of game state depending on how temporary or permanent we wanted parts of the experience to be.
As we got more serious and saw more potential, we wanted stronger capabilities for our game. So I pitched the idea of, “Hey, we could sell this on Steam.” What would that require? A standalone client, of course. We could still use the website aspect as a demo or have a simpler version of the game up for marketing purposes. We both liked that idea, and I was a bit naive about how much work it would take to maintain a dual architecture like that. Phill doesn’t quite have the same experience with that aspect of netplay, whereas I had quite a bit more. He trusted me to make that decision.
Looking back, I should have realized that it was untenable and redirected us earlier. At the time, though, I thought it would be fine and that we could move forward with it. So I eventually got it working and built a pipeline to deploy on our website, while also wrapping our game in a Tauri client. The problem is that it was a ton of work, and for two people it would basically require one of us to work on the website side of the game while the other worked on the “actual game.” We just don’t have the manpower, time, or bandwidth to execute that. Once I realized what it would cost us and what we would lose, I wanted to make the full switch to Steam. This would reduce our netplay costs significantly, and we could support more online players.
I was really worried about scalability, server costs, hosting, and all the overhead that comes with managing that yourself. Moving our netcode to Steam removed a lot of those concerns. It was a giant pain to do, but I think the game is more resilient because of it.
At some point I will probably slightly decouple it since I really want to have a ranked play system, if we ever figure that out for our game.
Anyway, that rewrite is finally coming to an end three weeks later, and I couldn’t be happier about it. I think it was the right decision. There are still some remnants and bugs from the previous architecture, but I believe it was well worth the pain.
There’s a ton more I could write about this, so if you want me to talk about it more, please let me know and I’ll respond as best I can.
Thanks,
-Nate
DevBlog #02
One thing I’m still figuring out is how much art I can share here during development. Some of the pieces are close to done but not quite there yet and the last 10% can make a huge difference.
Anyway, I wanted to share a little more about the project management aspect of making a game. You kind of need a smorgasbord of skills to get a game moving from scheduling contractors, reviewing art, researching marketing and occasionally beating Metal Gear Solid 3 during an in person devjam session. Those skills are more project based. It’s something that may seem obvious to other people but for me as a developer It’s more fun to just think about the code and product itself.
Fortunately Phill has been taking over a lot of that work so I’ve been blessed with just focusing on the code. It is weird but context switching between all those tasks really takes it out of you and makes you lose focus on the gritty details of the code/design. We’ve recently started creating design documents for each other to reference. As we’ve gotten busier and our time is more fragmented having those documents/design choices to reference really helps our communication while cutting down our “what are you working on?, How does this work again?, “(Phill)Where Am I?”, “(Phill) Is the earth round or flat?”.
With just the two of us we’ve really been able to come a long way very quickly and our work is significantly better because of it. I can’t imagine how solodev’s overcome some of the challenges we’ve encountered. Having a teammate is really important just for sanity checks and morale. A lot of our conversations are hyping each other up before we tackle a big aspect of the project like rewriting the netcode or rewriting all of our art interfaces lol.
With the power of teamwork we are rapidly making progress on the art aspect of our game and I’m really excited to share some of that when we release our steam page which is still a few months off. Next time I’ll talk about my struggles rewriting our network code(exciting!) and I think that’s all I’ve got for now.
-Nate
DevBlog #01
First post!!!
Four months ago my friend Phill and I started building a game on a random Sunday night – https://thirteenknights.tech/about/
I’m excited to share the journey I’ve been a part of in the past 4 months where I’ve encountered all kinds of problems working on something I really have grown to love(and hate sometimes)
INDIE GAMEDEV!!
It’s been a really interesting journey where people’s experiences are going to vary widely.
Me and Phill have always wanted to make a game and this is actually our third attempt at it. We were working in Unreal Engine and I was tired of using all these complex tools and things I didn’t understand as a more traditional corporate developer.
We had a free weekend and Phill was in town so I pitched “Let’s just do a game jam for a weekend” which due to our busy lives and obligations turned into 3 hours of work late on a Sunday night before we both had work in the morning lol.
We had so much fun and made so much progress in those three hours we scrapped our other ideas and started our new work flow in this environment. After that we started taking it more seriously and had such a blast talking about what the game could be that it kind of built itself between our talks and our work.
The pitch was a game inspired by a PS1 game “Brigandine: Grand Edition” – A game I had previously worked on modding/patching when I was in college. Phill and I realized all the fun aspects about the game we liked and wanted to contribute to the community that had brought us so much joy. A strategic turn based tactics RPG where you can grow/level your characters and very importantly.. FIGHT OTHER NERDS ONLINE. It’s always bothered me how these tactics games have not focused on the multiplayer aspect of the gameplay.
And here we are ~4 months into the game process sacrificing our weekends and weekday nights to make this game and it feels closer and yet farther than ever.
I hope to provide more concrete updates in the future but for now I just wanted to share the joy working towards something you’re passionate about can bring. I have loved games my whole life and I’m so excited to try and bring to life the best aspects of all the games I myself have experienced. I’m really excited to share the art and gameplay in our next post. As well as my experience rewriting the netcode 5x which I’m sure everyone will want to hear about =).
-Nate
Support our Patreon!
We are currently in the works of replicating one of our favorite PS1 games – Brigandine! We will be making it online in a web based browser and a slightly more competitive turn based game. We will try and stay faithful to the game as it was but will be making balance patches and tweaking a less faithful game (our emphasis will be multiplayer playability)
