It's Alive!

I haven't posted in a little while because I've been waiting for the next natural breaking point in development, where I have something significant to say.

Making things like this always feels a bit like a long road trip to me, you've got your mountains, your valleys, your long stretches. Right now I feel a bit like I've finally reached the ridge after a long uphill stint. Suddenly a bunch of things have come together and started working and there's a great sense of possibilities.

The things in this simulated world have finally started to talk to each other. I wanted to start with something simple, so I decided to get the power grid working, starting with the power stations. The first official breath of life in my world started in the power station located in Jakarta (which happens to be positioned almost directly beneath the camera's initial position, so it gets a lot of attention). I zoomed in to it until I could see it's constituent parts. The "SuperHighVoltagePower" generator (I really should find out the technical terms for this stuff) sputtered into life after it's initial 5 second delay period. It's produced a signal of "1" on the SuperHighVoltagePower wire which slowly traveled down it's connected wires, leading it to the power station's external power connection. The connection, as defined by its relay function (described in my last post), transmitted this power signal over to the adjacent Large Power Substation, who's job it is to bring the voltage of the power down from SuperHighVoltagePower to HighVoltagePower (yeah... I'm a scientist me) and transmit it to the other power-needy sites in Jakarta.

What I quite like about what I've created so far is all these behaviors are pretty much all defined in these easily modifiable JSON files. The only behaviors that live in code so far are the functions' logic, and given how very atomic and simple they tend to be, I will likely pull that behavior out into a scripting language, probably LUA, to make sure they are moddable too.

The next interesting challenge is going to be getting a city to adopt the behaviors of all its children and its children's children, so looking at a freshly generated city, you would see it spitting out the network traffic and power output you would expect to see it's as-of-yet ungenerated children produce. I could brute force this using a recursive approach that scoops up any important functions of a city's children, and run those functions on the children's behalf until they have been generated and can take over. But I think I'd prefer to start work on a more scallable kinda "traffic profile" system.

I'd want the traffic, be it network and power, to be produced by a traffic profile that is defined by the the profiles of a node's children. Instead of running hundreds of individual functions on the children's behalf, it would lump all this behavior together into a single traffic profile. If changes were to happen to this profile, say the city receives a number of new virus infections, when the player zooms in on the city and its children become relevant again or are generated for the first time, these new infections would be distributed to the node's children, and when zooming out again, the profiles would be consolidated back into its parent's profile. This feels like the only way to simulate an approximation of the entire internet on a little tablet :S

So that will likely be taking up quite a few of my next lunch breaks. Will report back when I've made some progress there :]

Keeping it Moddable

I've always been a huge fan of heavily moddable games, and I derive a bit too much pleasure from creating purely data-driven game systems. Not only for the benefit for the end user, but for my own sanity, I like fast turn around times and quick iterations, and if that means editing a simple JSON file vs recompiling the source I'll happily put the effort in to make things work this way.

Up till now, everything generated in HTP has been defined by node templates, as shown briefly in my last post. But till now, these node templates have only defined the structural qualities of a node. The size, name, requirements, provisions and children. Not the functionality.

In keeping with the data-driven approach, I want to keep as much of the functionality of these nodes in their template files as well. So I've introduced the concept of 'functions' to the templates. As an example, here is the new CPU template:

{
   "ShouldScale": false,
   "StaticNodes": true,
   "MinSize": 0.1,
   "MaxSize": 0.1,
   "Needs": ["Power", "Network", "Storage"],
   "Provides": ["Cycles"],
   "MinimumNeeds": ["Power"],
   "Functions":
   [
      {
         "Type": "ProvideResource",
         "ResourceType": "Cycles",
         "Amount": 1,
         "Interval": 5
      },
      {
         "Type": "Relay",
         "SignalTypes": ["Network", "Storage"]
      }
   ]
}

Here you can see that a CPU node offers two functions. First, when it is powered up and active (determined by the new 'MinimumNeeds' property), it will produce 1 'cycle' every 5 seconds. These cycles will be carried down bus connections to other nodes, notably the OS node, which will power up and start providing its functionality. The second function of the CPU is it to act as a middleman and relay certain types of signals from other nodes to all connected nodes, in this case network and storage signals to the network adapter and hard drive respectively.

It's still early days with this new system, but the goal to keep as much functionality in the data files as possible, to the point where I might look into replacing these function definitions with some kind of scripting language in the future.

In other news, I picked up a copy of Light the other day, not because it's my kind of game especially, though it is very good. But mainly because some of the visuals are exactly the kind of thing I've been imagining for HTP. The glitchy, staticy menu effects are fantastic, I've actually emailed the developer hoping for some friendly shader advice if they don't mind giving it.

Getting Things in Order

So I guess I'd like to bring this blog up to speed now by talking a bit about HTP's procedural generation system and it's current graphics. This one will be a fairly technical I warn you.

