Knuckle Cracker
Blog: Fresh Ideas in Gaming
Creeper Redemption
Aug 4th
What if there were a way to take that nasty old Creeper and make it your pet? Destroying the ever expanding Creeper is plenty-o-fun, but what if you could manufacture your own Creeper and send a little payback towards those emitters?
Well, that’s the plan for game 2:
Now this is just a quick game shot with no real care for level design or play-pattern. But you can see I’ve manufactured some good Creeper (the gray Creeper). I built up a little stock-pile and then dug through a single terrain tile and dumped it onto a chamber full of the evil Creeper. There is some nice sizzling as the evil Creeper remains equally evil but is becoming smaller in volume. It’s a nice sight watching that stuff get destroyed and replaced by benign Creeper that does my bidding.
The blue squares are shields that let units and packets pass but not Creeper (friendly or evil). Don’t worry about the shield graphics, that’s just stand-in developer art till I draw something better. I put the shields there so I could confine my own Creeper. I could also have used Repulsors to push it around.
Note that to make good Creeper I have to spend Ore…. and I’m just about out of it in this screen shot. In fact, the reason I have tunnels dug all over the place is because I was collecting Ore from deposits that were scattered around.
Anyway, just wanted to do a quick shot and let folks start dreaming of redemption…. Creeper Redemption.
Play Area
Jul 26th
Here is one more very early screen shot for game 2. This shows the main play area of the game. I’m not showing the menus at the bottom because, that contains spoilers right now…
In this shot, you can see the main Assault Ship at the top center. This is home base and what you travel from world to world in. It’s the source of your packets and the only thing you start most missions with. It has no trouble flying around and hovering above the surface as shown. You can also see a couple of Collectors in this shot. I dug down a couple of shafts and put them at the bottom. The green area is the area they are collecting fractal space energy from. You can also see three beacons. They are providing wireless power (along with the Assault Ship) to most of the visible area. In the lower right and left of this screen shot you can see dimmer terrain. This terrain isn’t in range of any Beacon.
At the bottom of the center most shaft you can see a couple of red X’s. These cells have been targeted to be dug and you can see three “Excavation” packets in route to the first X. You can see a Blaster under construction back up on the surface. It isn’t necessary to build things on the surface, though. Most military units can be built anywhere not blocked by terrain. Most other units can be built in clear areas, but the ones that can’t be moved must be anchored into the surface. The Beacons and Collectors you see fall into this category.
On the right you can see a scroll bar. This lets you scroll the map up and down. In this screen shot you are only seeing about 20% of the total map! So that Creeper you see is just the easy stuff… Down in the depths you may find more intense Creeper, other surprises, and perhaps other menaces.
Speaking of the Creeper… on the left you can see that an emitter has filled up the chamber it is sitting in and the Creeper has just flooded over a ledge. It’s running down the ledge and will fill up that larger cavern. Unfortunately, this chamber is surrounded by hardened terrain that can’t be penetrated. So I’m going to have to dig down and approach that flooding chamber from below. I best get to it sooner rather than later….
So this is just a tiny portion of the core game elements. There will be other terrain types, a second resource, and right now I’m looking at 16 main structures/units. Everything is of course still open for change, but the major elements have started to come together. Stay tuned….
Unit: Repulsor
Jul 25th
One often requested unit in Creeper World has been a shield, a fan, or some kind of mechanism that would push the Creeper around. In Game 1, this was sort of difficult to pull off since the field of play wasn’t originally designed to handle this.
For Game 2, this changes. I planned from the beginning to accommodate various forces that could act on the Creeper. One of these is gravity. Since Game 2 is a side view game, gravity should be a key factor in the way that the Creeper moves about the map.
Once I had all of the Creeper flow equations modified to accommodate gravity, it was a relatively simple matter to allow an additional force that can push in different directions and also only be in effect on certain regions of the map. From this was born the “Repulsor” unit. This unit doesn’t destroy once milliliter of Creeper, but it can be the difference between life and death in certain situations. Take the following two before and after pictures as an example.
Here you can see a Repulsor with its beam pointing straight to the left. The beam is hitting some solid terrain. The picture on the right shows where I have dug through this terrain. The Creeper isn’t flowing out into the tunnel to the right, though. Instead, it is being pushed back against the far wall by the Repulsor beam!
Repulsors also work with your own friendly Creeper (not shown in this picture). In fact, Repulsors can be a great way to move pools of your own Creeper from one place to another. So if you happen to produce a big reservoir of your own Creeper and then need to move it up and over a ledge, a few Repulsors can make that happen.
I’ve still got to properly balance the beam strength, distance, and energy consumption of this unit, but I wanted to go ahead and give a preview of how it will primarily operate. It’s a cool little unit and I’ve wasted hours just setting up little Creeper fountain displays, “heat exchanger” flow circuits, and playing a “save the good Creeper” mini game…
Enemy Finding Algorithms
Jul 23rd
Sorry that it has been a couple of weeks since my last update…. I’ve been busy making some serious progress on game 2. I’ve been on a sprint to get some major things in place and I have achieved some pretty cool things. One of these things has been formulating a strategy for identifying what to shoot at.
In game 2, there will be the equivalent of the good old Blaster featured in Creeper World game 1. This unit just needs to shoot at the closest enemy Creeper in range. Of course it can’t shoot through solid terrain, so a line of sight (LOS) calculation also has to be done. So, from a Blaster’s perspective it needs to find the closest Creeper within its firing range that can be seen. To do this, a Blaster starts by inspecting the cells closest around it. Imagine the square made up of the 8 neighboring cells in an array. This square expands until Creeper is found. For any Creeper found, a LOS calculation is made. If the Blaster can see the Creeper, then that becomes the target. There is no reason to keep looking at further distances, since the Blaster wants to find the closest Creeper. Also note, that the expanding square doesn’t really remain a square for the entire search. For each cell being checked, the distance from the blaster is also checked. If the distance (actually the distance squared since I don’t want to do a square root calculation) exceeds the range of the Blaster, the cell isn’t checked.
But, what about the equivalent of the Mortar in game 1? Well, I call it the ‘Launcher’ in game 2. Keeping with game 1, it wants to shoot at the deepest/densest Creeper in range. In game 1, this meant searching in an expanding radius just like the Blaster does. But in this case the entire collection of cells in range have to be checked. As each is checked, the deepest Creeper yet seen is remembered. After all cells are checked, the Mortar from game 1 would have remembered where the deepest Creeper was and that becomes the target.
In game 2, the Launcher has an extra constraint. It wants to fire at the deepest Creeper in range, but it can’t fire it’s projectile (missile) straight at the target. Take the following image as an example:
Launcher Missile Path
Here you can see that a Launcher is in range of some of the oh-so-evil Creeper. But it is “around the corner” and doesn’t have a direct line of sight. Now, the Launcher’s firing solution has to be: “find the deepest Creeper in range for which there is a path and that path doesn’t at any point exceed the range of the Launcher”. It’s easy to see that there must be a path… imagine if the Creeper had been totally walled off. In this case it doesn’t matter if the Creeper is in linear range of the Launcher or not. No missile could reach the Creeper if there is no way in. But it is also important to realize that even if there is some path to the Creeper, this path can’t just wind around to the far reaches of the map. It would be unrealistic if the missile didn’t have a range, but the Launcher’s ability to target did.
To accomplish this firing solution, the Launcher searches outwards just like described above. As it expands its search radius, it doesn’t just remember the deepest Creeper it has seen. Instead, it remembers every cell that has Creeper in a sorted list. Once finished with the initial scan, the Launcher has an ordered list of all cells that contain Creeper. The item at the top of this list is the cell with the densest Creeper. For this item, the Launcher has to run a path finding algorithm to see if there is a path from the Creeper cell back to the Launcher. This path finding algorithm has a constraint that it can’t consider cells that fall outside of the range of the Launcher. If the path finding algorithm finds a path, then the Launcher has its target and can fire. If not, the next item in the list is inspected in the same way. Every cell that contains Creeper will in turn be inspected until a target is found, or there are no more possibilities.
The path finding algorithm is an AS3 optimized Vector.<int> A* algorithm. Actually its Dijkstra’s algorithm since I don’t use a heuristic because of another unit I have called “Micro-Rifts” that create “wormholes” on the map, but that’s fodder for another blog post…
Save Games
Jul 9th
Yes, game 2 will allow game saves. This is not necessarily an indication that the missions will be intrinsically longer, just a realization that some maps and some players sometimes need to be able to save a map and continue it later. I suppose it may also lead to a ‘gray’ market in saved game files, but that’s a price I’m willing to pay.
So, for the last few days I’ve been working on the save game infrastructure and it’s every bit the pain I remembered it to be. “Why so painful?”, you may say. Well, the state of the terrain, creeper, units, packets, and game metrics all have to be persisted and then reloaded. Sounds straight forward…. for the creeper just record the creeper array and then reload it… and same for the terrain. For most units there are variables that change (like its state, its position, its health, ammo load, etc). These numbers are easily persisted.
But then along comes something like a packet. A packet begins at some location on the map and then remembers the target unit that it is headed for. It has to remember its target unit because the target unit might be moving around while the packet is en route. The target could even be destroyed before the packet reaches it. So the packet needs to know where the target is at any moment. Naturally, I simply stored the object reference of the target unit in each packet during run-time.
This means that when I save a packet in the save game file I have to know what target unit it points to. To solve this problem, each of my units have UIDs (Unique IDentifiers). These UIDs are just integers and no two units have the same integer. So now a packet just needs to save the UID of the target when it is saved in the save game file.
Upon reloading, I have to look up the object reference of the target unit based on its UID. The packet does then when it is being loaded and created from the save game file. Of course this means that the target unit must already exist and have been loaded already! This means load order is important….
So, this solution works as long as cross object referencing is minimal and manageable. If two objects each held a reference to each other, no load order could resolve the issue. In this case, object construction would have to proceed “on demand” and not really in the order the objects are encoded in the save game file. Or, the assignment of the object references would have to be lazy and done at some point after all objects are constructed.
Anyway, technical issues aside, there will be save games… yay!
Swf2exe’s
Jun 29th
Wow… and I thought this would be easy. All I wanted to do was explore products that would take a swf (a flash application) and package it as an ‘exe’. Sounds straight forward given there a like a ton of products that claim to do this.
First up, just create an exe using the standalone flash projector. Like here. Of course I would have to hack the icon, and this says nothing about reading and writing local files (so I’d have to use SharedLocalStorage like any sandboxed flash app). But whatever, I just wanted something to work. Verdict: doesn’t work with flash 10. Specifically, I can’t remove the flash projector default menu on flash 10 via fscommand(“showmenu”, “false”); And I mean the menu at the top of the flash projector, not the right click menu. Score one for Adobe… touche on removing one alternative to AIR.
Second up, mdm Zinc. Looks like one of the most popular options. Downloaded the trial and gave it a go. There are TONS of nice looking native system options (reading/writing files, etc). I was pumped up and expected the best. Well, mouse wheel support appears broken. I’ve questioned it here. No response so far…. with each passing day I get more bummed. Performance also appears to be… poor. Some people blame that on the demo water mark. Perhaps so, perhaps not. Keep reading for what I have to say about this regarding another option mProjector….
Third up, Jugglor. This app looks kinda crazy what with the bright red controls and all. I mean I’m an NCSU fan and grad but this is a bit much. Anyway, red filter glasses on and things look better. After all I’m here for what it does, not how it looks. I click around through a bunch of options screens and get an exe built from my swf! Now, I had to uninstall flash 10.1 from Internet Explorer, find archived editions of flash 10, install one of those, then I could build the exe, but that’s fine. Anything… ANYTHING at this point is acceptable. And guess what? Frame rates are just fine! At least they are AFTER i click “Convert SWF to Flash Projector”. If I don’t do this, the resulting exe doesn’t bundle the flash player and for whatever reason the resulting frame rates are less. So, feeling confident I decide to try the window options. Things like controlling what happens when you resize the window, full screen, etc. One thing it does that is cool is that it will lock the aspect ratio of the window. So as you resize the window it keeps things non-distorted. Of course this is true right up until you hit the window maximize button. On my 1920×1200 desktop that stretches the window away from the 4:3 ratio and my flash app gets distorted as well. So much for locking the aspect ratio. I thought I’d get cute and remove the maximize button. That would cure this problem. ‘Click’ in the jugglor settings and problem solved. But this begs the question of full screen support. How will that work? If I take out maximize I would like a way to switch to full screen. So I set Jugglor’s setting to start the app in full screen. It even has an option to change the screen resolution. I set it to 800×600. Build the app and run it. Resolution changes….. and app is nowhere to be seen. In fact what I have is an 800×600 version of my desktop. My app is in the taskbar. Rick click and close it and my screen resolution resets to 1920×1200. Ug…. total bummer. 1024×768 produce the same results. Ok, lets not switch the resolution. I’ll just keep whatever the user has. Now this does work……. but I’m still nervous. I feel like I’d need to test this on just about every platform and OS I’ve ever heard of. If this screen resolution switching is broken, then what else is broken? At this point I thought to see if they have a mac version (like zinc does). Whoops. I must have neglected to look at this. I had been trying to look only at solutions that could target both mac and windows. End of road….
FOURTH up, mProjector. I’m so sick of these things by now I’m ready to go running back to AIR as fast as I can (well not really, but it may come to that). mProjector seems clean and has a fair amount of functionality. The forums are really slow, but not dead at least. I grab it and try it out hoping for the best and expecting the worst. It is easy to use and produces an exe pretty quickly. It runs and doesn’t suffer from mouse wheel issues like Zinc. It is supported on both PC and Mac, unlike Jugglor. I don’t know about full screen support yet, because the next thing I noticed was my game’s frame rate. It was clocking in just above 20, not at the 30 I had set it to. “Here we go again”, I said. I document the issue on their forums here. I just posted this a little bit ago. Hopefully somebody will say something in the next day or so. Why…., oh why! Oh, after noting this about mProjector it made me wonder if Zinc suffers from the same issue….
Fifth up???? SwfKit was last released in the middle of 2009. Flash 10 and 10.1 have probably eaten it alive since then. I hesitate to even download it. Northcode only support windows. I’ve read some good things about it, but only windows is a real killer. That just hurts. There are other little swf2exe’s scattered all over the internet. But few of them do more than host the flash ocx control. I was really looking forward to some native functions (that WORK, of course).
Well, back to the game proper I guess. There is always AIR if I must…. I’ll give mProjector and Zinc a chance to respond. They both are probably working on flash 10.1 support, so a whole new set of behavior is probably right around the corner…
Toxic AIR
Jun 22nd
No I’m not talking about a new kind of enemy (at least not yet…. more on this later). What I’m talking about is Adobe AIR. I’ve had a love hate relationship with AIR over the last year. As most know I wrote CW in flash. Not because I’m a flash fan-boy, but because of all of the flash portals. I wanted to do a flash portal version of CW. Well it seemed natural to use AIR to produce the full desktop version of the game. This is what I have done and for the most part it has been fine.
Recently Adobe released AIR version 2. Should be great news… should be packed with performance enhancements and maybe even some tonic for the full-screen performance hit. Adobe even pushes the update to everyone with AIR installed by prompting them to upgrade. And like any reasonable person would, most people say “sure” and upgrade.
What they get next is a version of Adobe AIR that has demonstratively inferior performance when running CW compared to AIR 1.5. Here’s the KC forum topic about it: http://knucklecracker.com/forums/index.php?topic=3568.0 and here is an Adobe forum topic about it: http://forums.adobe.com/thread/659527?tstart=0
Now I have no real doubt that Adobe will over time get this sorted out and life will once again be good. But… what’s a game developer to do? Release another game and hope this never happens again? Wouldn’t I have been better off to use something like mProjector or Zinc and built a bound executable? At least this way I wouldn’t have to worry about Adobe causing me a support nightmare because their QA let a problem like this slip out the door.
CW 2: More considerations
Jun 2nd
Currently I have these three things implemented/planned as ways to extend the core ‘creeper game’ concept:
- Resources: CW had one very important resource: Energy. In game 2 I am considering a second resource. Specifically, you would need certain amounts of this resource in order to build certain units and you would also need this resource to produce ‘friendly’ creeper. This resource would only come from fixed locations on the map. So you would have to fight your way (sometimes) to get access to more of this resource.
- Terrain: Terrain modification (as I have previously mentioned) is key in game 2. Packets no longer need pathways to move around on. However, they do need tunnels and caverns to move through. This means that digging out the earth is required to get places. Specifically, you are trying to reach creeper emitters buried deep in the ground. So you have to go spelunking to get to them. This introduces an interesting choice for the player. The more you dig the more places you can reach and the more room you have to build things. However, in the process you eliminate the ground…. which is the source that your collectors gather energy from. I’ve yet to decide if if this is a good or bad thing for game play…. more later.
- Upgrades: I really like the idea of a point based upgrade system. You get upgrade points by digging up certain artifacts but you can also get points by building ‘research pods’ that produce points over time. This affects your early game strategy. In CW you basically only have to decide what energy to invest in building vs weaponry. In game 2 you will have to decide between building/digging/weaponry/technology investment.
CW 2: Some Considerations
May 31st
I’m not quite yet ready to reveal too much (like a screenshot) of game 2. But I would like to document some of the areas that have been a focus. Don’t bother trying to figure out what all of these have in common…. that they are all in my head is about all that seems to relate them.
Scale: More creeper that moves in a more fluid fashion would improve things in game 2. To accomplish this I have rewritten the core creeper flow algorithm and noted a few interesting things.
The creeper flows around like a cellular automata simulation of heat. At least it starts out this way and then the math gets tweaked a bit to make it behave more like a thick, viscous fluid. The performance of the algorithm depends heavily on the number of array (or vector in the case of AS3) accesses. This is because vector member access is so slow in AS3. It isn’t like C, where you can do millions per second with no real performance impact. So any reduction in vector member access will improve performance. In CW for each cell, I have to look at 4 neighbor cells (the three along the bottom and the one to the right). In game 2, I have this down to 2 neighbor cells. Instant double performance improvement! Also, since I am targeting flash 10 only, I have switched to Vectors over Arrays. This is a small gain, but still a gain. Couple these two things with a third: Integer math. In CW I used ‘Number’ for everything, In game 2 I use int’s. So instead of Creeper cells containing 2.3725 for instance, they now contain 237250000. Keeping everything as Integers makes the math faster in AS3. Doing all of these things has helped increase the creeper calculation scale by about a factor of 4…. and this meets my needs for what I have in mind for game 2.
Purpose: In CW you are on the run… it’s the end of all civilization and each mission is a mission of survival. You push back the sentinel creeper long enough to activate the rift. You never really defeat the creeper you just hold it back.
In game 2, it’s payback time. Thousands of worlds remain to be reclaimed and new technologies have been developed to destroy the emitters once and for all. Problem is, they are deep…. I mean DEEP beneath the surface. So guess what, time to start digging! ‘Terrain modification’ is central to game 2 and to the story. This has created a number of interesting technical challenges…. one of which is path finding.
Path Finding: In CW, path finding was done by packets as the moved along your network. This was one of the cooler things about CW. Many people just liked watching those packets find their way. The packets were themselves a kind of “unit” that moved around on the map and made the whole simulation alive and animated. Classic A* was used to route the packets with a new evaluation being done at each place along the path. In game2, the network isn’t made up of straight lines that connect structures. It is made up of tunnels and caves that the player digs. Packets move around through this collection of tunnels to find their targets.
So I also had to rewrite my A* algorithm to get its scale up. It now also works on integer Vectors rather than arrays of objects. I’ve improved it’s performance by about a factor of 5 and this allows me to have lots of little packets making their way through a large collection of user created tunnels and structures (and hopefully avoiding creeper along the way).
Anti Creeper, and Anti Gravity: I always wanted to see what would happen if “good” creeper flooded against “bad” creeper. Well now I know… and soon will you I hope. Balancing is an issue (unlike any kind of unit balancing problem I’ve ever even heard of) but if I can make it work out, game 2 will feature creeper that you can control.
And while on the topic of “anti”, why not throw in some anti-gravity or force fields as well? I’ve implemented them and they are way cool to play with. Whether they will be a defensive system, an offensive weapon, both, or something else is something I am working on.
Adobe AIR: Should I stick with this? Writing the game in AS3 is fine. No complaints there. Performance is well, so-so. AIR gives me access to local files (so importing games works very well). So what is the problem you say? Well to name a few:
- The installer has to be signed. I either have to buy a signing cert and keep up with certificate chains over years of time, or I can do what I do now: Ignore the warning that pops up during the install. I decided to ignore because even with a signed installer, the AIR installation still had a “red” indicator during the install (for a different reason, but it is still red and the eyeballs of the person installing still see red that they have to ignore). If I didn’t use AIR none of this would be an issue.
- About 1 out of 2000 installs of Adobe AIR seem to fail. At least this is true for what is called the ’sidecar’ install. The sidecar install is when I bundle AIR and the game together in an executable zip file. This allows the user to just run a single executable and they get Adobe AIR if and only if they don’t have it installed already. For some really small number of users, this fails and Adobe AIR has to be installed manually first. Not a bug deal, but still in the negative column.
- Once upon a time I was talking to Steam about making CW available in their store. I mentioned “AIR” and that is the last I heard from them. Maybe they just decided they didn’t like me, or maybe they don’t allow AIR games in their store…..
So that’s it for now. I hope to have an early screen shot (complete with developer art) in a few weeks.
Hello World
May 31st
Welp, figured it was about time to start talking a bit about what we have going on at KC. Lots of things have been moving and happening and lots more are to come.
Creeper World has turned out to be an unconditional success as small indie games go. It and its cousin the ‘Training Sim‘ have been played over 4 million times so far in 2010. Currently, the Training Sim is globally played between 5000 and 8000 times daily. Daily peaks during the major portal releases were over 70,000 game launches per day.
So I really can’t complain too much about these numbers. CW:TS is on track to surpass ChopRaider in another year (ChopRaider is currently in the wild for 2 years and has been played 5.1 million times). Chopraider, for those that don’t know, was my first ‘experiment’ in large scale distribution indie games.
Traffic to knucklecracker.com remains high as we head into being live for 1 year. Monthly unique visits hover around 100,000. Sales for the full desktop version of Creeper World have been good as well. Much of this can be attributed to the great user community and the custom maps. They have extended the lifetime of the game and I see no end in sight.
Here you can see the unique site visitors since the site launch on July 27, 2009:
KC Traffic stats
The long stretch at the beginning was me doing the “normal” indie game release stuff. It worked ‘ok’, just not that great. The giant spikes were major portal releases. The first was bubblebox.com. The others were kongregate.com, armorgames.com, addictinggames.com, and a bunch (like 1000) other game portals. The last spike was when badges were added to the Training Sim at kongregate.
So…. as we move forward I will be posting about upcoming releases (Yes, Game 2 is under development and I can’t wait to reveal what I have up my sleeve!). I will also take moments to cover numerous technical topics I care about. And I might even ask for help from time to time. So stay tuned, crack your knuckles, and get ready for what’s to come!