4. Jan 2020 3. Oct 2019 2. June 2019 1. May 2019
Development Updates

Update 4 - Jan 2020

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). Design, technical and lastly Q & A.

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.

Design Update

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 it’s 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! :)

Tech Update

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.

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.

Q & A

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?

A: It’s really looking like that is the plan, but like I’ve told developers who have talked to me about building something on the platform… you can still deliver a game in other, more traditional ways, using the same Kanoogi server backend, as none of that tech stack in the cloud cares whether it’s a browser or not.

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

Update 3 - Oct 2019

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!)

Design Update

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.

Tech Update

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 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

Update 2 - June 2019

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

Update 1 - May 2019

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