I've always been a big fan of procedural generation in games, I guess you could say it's not only the calling card, but the saviour of indie game developers. With tiny teams and limited resources, why not get the CPU to do the leg-work for you? But PGC (I've had a couple beers and don't fancy typing about procedurally generated content more then once) can seem very lifeless and boring if not treated carefully. I feel PGC should help the developer fill in the blanks. Provide the world with a good starting point for custom content, and if possible, be clever enough to hopefully provide some emergent gameplay experiences while it's at it.

For HTP, I wanted to be able to define how different nodes (pretty much everything in HTP is represented by a node: computers, networks, cities, etc.) should be generated depending on the size, security, population, etc. of it's parent node. This is defined in a JSON file that's easy enough to hand edit at the moment that I don't feel the need for an editor. For example, the following is the current definition of an ISP that might be generated in a city (if it's large enough to have one):

{
    "ShouldScale": true,
    "MinSize": 0.1,
    "MaxSize": 0.1,
    "Needs": ["Power", "ExternalNetwork"],
    "Provides": ["Network", "ExternalNetwork"],
    "Structure":
    [
        {
            "Type": "Router",
            "Serves":
            [
                {
                    "Type": "Firewall",
                    "MinSecurity": 0.3,
                    "Serves":
                    [
                        {
                            "Type": "Computer",
                            "Role": "Webserver",
                            "Max": 3
                        },
                        {
                            "Type": "Switch",
                            "Serves":
                            [
                                {
                                    "Type": "Computer",
                                    "Role": "Workstation",
                                    "PerPerson": 0.75,
                                    "Hours": ["Work", "LazyNights"]
                                }
                            ]
                        }
                    ]
                },
                {
                    "Type": "WiFiAccessPoint",
                    "MaxSecurity": 0.1,
                    "Serves":
                    [
                        {
                            "Type": "Mobile",
                            "PerPerson": 0.2,
                            "Hours": ["Work"]
                        }
                    ]
                }
            ]
        },
        {
            "Type": "FuseBox",
        }
    ]
}

There's a few interesting things here. As you might be able to see, if this ISP is generated with a low enough security rating (ie. it's got pretty shitty security), then some terrible network admin might have inadvertently plugged a Wifi access point directly into their main router, in front of the firewall. Massive security risk, and something I wanted there to be a chance of encountering in the wild. I can also specify the hours that a given node might be active. So for the employee workstations in this ISP, they will always be active during work hours, but with the added possibility of being active during the night if an employee forgot to turn it off or just likes wasting power.

There's still a lot more work to do here, but my goal is to make these definition files very moddable and extensible, as well as easy to edit.

At this point I was generating some pretty busy worlds, with the largest cities having their own power plants, ISPs and residential neighbourhoods, and smaller cities feeding off those large cities with network and power substations (I still really need to figure out the real names for those :P). But things were getting very cluttered and disorganised, I had no choice but to simple randomly place nodes anywhere within their parent node's bounds, resulting in a lot of ugly overlap. I spent some time looking into box packing algorithms to try and make some more sense of this mess, but it turns out hierarchical box packing is a bit of an NP problem.

Then along comes physics to the rescue. I love physics, it makes extremely hard to solve analytical problems just sorta "pan out". I read up on force-driven layouts. This technique applies attraction and repulsion forces to a set of nodes and will, given some time, settle them in the lowest energy state, which very fortunately, usually looks quite nice :]

I'm still working on the layout system, so take the following video as a work in progress, but here it is so far:

This brings this blog pretty much up to date to where I am now. I'm hoping to post once or twice a week with the latest developments from my lunch-break programming adventures, I hope you keep checking in :]

Making Ends Meet

Shortly after I began developing HTP I discovered an interesting free course on Coursera.org called Malicious Software and its Underground Economy. I jumped at the chance to learn a bit more about how the darker corners of the internet function, and whilst I didn't have the spare hours in the week to finish the whole course, I did watch all the lectures and read the subject matter and learnt a lot about malware, and in particular, botnets. Building up a botnet seems like a good gameplay avenue, it's measurable, it's useful, and it's volatile,

I'm still playing with ideas in my head about how one could have fun in a simulated internet, and hacking is the obvious choice. As much as I have enjoyed games like Uplink in the past, they have always been more mission based, where you take on a single target at a time in a fairly rigid and structured way. I would prefer to have a more emergent experience with HTP, where networks and computers operate as they would in the real world, controlled by AI agents with varying motivations and skill levels.

You might find a neighbourhood populated with many low security home networks. These networks would contain computers controlled by average Joes. The kind of traffic you might expect to see coming out of a home network would be social networking, low level e-commerce, maybe some internet banking. These target themselves maybe not usually be very juicy, but their relatively low level of security and abundance make them perfect targets for learning the ropes, and more importantly, building up a botnet. And a sizable botnet might open up doors for other, larger, opportunities.

I'll have to make a post here at some point outlining how I plan to handle the procedurally generated network traffic that will breath life into this simulated internet, while still scaling well enough to allow me to simulate a whole planet's worth of net traffic.

