There’s a lot going on in Kanoogiland, and as always I’ll try and provide a bit of an update, but while I’m at it, I want to talk about something I haven’t talked about since I started this project. Let’s dive in and get the business out of the way first.

When I started this project, I quickly shifted from the simplistic idea of developing a fun web game, into the more ambitious idea of building a platform for indie developers. But even as I worked away at that, the website was annoyingly practical. The graphics and design were amateurish, to say the least, due mostly to my stubbornness in using any sophisticated website solutions. Not a whole lot has changed since then, but I did decide to make an improvement pass on it, modernizing it somewhat (the new Kanoogi logo is done in SVG now and looks great at any resolution). While doing so, I took some time to think about what it would be like to login to the site, have a profile, a place to visit the forum (which is coming soonish) and all the sorts of things you might expect. Once I got into it a bit, I realized I needed to step up my game and learn a whole lot more about what it takes to build a website that will scale up and grow as the platform requirements expand. I went on a dive into JWT tokens and all that this entails to have a proper site you can log in and out of. The forum in particular is important to me, as I want to have a place where we can all chat and have public discussions. I want to be able to talk about the project, indie gaming and web technology in general. My son and I are working on this together, as he has just begun learning full stack web development, and it’s turning out to be the perfect team project for us both. This past 6 months I learned more css, .ejs, svg and jwt, and a bunch of other things on the backend, like secrets management. This is apparently what it takes if you want to build your own platform from scratch.

On the game side of things, I made the decision to return to the planet surface, or at least the asteroid surface. I’m so flaky on this it makes me crazy. I talked about it in more detail in previous updates, but to recap, I just can’t find a way to make space combat fun. I realize others have done it, but that doesn’t really change my mind, I need to have my own version of it, something I can understand and apply my game design principles to. So back to the planet’s surface I am going, and with conviction for terrain relief, and obstacles where cat and mouse tactical gameplay shines, with a healthy dose of large scale strategy to go along with it. So that decision is unchanged. Sadly I need to continue reworking the engine to include it, but I’m not giving up on the ability to have some aspect of space combat. Without publishers telling me that I can’t have more money, and strict deadlines, I’m basically doing whatever the heck I want. It’s complicated, it’s probably irresponsible, and it’s a lot of fun to work like this.

As I was thinking about writing this update, I realized that I’ve never talked about my experiences these past 35 years in the game industry on the site much or in these updates. To try and summarize, I’ve worked on a lot of games, I met a lot of people, I traveled to a lot of places, and I did my share of crazy things. But through it all, there are stories I can share, and highlight some amazing people, who were so much fun to hang out with, to share the journey with. Someone might tell me to save those stories for a book, and I used to feel the same way, but the older I get, the more I feel like these stories can be told now, and to some degree, while they are still fresh in my mind. Not all of them are wild and crazy, though some are, and maybe others are better told in a book format, and not a game update on a website, but there are many stories that remain, and I think it would be fun to share them with you.

I wanted to wrap up this update by mentioning something very important to me, and which is also long overdue. I want to give a huge shout out to the passionate and hardworking communities that have continued to keep Total Annihilation and Supreme Commander going in the hearts and minds of a new generation of gamers. Please check out each of these websites for more information about the truly amazing and inspiring work these teams have been doing.

Forged Alliance Forever

Beyond All Reason

Sanctuary: Shattered Sun

I need to talk in more depth about each of these, which is a perfect subject to post and talk about on the Forum… so I better get back to work on that!

I wanted to share this fun thing with regard to AI. Google recently added Gemini (their own competitor to ChatGPT, which was previously called Bard) to Google Docs editor. So it decided to give me a high level summary of what the Kanoogi platform was all about, and it did a pretty good job.

“Kanoogi is a gaming platform that runs in the cloud and renders the game locally on a client. The Kanoogi platform consists of two main parts: a cloud backend and a web client. The cloud backend is responsible for running the game engine and providing game data to the web client. The web client is responsible for rendering the game graphics and handling user input. To play a game on Kanoogi, users simply need to click on a link and the game will load in their browser. There is no need to install any software or updates. Kanoogi is compatible with a wide range of devices, including PCs, Macs, tablets, and smartphones. One of the key features of Kanoogi is its fast loading times. The game is designed to load in seconds, even on slow internet connections. This is possible because the game is rendered on the user's device, rather than being streamed from a server. Kanoogi also supports cross-platform play. This means that players can compete against each other from different devices. Cross-platform play is made possible by the fact that the game is played on the user's device, rather than on a server. Kanoogi is still in development, but it has the potential to revolutionize the way games are played. The platform offers a number of advantages over traditional gaming platforms, including fast loading times, cross-platform play, and no need to install software or updates.”

See you soonish!

Chris Taylor

Here we are at the mid-year point, and it feels like it’s time to drop an update. I do always appreciate the reminder emails I get asking me to get off my tuchas, so here I go. Since the project started you could say the focus was on three pillars, the first of which was web technology, and all the ways in which this was starting to enable developers and designers to build games in a browser. The second pillar was how “The Cloud” would have a profound impact enabling games that would run in the browser. And lastly, the game itself, which includes the design and advances in RTS gameplay that I’ve been thinking about since the last RTS project I worked on, which was the sequel to Supreme Commander. I figured it would be good to review each of those, as they’ve all advanced in some interesting ways.

I’m calling it the Browser, and specifically not the Web Browser. That’s because I don’t think it’s really a Web Browser anymore. Due to all the advancements in the technology, whether it’s processing power (improvements to the Javascript engine and WASM), security (code sandboxing), graphics capability (WebGL and WebGPU) and general API feature set (the ability to tap the native capabilities of the platform it’s running on), the “Web Browser” has emerged as a virtual operating system. How can it not be? The fact that it was originally intended to be a way to browse the internet is no reason to continue to think of it in that limited way as it quite literally has become an abstracted way to operate on any piece of hardware running any flavor of CPU/GPU and system architecture. In short, it went from a way to browse things to running powerful applications that can do, well, almost anything. Resistance for giving it this title in the past came from the idea that it really just wasn’t as good as compiling a native application that did the same thing, and that was fair. If we think of it conceptually as a “gap” between native applications and Browser applications, the gap was noticeably large. That gap has been closing this past decade, and recently the gap has narrowed more than it ever has, to the point where I believe it’s no longer an issue. So, my personal view and philosophy aside, the big news was that WebGPU has now officially launched, and is available in Chrome 113. I’m pretty sure that in the next 6-12 months we’ll see it launch across all the major browsers, and then this will be a done deal. When I started the project, I wasn’t sure how long this would take. There have been some false starts and shifts with Browser technology, so building a business plan around what could happen is a risky proposition. WebGPU is a transformative technology, and the impact on all future graphically rich Browser applications will be huge, and you can tell I’m thrilled by it.

Chrome ships WebGPU

Next up, we have the cloud, and the big news here is Generative AI. Up until early this year, we were just calling it machine learning, or simply AI, and it was cool, it was interesting, but it wasn’t mind-numbingly awesome. Talk about making a grand entrance! It was so huge, it slapped NFTs right out of people’s heads! That sounds like a joke, and it is, but it’s also not. I was never really that fired up about block chain and NFTs, although I can see why the technology is useful, and perhaps even necessary, but Generative AI is on an entirely different level of transforming our everyday life. What I want to point out here is that this really was arguably only possible because of the Internet, and because of Cloud computing. I’m not saying that this technology changes the direction or development arc of the Kanoogi platform and IGSE, but it has sucked a lot of oxygen out of the room. Being the easily distracted and wonderstruck nerd that I am, it sucked up hundreds of hours of reading, research and video watching. What surprised me the most is how a chatbot like ChatGPT or Bard could be asked to generate prompts to instruct an image generating AI like Midjourney or Dall-E on what to render. WTF?! And then there’s generating missing pieces of pictures, sharpening or enhancing visual detail, generating audio from text that’s been trained to a voice, and so forth and so on, to name a few. The list is impressive, but what’s even more impressive is how this list has been growing, every month and sometimes by the week. I could hardly keep up. Now, if we put Generative AI aside for the moment, it’s not like cloud tech has been standing still. Everything seems to get better, all the time, and besides power and capability, cost is going down. My GCP (Google Compute Platform) bill dropped in half this past three months… amazing.

As you can probably guess at this point, my development output on the game itself continues to be slow, and I try not to be unhappy about that. I could make an argument that by dragging my feet these past few years, it’s provided time for some critical browser technology to emerge. This is not untrue, but it’s not a terribly good excuse either, given that time will always do that, and we can’t be standing around forever waiting for the latest tech to eliminate a venture’s risk. However, I also know that life is a balancing act with all the demands that are placed upon us, and though it’s tempting to psychologically unload all the things going on in my life, looking for justification or to be consoled in some way, I’m not going to do that. We all have to walk the path that is right for us, balance the various challenges we face, and accept that we’re doing the best we can and trying to have a little fun along the way.

Moving on to some design stuff, I want to share some thoughts and insights I’ve had as I continue to work and rework the core design ideas for Rock War. I mentioned in an earlier update that I am pivoting away from the idea of the core gameplay taking place in open space, and returning it to ground based combat. I fought with it for years, and decided I couldn’t make it fun, at least not in the way that would satisfy my design sense. I think space combat works well as a complement to a ground based game. If I had to explain it in a sentence, it would be that the outcome of space combat would be almost entirely driven from tech level and resource strength. Reliably predicting the winner would be easy, with no surprise upsets or turnovers (the very thing that makes sports fun to watch). This would translate backwards into a resource gathering game, rewarding the player with higher clicks per second. What I want instead is strategy, and to a less extent, tactics in a roughly 70/30 ratio. Though I can’t say for sure, many RTS games, MOBA included, are probably closer to 40/60, or something like that, truly favoring young players with sharp minds and lightning reflexes. Just for fun, let’s compare that to chess, which is 100/0 where no time limit is imposed. It’s a fun ratio to think about, and who knows, I could be off base here, but it is thought provoking to think about how moving from open space, to a landscape with a lot of map relief can bring strategy into the mix. Stuff I didn’t really think deeply about back in ‘96! When I think about terrain, and how a player can use it to reinforce strategy, it turns assaults into puzzles, where the player has to think deeply about one approach over another. It’s ultimately what makes winning so rewarding! Allowing words like clever, tricky, surprising, innovative and sneaky to be used when describing a game... is a winning design philosophy to me. Though I’m not giving up on Space, I’m thinking of including maps that take place on Earth, it’s a worthwhile thing to consider.

