Tuesday 9 December 2014

Tutorial-Driven Development

I've come up with a new approach to development. Previously I would just choose the next feature I though HTP needed to slowly drive it towards gameplay completion, and tackle that. It was working, but it was slow and haphazard, also it resulted in a lot of the little details that make a game complete getting missed out.

My new approach is something I'm called "tutorial-driven development", I suppose it's a bit like test-driven development for games in a way. I started by planning out the entire tutorial sequence a new player will be presented with on the start of a new game. A sequence that when completed will give a new player a basic handle on the gameplay. It was a little intimidating to realize how much work was still left to do before I could call HTP a 'game' of any description. But it also gave me an excellent to-do list of large and small features I needed for that to happen. I've just been slowly chewing my through those features.

The first step was to create a mission chain system, since the tutorial would be made up as a series of missions, which might share common source users and target devices. For those interested, a mission chain template looks a bit like this:

{
"Contacts":
[
{
"Name": "A Friend",
"Type": "Hacker",
"IsMale": "false"
}
],
"Targets":
[
{
"Name": "NeighbouringComputer",
"DeviceTypes": ["Computer"],
"Vicinity": "HomeNetwork"
},
{
"Name": "NeighbouringNetworkRouter",
"DeviceTypes": ["Router"],
"Vicinity": "NeighbouringNetwork",
"Origin": "HomeNetwork"
}
],
"Chain":
[
{
"Description": "Welcome to the grid {ACCEPTINGUSERNAME},\n\nYou don't know me, but you can trust me. I was once like you, back when I was just getting started.\n\nI guess I feel for you.. I know how hard it can be, at the beginning. I'm going to help you, cause a long time ago, someone helped me, so it feels like the right thing to do. Besides, I could use a little good karma right about now.\n\nReply to this message and we can get started.\n\n - {SOURCEUSERNAME}",
"ShortDescription": "Welcome",
"ResponseMessage": "Let's get started.\n\n - {ACCEPTINGUSERNAME}",

"Goal":
{
"Type": "Respond",
},
"Source": "A Friend",

"DelayUntilNextMission": 2
},

...

I won't get into too much detail explaining this, as I'm trying to keep this update more gameplay-oriented, but I'm sure the coders out there can see where I'm going with this. Unfortunately these mission chain templates, unlike many of the other templates, are getting quite clunky to edit by hand, so at some point I think I'm going to have to pull my thumb out and write an editor for all these templates. I'm mainly putting it off cause it's boring as hell.

I've completed the first 9 tutorial missions so far, and in the process have been forced to code lots of little tiny features and polish existing ones, it's been a great exercise.

Another thing I've been working on has been revamping the connections between nodes. Until recently they were just simple 1 pixel wide lines that flashed with network activity, I always wanted them to be more then that, so to that end I've replaced them with true cylindrical meshes. Now now have real dimensions, and will be able to contain things like neat traffic effects, or even the player, acting as kinds of highways.


Obviously a lot is still to be done with their visuals, but I've proven the performance hit of having thousands of true 3D connections instead of simple lines is negligible.

Well that's all for now, just a quick update. The next thing I will be working on is letting web servers has a role defined, which governs what kind of web content they will serve. Starting with a vulnerability database needed for the next tutorial mission.

Hack the Planet!

Saturday 6 December 2014

Saturday 29 November 2014

Thin Vertical Slice

It's not even been a month yet, I feel like I'm jumping the gun with another update. But I've got so much done over the past few weeks I feel like if I left it any longer it would result in my brain exploding into an endless wall of text no one would care to read.

I'm going to present this in more of a bullet point form, as there are a bunch of small and large things I want to document here, so in more of less chronological order since since my last update:

Users:

Users are tangible things now, they have names, skills, homes and workplaces. They come in a variety of types, some separated by income brackets, some by affiliation. Different kinds of users will generate different amounts of network traffic, and their files and network traffic have different values based on what kind of user they are. A hacker will generate gobs of network traffic of a fairly high value, but has an extremely high security skill rating, which will make it much harder to steal from them. A low income average user has a lower security rating and lower value files and traffic.

Next thing I want to do with users is give them presence, so they can either be at work or at home, and depending on their job and function, this will effect gameplay. If a extremely skilled security officer in a corporate network is giving you grief, simply find out where he lives, hack into his home network, and set off his security alarm, causing him to go home and getting him off your back.

Movement:

I always wanted to tie movement into the connections between networks. I still want to maintain the feeling of flying freely through cyberspace, so I've compromised and calculated the player's speed based on their proximity to network connections and how much bandwidth those connections have. The result will be that a player must more or less follow the connections between networks, and faster connections will act as highways between distant networks.

I've also replace the old camera controls with a new physics based camera. I think it feels much more satisfying to get around with these new controls. The camera accelerates, drifts, can spin and roll and interacts with the world more realistically. I also added a neat impact effect using the new post-effects (more on that later):


Traffic Visualization:

Network traffic is visible now on the connections between networks. Depending on that kind of devices are connected, and who is using those devices, different amounts of traffic is generated. A printer talking to a home network's switch will create very little traffic, whilst a web server connected to a firewall will create a significant amount of traffic. These effects can be seen in the video below, and are made all the more obvious with the new bloom effect (again, more on that later):

Network Entrances:

Networks are now contained spaces, with entrances consisting of devices like routers. You can 'pass through' a network by flying around it, but if you want to access the internal devices in the network, you first have to gain access to one of these entrances.



Once inside a network, they are kind of self-contained little levels, which you fly around and hack your way through. Still a lot of work to do here, I want to have the outside world sill visible through the boundaries of the network, though slightly blurred. And I would love to differ the style and appearance of varying types of networks. Cold, monolithic regimented looks for military and government networks, and warm, cozy, loose looks for home networks.



Post-Effects:

The Unity asset store takes most of the credit for these improvements. I found an excellent old TV tube shader to create the scanline, noise and chromatic aberration effects (check it out here: https://www.assetstore.unity3d.com/en/#!/content/24046). I also added some bloom, glow, vignette and FSAA effects to some cheap graphics wins. The improvement in appearance should tide me over for a while and make me less embarrassed to show off what I have so far.

Messaging System:

This was going to start out as a tutorial system for new players, but I think will become much more integral to gameplay in the future. It's basically an email inbox. When writing the initial introduction message, it became apparent that a storyline could very well fit into this game, and as much as I don't really care for storylines in games, I do kind of look forward to writing one, no matter how flimsy, for HTP.

Missions:

After creating a basic messaging system, I got a bit carried away and ended up writing a random mission generation system. I didn't really plan on having missions in HTP, but after having added them, I'm not sure how it would have ever worked without them. Here's a short video running through a simple 'steal the file' mission. The mission is only completable with debug tools, but it gets the idea across:


Name Generation:

Finally, after having added missions, and not wanting to simply waypoint the mission's goal out blatantly, I added random network name generation to the world. This will help me guide the player to a mission's target without directly revealing it, "Please steal file X from Mrs. Y, she lives near Z.". This was pretty fun to implement, I do love seeing procedural generation in the wild :) Though I have to say, most of the business names come off as a little 'new media' at the moment :S

Well that's it for now, I think I've got enough off my chest to carry on with the next push. I think the next thing on my plate is giving money a purpose and adding 'shops' to the game. Don't know how they're going to work yet, but I'll figure something out.

Now if you'll excuse me, there's 23 punk bands playing tonight for $15 and I need to get my drink on...

Hack the Planet!

Tuesday 11 November 2014

Gameplay Brainstorming


Some lunch break gameplay ideas to help guide my development:
  • A frontal attack is too difficult on a high security target, so instead, discover a nearby person who works at the target and infect their phone or laptop with malware that has a chance of spreading to the internals of the target network.
  • If a target's primary entry point is too secure, but a currently unused backup entry point is less secure, a DOS or other disabling attack to the target's primary entry point could result in the backup entry point becoming active, allowing for entry into the network.
  • Some extremely high security, high value networks are air-gapped with the exception of a highly controlled satellite connection via another high security network.
  • A target's security personal are only human and can be distracted by attacks on secondary targets on a network, lessening the chance of detection of an attack on the primary target.
  • Harnessing the power of a botnet can make it possible to crack crypto-coin wallets.
  • Networks containing devices owned by VIPs can yield high value data which can be sold on the blackmarket.
  • Messing with VIPs' data will attract the attention of the authorities, raising your suspicion level.
  • A high suspicion level will cause the authorities security professionals to actively seek you out. You can reduce your suspicion and lower your chance of arrest by moving your home base.
  • Dwelling at the same home base for too long with a high suspicion level will result in the authorities probing your network. If these probes go unnoticed for too long, you will be raided and arrested. Taking the appropriate precautions and looking out for activity by the authorities at your home base will keep you one step ahead.
  • Moving your home base takes time and costs significant amounts of money. The new location should be chosen carefully.
  • Software and exploits can be purchased from other hackers, finding these hackers can be difficult and some will not deal with you until you've reached a certain skill level.
  • The presence of another hacker on a network can be identified by the unusual behavior of a device on the network.
  • Other hackers have home bases as well, containing their collection of software and exploits, these devices are extremely high security and difficult to attack. Doing so will not raise your suspicion level with the authorities, but will likely result in retaliation if detected.
  • Security advisories can be translated into exploits with a high enough skill level.
  • Every workstation has a user. Every user has a home network their other devices may be found on while they're not at work.
I've also added filesystems, money and time too, so here's a picture to keep things colorful:


Saturday 8 November 2014

5k lines of code lighter...

So another month has past, there seems to be a pattern forming here. Maybe I'll make this a monthly update kinda deal. I've been finding much more time to spend on HTP over this last month, mainly because I've been making it a high priority to find the time. Things have been going very well, my decision to throw out my old art style was definitely the right one, and actually led to me throwing almost my entire code base away, a depressing thing as any programmers out there will know, but almost always worth the pain.

I had a gameplay epiphany the other day, on the toilet of course, where all epiphanies must occur. Up till then, I was never really sure how I was going to translate this strange simulated internet thing I've been creating into some kind of game, something fun. Up till then, I was adamant on simulating every tiny little aspect of everything as a node in a hierarchy. The world had cities, cities had sites, sites had networks, networks had computers, and computers had components. It was kinda cool, being able to zoom right down from the world level to the CPU level. Cool, but extremely costly. To generate the 100,000+ computers I wanted to make the game feel 'vast' meant simulating literally millions and millions of nodes. All the time. It didn't scale, and was really leading me to any kinda of gameplay.

So on the toilet, it dawned on me, I could simulate thousands of nodes without much difficulty, so if these nodes weren't individual components, but entire networks, I could easily have the hundreds of thousands of computers I wanted, and each of these networks, which would form the galaxy of interconnected nodes floating in cyberspace, the experience I wanted to create, could be its own sort of 'level', with its own puzzles and challenges. It's kind of hard to articulate how I think this is going to work in my head, so I supposed it's probably easier to just show you. So here is the closest I've come to a thin vertical slice of how the finished game might play so far. You'll notice for the first time a few actual gameplay elements going on as I take on a small home network and infect a computer with some malware:



I'm much happier with the visuals, as primitive as they are, I think I could do a lot with them. It's also nice simulating networks like this because I can happily simulate the physics on 100-200+ computers in these networks and get that nice movement as new nodes are discovered and the network fleshes out.

In terms of the user interface, I started out trying to use a 3D interface that surrounded each node and displayed relevant information, but I found it hard to read, clunky, and getting in the way of the cyberspace feel. The current system console UI started out as a quick and dirty debug placeholder, but it's starting to grow on me, I think with some love, it could actually work for the final UI. It suits the hacker motif and I can convey a lot more information then I could with a 3D in-world UI. So it'll do for now, and I'll see how it pans out later as the game gets more complex.

Whilst the gameplay is still very very early on, I'm still trying to be very careful to try and not corner myself into repetitive gameplay, so am trying to think of ways to encourage lateral thinking and emergent puzzles. For instance, when attempting to hack an ISP or other high security network, a full frontal attack may be extremely difficult, with layers of firewalls and intruder detection systems. But ISPs must have a human element, an alternative approach would be to identify a nearby home network in which one of the ISP's employees works, then attempt to hack through their relatively low security home network and plant some malware on their mobile phone whilst it's connected to their wifi. This malware may in turn find it's way onto the internal network of the ISP and provide you with a backdoor that would be otherwise very hard to establish. It's this kind of gameplay I want to encourage, and while I'm a long away from that level of gameplay now, it helps to keep that in the back of my head at all times.

Well I guess that'll do for this month, I'm very excited with where HTP is at now, mostly because I've gotten over a lot of the technical challenges now, and am able to work on some of the pure gameplay elements.. which is not only more fun, but much easier work in comparison. The next month should be quite productive if I can still make the time to work on HTP.

Hack the Planet!

Tuesday 7 October 2014

Bloody Crunch

It's been a long time since I both had a chance to write something on here or even work on HTP. The promised 2 weeks of The Crunch turned into 4 weeks, as always seems to be the way. The Crunch simply prevented me spending any time at all on HTP. As I'm sure some of the other developers out there know, time spent away from a project slowly builds up a barrier to re-entry, as knowledge of the code base fades and momentum is lost.

Crunch time is starting to end at my work, and for my own sanity I need to take my personal project time more seriously and make time for it.

This is not going to be a technical blog post for once, this is I guess more my ramblings about how, as developers, we tackle code block (the equivalent of writer's block for the non-programmers out there) and keeping project momentum going. I've been in this situation many times, and I've slowly learnt how to deal with it.

When approaching a project I haven't touched in a little while I don't try and pickup where I left off with the bugs I was tackling those many weeks ago. There's no point, my train of thought has long since left the station and you need those first steps back into a project to be fun and exciting.

So on that note, I've going to throw away my whole visual style and try some experiments. As much as I like the idea of flying around a globe with with real geographically accurate locations, the technical challenges are substantial, and I kind of feel I'll be losing the whole otherworldly feeling of drifting through the alien world of cyberspace. By limiting myself to a flat surface (which obviously the world isn't, I'm no flatlander.. but for all intents and purposes it is when you're zoomed in looking at a individual computer), I feel like I might lose some of the experience.

I plan on turfing out my entire graphics layer and trying something more akin to flying through a galaxy of connected nodes, to do this with my current code base would no doubt require MASSIVE refactoring, and would likely kill my attempt to regain the momentum I lost after taking a break from the project. So I'll be playing around with a few standalone demos probably, seeing how each one feels and what looks right. I'll post my results on here and whilst I know I don't have many followers on here, I'd love to hear feedback and opinions when I do :]

I'll leave you with a reference picture I've had kicking around for a while which I always find particularly inspiring:



Hack the Planet!

Sunday 7 September 2014

It's STILL alive!

It's been exactly a month since my last update, my excuse is a lot of work commitments and The Crunch have really sapped my time. But 2 more weeks of The Crunch and I should have more time to spend on HTP.

Having said that, I have managed to squeeze in the odd hour or two here and there and I've actually made some good progress on something I'd like to share with the tumbleweeds :]

I've completely rewritten how the signal routing system works and have finally got it up and running. Nodes can now now 'provide' or 'request' things based on their functions, for example, here is part of the definition of a computer's power supply:

"Functions":
[
  {
    "Type": "Request",
    "ResourceType": "MediumVoltagePower",
    "Interval": 5,
    "ShowRequest": true,
    "Critical": true
  },
  {
    "Type": "Provide",
    "ResourceType": "LowVoltagePower",
    "Channel": "Power",
    "MaxPerSecond": 100
  }
]

What this means is every 5 seconds a power supply will attempt to request a unit of 'MediumVoltagePower'. Initially a power supply has no idea where it can get this request fulfilled, so it sends a broadcast request to every other node it's connected to. Put simply, this broadcast request will spread out across the entire power network until it encounters a node which has a 'provide' function that can fulfill the request. When this happens, the providing node sends a signal back down the reverse route that the requesting signal took. When the requesting node receives this signal, it now knows of a node that can provide for future requests so it stores the route to that node for future use.

I do a few other things to help speed this broadcasting process up, like if a request signal passes through a node that can't provide for the request, but does know of a node that can, it will point the request in the right direction, speeding the process up. Also, if any node is asked to pass on a providing signal, it will know where that signal came from, so it knows if it, or any other requesting node, needs that particular resource, it knows where to find it.



Well that's the dry details of how the system works out of the way. What's quite interesting about this system is pretty much all the traffic on the internet can be boiled down to requests and provisions. Some of them are critical for a node's operation, like power. But some are simply the byproducts of the behaviors of the AI agents in charge of the nodes. Take the following example for taken from the definition of the 'AveragePersonComputer' role (roles are something I use to describe the behaviors of a node):

"Functions":
[
  {
    "Type": "Request",
    "ResourceType": "Network",
    "Channel": "SocialNetworking",
    "TimesPerDay": 20,
    "ShowRequest": true,
    "Critical": false
  },
  {
    "Type": "Request",
    "ResourceType": "Network",
    "Channel": "Banking",
    "TimesPerDay": 2,
    "ShowRequest": true,
    "Critical": false
  },
  {
    "Type": "Request",
    "ResourceType": "Network",
    "Channel": "Porn",
    "TimesPerDay": 1,
    "ShowRequest": true,
    "Critical": false
  },
  {
    "Type": "Request",
    "ResourceType": "Network",
    "Channel": "Piracy",
    "TimesPerDay": 1,
    "ShowRequest": true,
    "Critical": false
  }
]

None of these requests are vital for the operation of the computer, but they will be requested by the node as long as it's active. These behaviors might change over time too, if a computer is infected by malware and becomes part of a botnet, it may start producing spam traffic as well as it's normal traffic.

This is all kind of exciting for me, cause the signal routing system is one of the first big systems I need to start doing some interesting stuff, stuff even bordering on gameplay! :O It's also really exciting to see the world come to life for the first time:



Having spent a good chunk of my day today trying to tear out quite an impressive infestation of spyware, browser bars, search hijackers and all kinds of other nasty computer bed bugs from my girlfriend's laptop, I can't wait to start simulating that kind of stuff in my little internet :]

Hack the Planet!

Thursday 7 August 2014

Home Sweet Home

Wanted to just quickly share a screenshot (click to expand):


This is someone's home network. You can see the external network and power connections on the border there, they connect to the outside world and relay network and power signals as needed. The fuse box, for lack of a better name, feeds off this power, and in turn powers all the wired devices in the house, indicated by the yellow wires. The router is connected to the outside world and serves the house's 3 computers (it turns out this is quite a large house, 3 is the current maximum for a home network) and their wifi access point, indicated by the green wires. The access point appears to have a mobile phone and laptop connected to it wirelessly, indicated by the white lines.

I just found this screenshot quite satisfying, the procedural generation is coming along quite well, and it's nice to see it working after this huge refactoring I've been doing. For those interested, below is the template file for home networks:

{
  "ShouldScale": true,
  "MinSize": 0.05,
  "MaxSize": 0.1,
  "Needs": ["MediumVoltagePower", "Network"],
  "Structure":
  [
    {
      "Type": "FuseBox",
    },
    {
      "Type": "Router",
      "Serves":
      [
        {
          "Type": "Computer",
          "Min": 1,
          "Max": 3
        },
      ]
    },
    {
      "Type": "WifiAccessPoint",
      "Serves":
      [
        {
          "Type": "Mobile",
          "Min": 0,
          "Max": 3,
          "Hours": ["Morning", "Evening", "LazyNights"]
        },
        {
          "Type": "Laptop",
          "Min": 0,
          "Max": 3
        }
      ]
    }
  ]
}

Saturday 2 August 2014

The Whole World at Once

So I'm about half-way through a major refactoring of the procedural generation system, it's coming along slowly. It's one of those refactorings when your code base seems to half in size. I usually take that as a good sign.

Up till now the world wasn't generated until it became 'relevant'. This means until you zoomed in on a city, it was nothing but a placeholder. When it became relevant, it would generate all it's component parts: power stations, ISPs, neighborhoods, etc. The problem with this though, was that a freshly generated world had no knowledge of its constituent parts, so was unable to generate network traffic on their behalf. This would have led to a very boring world.

The brute force solution would have been to just generate the entire world at loading, the problem with this though is the majority of the CPU work done during generation is related to the physical representation of a node. All we really need to know about a node beforehand is what it is, how big it is, and what it belongs to. So what I've been refactoring towards, is a system where the entire internet is generated at the start, but only at a minimal level. This meant breaking apart the relationship of a node's details and its graphical representation.

I'm nearly done this refactoring now, and it's been interesting to see some of the numbers it's producing. Up till now I've not really had any real idea how big the internet I've been creating is, since it would only generate nodes when I looked at them. But now since I'm generating all of it beforehand, at least at a minimal level, I know exactly how big it is.

So far, for the sake of fast turnaround, I've only been generating 200 cities in the world. It's been enough to get a fairly populated internet and takes about 20 seconds to generate (with completely unoptimized code mind you). So for the first time I've had a chance to see what my world is made of, here it is:

51605 CPUs
51605 PSUs
51605 OSs
51605 NetworkAdapters
6248 Routers
6008 WifiAccessPoints
6008 HomeNetworks
1041 SmallPowerSubstations
852 NetworkSubstations
852 Neighbourhoods
189 LargePowerSubstations
173 NetworkProviders
200 Locations
208 NetworkExchanges
16 Generators
16 PowerStations
16 ISPs

This translates to roughly 50,000 devices. Some of them desktop machines, some laptops, some phones, some routers, anything with a CPU. I'm pretty happy with this number considering it only takes 20 seconds to generate with the current unoptimized code. I'd ideally like to see upwards of a million devices in the finished game, but I'm actually less worried about the generation time and more about the graphics load and amount of UI clutter.

I plan to dump Unity at some point in the future and roll my own engine for this. I'm using very little of the goodies and niceties that Unity provides for most types of games, and it doesn't give me the low level rendering support I need to achieve the framerate I want. For instance, it doesn't provide access to GL vertex buffers so I'm pushing the thousands upon thousands of lines to the GPU every frame. With 1000+ cities in my world, the framerate drops below 15 fps on my little tablet. With vertex buffers I suspect this will rise to 60+ fps. But for now I'm putting off this migration, functionality first, optimization second and all that jazz.

I started this post with the full intention of talking about potential gameplay ideas and lay off the technical stuff, but I guess my fingers had a different idea. Well, it's always nice to get this technical stuff off my chest. Maybe after a couple more beers I'll rant about botnets and cryptocurrencies for a while.

Hack the planet!

Saturday 26 July 2014

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

Sunday 20 July 2014

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.

Thursday 17 July 2014

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