So at this point I'm in the strange position of having already programmed a fair bit of the low level details of how computers operate. I have functioning kernels running processes, powered by a CPU, powered by a power supply via a PSU. I have DHCP discovery and basic packet routing. I have a lot of the little functional details, but have no world for them to exist. So I've ended up with a fairly strange approach to development so far. I'm currently programming my way down from the 20,000 feet level to ground level, which means I still have no vertical slice, even after being at this for almost 3 months of lunch breaks now. It's a *little* disappointing, but isn't really accompanied with the usual feelings of frustration of not having seen everything working together, because I already KNOW the little details can work, and I'm just slowing making both ends meet up somewhere in the middle.

Anyway, a guess it's time for some visuals. This video was taken just after I got my 3D globe up and running and was testing out the zoom system (which was actually a lot harder then I though, given the scale of the world and the fact I want to zoom right down the component level without hitting the near clip plane, still lots of work to do there).

In my next post I'll talk a little bit about the procedural generation system and force-driven node layouts :]

Creating the Planet

Ok, so I know more or less what I want to make HTP into now.

The first thing I decided is that when real-life data was available, I would my best to use it. The first gem I found was a list of every city and town in the world with a population of more then 15,000, complete with the longitude and latitude, country code, language spoken, alternative names, etc. It was a perfect starting point.

Next I found a vector drawing of the world and all it's borders. It is an equirectangular projection, which made plotting the locations of the cities in my huge city list easy, with this kind of projection, X/Y map directly to longitude/latitude. This is why it's so often used in computer graphics, it makes mapping UVs trivial.

The map was in the SVG vector format, something I didn't have much experience with. There are parsing libraries out there, but it turns out web browsers are already very capable of parsing them for me. So I wrote a little javascript that would let the browser do the hard work and spit out a huge vertex list which I could dump into a text file and use in-game.

I'm using the Unity engine at this point, though I'm fairly certain I'll roll my own further down the line. I'm using so little of the heavy-lifting Unity offers and the overheads for what I am using it for are too high for the scale of what I'm trying to create. For those familiar with Unity, the possibility of over a million GameObjects in a scene at once doesn't smell very good. But for now, Unity will do fine. On another note, I made a production choice very early on with this project, and it might sounds insane to many. I'm doing 100% of the development of HTP on a Microsoft Surface Pro tablet. My reasoning (beyond the joy of developing in a bar in my lunch breaks), is that I'm afraid developing on a powerful desktop machine will only end up with me creating a massive, but horribly inefficient simulation. This approach will force me to keep my code lean and clean, hopefully resulting in a very slick gaming experience for all users in the end.

But, saying all that, I have made a few 'upgrades' :]

The Beginning

So here it is, the start of my development blog for a game I'm working on called Hack The Planet.

One or more of you out there might notice the blatent Hackers reference, if not, you're missing out on one of the best worst films ever made :]

I'm trying to think of what I consider influences for HTP, but I'm drawing somewhat of a blank, likely because I have very little idea of how the gameplay will work yet. I suppose I am inspired by Introversion's excellent offerings Uplink and Defcon. But as great as those games were, they really just set the scene, and I always craved more realism, scope and emergent gameplay. So that's what I hope to achieve with HTP.

HTP didn't start out as a game project, in fact, it started out as a silly little lunch break project to take my mind off my day job. It started life as a little graphical representation of some command line processes.

I could start a ping process, wire it to a port scanner process, and fire the result over to an echo node. The output produced by the processes would flow around the system, they could be filtered, diverted, thrown away, and consumed by other processes.

This little distraction of a project went on a for a couple weeks of lunch breaks, then one day I found myself in a bar around the corner from work with no Wifi. Annoyed that I couldn't work on my project, I thought to myself "Oh well, I guess I could just fake the internet, yeah.. how hard could that be". So I made my own little internet. It started as a simple fake google.com I could ping and poke at and it would produce results similar to the real thing. Yay I though, I can carry on.

But then I got a little obsessed with the idea of creating a functioning internet inside my computer... even when I had access to the real thing, I kept on developing my simulated one. The project took on a life of it's own, I didn't care about the original idea any more, this thing was almost writing itself. I poured through RFCs, tried to expand my knowledge of the inner workings of the net, what made it tick, then reproduced what I learnt with my net-in-a-box.

Things started to get unwieldy though. Even with a save/load system, creating and recreating these small networks was becoming cumbersome. I must have built hundreds upon hundreds of computers and networks. Carefully placing the PSUs, CPUs, network adaptors, OSs, kernels, individual processes. It became obvious this wouldn't scale. Procedural generation was the only option.

This is when things got interesting, when I realised I knew what I wanted to create. I wanted to make an internet simulator, built around a fully functioning, breathing internet, made up of millions of computers, thousands of networks, hundreds of locations. I didn't and still don't have any clue how I'm going to make this into a game, but it's the most interesting project I've ever worked on in my career so fuck it, here goes :]