I’d love for any of you who just read that, to marinate on it for a week, and put some deep strategic thought of your own into what makes an RTS game fun for you. Ask yourself the question when you reflect on the last game you played, and where you invested your time, and at what point you had the most fun. How much “hard thinking” do you like to do vs. scrolling and clicking at high speed? If you like, send me your thoughts, don’t hold back, and let your opinion fly! And besides the critical and creative feedback, I’d still like to encourage you to tell me your story. I especially love the ones where you first played TA or SupCom. Those are so heartwarming and fun to read, they really brighten my day as I continue on this journey.

Until next time...

Chris Taylor

Welcome to the latest update, and yes, just as late, if not more late, than ever!

Clearly if these updates were easy for me to write, I’d write them more often. I think a lot of my delay in providing updates is mostly due to the fact I don’t have anything super fun to talk about, or perhaps super interesting. Lots going on though, but not the usual outwardly interesting stuff that goes hand-in-hand with typical game development PR… which I did for years while running Gas Powered Games, designing games and working with publishers to get the word out and generate interest in the next game we were about to release. All of that leads me to my next point, about the technical nature of this project and platform.

Technically Oriented

If you’ve been following along from the beginning, you’d have noticed quite obviously that this is a very technical project. In these updates, I have discussed in great detail, the technology I am using and considering to use, more than I ever did in the past on games like Total Annihilation and Supreme Commander. Those games were pretty much all about the gameplay systems, unit designs and capabilities and the game interface advancements, and not so much about C++, Direct 3D or the tool chain used to build it all. This project is different, but it’s also because my core interests have evolved and shifted this past 30 years. Where I was very much into “just getting results” no matter what it took, in this next phase of my life, it’s about the tools, the technology, and really enjoying the process of figuring them all out and how they fit together. I have been so curious I sometimes wonder if it’s counter-productive. When I was younger I joked about people who studied computer science in universities, got PhDs and then never wrote a commercial piece of software. I have to ask myself, am I slowly turning into that person? I love to read, study, compare and think deeply about whether a particular solution is the right one, and will it be widely adopted, or be another technological dead end. I’m warning myself regularly of the pitfalls of thinking this way… in case you wondered. I know I’ve taken it too far on many occasions.

Latest on Web Tech

Well, I am continuing to work away on deepening my skills in the field of Enterprise Cloud, like I mentioned in my last update, but recently things have shifted more towards web technologies, like WASM. If any of you work in this space, have built and run your own website, then you’ll have experience with things breaking because you make security updates, and sometimes just while doing general maintenance. Each one seems like a brand new, freshly crafted experience, where you roll up your sleeves, dive in and figure out “what the hell happened?”. This happens like clockwork, and you deal with it.

If you’ve been following the 3D rendering capabilities of the most popular browsers, you’ll notice that WebGPU has still not made its official entrance, though it is coming, albeit slowly. And while we’ve been waiting, WebGL 2.0 has finally gained parity with WebGL 1.0. Again, you can track this at this site, one I use and trust regularly. Tell me, after you’ve had a look at this and read a few articles here and there, which would you invest in? And while you’re at it, share your opinion on WASM and tell me what you think. I have been waiting for the tech to mature the last few years, but I feel like it's fully baked and ready now, and it’s playing a critical role in enabling the next generation of powerful web applications. I think the wait is now officially over, and it's time to get cracking on bringing the code over.

Hard stuff to talk about

I’m going to take a shot at talking about something difficult, because I really don't want to get political on my site. I'm just going to say it, it’s hard to make a war game for fun when there’s a war going on and I have friends in both countries that are suffering from it. I really don’t want to write a lot about this, but I have to at least write a little. I can’t hide from the fact that for years, I have spent hours researching weapon systems, devising units with interesting behaviors and diverse capabilities, and building dynamic simulations that let all these different weapons, offensive and defensive, play out on the computer in fun and interesting ways.

And then I start seeing the real-life equivalent take place, watching these videos every day, especially this recent display of missile and anti-missile systems. This project and the game itself, is 100% about having fun, because in my mind, when you fight imaginary wars on a computer, it is fun, and it is safe, but it doesn’t make it less awkward for me. Maybe it’s my age, because as some of you know, age does this to a person… it widens your world view, and it allows those more mature inner voices get a little louder and be heard a lot more.

If you’re not there yet, don’t be surprised, it could happen, and you’ll totally get it. What’s even more strange to me, is that I’m learning from it all. I’m asking the hard questions about where modern warfare is going next, and how will the role of drone warfare play out in space? I think it’s conceivable that almost all of the warfare that will take place in space will be fought by drones running a specialized combat AI or by a remote operator. Back when we were working out the backstory for Total Annihilation, and we knew we didn’t want to show any bloodshed, we concocted this idea that everything was a bot, controlled by an AI which was from a human consciousness. Looks like we’re heading in that direction, and with the recent, and very public advancements in AI, we’re making leaps and bounds that are exceeding a lot of estimations.

That reminds me of a book by Ray Kurzweil, The Singularity Is Near. If you’ve never heard of Ray Kurzweil, that link will take you to wikipedia.

But back to what I was saying, and then I’ll be done. I am deeply saddened by what is happening, and though I am certainly not profiting from it, I can’t help but learn from it. War is not just bad, it’s extremely bad; it's the worst. It could be the thing that tears everything we’ve built down faster than all the other existential threats we face, and it needs to stop.

Okay, I’m done, I had to get that off my chest. So now I guess I go back to working on that war game that takes place in space. Somewhere far enough into the future that it doesn’t feel real, and feels more like a game... and not a prediction.

Your Emails

I can’t wrap up this update before saying thank you to all of you who sent me an email telling me a little about yourselves. I read them all. Some I was able to reply to, some were long and seem to deserve a much longer and better thought through reply. I might still get around to replying to all of them. If I don’t, please just know I still appreciate you taking the time to write. The story that each of you have of your own life and games played has been a pleasure to read about. They have been a bright spot in my evenings, and they bring me energy and inspiration, and propel me to keep moving things forward when I slow down to a crawl. Thank you again, and please, keep them coming.

Until next time...

Chris Taylor

Welcome to the latest insanely late update of the Kanoogi platform and Intergalactic Space Empire project.

This update is going to be a little different, but I suppose you could say that about all of them. I wanted to provide an update on things but also give some insights and perspective on where things are at for me, as it's been awhile since I've written. As always, I'll try and update more often in the future.

For those of you who stop by every now and again to see how things are coming along, I appreciate it, and I also appreciate your ongoing support of this crazy and ridiculously ambitious project. Every now and then I get an email expressing support with many kind words, sometimes about the excitement of IGSE, and sometimes with regard to Total Annihilation, Supreme Commander or Dungeon Siege. Heck, I still get emails about Hardball 2 and 4D Boxing. That's pretty amazing, and such a bright spot in my day when I receive those. That is the kind of support that propels me forward, and again, for that I am deeply grateful.

Learning Enterprise Cloud

I want to talk about time a bit, and how long everything is taking, and how naively optimistic I always seem to be about how long something will take. My original plan, as conceived back to 2017, might have worked out fine, but things changed and my plans evolved. I can't even really blame Covid for it, but it sure did change my view on things. Even now, world events have me reconsidering and contemplating some of the choices I've made. And regardless of time spent, I've had some great technical wins this past two years, and learned so much stuff that was foundational, and mission critical, it's hard to feel too bad about it all. The other factor that played a part in how long all of this is taking is that I wasn't ready to put together a larger team and go into production yet. Intuitively maybe I felt that there was still a lot to learn. I kind of took a signal from the universe, and decided that instead I'd pivot and take the time to go off and learn about Enterprise Cloud more formally (which I talked about in my last update). I thought I would spend a year or two, and now here I am, entering my third year. I still think that was a good decision, but on the flip side of that, it took up quite a bit of time and really pushed things out. And while I'm off learning, the clock is ticking, and weeks turn into months and months turn into years, which is sometimes hard to endure.

I'm already modernizing

I just wanted to quickly mention something, because my early updates went into a fair bit of detail on how I built out the backend systems, which all runs up in the Google Cloud. I recently refactored that code (which has no game specific logic in it, it's all work that supports the general Kanoogi platform), containerizing and building out a CI/CD workflow that automate my deployments. I've effectively modernized my orginal proof-of-concept. I've used what I've learned this past couple of years and applied it to my original implementation, and embarrassingly tried to correct all the amateur stuff I did early on. In the process of building out these new workflows, I even built a test environment, which was a very welcome and long overdue addition to my development process. Who knew that developing a test environment was a project all by itself, let alone authorization systems, logging, monitoring, secrets management and security systems, much of which I still have to implement or improve in various ways.

Pottery

As some of you may know, one of my hobbies is pottery, ya, actual pottery where you spin clay around on a wheel. I've thrown (in pottery the act of actually making stuff on a pottery wheel is called 'throwing') all my own bowls and plates that I eat off of every day, and you may have even stumbled across my Instagram account. Here it is if you want to follow me there. I haven't posted much in the last few years, kinda fell off the wagon, as it just wasn't a priority for me. I'm going to be doing a fundraiser for the Ukraine in a few weeks, so I'll likely post some stuff up then, as I'm basically auctioning off some bowls for charity.

Click this icon to go to my pottery account on Instagram

IGSE:Rock War

For the past nine months or so, the game design has continued to evolve, and as I mentioned in the last update, has returned to a ground based game, if you can call it that, where all the combat takes place on the surface of very large asteroids. This brings back the various strategic elements that I think are necessary. I've gone around in circles a few times, and believe I've got a pretty good solution for the technology tree and resource system. At present I do not intend to duplicate the system I designed for Total Annihilation and Supreme Commander, but if the initial experiments aren't fun, I might go back to that resource model. It's not like I can spend a lot of time on that right now with all the other things that I have going on, but I think it's important to at least be transparent with those of you who are following along on where I'm at. Thank god I didn't run a Kickstarter and take your money, or you'd be kicking my ass right now and wondering where the heck the game is!

Again, I'll say this, and I mean it. I appreciate the support and patience as I continue to work on this project and prove, one way or the other, if a single developer can build a system to this level of complexity. There are certainly no guarantees, but time will tell, and so far, I'm still being foolishly optimistics that I can pull it off.

One last thing...

As I watch the beta signups grow, I wonder about all of you, and I asked myself, who are these strategy game enthusiasts? So, if you're willing, I'd love to hear from you, and learn a little about you. You don't have to write a long email, just a sentence or two about yourself. Don't reveal any secrets, this isn't a plot to get your Netflix login, instead just a little about what games of mine you've played, what you're playing now, and what you are most excited about in gaming. But you can elaborate and share what you like, as it's damn time I learned a little bit about all of you! I promise to read them all, and I might reply with a sentence or two, or just a simple thank you. I don't know, I'll play that by ear. Send those emails to general@kanoogi.com and let's get to know each other!

Until next time...

Chris Taylor

Welcome to another unbelievably late update!

The previous update was “long overdue”, and now this one is “unbelievably late”, so I imagine the next one will be so late it will exceed your wildest estimates of how lazy at writing these I am getting.

Okay, without further ado, let’s get into the juicy details.

So after a few deep and contemplative conversations with a few of my friends in the industry I needed to ask the hard question, am I making the right game for a web platform? And to go even further, was my plan to build a game that ran in a browser, on both desktop and mobile a good idea, or was I being naively ambitious? And what about the plan to make Kanoogi a gaming platform that would support other games from other developers in the future, was that still a good idea? I think I've got some reasonable answers to these questions I wanted to share in this update.

Let’s hit the big one right out of the gate. Should my next RTS game, regardless of the scope, really run in a browser, replete with all the technical challenges, mostly performance related, and the various uncertainties that the tech brings with it? The answer is… probably not, but I have decided to press onward, with a couple of important caveats. The first is, I’ll plan to make native clients for the two big mobile platforms, iOS and Android, and won’t worry about whether platform holders will or will not charge the 30% fee if revenue is generated outside of their respective platforms. I spent a fair bit of time considering that, and with the recent news of the “Epic v. Apple” lawsuit, things are looking up (a bit?) for developers who want to generate revenue outside of these walled gardens. So the decision to not try and make IGSE perform on a mobile browser seems to be a sensible one. The sad part of this, when looking backwards, was all that time and energy I invested chasing down bugs which is difficult without the debugging tools (you can quickly see where native development for these platforms makes development so much easier). The conclusion is, I’m focusing on the desktop browser and will simply not worry about mobile going forward, and when the time comes, I can just release native clients for mobile. OK, so that’s one big question answered.

Next up, does the concept of Kanoogi as a platform still hold up?

When I first started thinking about this idea, the motivation was to support my first game, and potentially some others, but then it grew in my head because I wanted to give other developers a low cost platform with global distribution and the same low friction access. This part of the Kanoogi vision is now stronger than ever, and I’ll tell you why. Over the past 18 months, I have been distracted from the game, and I’ve been learning Enterprise Cloud… in a big way. Without sounding too dramatic, I went a little nuts (and yes, this is in parallel with what I talked about in my last update in December). I know a lot of this would not sound terribly relevant to game development, but now that I’ve spent this past year studying the subject, I can tell you how incredibly relevant and exciting it is. This is my sales pitch… the world is very rapidly changing, and we’re seeing it every day, in everything we do, as businesses everywhere shift their entire backends from “on prem” to the cloud. We can point to so many examples now of how the cloud has transformed the world we live in, but is this true when it comes to gaming? I’m not so sure that games that are rendered in the cloud and streamed in real time, for example, are there yet. Some of you may have first hand experience trying those various offerings. There’s potential, but I’m not buying it… yet. I still believe that games need to be rendered locally, but to be clear, developers can do a lot of computation in the cloud… a lot! But regardless of that, what the cloud brings to the table is undeniably awesome, and the power it unlocks will become even more apparent in the years ahead. So, is Kanoogi really about playing games in a browser, or about unlocking the power of the cloud? A little of both, but the cloud is now fast becoming one of the most exciting and important parts of this endeavor, regardless of whether the games are played in a browser or not.

Before I wrap up this update, I’ve got one more thing to share.

I am shifting focus of the game from space combat to a more traditional ground based RTS game. The concept largely stays the same, in that the player will build bases and can fight from one asteroid to another, what I’m still calling IGSE:Rock War. The thing I’m adding is ground units that move and fight on the asteroid itself, much like what you would expect from a more traditional RTS game. The original space combat only concept just wasn’t working for me, it was too flat and uninteresting, and the logic behind this takes a little explaining. In space there is no interesting terrain or rocks, and certainly no gravity that helps shape the trajectory of an artillery round (one of the key elements that makes ground based combat interesting). While I have been thinking about the gameplay mechanics of making the strategy engaging, I found it hard to imagine those same cool ‘moments’ that come about when a game is played on the surface of a planet, which often relates to the relief and variability of the terrain. This decision is a return to my RTS roots as I move back towards developing a ground based game with space elements. If it’s not fun, then I'll try something else. This whole thing is a grand experiment, and I won’t stop until I get to something that I really think is cool. Because after all, what’s the point unless it can achieve that.

As time passes, the technology and the concept behind it continues to evolve, and I get a little closer to creating something new and original. For those who wonder about the project, and perhaps wonder about my sanity, I’m hanging in there and doing fine. And most of all, I’m still having fun.

And I’ll try a lot harder to drop another update sooner next time!

Chris Taylor

Welcome to another long overdue update!

I think it's fair to say that this year has been thoroughly distracting on pretty much every level. Like a flat out attack on the senses. I won't even go into the whole COVID thing, because that's already sucking up a ton of bandwidth, so I'm just going to heave a sigh and move on to the update itself.

You know the saying, "gone off deep". Well, it happens with game developers sometimes, and I'm starting to think I fit that description. The road to recovery for times like this is to first recognize and accept that it's happened, and then have a good therapy session. This update will have to do, because with everything else going on, there's not really time for therapy.

To kick things off, let's talk about web technology. There have been quite a few amazing advancements since this project started back in 2017. It was early days for WASM (Web Assembly) and WebGL 2 was slowly getting adopted in the major browsers. The language Rust was also slowly picking up momentum as well. And though these advancements were all very interesting (and exciting to tinker with!), I wasn't taking the bait. You likely know where I'm going with this, and you'd be right. These technologies are too important to ignore (so ya, I took the bait finally), and this past six months I've been reading up on all of them and asking the question, are these ready for prime time? The answer may not be a 100 percent yes, but it's more relevant to ask, will they be close enough by the time I launch, and the answer is a very likely yes. So you get the idea, these big tech improvements have been worth the time and energy to more fully explore. There is also a lot of other great web technology, like WebGPU and Web Audio, which I am keeping an eye on. I don't think either of these will cause the project to be delayed or be reset, otherwise I will be in a perpetual development loop. Don't laugh, this does happen! At the end of this update I'll provide a bunch of links that go into more detail for those of you who are interested in more information.

Now that the tech stuff is out of the way, let's wrap up the year by talking about a few of the elephants in the room. The reason I thought it was time to bring this up is because over the past several years, I've been getting these questions quite a bit, so let's just get it all out there, served up in a nice Q & A style format. And I know this isn't all the elephants, but it's getting late, 3:12am at the moment.

Q: Why don't you make a sequel to Total Annihilation, Supreme Commander and/or Dungeon Siege?

A: The short answer is, because I have no legal rights to any of these game properties. The longer answer is, Total Annihilation was developed while I worked for a company called Humongous Entertainment. That company was then sold to GT Interactive. GT was then purchased by Infogrames and renamed to Atari. Atari then sold the TA property to Wargaming, where it resides today (to the best of my knowledge). Supreme Commander and Dungeon Siege were sold to Square Enix while I was the CEO of Gas Powered Games as part of an effort to recover financially from the recession. I could give you a very long version of this story, but suffice to say, these were very hard times, and we survived by making the hard call. Having to sell those incredible game IPs was tough, but when you are running a business, you do what you need to do.

Q: Why don't you purchase the rights back for your old games and then do a sequel?

A: As straightforward as that sounds, these IPs are generally pretty expensive to purchase. And not only are they often north of seven figures (millions) they aren't necessarily for sale. To put it bluntly, even if I had the money and wanted to buy them, I probably couldn't. My attitude is that this is OK. The process of creating something new, without being constrained by the canon of an existing IP is liberating! You can start fresh and create a bunch of crazy new ideas which is quite a bit of fun. It's how those other IPs were created! I guess there was a time in my life when I really wanted to do a sequel for TA, and a part of me (down deep inside) still does, but I've let go and moved on, and I'm fine with that.

Q: Why don't you run a Kickstarter campaign and raise the money to hire a bigger team?

A: This is a slightly harder question to answer, because I do go back and forth on this a bit in my mind, but at the moment I don't think the model works for me, which I can try and explain. When money gets raised to deliver a game on Kickstarter or Indiegogo, it's like a starter pistol gets fired and you have to start running. There's not only more stress, but there's more of a financial motivation towards the development. Time plays such a key role that decisions are often made with time and money at the forefront. It's like a game winning free throw in basketball... it's not whether you can make the shot, it's whether you can make the shot while under pressure, which is a whole different world from creating a game without all that pressure and stress. I developed games under that stress for 30 years, and I wanted to try a different approach. Now having said that, I was beginning to have fundraising conversations at the start of the year, but when COVID hit, I decided that perhaps I needed to stick to my original plan and just develop the game on my own, and at my own pace. And believe me, I can already start to see how time pressure can keep a development process focused, because without it, it's entirely possible to develop forever and never deliver anything. Under the right circumstances I think there's a way to raise the capital to help fund this project, but I don't think crowdfunding is necessarily the right fit for the approach that I'm taking.

Q: Why don't you use state-of-the-art web development platforms and tools so that your website doesn't look like something from the 90's?

A: I do laugh when I get that criticism, because it's 100% correct, and I'm guilty as charged. When I started to code back in the early 80's, I did everything from the ground up. This was necessary back then, but it's really not today. My view on it is that I really like getting a fundamental understanding of how things work. If you're reading this and you've never built your own website from scratch, give it a try! You'll not only feel closer to the web, you'll appreciate how far it's come, and how much abstraction and distance those development tools put between you and the final HTML code. What if something breaks, can you fix it? Or are you one of those aliens on the original Star Trek that can't fix the computers they rely on? (I can't remember if Kirk decided to fix them and break the Prime Directive). Sorry I got a little off track there, but you get the idea. As time goes on, this website will become more sophisticated, and if something breaks, I can fix it.

As short as this update is, I wanted to let you all know that I'm alive and kicking, and that things are still moving forward, even at this slower pace. And importantly, I want to take a moment to wrap up this insane year by thanking all of you for your support, kind emails and words of encouragement. Not to sound cliche, but words truly cannot express my thanks and appreciation. And finally, let me wish all of you the very best, safe, and a most enjoyable Happy New Year!

2021 here we come!

Chris Taylor

Here's a list of links to the sites that have more information on the ones I just mentioned.

Web Assembly: webassembly.org/

wat2wasm demo: https://webassembly.github.io/wabt/demo/wat2wasm/

Rust reference: www.rust-lang.org/

WebGL 2.0: www.khronos.org/registry/webgl/specs/latest/2.0/

WebGPU: gpuweb.github.io/gpuweb/

Web Audio: developer.mozilla.org/en-US/docs/Web/API/Web_Audio_API

Oh, and check this out, pretty darn cool (and I'll come back and add more as I go)

Web Assembly Studio: webassembly-studio.kamenokosoft.com/

Hit this site to see if your browser supports WebGL 2.0: get.webgl.org/webgl2/

Welcome to the latest update of the Kanoogi platform and Intergalactic Space Empire project!

This update is not only long overdue, it’s going to take a bit of a different format. First of all, there are a multitude of reasons it’s different, one of those you already know, and have heard about non-stop since it affected us all, and we went into this global quarantine, but second of all, how working on this project as an indie for the past few years has affected me. So for this update, a small blurb about the state of the project and then I’ll try and answer a few of the questions from the backlog. If you want to add more questions to that list, which I will endeavor to answer in the future, you can send them to questions@kanoogi.com. If you send me a single question, I can often just reply back to that right away.

This past 4 months has been hard, to put it mildly. As I’m learning, being an indie developer takes an enormous amount of discipline. With world events being what they are, it has taken the need for discipline to a whole new level. I wished I could say I had that, but given how much things have slowed down for me on the project since the virus started spreading, it’s fair to say I don’t have it. I think the whole COVID thing came at a coincidental time for me, because after pushing to get the platform and game finished within about a 24 month timeframe, I burned myself out. I was heading into February, having just decided that I was going to approach the graphics a little differently when all of this hit us. I felt as if stuff going on ‘out there’ was more important and made what I was doing in my own little microcosm pretty irrelevant by comparison. I don’t want to go too far down that rabbit hole, but suffice to say, it’s not been an easy stretch. Not all is doom and gloom however, as it does sort of feel like there’s progress being made, both in terms of mitigating the effects of the virus, and economic recovery. I’ll stay positive that both of those things are going to continue in that direction. And while that is happening, try to stay focused on my own mission to build this game and platform.

Let’s talk about graphics for a minute. I started out with the idea that it would be really cool to make a game with a complex backend simulation but rendered with highly simplified graphics… like the vector graphics used in the early arcade games like Battlezone and Asteroids. I thought this would be perfect to combine the browser and cloud. As time went on, I switched to polygons, and then to an extruded 3D, and then felt that it wasn’t enough. Up until then, the graphics were created by hand (as they were all just geometric primitives), super lightweight, and took almost no time to load. I knew that if I made the jump to importing 3D models, the load times would slow, and I’d be going back to a more traditional model of game development. I resisted this, but I began the process of investigating the possibilities. A friend of mine, who had been asking why I didn’t want to go to a fully modeled 3D approach, offered to create the actual models and suggested I take a look at the Wavefront .OBJ format (due to its power and simplicity). I kicked this around, and decided to write a converter to create a highly optimized binary version of the format that would only include the specific data I needed to plug directly into WebGL (This is important because the browser is not a good place to twizzle or transform data). This decision would be a big change in the visuals, and it meant that the game’s development schedule would be further delayed, but that the graphics would undoubtedly appeal to more people, especially those who played Total Annihilation. Oh, I should mention, I did search for a tool that would convert the data and found a few that came close, but didn’t find exactly what I needed, so at some point, I’ll make this code available publicly, as it might be handy for others who are interested in doing something like this. And we’re not talking about Unreal graphics here, but very simple models (flat shaded and textured), roughly equivalent to what we had 20 years ago. The other idea is, the game could still load really fast, by using the original vector graphics, and then over time, asynchronously load in the more graphically detailed models. This is what convinced me the idea would work. I am absolutely opposed to a loading bar of any kind. I’ve never liked loading bars! (Does anyone remember the days when I was promoting Dungeon Siege, and I was like, “no loading bars!”). Do I absolutely believe this is the right decision? No, but because you’ll have an option to turn off the loading of those models, the answer will be evident when we look at the stats. A perfect thing to learn more about during the beta. I could ramble on quite a bit about this, but let’s leave it at that for now.

I sort of talked a bit about tech above, but I wanted to add that if you are reading this right now because you received an email from me notifying you about this latest update, it’s because the code I wrote to email everyone currently signed up for the beta actually worked as intended. That’s some temporal shiznoodle right there!

So ya, as part of this project, I am not only writing the game engine, a cloud platform and rendering client, I’m also authoring my own website by hand (no web building software used, that’s why it’s pretty basic), and managing my own beta signup and email management system. You might ask me, why am I doing all of that? Well, first of all, it’s darn fun! Second of all, I like to know how things work. When I wrote the first hack at the beta sign up, it taught me a lot about what goes into a system like that. And did you know that roughly 10% of all beta signups are non-confirmed? Ya, so when I send out that email to confirm, they are never responded to. It’s been a very educational project to say the least.

With all of that said, let’s run through some of the questions sent in. These are continuing to work through all the questions, largely unedited (just spelling and grammar fixed), as they came in and added to an internal spreadsheet.

Q: One question I do have is that with TA and SC much of the game logic was generic/parameterized which allowed for easy modding, is there going to be a similar system in IGSE? Like will there be some way that I can upload my own unit pack and create a game instance using this data opposed to (or in conjunction with) the regular units? It's not the most important feature to me (I mostly play vanilla SC:FA tbh) but I always thought it was a cool feature for your games and it's probably the biggest reason that TA's community is still going strong.

A: Because I’m writing the code by myself, I won’t likely be able to support modding at the beginning, but the potential for doing modding in the future, far exceeds anything that my previous games had done. It will be possible for modders to create new, crazy and outrageous mods by replacing models, and all of the internal economic systems, weapons, you name it, and then have those games available for others to play without requiring any downloading or installation of packs or modules of any sort. This is yet another game changing part of building games this way. The potential for modding will be nearly unlimited. The only catch is, I won’t be able to support this until I get the core game up and running.

Q: Oh also I've heard this described as a 2D RTS, do you mean 2D as in it isn't like Homeworld where all dimensions are totally usable, or do you mean it's a 2D game with 2D game logic (no calculating bullet trajectories in 3D space like TA or SC)?

A: This definition has shifted a bit, but to recap, originally it was the graphics and the trajectories, but with the addition of 3D units, it will likely also mean that I will add the 3D trajectories as well. The only problem is with realism, as there aren’t quite the same intuitive projectile trajectories in space as there is on a planet’s surface. I haven’t changed that code in awhile, so for now they’ll remain flat.

Q: Big question on my mind: One of the key features of Supreme Commander that made it so great was the ability to start a random ranked game and see the global ranks of all players based on what seemed to be a chess rating system. Will this exist in IGSE?

A: Totally possible, but not something I can code at launch, but I will say this, if the game is popular, that can be added without any problems at all.

Q: For IGSE, I'd want to know more about the game before recommending "keep this behind a paywall / limit that", but I'd advise looking at either a "battlepass" system of "okay there are four factions in the game, you get one from the outset for free and can level them up and unlock others, OR you can pay to unlock them from the get-go.

A: I love this conversation, and it’s something we should talk about more in detail in a forum environment. I need to get a forum up and running before the beta launches so we can all discuss this kind of thing together as a group. I want to hear all the ideas and have a healthy discussion about the right approach.

Q: Cosmetics. Granted, depending on the graphics angle (given lack of texturing) this might be a no-go, but even with just vector art you can differentiate a bit. If you're going for "one faction fits all", this actually might be a great boon -- you can keep things "visually telling" (Artillery ships will always have a big gun sticking out of them, carriers will always have launch bays) but use this to give players a sense of "ownership" while drumming up extra dosh for the coffers. Take, for example, Zero-K, where you have a singular faction for all players, one thing that would cut down on some of the "but it's the saaaaaaaaaame" complaints from some players would be additional customization of the in-game units.

A: A lot has happened since this question was sent in (sorry I’m still working through questions from last year), but the sentiment expressed here is still valid. My sense is that now that things are moving to 3D, and utilizing textures, it will be more important than ever to have clean ship and unit designs to clearly portray functionality. I’m still working on the new tech, so we’ll see how it plays out. Your feedback during the beta will be critical to whether or not this is moving in the right direction.

Q: Will there be microtransactions/pay to win mechanics for Intergalactic Space Empire? And how much will Kanoogi cost?

A: I personally don’t like microtransactions, and I 100% don’t agree with games that operate on the principle of ‘pay to win’, but I do also recognize that you can’t run a cloud based gaming service without some kind of recurring revenue. The costs to run Kanoogi should be pretty low, but I won’t know how low, until after I’ve had it operating for a number of months and have some metrics to study. Access to all things Kanoogi, at the platform level, should not cost anything, and only access to specific games should have any fees to play them (whether it’s a single payment or a content unlocking system).

Q: I play 99.99999% of my games on my PC. My monitor has a resolution of 1440x3440, commonly referred to as 1440p ultrawide. Additionally, my monitor runs at 100 Hz. Will Intergalactic Space Empire be supported on my monitor, or other bizarre resolutions or refresh rates?

A: That’s all dependent on whether the browser you are running supports that. My guess is that yes, it will. I develop on Chrome and have set the fps to run as fast as it can, and it can run far in excess of 100 fps.

Q: Core Contingency to Supreme Commander and SupCom: Forged Alliance was the number of paths to victory, and counters to each path. It wasn't ever a simple 1 strategy wins every game. However, there were stages to the game. Early game, mid-game, late game, and ultra-late game (Past the 45 minute mark). There were also many different combat units to choose from with varying tradeoffs, and not a simplified rock paper scissors counter system where unit x always beats unit y, so you need unit z to beat unit x. I guess I know nothing aside from the name of your next game, and a guess that the genre is an RTS in space. Will you have a similar system, or something more advanced?

A: I think IGSE, and the first sub game, I’m calling Rock War, will share a lot of the same design sensibilities as SupCom and TA, where there will be many paths to victory, and will definitely not follow the rock-paper-scissors model… something I have never advocated for, and have never believed will result in particularly fun gameplay. I say keep it wild, weird and interesting!

Q: Is this game persistent and unending, or is it going to be structured more like a traditional RTS where there's a 'you win' announcement, then the game ends?

A: The original design of Intergalactic Space Empire was more open-ended, but due to the complexity of that original and quite ambitious game, I am going to release IGSE:Rock War, which will be the smaller scale, and more traditional RTS. If there’s demand, I’ll continue to develop on the larger scale game as well… and things will truly get Intergalactic!

Until next time...

Chris Taylor

Welcome to update #4 of the Kanoogi platform and Intergalactic Space Empire project!

It’s been awhile since the last update, and a little too long, as there’s been a lot going on, as I push onward through development. This update will cover the same topics as last time, but for the technical update, I’ll talk more about the client-side systems that are being used (as opposed to the server-side). So, in short, I will cover the design, technical and lastly answer a few questions in this update.

If you are curious, right out of the gate, what the status of the beta is, let me give you the bad news first… I’m still too far out to start it, and as I’ve been pulled into business development, and the website, it’s pushed the date out to where I’m thinking about a way to start a beta to test some of the subsystems of the game and platform. As might be expected, if I was developing a PC game (as I did for most of my career) or an iOS/Android game, it would be all about the game itself, but with this project spanning client and server, it’s a much more ambitious undertaking.

I’m happy to say, I have not changed the design direction or had any big reversals lately, but as development progresses, some of the vagaries of design were necessarily filled in a bit. Let me give you an example. When a ship, whether it’s a “stock” ship or player designed takes damage, the specific hull that takes this damage has its armor reduced (yes, insanely I model damage to every hull piece on the ship). When that armor has been penetrated, it’s time to decide how the contents of that specific module inside the hull will react. If it’s an energy storage module, then it’s a big explosion, but if it’s something like an impulse engine, then it would be less explosive, but still produce a pretty big bang (and potentially an “area of effect” damage radius). But what if that energy storage module was empty? Then it wouldn’t make sense for it to explode at all (besides the weapon that hit it). That’s an example of me working through the design decisions, where I need to ask, how far do I take this before it’s too much, to a point where only a small handful of players would care? Write me back, let me know your thoughts.

If you’re starting to wonder when I’m going to start releasing screen shots, you’re not alone. I’m wondering the same thing! This is the Internet we’re talking about here… once you put it out there, you can’t take it back, so I’m suffering from a bit of that anxiety. I will say this, however, I’m getting close. I’m thinking that instead I should post short videos. I can narrate a bit to explain what’s happening, as a single screenshot doesn’t quite do it justice. That’s where I’m leaning right now. We’ll see, hopefully I’ll be ready by the next update.

Oh, and though it’s not super exciting game design stuff, there is a bit of design going on with the website. I decided not to keep advancing my canvas based website design idea, as frankly, it was too time consuming to add features (and they weren’t compatible across all devices and screen sizes), and it was distracting me from the game’s development. I’m talking about the spinning Kanoogi letters. I had put that together for the GamesBeat summit, but since now realize it’s much faster to just use CSS/HTML. So a few weeks ago I decided to build a good ol’ fashioned website from scratch. I’m still being stubborn though, as I didn’t want to use a newfangled web design system where you just add water, and presto, you have a website with all the bells and whistles. It’s actually been a lot of fun to dive deeper into CSS, and it did come together quickly, but now that it’s up and running, it’s calling my name to fix all these little things that I notice. Oh, and worst yet, when I’m browsing the Internet, I see other website features and wonder, how did they do that… and, I wonder if I can do that? Distracting! And yes, it does look a little like the mid 2000’s… but it will evolve, and again, your ideas, suggestions, criticisms and feedback are welcome.

Oh, before I forget, I want to thank everyone who sent feedback in with regards to the question I asked about Keyboard/Mouse vs. Touchscreen. I would say it ended up being about 60/40 in favor of just supporting Keyboard/Mouse vs. both. So not a landslide victory, but it was enough to convince me that I need to focus on the KeyBoard/Mouse first, and then solve the touchscreen later. I added an option to allow the player to decide between Drag Select and Touch oriented controls, so now there’s an official point of departure for these two UI paradigms. And I’m not closing the door at all on TouchScreen to be a very cool, and complementary way for a player to get another screen to show status updates on what’s happening in the game. Imagine this, you’re sitting in front of your PC’s main screen, and you’ve propped up your iPad or Smartphone next to it on a stand, and you can log into the game on both devices and use that secondary screen (I can make this any number of logins) to monitor stuff that’s going on (dual screen anyone?) and even give some occasional commands. I don’t know why I like that so much… I’ve always had a thing for dual screen!

There’s a lot more design to talk about, but because these updates need to be shorter, I’ll leave some design for the Q&A section.

Oh, and like last time, please skip over this section if you aren’t interested in the technical stuff. Nobody will know! :)

Last update I went into some detail on the Cloud/Server side of things, so this time I want to talk about the game client.

This is a bit of a walk through of some of the key components that the client uses, and what makes the game and platform possible.

Javascript - As many of you know, javascript has come a long way since Brendan Eich developed the very first version back in 1995. Big advancements came when Google developed the V8 engine and took it from a quaint utility language, to one of the most popular web languages used in the world today. You might wonder, what about WASM, and that’s a good question. My guess is that I will start making a transition to this in the next year, but I wanted to wait to make sure it was going to really stick before I bet on it. In short, the power and versatility of Javascript was instrumental in convincing me that this particular combination of technologies could be a viable game platform.

WebSockets - This is an upgraded HTTP(S) connection, and unlike HTTP where it closes the connection between client and server after a short flurry of exchanges, WebSockets leaves that connection open until it is no longer needed. Without it, there are a bunch of hacky ways to create a layer of communication with a server (long polling is one example) but it’s not great, and it wouldn’t really produce a decent player experience. You can use text, and I actually do for some things, but the great bulk of the data that is sent from the server to the client is done using a binary protocol. I was kinda warned that this wasn’t quite as good as using a UDP (User Datagram Protocol) like we used back in standard game development on the PC, but I’ve had no problems with it, and I’ve been testing across a huge range of networks. I attribute the success of this (WebSockets) to the fact that the networks are so much better today than they were 20 years ago. For example, as a reliable transport protocol would have been more problematic when a network failed to get a packet through on a first try, and then delayed future traffic with retries. Because networks are so good at sending data reliably these days, failed packet transfers are less likely, making the underlying requirement of resending data a non issue.. But I digress!

WebGL - Probably one of the most important things added to a browser to support game development. When I first thought about creating a game in a browser, I had dismissed WebGL because I didn’t believe that it had been adopted across all browsers, and oh how wrong I was. In fact, not only has WebGL penetrated 100% but WebGL 2.0 is not far behind. Safari might not get there, but the other major browsers look like they’ll be supporting it.

Though there are many ways to approach WebGL via the use of libraries and middleware, I chose to implement my own code that sits right on the browser API, and this has given me 100 percent control over the results. I can squeeze more performance out of the hardware and reduce the memory footprint too. I am continuously blown away at how many pixels I can push using this tech… and the fact that it’s in a browser, blows my mind. I get quite excited every time I test out a new system and watch that my FPS is locked at 60+ (on my MacBook Pro at least!).

Google’s Closure Compiler - Not that using this is mandatory, but it does really crunch down the Javascript into a much smaller download, but it also creates a layer of obfuscation and strips out white space and comments. It’s true that this is now looking more and more like a stop-gap measure until WASM completely displaces JS for performance oriented progressive web applications.

Audio - At present I use a package called Howler. It’s been great, but it’s been giving me some trouble lately when using the Closure Compiler to compile Javascript in ADVANCED mode, so I’ll be switching to using the native Web Audio API directly in the near future. And if you haven’t seen the specifics on the Web Audio API, it’ll blow your mind. I dare say, there’s little you can’t do in a browser, especially true of audio.

I should mention, I use this site quite a bit to check to see if something is either supported or will be supported in the near future. It’s pretty awesome.

Check to see how widely implemented a given web tech is: https://caniuse.com

I’ll wrap up the tech with this final thought. If there’s something you are curious about or want me to dive deeper into, please let me know, and I’ll see if I can cover it in more detail in future updates.

As a quick intro, I will say, these are great questions, and in keeping with my somewhat structured system, I’m answering them in order as I received them.

Q: Regarding the idea of salvaging tech upgrades, will these be permanent upgrades or something you have to do each time you play a session?

A: For the shorter game mode, Rock War, I’ve made the hard decision that the game follows more of standard RTS approach, like most are familiar with in TA and SupCom. This shorter mode of play makes it almost impossible to use a persistent model (but is possible at the meta level for things that don’t upset play balance). I want to leave the door open for some emergent behavior, kinda like capturing a unit, where you can blast an enemy ship and acquire the tech, but this won’t persist into the next game.

Q: If the user invites a friend, and this friend is new to the game, how can help the player play the game? The user has already spent some time building the ship and his friend has just started. This is an interesting thing, how can they play together?

A: If a friend joins after a game is started, they are very much coming in as a support role. The possibilities branch out from there, as they might scout enemy positions, collect resources or manage the base. Conceivably a player could transfer some ships to the friend and have them simply join them in the next big battle they engage in. This is quite rightly an exciting area of gameplay exploration. I’m not sure it’s specifically a hard game design challenge, but historically has been prohibitive because of the technical requirements. I guess we’ll find out.

Q: Will IGSE be a real time strategy game or a turn-based strategy game?

A: The roots of IGSE are RTS all the way.

Q: First, I'd like to know a bit more about IGSE, since it will be the first RTS you've made in quite some time, and in my opinion, the RTS genre hasn't had too many interesting releases come out of it in recent years.

A: Someone asked if they could post up all the updates to a website, and so I finally got off my ass and built a better site (still lots of work to do!). You can scroll down and read the other updates and get quite a bit of information now. I will say this, regarding your statement about not too many interesting releases… this game breaks a lot of new ground. Whether that’s fun or not, remains to be seen, but that ground is being broken!

Q: Is IGSE based around what's pretty much your RTS formula (Base building, large battles, TA economy, etc)?

A: In quite a lot of ways, yes, absolutely. I tried to make it about just ships (or units) but it went sideways on me last fall, and I broke down and shifted to a more traditional model of gameplay for a shorter and more controlled game experience that included isometric 3D units on asteroids (for base building mostly). I’m holding out that the bigger, truly Intergalactic, part of the game will come later on, as that crazier and truly epic, universe scale game requires a lot more development resources.

Q: How do you plan on generating income from the game? Will it be an upfront price, a subscription, free with DLC, or the standard Free to Play model, micro-transactions and all?

A: The core of it is definitely Free to Play. The details of what is free and what is purchased is still being worked out. I also respect that for many, especially younger players, that access to payment systems aren’t always possible, so this is why watching ads can be good for that group. However, for those who want to simply pay to unlock something and be done with it, I think that option is essential.

Q: What sort of 2d graphical style will the game have? Pixel art, Isometric/pseudo 3d, basic shapes, or will it look a tad more utilitarian?

A: You’d laugh if I told you what I had originally envisioned… straight up wireframe style artwork like the old classic Asteroids arcade game, but since then, things have evolved. I went to solid geometry, and then isometric 3D, and now I’m adding lighting and other advanced forms of shader rendering, so it continues to evolve. It’s definitely not supposed to be a high end AAA game like SupCom, so I’m hopefully keeping expectations for that to a minimum.

Q: Is the game going to be like those Free to Play "RTSs" that are incredibly prominent on mobile? (Clash of Kings, Clash of Clans, Ark of War, Lords mobile, etc)

A: No, I’m not going in that direction here at all. Plus, those examples are more turn-based and IGSE is a true, real-time game in every sense of the word and has roots in the older classic RTS games.

Q: How likely is it that referred friends would get accepted into the beta, and does being a beta tester give access to the full game on release?

A: At this stage it’s pretty likely that anyone that signs up can get in, but that would change if the numbers climb too quickly. I haven’t done any advertising or outreach to promote the beta (just a few posts to FB, Instagram and Twitter). The beta will unlock the game in stages as I stress test the server tech. My guess is that if you test the game and unlock something, or earn that unlock, you’ll keep it. If there’s a server reset, I think it makes sense to credit beta testers in some equivalence to match the unlocks. It’ll be my first time working through something like that, so I’m totally open to ideas about how to manage that process fairly.

Q: Is this a paid service/platform?

A: The Kanoogi platform has no associated payment scheme, at least at this time. Each game, starting with IGSE, will have its own system. I suppose it would be possible in the future to create some sort of All Access Pass, but that’s not really something I have given much thought to.

Q: Do you plan on releasing all your future games on this service/platform?

Q: Does Kanoogi or any of its current games have system/internet requirements?

A: Well, I have tested IGSE on an old iPad, and the FPS was starting to drop a bit, so I think if you have a relatively modern computer or Chromebook, then things should run fine. And so far, the game has run beautifully on iPhone 6 and up. The Internet and bandwidth requirements are crazy low, as in the heat of a battle, it can hit 50Kbps, which is nothing by today’s standards. Compare that to Google Stadia’s 20Mbps requirement… not even in the same ballpark.

Until next time...

Chris Taylor

Welcome to update #3 of the Kanoogi platform and Intergalactic Space Empire project.

It’s been a few months, so it was definitely time for another update. I got a gentle reminder to write another update, which I appreciate.

I will start off by saying, there has been quite a few changes. Some of them are reversals on my previous design, and though this isn’t something I ever think I’ll do, it just happens. I think it’s important to “pivot” as it were, it’s just important to me that these pivots are all within the realm of the original vision… but some do push the envelope a bit.

Before I dive into the details, I want to warn you right out of the gate, this is a big update. I will break this update into three sections, the first is a design update, then a technical update, and lastly, I’ll answer the questions that were sent in (most of which are in the order received). Someone suggested a forum or website where I post these publicly, which I agree is a good idea, so I’ll likely do that in the future.(ed. - I did!)

In my original design, this was a game about spaceships, and for the most part still is, but I imagined that in future versions, I would add units (in the form of built structures) to the surface of asteroids. Well, I received a lot of feedback over the summer, and that feedback made me take a second look at that decision to wait, and I slowly got more excited about the idea of moving ahead into full ‘base building’. However, with these asteroid based units, I pretty much had to make the move from 2D to 3D. However, just because I decided to go 3D, doesn’t make this a crazy, over-the-top, AAA RTS game, as I still have to design within a somewhat minimalist set of constraints. For example, I can’t use a lot of textures, and there can’t be a lot of geometry either, so I had to come up with a system for compressing everything down to the smallest amount of data possible for transmission across the internet, and the units themselves will need to be highly stylized. I can go into that in a technical update, and in fairness, that system is still evolving, so it’s probably good to wait a bit before talking about that in detail. But back to the 3D decision, I have to tell you, I understand that I’m now in dangerous territory of delaying the game, and I accept that, but there are days when I have to ask myself if it was the right choice. What’s interesting is I was testing some very simple geometry on the surface of an enlarged asteroid, and at last count there were over 1100 units on it, but this made me think… can an entire game be played on a single, slightly bigger than usual asteroid? Hmmmm… interesting!

OK, so very quickly, let’s talk about asteroids. Besides the fact that I loved playing the original Atari Asteroids game that was released back in 1979, and besides the fact that I was very lucky to acquire an actual original arcade unit back in 2016 from a friend (and it runs great as it surpassed its 40th birthday… which is just absolutely crazy!), I had envisioned asteroids to just be a place to gather resources. So you took your mining ship, and you sort of got into a geosynchronous orbit, and mining lasers would slowly strip away the ore and presto, you had your solid mass for building new units. Well… this latest development has taken the asteroids from a resource component, and brought them onto the main stage. I gotta say, I really love this! I’ve also done a lot more reading and study of asteroids in our system, and the more I read, the better it gets. So now, when I think about the future of space combat, and the complexity of landing ships on large planets (of any sizable mass) and getting them back into space, I realized that asteroids are the perfect thing to support military bases… and the moon is perfect too (conspiracy theories anyone about the renewed race to set up bases on the moon?). In short, because I think it’s possible to talk for an hour about this, asteroids are kinda perfect for a space RTS, and I see this as a pretty important piece of the puzzle. OK, that’s asteroids.

The other big thing that is coming up, and maybe keeping me up, is the battle between keyboard/mouse and touchscreen. I’m solving for both at the same time, and though it’s not an insane amount of work, it’s fair to say, it’s not trivial UI design. The problem with it is this… there are 2.4 Billion mobile devices on the planet, and this is a phenomenon that is still growing. Conceivably there will come a day when almost everyone will have one, so let’s call that 6 Billion+ (excluding 1.5 Billion who are too young or too old to use them). These mobile devices keep getting more and more powerful, and as a part of that, we could see a decline in laptop and desktop systems, as well as traditional consoles. Now, I would say, that’s too bad, I will just focus on keyboard/mouse, but the problem with this is, every time… and I mean EVERY time, I’m out talking to a friend at lunch, I’ve got my iPhone out and giving a demo. The demo goes like this… I show them the game on my phone, and then I send them a link, and about 5 seconds later (we’re not on wifi) they have the game running on their phone. And every time I get a little jolt of excitement, like ya, that’s what I’m talking about… but it does come at a cost. So, my question for you is this: How important is it that the game support smart phones? You can just reply back to this email with your answer. And if you have opinions on asteroids, or 3D vs. 2D, or anything else I mentioned above, your thoughts and input are also welcome. Alrighty, that’s the design update for now.

This is the first “full on” technical update, so my guess is that it might not be as interesting to most as the design, but hey, it’s here, so you can read or skip, no worries at all. And though we often see the technical aspects of game development as being pretty standard these days, whether it’s a game built on Unreal, Unity or a custom engine, this project is quite a bit different.

Let’s dive in. In practical terms, IGSE runs in the cloud… or on a server in a datacenter. At present, I am running the game on the Google Cloud inside a VM that uses Debian Linux. I don’t do anything too fancy with the VM. I have experimented and deployed the game inside a Docker container, for day to day development, I prefer to work on the bare metal. Now, for terminology sake you could call the Game Server Instance (GSI) a server, but it’s important to distinguish between software components and hardware. Let’s walk through all the various systems and talk about what each one does.

Main Kanoogi Server - This server is what currently spins the Kanoogi logo and allows people to sign up for the beta. It runs in its own VM. Besides my whacky canvas logo screen, it’s mostly HTML (I whipped this up in a few days, so please don’t hate on it too much) (ed. - this has been replaced now with my new website).

Login Server - This server does a couple of important things. First, it allows players to login and pick the game they want to play, which then include authentication and authorization. Authentication is where I make sure that you are who you say you are, and then authorization is where I check to see if you have the permissions to access a particular system. This is all pretty standard stuff. Once a player has logged in and been through those systems, they get two keys to proceed with. The first key is the UUID for the game server and then second key which is authorization in the form of a session ID (also a UUID). Each player needs both of those to penetrate through the security systems and gain access to the GSI.

Game Server Manager - The GSM, which I also consider a proxy server, takes the two UUIDS and checks the database for the game, and re-authenticates the player to be playing on that specific game. In doing this, opens a connection to the GSI. This is written today in Node.js but could be written in almost anything. My feeling was to see if this would hold up under stress, but if it didn’t, replace it with Golang, or maybe even custom C code. I learn more and more about GCP (The Google Cloud Platform) every day, and feel more comfortable writing custom high performance interfaces. In game development, performance is pretty darn important, so I’ve always got my eye on it.

Google Cloud - The GCP is a huge part of this whole thing, but as the years have gone by, I’ve slowly been learning about Amazon’s AWS and Microsoft's Azure, and they’re all pretty awesome. Google apparently has the fastest backend, where packet transfer times are measured in microseconds (millionths of seconds) instead of milliseconds (thousandths of seconds). Google’s API is thought to be a little more difficult to work with, but I’ve never had a problem with it, and I like the no nonsense aspect to it.

GCP Load Balancers - Using the cloud means that load balancing is a snap. If everyone hits the servers at the same time, everything should work as usual, as more capacity is almost instantly available. This just applies to what is called the “front end”, but on the “back end” it’s a different story, and those servers need a system called, “Auto Scaling”.

GCP Autoscaling - Google’s auto scaling systems are completely configurable. When a criteria is met, more Virtual Machines are created to match the load (load can be CPU, memory and bandwidth to name the most common), but this actually takes time, so this autoscaling should pay attention to trends to bias the predictions based on past demands. Suffice to say, if things get crazy, the backend system, one way or the other, will scale up the number of VM’s to meet the demand. It’s worth noting, that auto scaling works in both directions, which is really important, because when demand drops, those VM’s need to shut down to save on operating costs.

GCP Security - The game runs in a browser, so I am using HTTPS, which is now a standard and is pretty must required today on most websites. I use 2048 bit SSL, which if you look at this encryption statistically, is insanely hard to break. I think banks take it a little further, but for a video game, this is plenty of security. Way easier hack with some phishing scheme than to hack this security directly. Anyone who is a security expert and wants to help me test the system, I welcome the support and help.

GCP Databases - I use two Google databases at present, the first is called Google Datastore, and the other is Google Storage. Google Datastore is a pretty slick indexable database that stores all those mission critical UUIDs. And for big data blobs like save games and scenario data, I use Google Storage.

Data Mirror System - This is is like my own personal Google Drive, where I run a Node.js server that copies those save game files around in the background. I currently save all the game data as a JSON file, which is pretty fluffy and .zip it all up before shoving it up to Google Storage. This service also pulls those same save game files back down, unpacks them, and puts them into the right folders for the game to use. This process is called Hydration and Rehydration by some industry people. This service also keep an eye on the GSI Monitoring system, and reports the health while also restarting it if it fails.

Monitor System - This GSI Monitor primarily makes sure there are enough GSIs running inside a particular VM (the auto-scaler does this job at a regional level). This monitor will start up any additionally needed GSI’s and shut down the unneeded ones, and will also shut down sick or unhealthy instances. It’s important to run as many GSIs on a VM as possible to keep server costs down.

GCP Health Checks - As you can imagine, anything can happen, and for any number of reasons, so it’s important to continuously monitor the health of these systems. The GSI Monitor does this on a VM level, but the Google Health Check system does this on a higher level. This system can simply shut down non-responsive VM’s or it can engage in a sophisticated auditing process where the VM needs to respond within a certain amount of time to let the Health check know it’s OK. Pretty cool stuff!

Wow, that was a lot of stuff, and we haven’t even talked about the client side of things, which includes WebSockets, Javascript and WebGL. We’ll have to save that for next time, but I will tell you, it’s not any less interesting than the cloud part of this, trust me on that!

If you made it through that technical section, let’s get to the last part of this, and answer a few of the questions that have been sent in. And sorry, these are old, but there’s quite a backlog, and I promise to get through them all!

Q & A

Question: Will this game have a story? How about music?

Chris - Those people who know me, and know my design history, know that I’m not really much of a story teller. But for this game, I'd like to try and change that, but I know that to do it right will take a lot of time and energy, and right now I’m focused pretty heavily on the tech to power the game and platform. What’s on the table right now is a gameplay mode that does not have a story, and then later, I want to follow up with a big single player campaign that has a big Intergalactic Space Empire story. As for music, I have a completely new idea and approach, which I will talk about in future updates. (and here’s a hint: We all know that hiring a single composer to create a single musical theme is cool, but it’s been done to death, so I want to push the boundaries and come up with a system that allows for composers to create music almost like a spotify system… damn, I think I just gave away the whole idea… lol!!).

Question: Is the “infinite desktop” idea you talked about years ago going to be a part of this Kanoogi system?

Chris - Great question and I'm glad you asked. At first I thought it would, but after I started to get into the project, I realized that I would not be able to use the work I did on the Infinite Desktop system. You see, that system is all based around a canvas rendering system, and Kanoogi is mostly in WebGL. It’s not to say that I wasn’t able to use the knowledge I gained, but in terms of code, I pretty much wrote the systems from the ground up.

Question: About the RTS game, will there be totally different asymmetric races like Starcraft or will they be similar, but with some differences like Supreme Commander?

Chris - In the first phase, all of the units are the same, and this is due mostly to the fact that I’m an indie developer, and not because of any particular design bias on my part to have only one faction. Because this game will evolve over time, I imagine that it will follow quite naturally that there will be new factions (I call races factions as it's a little nicer sounding) released in the future. That should actually make things interesting, and also allow players to provide some feedback on the core gameplay in the meantime. There is an important point that I almost forgot… at what we think of as Tech Level 3, the player can design and build their own units. So in a sense, the player actually creates their own faction, but only at this higher level. The modules that those units are built from are fairly standardized, whether it’s a weapon system, armor or energy storage module, etc.

Question: Will there be a campaign or is it skirmish only? Will there be a map editor?

Chris - The first phase, and definitely for the beta, I will release the skirmish only mode. It’s also planned to not only release a map editor in the future, but an entire game editor, effectively taking the concept of modding to the next level. And because it’s all in the cloud, imagine it will be like Google Docs… you can edit the game’s systems and it’s all automatically saved on the cloud. This alone makes this new system pretty revolutionary.

Question: Will the online nature of the game allow for bigger games? I would love to play an RTS that could include more than 8-10 armies without slowdown or lag.

Chris - Yes, absolutely. So one of the tests I want to conduct during the beta is a session where there are dozens of players all playing at once. And I also want to test a gameplay mode where players are free to come and go during the game. Lots of craziness is going to come from that. We need to free ourselves up from the constraints of RTS games of the past and look to the future of wild, crazy and experimental new modes of play!

Question: I am curious about the tradeoffs you mentioned and how they will be made smaller in the coming years.

Chris - First off, every year, the internals of the browser become more optimized for graphics, and we’ve seen this with WebGL 1.0, but WebGL 2.0 (which is almost adopted across all browsers) will take that further. Next up, WASM, which is an acronym for Web Assembly, is yet another huge step forward for performance. And there’s more advances that will come from more local storage which can cache assets and more system memory to use for building dynamic and fractally generated textures. I foresee a time that people won’t even blink when they are told the game runs in a browser.

Question: What’s your vision for background? - The rendering of the game - The gameplay itself : Real time strategy game? Similar to TA/SUPCOM/FA gameplay (thinking of resources management)?

Chris - The game takes place in space, and from a timeline perspective, it’s looking more and more like the years 2050 - 2150. This is where humans finally start fighting over planets, moons and asteroids in the solar system. The game is rendered in top-down 2D (which is fast becoming 3D like Total Annihilation), so call it 2.9D (this is a bit of a geeky label, as it’s almost 3D, but because the view is isometric, but I digress). And yes, the gameplay shares its roots with RTS, and though I started out trying to do some stuff that was really “out there”, its slowly kinda found more and more of a foundation in traditional RTS. This happened as I got feedback from friends that they just weren’t feeling it with my pure, somewhat avante garde, space RTS. And as a part of that foundational RTS gameplay, the resource model will be very familiar to those who played TA and SupCom.

Question: How many units can you manage simultaneously?

Chris - I have over 1100 units rendering on a single asteroid, so based on this (it’s highly efficient to build the game this way), there could easily be 10’s of thousands of structural units in the game at any time, especially when you start to consider multiple star systems (for larger games) and then beyond that, multiple galaxies… which is just ridiculous, but I did build the game to support that. It is important to differentiate between “built structures” as units and ships. Ships are more expensive, both on server resources and client resources (and when I say resources, I mean CPU and network bandwidth, memory isn’t a problem). For ships I think somewhere around 1000 in total is probably doable. What’s interesting is that these ships can get quite large, which the system handles just fine. In the future this number will just go up, so by the year 2025, let’s say, I wouldn’t be surprised if there were over 50,000 structural units and 5000 flying units in the game at any one time… in a browser!

Question: Are you going for a massive scale RTS?

Chris - Sadly I wasn’t initially, and then it got out of control, but at that point it was all just math and numbers, so that wasn’t a problem, but now that I’m getting into the specifics of gameplay, I needed to dial it back. That’s why the beta is going to be the skirmish mode, or what I am now calling… wait for it… Rock War (ed. - Ya, I renamed it again!). Rock War is the battle over the asteroids that are in a special system that is totally contrived for an RTS. I do have a model of our solar system, but it doesn’t lend itself as well for a nice, balanced RTS game (and we all know how important it is that things are balanced, otherwise there’s not much point in calling it a strategy game). So not to confuse, but this would be called IGSE: Rock War, as each gameplay mode needs its own specific name.

Question: Will this game feature a persistent universe that continues after you log off/go afk or will it be more traditional where you select/generate a "map" and play matches?

Chris - Yes, everything is persistent. It doesn’t matter if you are playing for an hour, or a week, everything runs in the cloud, so if you stop playing and everyone else keeps playing, then the game will keep running and you can join in at any time (and in 5 seconds or so). If you happen to be playing a single player PvE game, then the game pauses when you close your browser (or the browser times out which is often the case if you just shove your phone in your pocket, or switch away to another web page). This is something I really love about the architecture, as it makes playing so darn convenient!

Until next time...

Chris Taylor

Welcome to update #2 of the Kanoogi platform and Intergalactic Space Empire project.

So here we go, another update, and I will tell you, I know this is a pretty strange thing to be sending out, because you haven’t even seen the game yet. I think I’ll get some screenshots together in the near future, but it’s still early, you can imagine that I’m a little shy about doing that.

I’m going to dive straight into some questions, and I’m answering these, more or less, in the order they were received.

Question: I’m hoping there is some way to use flowfields to do space battles. Lots of little ships huddled around a center base ship with some equations to steer them are probably better than calculating paths for all of them separately. Unless the game is planned to be full 3d motion paths (something akin to Homeworld) then I guess this would not work.

Chris - Ya, flowfields would be awesome, and the reason I say that is because I haven’t implemented a traditional RTS pathfinding solution yet. I’m still thinking about what would make the most sense for a space game. So, for example, I think it’s okay for ships (especially fighters) to pass through each other (which is what they do right now) like in TA and SupCom, but that doesn’t feel right for the bigger ships. But if you recall, often pathfinding makes the unit movement feel pretty mechanical and not very fluid, so my thinking is to try and make the ships movement more forgiving. I think flowfields would work for this, but I also want physical collisions for the big capital ships, something that has not been done in any of my previous games. I think smashing a large ship into another would be pretty epic, so I’m still thinking about the best way I can do that, and still satisfy the other design goals. Flowfield pathfinding is pretty close to the top of the list though.

Question: Out of curiosity are the graphics going to be simplified 3d or some form of 2d with hardware acceleration (probably for smooth transforms). Most people usually played a lot of your previous RTS games zoomed out so we are pretty used to tactical icons. Just wondering if we can zoom in on the action.

Chris - Great question, and surprisingly, this is a 2D game! I can’t remember if I mentioned this in the Gamesbeat story, but this is my first ever 2D game… yes, ever! OK, in truth, when I was working on my TRS-80 back in the early 80’s, I did a bunch of stuff in 2D, but every single game I did professionally, including Hardball II (which looked 2D but was actually 3D under the covers), was mathematically 3D. The Hardball II story is fun and would take some explaining, but trust me on this, you can’t get a ball to bounce properly and detect the back wall without modelling it in 3D. Well, you sort of can, but I just thought it wouldn’t play or look very good, but I digress! Back to the question… So, this game is totally 2D. And for a strategy game on this scale, I think it makes sense and works pretty well. And as you mention, when you pull back and see things while zoomed out, everything more or less becomes 2D. So, in IGSE, you can see a ship at 1:1 zoom, and pull all the way out to 1,000,000:1, ya 1 million to 1. This will show you the entire galaxy (a baby model of the milky way) which contains, at present, 100 stars instead of 400 billion. I think that’s enough star systems for now, but we’ll see. Each star system has a bunch of planets and asteroid belts. And the test map that I am playing with has a small test galaxy on the left, and a large randomly generated galaxy on the right, so you have to scroll to see them. There’s some room to stretch your legs in this game.

Question: 6.) What kind of sacrifices needed to be made to make this game work on a browser?

Chris - Without a doubt, there are some pretty significant sacrifices, but it’s not all bad, meaning, the sacrifices aren’t as painful as I thought they might be when I first started the project. The biggest sacrifice is not performance, like one might expect, but rather it’s the use of textures. Textures for models, the UI, sky boxes, etc, are awesome, but when you don’t have them, it creates a very different experience, but as you’ll find out, you can get over this pretty quickly. I find that fascinating. But even Minecraft, which is now famous for its 8 bit, and rather simple textures, does in fact need textures, and those textures are a very important part of that game. So how is it possible to create a game without them? This is all part of the fun, and the challenge of creating this game, and one that I wasn confident about, and still had me a little worried. The theory is, that gameplay is king, and that even without textures it is possible to make a fun game. So the pressure is on, and we’re going to find out.

Other sacrifices get a lot smaller, but they aren’t zero. Things like, always being online to play, and having to create a game that supports a mechanism to pay for server time. In other words, it’s not using a tried and true model of charging once for the whole game. If you stop and think about it, as soon as you host a game on a server, you need to change the business model, and though I’m not super comfortable with this change, it’s one that I’m working through and hope I can find the right set of compromises for. That’s perhaps a whole update in and of itself.

Question: When this goes live, how will it be monetized? Will it be a subscription service or will it have microtransactions?

Chris - When I wrote the previous answer, I didn’t even look at the next one, and coincidentally, it hits on the point that i was starting to dig into. I’ll try and answer it as directly as I can. Right now, the game would be classified as free to play. I am currently looking at opt-in advertising (you watch a video to generate some in-game currency) and/or you can just pay to unlock the feature. If you are reading this and you have an opinion, one way or the other, please let me know, I would find it very valuable to know how you all feel about it, and perhaps, what you prefer.

Question: How will this game look in terms of graphics?

Chris - I think the easiest way to answer this is to simply include a screenshot of the game, as it currently looks today, so I’ll try and do that in an upcoming update. The graphics are very simple, and they are kinda old school like early polygon games from the 90’s, but really kinda sit in a category all their own. For example, I use shaders for things like the stars, which looks absolutely stunning, but that’s in sharp contrast the ships, which are more like vector graphics. The first reaction I get (and perhaps I’m being self conscious about them) is that friends and acquaintances I show the game to are a little surprised and expect more (and specifically textures), but I know the graphics will go through a lot of changes and the final game will look quite a bit better (it’s not quite fair to call it programmer art, but it kinda is). I think it’s going to be great to get your feedback on it in the near future. What is a huge positive about this graphical style is that they render blazingly fast, and the game runs on most devices at 60 FPS. And when projectiles are flying, and there are explosions everywhere, you can quickly forget about the simple untextured graphics. There’s a little magic in there, and I’m watching it grow.

OK, last question for now, but there are more to come next time…

Question: Will the controls be with mouse and keyboard? Controller? Touch screen? Or all?

Chris - The game works on both PC (Keyboard/Mouse) and Mobile (Touchscreen). This is no small feat, and some things are easier on touch vs. mouse or vice versa, but I think ultimately many of you will enjoy the PC the most, as it’s my guess that most of you who have joined this beta are PC gamers. I also know that some of you will just be amazed at how well it runs on your mobile device, whether that’s an iPhone or Android, and some will get a kick out of playing on iPad and Chromebooks. It’s probably ridiculous what I’m doing, but with your help, I can break new ground and create a game that can be played on any device… and that’s around 2.5 Billion globally. It's a worthy goal.

Until next time...

Chris Taylor

Welcome to the first ever Kanoogi and Intergalactic Space Empire game and platform update!

These past few weeks have been really great, as I’ve received a lot of very insightful questions about the project, which as you know, is not quite like any other gaming project you’ve likely heard of in recent memory. So I’m going to jump in and start answering questions and tackle the biggest one of all first.

Question: What is the story or history behind your decision to create this game and why are you doing it as an indie developer?

Chris - When I first started working on this project after leaving Wargaming as GM of the Wargaming Seattle studio back in Oct 2016, I wanted to take a break from doing what was considered very traditional big “Triple A” PC games. I had been doing those games for most of my career, sort of. Well, you see, back in the late 80’s, those big triple A PC games weren’t very big, they were actually quite small, and oftentimes they had just one of two people on the team. As the years went by, those teams grew, and the complexity of building a game grew with that team size (and as you can imagine the total development budget). This was really fun at first, because all of us in the games industry could really feel the business “grow up” and that was without a doubt, a truly fun adventure to be on, and I wouldn’t change a thing. However, as the business continued to grow and evolve, the focus started to shift away from the games themselves and more and more towards the financial aspects of it all, and the finances would often interfere with the creative decision making. It’s not to say that this was all bad, as some studios were able to find success early on, and use that success to sort of “beat back” the financial interference, but for many, working with publishers who had financial goals to meet became our reality. And slowly, over the years, the fun was slowly disappearing and the stress of running a business and managing money, took its place.

So back to Oct 2016, this was when I had to think about what I wanted to do next. My decision was easy, I wanted to make a game, and return to the times where I had the most fun, and a time that was about making games for fun, and for players to truly enjoy as an artform, and not as a business. So, I made the choice to create a game that I had been thinking about (I made notes in a little book I keep called, “Chris Taylor’s insane book of game ideas”) a little game I called Space Empire. The idea was to make a vector graphics based game that was visually very simple, but that had a lot of depth to it. Anyhow, this was the game I wanted to make, and oh, the best part of it all, I wanted to create something so “avante garde” that the player would be looking at vector graphics all the while listening to an amazing soundtrack, and listening to their ship’s crew with top industry voice talent. I thought the blend of these two completely different ideas would be awesome. I guess we’re all going to find out! But I digress, there’s a lot to this story…

So, when I finally sat down and decided that I wanted to allow people all over the world to play, and play on any device they owned, the browser was the only clear choice. However, the browser has historically been a nightmare to develop on, with so much incompatibility, the development would be difficult, and there was another big problem, security. Oh, and don’t even get me started about performance. How was I going to move massive fleets of ships around using Javascript? Well, I’m happy to say that each of these has a solution. So first of all, browsers have finally crossed a critical threshold of compatibility, and there are only a few things that need to be done to make stuff run on almost all of the major browsers today. Second, the performance of Javascript has made huge strides forward, which although isn’t quite enough to run an RTS game, was enough to communicate with a server and then manage all the rendering code, all while the more complex stuff could take place in the cloud. I’m talking about things like collision detection, pathfinding and the simulation that runs the economy and other game logic. So, the last thing was security, and that was taken care of by running the most mission critical elements in the cloud, which would run behind a secure 2048 bit SSL connection. Happy with all of this, I decided to press onward, and in doing so, I realized something fundamental. This game cannot really run on or be distributed by a typical game distribution service, as they really aren’t in the business of providing virtual machines that run in the cloud, and oh, by the way, auto-scale up to meet a rising need and then scale back down again as the need subsides. So I really had no choice but to create my own server solution and well, gaming platform.

Ok, so that was a lot of stuff. But you start to see how this is all connected. It starts by wanting to create something simple, and then it grew into something a lot bigger, but a lot more awesome, and a lot more interesting. But I also stuck to the original design vision and made decisions that were necessary to bring that vision to life.

Question: Will the game be a full open map (64-bit floating point) or are you planning on cutting space up into sectors (instances) and sticking with the integer range of coordinates? (I'm guessing ints would be kinder when it comes to bandwidth in a web game)

Chris - Yes, you got it right. Because 64 bit processors are now commonplace, it is possible to create an enormous universe with multiple galaxies without worrying about exceeding the numerical precision of a 64 bit number. I thought it would be fun not to limit the game in this regard, so a game could be played on a small "map" that spans a single solar system all the way up to a small universe.

Question: I've noticed you've become a big fan of tech trees throughout the years so I'm guessing I.S.E will have an extensive branching research system.

Chris - You might be surprised to know that although those tech trees were kinda fun, there was something that I just didn’t like about the predictability of it all. So instead, IGSE will definitely have a huge amount of tech, but you won’t research it on a tree, but instead acquire it by exploring the universe and taking it from other alien races or perhaps by finding it in an abandoned or derelict ship. The other thing is, because iGSE is an online game that can be updated almost continually, it is possible that new tech will be continually introduced. This is so much different than a traditional PC RTS game.

Question: Will ships / units have modular structures, this could cut download times and utilize a form of instancing.

Chris - Yes, you nailed it. Each ship is designed by the player to be completely unique. There are various shaped hulls and each hull can have a module installed inside of it. That modules power and ability is affected by the hulls and modules that surround it. The sizes of the ships in development are approaching 3000 hulls, so they can get quite massive. There’s no reason they couldn’t be 5000+ in size.

That’s probably enough for now, I’ll send another email out next week and I’ll dive into a lot more questions and specifics.

All the best!

Chris Taylor