Environmental Simulation Part 1

When I settled on the current game design idea a central piece was an environment simulation that would effect player experiences and that player choices could in turn effect - creating a feedback cycle.

Iteration 737 - Humidity Heat Map

The goal wasn't (and still isn't) to create an environmental simulation that was "physically accurate." The goal was to create a simulation that was an abstraction of reality or at least had some of the key features seen day to day and year to year. I wanted the player to be able to alter the world around them in a way that reflects reality but that doesn't need to be 100% realistic. 

Key Features:

  • Day to day temperature swings
  • Seasonal temperature swings
  • Wind to transport moisture
  • Water/Rain cycle
  • CO2 effects
  • Pollution accumulation and transport
  • Runs off the main thread

Building Blocks

The first step in creating the simulation was to break up the environment into a series of blocks. Each box would have it's own set of environmental variables (temperature, humidity, ground water, wind, etc). These "climate blocks" would interact with it's neighbors to create localized weather and also to allow local variances such as terrain height and cloud density to impact the weather. 

Test Terrain with Climate Blocks

As the simulation developed and more complex interactions were add a few changes/additions to the climate blocks were needed. The first critical piece was the addition of an "atmosphere block" on top of each climate block. The atmosphere block is simulated air space above that often has a different temperature than the air on the ground/ocean. This allowed for up and down drafts that could help move clouds and cause an on or off shore wind depending on the season (more about this later).  Without an onshore wind clouds and more importantly rain rarely make it to the land.

A second key addition was the classification of terrain types. At the time of writing this the simulation is only using three types of terrain ocean, grassland and mountains. This largely controls the "target" temperature of climate block and in the case of the ocean maintains a constant saturation of ground water. Oceans have moderate target temps with smaller seasonal and daily fluctuations. Grasslands have a higher target temp than the mountains but both have larger daily and seasonal fluctuations than the ocean.

Daily and Seasonal Temperatures

Seasonal sun intensity is controlled by an animation curve that is sinusoidal in shape. Max values occurring during the "summer" and of course minimum values occurring during the "winter." A second curve was used for daily fluctuations. The curves are currently identical... That may change in the future. 

At first these curves were used and tuned to be a true energy flux with energy being added during the day and energy lost during the night. While more physically accurate and potentially allowing for more emergent weather, it also made it far more difficult to tune and balance. After significant testing and tuning this method was abandoned for a more controlled method. 

Each terrain type has a median temperature that serves as a target temperature. There are also values for seasonal and daily fluctuations of that temperature.  This means that median temperatures + seasonal flux + daily flux is roughly the high temp and likewise median temperature - seasonal flux - daily flux is roughly the low temp. Variance from this is caused by the connection of neighbors and other factors. 

One of the other factors that adds some variability is the average height of the terrain. In the real world the higher the terrain the cooler the air. To reflect this each climate block samples the terrain height at multiple points and calculates an average height. From this the median temperature is adjusted slightly. This provides variation in the climate that (hopefully) lends itself to more interesting and emergent weather.

Wind

Wind in the simulation does not  have a physical presence and is simply a Vector3 that stores the wind velocity. The wind for an individual climate block is calculated based on the temperatures of the neighboring climate blocks, including the upper atmosphere. The inclusion of the upper atmosphere allows up and down drafts which allows for onshore or offshore breezes (as mentioned above). 

To calculate the wind the simulation calculates a temperature difference between the climate block and a neighbor and then multiplies that by a vector that goes from the climate block to the neighbor. Final direction (sign) of the wind is based on blowing from hot to cold. 

The simulation sums all the winds due to neighbors to arrive at a (nearly) final wind value.

A prevailing wind is then added. This allows larger global winds to be added to create larger and different weather patterns. The strength of the prevailing wind is a tune-able variable. Current testing is with an in/out pattern that helps to blow clouds away from land in the summer. 

An early WEather Prototype

After the prevailing wind is added the vector is normalized. There was some debate about normalizing the wind...  In the end the choice was made to keep the normalization as this meant that clouds always would have some wind. It also prevents unrealistically large or small winds that become problematic when trying to transport clouds/moisture.

The final step is a check on the vertical component of the wind. Since the upper atmosphere is often at a very different temperature it can therefore be the dominant contribution to the wind. This is a problem due to only simulating two layers of atmosphere rather than more layers or the ideal of a continuous atmosphere. Effectively the vertical component is clamped to a range between -0.5 and 0.5. This helps to keep clouds generally moving horizontally.

Additional controls are needed to avoid the clouds going too high or going through the ground. The altitude of the clouds is mostly visual as the horizontal location determines where clouds can deliver rain. Because of the this a simple min and max altitude are set. Clouds check against these values and degrees of freedom are restricted in the rigidbody to prevent clouds from going outside the bounds. Checks on vertical velocity are also necessary to allow the clouds to move away from the limits. 

Continued in Part 2

In Part 2 I'll discuss the most difficult part (so far) of the simulation that being the Water and Rain Cycle. Or more specifically the balancing of that cycle.

Building a Farming Game Loop and Troubles with Ground Water

Game #2 (still unnamed) is centered around economics and the environment. So a natural starting point (at least to me) when thinking about a game loop is farming. Yep. Farming. Does the world need another farming game? Hopefully!

A farming loop needs to allow the player to plant, harvest and sell crops. Nice and simple. Right?

Sunflower Farm: Testing visuals for setting up simple farming.

This means that models need to be built, stores need to be coded and basic UI needs to be added. So I setup a quick and dirty (ugly) inventory that allows the collection and basic handling of items. Items are stacked for organization and stacks can be split and recombined. Nothing fancy, just enough to play test. (A good tutorial to get you started.)

An ugly but functional inventory UI

Basic animations allow a player to dig and get some tilled soil in which to plant a crop. Crops can be added, but I didn't grab a image.

Testing of basic digging mechanics.

Testing of basic digging mechanics.

On top of this crops should respond to the environment. Crops should grow when the conditions are right - it doesn't make much sense for corn to sprout when it's below freezing or there's no moisture in the soil. So this means setting up each plant with ideal conditions and scripting growth. Still not too hard.

This is apparently what I think a carrot should look like... The jury is still out on this one.

This is apparently what I think a carrot should look like... The jury is still out on this one.

Which brings me to the current struggle...

Getting a working environmental simulation was a matter of a few hours of coding - okay probably double digit hours of coding, but still a very reasonable effort.

So far the wind is working, temperatures are reasonable, seasonal changes are working, it's even multi-threaded (not coroutines!) so there's no real performance hit. All good so far.

And then comes the water cycle. Damn the water cycle!

Ground water and ocean water evaporates into clouds. Clouds move and release water as rain. Sounds easy enough, but we all know what happens when you assume things.

The problem is getting a stable amount of ground water from season to season. How fast does the water evaporate? How fast can the clouds move? How much water can the clouds hold? How fast does a cloud release its water? How quickly does water drain back into the ocean? How many hours can I spent looking at a heat map? 

Visual Feedback on ground water... 

Visual Feedback on ground water... 

So many variables. Each with the ability to muck up the whole simulation. I could hard code values, but then I'd lose the players ability to screw up the world... And that has to be part of the game. Its part of the real world!

So who's idea was this game anyways? Why couldn't I try to make a 2D platformer like everyone else?

A few changes, including fixing a stupid mistake, are giving me some hope. I have now seemly stabilized the lowest ground water level for a given thermal input/output. This should allow players to mess up the CO2 level and get a higher evaporation rate and thus drier soil... Or allow other season to season changes to impact crop growth. 

One change was to make the ground water flow rate respond to the amount of water in the soil. It is also a function of how many environmental cycles there are per game year. 

GroundWaterEquation.png

This basically slows the rate if the average ground water dips below 0.5 and raise the rate if it climbs above 0.5 (almost all of the environmental setting are floats between 0 and 1). Not a perfect feedback loop, but seems to help contain the crazy swings. This would seemly allow the (minimum) average ground water to be a function of ground water flow rate, evaporation and temperature. 

If I can stabilize a minimum ground water level then I should be quite a bit closer to getting a overall stable and reproducible water cycle.

Fingers crossed. 

The Inevitable : FTF PostMortem

Fracture the Flag
Fracture the Flag

Fracture the Flag is my first and only game. Not the only game that I've published. It's my only game, period.

I'm pretty damn proud of FTF. Sure I had dreams of selling 100k copies or 50k copies or even 10k copies. None of which happened, but the real goal was to learn, to build a (small) community and create a game that at least some people thought wasn't total garbage.

By that measure it has been a complete and total success.

While the code base is a mess of poorly written spaghetti code it mostly works. I learned how to better organize my code and how to create more efficient code. I discovered that multiplayer is great idea, but like so many before me, I also learned it's freaking hard to implement. What works well on two test machines on my desk is very different from two players that are on opposite sides of the Atlantic. I figured out a basic workflow from Blender to Unity. I stumbled through the process of creating basic editor extensions to make my game development a little easier. I also learned I had no idea how to set up the lighting in a scene and still don't.

I learned that there is plenty more to learn.

Managing the game and community surrounding the game after the initial Early Access release was stressful, but still more rewarding than I could have expected. I had no idea how buggy the game was. Not really. I had no idea how thoughtful and kind some people would be. So many people were constantly giving feedback and helping make the product better. My biggest lesson in taking a game from Greenlight to Early Access through to Full Release is simple:

Be open. Be honest. Be human.

Folks can smell from miles away a developer that just wants a quick paycheck. While not every interaction in the FTF Steam community was positive I found most can be turned that direction with a little humility and honest listening. Not every customer has a good idea or even a valid complaint, but most do. So I did  my best to listen.

Case and point: Two friends each bought a copy of FTF hoping to play together. They quickly found several game breaking bugs that earlier players had simply ignored or hadn't noticed. These two players proceeded to rip FTF to shreds on Steam reviews - yes plural, they each wrote one. Both brutal and brutally honest. I didn't respond to the review, but when they posted in the forums I took the opportunity to start a conversation. After the exchange of several comments I had great feedback from the players and removed several sizable bugs from the code base. They dropped their negative reviews and decided not to ask for refunds. I never saw if they left positive reviews, but the huge negative reviews were gone. That's a huge win for a solo developer and worth every ounce of effort.

Fracture the Flag
Fracture the Flag

Let's talking pricing.

When I first had a vision for FTF I thought surely the game must be worth $10-12. I mean I've worked so hard on it! It's got multiplayer for crying out loud. As it got closer to the Early Access release date I got a bit gun-shy. I refocused on my main goals. Making money would be nice, but it wasn't the primary goal. So I cut the price. I cut it a lot. Down to $2.99 in the US market. This seemly had the effect of lowering expectations and doing so in a helpful way.

The early reviews were incredibly positive. Early on FTF has a 90+ percent positive rating - and not from people who got free keys. The game sold reasonably well in its first week with sales continuing to trickle in as the weeks passed.

ftfsteamreviews
ftfsteamreviews

I fixed bugs and added features before the full release. I added so much! So many good ideas came pouring in from the community. So I decided to raise the price. To the price of a latte in Aspen... All of $4.99. Sales slowed and expectations seemed to rise while the rating on Steam dropped to what it is now, 78%. Was it a mistake?

Then came release day.

Sales were modest but better than I hoped. The first day as a full release saw almost no exposure on Steam but was still the best sales day in the short history of FTF. More copies of FTF were sold in the those first three days then in the entire first week of Early Access. Not too shabby.

I hear people say you only get one release. Maybe that's true. But I think building a community and getting positive reviews helped to serve up more sales then FTF would have seen had it jumped straight in as a full release. I know I'm more likely to buy a game that has decent reviews and has been "out" for at least a little while. But who really knows, maybe I'm just seeing what I want to see.

7 months after the initial Early Access release FTF is essentially "finished." No, it doesn't have every possible feature. Yes, there are still bugs. And no, I didn't make enough to quit my day job - not even close. Sales are generally within the margin of error shown by Steam Spy but I have often seen the numbers dip too low (but I've never seen them go too high). I made enough to easily pay for a high-end mountain bike and new set of skis and boots. For a guy who's day job requires bikes and skis... Not a bad result.

My hourly wage? Probably didn't make it to minimum wage... No, let me rephrase that. I didn't make minimum wage.

You can see sales spike on the release day and then again during sales and of course the day FTF came out of Early Access.

sales-graph
sales-graph

So now the game is in the long tail. Sales have slowed as expected, but the trickle is still going. At least enough to buy my wife and I dinner out once a week.

So what would I do different?

No multiplayer. While I nearly dipped my toes into that pond again for game #2, a quick read of some FTF comments reminded me of the horrors of trying to sell a multiplayer game as a solo developer. This might be a lesson I have to learn more than once...

For game #2 I want to find an outlet for early builds beyond Early Access. Find a smaller market. Find a community interested in giving feedback and more willing to take risks on a title. Take the time to polish the game before heading to Steam.

As a solo developer I need my games to be more procedural. With FTF building a level took days and the way I built the level meant I often couldn't even make small changes without completely scrapping the level and starting over. Got a rock in the wrong spot? Combined the wrong meshes and can't get good occlusion culling? Too bad.

Game #2 needs to be a game I want to play. FTF started as memories of playing Crossbows and Catapults a kid. I loved that game. Then FTF started to morph. It turned into something totally different. Sometimes for good reasons and sometimes not. It's not even close to the game I first set out to make. As a result I tried to squeeze into an already defined genre and all the expectations that came with it. Slowly, with each added feature FTF became a game I wasn't really interested in. So, now I dream of the game that I simply want to keep working on. Wouldn't that be magical?

What's next?

Game #2 is next. I have a vision, but not a complete plan. I want to create something different. (Shocking I know). I am fascinated by how poorly we treat each other as humans and how poorly we treat our beautiful planet. I dream of a game that could explore those very real issues while still being fun and challenging. In my head the game is so hopelessly over scoped I worry I may never be able to finish it or if I do it will turn to total shit.

So ignoring common sense, step one is to create a game world that I want to spend more time in...

Procedural Trees 1
Procedural Trees 1

I know that's ass backwards for most folk, but a world that is pleasant and enjoyable to walk around it seems like the first step in learning to appreciate that world.

The page has just begun to be built, but you can see what there is to see about #2 here.

Leaving Early Access

After almost exactly six months after the initial release Fracture the Flag is leaving Steam Early Access!

FTF has come a long way from that first buggy release back in June! A sincere thank you to all that gave feedback and helped shape FTF into a much better game. The goal of an Early Access release was to get feedback from a wide pool of testers. No game is ever complete or perfect and FTF is no exception. There is always more that could be added and details that could be polished, but there also needs to be a time to call a project “finished.”


Support for FTF will continue but will be focused on fixing bugs rather than adding content. I look forward to taking all that I learned over the last few years and applying it my next game...


Low Poly Renders

Two years ago, I talked my school into allowing me to teach an intro game development class. I still can't believe it and I get a huge grin on my face when I think about how lucky I am. This fall I convinced folks that I should be allowed to run a week long intensive course about making low poly renders with Blender...

Sure I've done enough "box art" for Fracture the Flag to know the basics and produce work that's "good," but I've spent almost no time making non-game art.

Oops.

So in my game dev course I assigned a project where the students had to make box art for a new game. Basically an excuse to work more with Blender and dig a bit deeper into the program. The first part of the assignment was to find a published low poly image and use it as inspiration and guidance.

I joined my students and began to create my own low poly render. I choose Winter Night by Vitaliy Prusakov. I loved the lighting and the simple, but elegant colors.

My result was far from perfect or as tasteful as the original.

Snowy Village

Not bad, but I thought I could do better. Those roofs? Where'd the snow on the fences go? The fence rails are too straight...

I was having so much fun I wanted to do another. So I started working on the view from my front door.

The result is (obviously) highly stylized and somewhat idealized. I think its also step up in overall quality.

Backyard

Creating these images has been such great practice, not to mention great fun. I'm sure I'll make a few more, but I'm dreaming of getting a similar style into Unity for my next game...

I think I've figured out the light baking and textured needed to make it work at 60 fps and I'm pretty excited about it. It would be such a step up from Fracture the Flag's art work :)

FTF: Testing New Features

Recently I've been working to add a two new features to Fracture the Flag - both stretch goals. The first new feature is the addition of defensive watchtowers. The watchtowers can target workers, swordsman, siege weapons and enemy balloons, but won't target enemy buildings.

The towers provide much needed ranged defense against bombers and swordsman. Especially early in the game watchtowers can provide a good deal of security. They'll also easily knock down the new hot air balloon units.

Blender render of the bomb dropping hot air balloon

The hot air balloon unit does a low speed strafing run with three large and very effective bombs. While landing three bombs on a target can be devastating, the balloons themselves are relatively fragile and can be shot down by a watchtower fairly easily. Balloons are a one time use vehicle. After dropping their bombs they will fly off to the horizon.

The addition of the watchtower and hot air balloons (in early play testing) add a degree of balance and more variety to a player's strategy. It's also just really to see flaming arrows flying all over and bombs raining down on your opponents buildings.

A short teaser of the new features can be seen below.

For those who are REALLY interested I did a longer play testing session via Twitch. There are a few bugs and a few things that aren't ready for prime time, but you can see the new features (more or less) fully functional.

Watchtowers - Predictive Targeting

The soon to be latest addition to Fracture the Flag will be the defensive watchtowers. The towers will provide stationary ranged defensive. Something that is very much missing with the current build.

The watchtower script estimates a time of flight, gets velocity of the target, and uses a healthy dose of high school physics to predict the location of the target when the arrow will arrive. There is some inherent error in the calculations as a few assumptions must be made, but these turn out to be minor.

Once the predicted position has been calculated another healthy dose of kinematics is used to create a launch vector for the arrows. This is then turned in to a velocity vector and passed off to the arrow's controlling rigidbody to provide a physically accurate trajectory.

There are some errors in the calculations, such as the time of flight shouldn't be independent of the angle, but one value needs to be calculated before the other... The result can be small errors. The coding also allows a degree of inaccuracy to be added (not shown) for the sake of realism. This quickly makes any numerical errors pretty irrelevant.

Click to Color

I was needing something simple to work on (the day job has turned my brain to mush) so I spent a few hours last week polishing a tool that I've used in the production of Fracture the Flag. The tool allows the creation and editing of color palettes within Unity.

Low poly scene and the 

Click To Color

interface

The use of color palettes along with flat shaded low poly assets allows a significant reduction in the number of materials being used in a scene or project. This can also reduce draw calls and improve performance.

Due to the flat shading models can be unwrapped and the UV's can be stacked. This allows the texture size to be very small - in theory as small as one pixel per color used in the project! This means that by using a 32 by 32 pixel texture a project can have up to 1024 colors contained in a 4 kb file! Ideal for mobile uses or simply keeping a desktop build size down to something reasonable.

Unwrapped model in Blender

The editing of these textures within Unity also allows the artist or developer to quickly adjust colors of models in a scene while lighting and image effects are shown in real time. This speeds up development time as there is less back and forth between Unity and a photo editing program.

Click To Color will be available on the Unity Asset Store:  https://www.assetstore.unity3d.com/#!/content/72930

All the features of Click to Color can be seen in the video below.

A potential work flow using Unity and Blender is shown in the second video.

Unity Object Swapper

A while back I found myself looking at a Unity scene with several hundred trees that each needed to be updated and the connection to the prefab had somehow broken... Rather than spent hours replacing each one I spent almost as much time writing an editor extension to do the same thing.

I'd forgotten about the tool, until a student of mine ended up in a similar position. Which made me revisit the tool a do just a bit of fine tuning.

Screenshot of the editor window

It's a pretty simple script, but handy all the same. If I find the time I might add it to the Unity Asset Store as a free asset. Until then, assuming this looks like useful, you can download it from this link (box). There's no documentation, but it should be pretty self explanatory- the search is case sensitive.

Testing Single Player Combat

The next major goal for Fracture the Flag is adding to the single player challenges with the addition of some basic combat oriented levels. The new levels will continue to be time based - how fast can you take out the AI base. It will not be a full blown single player campaign - as a solo dev it’s just not possible to pull that off so I won’t promise what I can’t deliver.

Testing of the new scripts was recently done live on Twitch. The stream was also reposted on YouTube.

 AI bases will have a functional economy to support their attacks on the player’s base. If there’s no ammo then the siege weapons will fall silent. If build points run dry the AI can’t recruit more workers or swordsman…

 The AI will not be capable of adding new building or siege weapons. The AI base is largely static, once a player destroys a building, siege weapon, or flag it’s gone. However, workers and swordsman will be replaced.

 The AI is capable of both offense and defense. Sending groups of swordsman to attack buildings and delivering bombs to the base of flags and other buildings. Defensively swordsman will patrol or stand and guard. Siege weapons will also fire if you get too close.

AI Controlled Bombers

There are lots of little bugs and plenty of balancing to work on. So no promises on a release date. The first release will likely be on the beta channel as many scripts have been adapted to allow the AI which will then need testing to ensure multiplayer didn’t break…

Release Date and First Video Review

Fracture the Flag is the first game to be released by One Wheel Studio. The release date has been set and the last minute tweaks and optimizations are being made.

FTF will be available on Steam June 9!

 Fracture the Flag will be priced at 2.99 USD. Prices may vary with your currency.

Also! The first video review has been posted by eNtak. The video shows some of the main features of FTF and plays a little of a single player challenge. Don't just take my word for it. Watch the video...

Getting Greenlit on Steam

The intent of this post is to share both my experience with Steam Greenlight as a solo dev and the data from that experience. I am happy to share more data if I have it.

I am a solo developer, or at least I’m a just one guy working in his spare time (not sure that makes me a "developer" yet).  I started working with Unity and Blender a little over two years ago with no real thought beyond “Hey, this looks cool.”

Oh, the wild ride that is Steam Greenlight! 

Steam Concept

Fracture the Flag is the result of twelve months worth of my spare time. It’s the first and only game that I’ve made. I have a full time job that pays well enough, but why not swing for the fences with Steam Greenlight and see what happens? Maybe I could upgrade the office? Or buy a new mountain bike? And I’d be competing with things like the “Toilet Simulator” so how hard could it be?

Being cautious and curious I setup a Steam Concept page, just to see what would happen. I knew the traffic would be a small compared to a true Greenlight page would be, but it still seemed worth my time - and it was.

For the first few days the Concept page was getting 4-7 hits a day and almost entirely “yes votes.” Even that small trickle of traffic died down after 4-5 days. Now almost 3 months in only 90 people have visited and a bit over 30 of those have voted the game up. This resulted in a fantastic yes to no ratio of 97%, but not much else to get excited about.


My stats matched up with Quiver of Crows data which was Greenlit back in January. I was feeling cautiously optimistic. 

I put in some more work, finished a second level that was, in my opinion, better looking and more interesting than the first level that was featured on the Concept page. With this and a few other visual details added I put together a second and updated game trailer.


[youtube=https://www.youtube.com/watch?v=5m-NOCxpiP4&w=640&h=340]


Steam Greenlight

So off to Steam Greenlight I went…
Once the small fee had been paid and the page was setup I was terrified to push the publish button. I double and triple checked the screenshots and that the video played.

Was everything as good as it could be? No. Did I know how to make it better? Nope. 

The first few votes came in. Oh no... Way more no’s than yes’s. Not good. It's over. Next game?


I took a deep breathe and the tide changed. Over the next few days the number of yes and no votes started to even out. I obsessively checked the page, cheering when yes’s came in and responding to thoughts or criticism in the comments. As a side note: as the number of comments increased so seemly did the ratio of yes’s to no’s. Interesting.

24 Hours into the campaign the yes/no ratio was at 44% yes's which was well above the meager 31% of the average top 50 game!

I was starting to get excited!

I also began to wonder “How does a game make it to the top 50 with only 31% yes votes?” Wow! How can you drive that many people to your page that aren’t excited about your game? Send a few my way?

By the end of the second full day the yes and no votes had evened out - each at 48% of the total votes cast. This was a pretty good boost to the ego. I’m a first time solo dev working in my spare time and I’m doing better, maybe a lot better, than the average!


These “great” results continued through day 6 of the campaign. Breaking into the top 100 on day 4 and getting more yes votes than no votes!​​


Then the Spigot Turned Off...

I’ve never played a full round of golf in my life, but I know what a dog leg looks like...  And it looks like the bright green line in the graph below.

Unbelievable how quick the spigot of visitors shut off.  The page went from 600+ visitors a day to less than 50! On day 6 I got almost 300 yes votes. On day eight I got 6 yes votes (no typo there). Judging from the incredibly hard to figure out and ever changing  “Cumulative ‘Yes’ Votes” graph this is not uncommon and is pretty much the norm for all but the top 5 or 10 ranked games.

And maybe that’s okay. Maybe my game isn’t good enough. Maybe it shouldn’t be on Steam. I can deal with that. There are games that get to 2000 or 3000 or even 4000 yes votes in just a few days. Clearly those developers have done something right. I managed just over 1300 in 6 days...

One of the best descriptions of the (hypothesised) criteria for being Greenlit suggested that Greenlight was not about popularity, but rather is a way to gauge the developers ability to drive traffic and thus sales. If a developer can drive traffic then Steam stands to profit. If the developer can’t drive traffic once Steam stops sending people to the page then maybe the game wouldn’t sell enough copies…

It’s not a flawless, but I can see that perspective.

So What Now?

I'm not sure what's next. I am torn. One minute wanting to move onto the next idea. After all I've learned so much over the past two years. The next minute I still believe in the game... After all its been 8 freaking days! What could I possibily expect?

Fracture the Flag is currently bouncing around in the mid 80's in the rankings. Not bad. Only one round of games has been greenlit since the game hit the top 100. So there is hope, plenty, if I'm honest.

So I don't know. No pity party. Just lack of certainty.  Its been a rollercoaster to say the least.

3 Weeks Later...

I'd all but given up. I was ready to make the next game. I was on the road to a bike race and got the email that FTF had been Greenlit! Wahoo! 

I apparently forgot to take screenshot when FTF was Greenlit so the image below is 9 months after the fact. The votes don't change after a game has been Greenlit but the vistors and followers still do. 



A Little Commentary

As with many other people I am stunned by what gets submitted to Greenlight. After all Fracture the Flag was in the batch of games with the “Toilet Simulator.” We can speculate all day long what the point was, but that developer got way more action than I did - I bet the Toilet Simulator guy isn't talking about me!

When I see games like the “Grass Simulator” for sale it makes me want to cry a bit. I know my game is better and I suspect most people, or at least 48%, would agree with me.

At the end of the day I’m glad that Valve is making the decision not purely based on numbers, but the process is still mysterious. When Fracture the Flag was floating between 91st and 93rd on Greenlight the 92nd ranked game was Greenlit… Ouch.  

From what I’ve read, and deduced from the stats, Fracture the Flag will continue to slowly march up the rankings. It jumped to 83rd once a handful of other games had been Greenlit. It seems likely that eventually the game will be given a thumbs up. If the day ever comes that Fracture the Flag is Greenlit I will no doubt be ecstatic! 

Until that day comes I'm on the slow part of the rollercoaster hoping for one more loop da loop.

There are a few things that I wish were different.

The first would be for some criteria to kick games off Greenlight. Maybe after 2-3 days you need a certain yes/no ratio. Or maybe during those first few days you need to get a certain number of yes votes per day. Something needs to be done to quickly filter the total crap that folks are submitting. Getting “voted off” and then having to wait before resubmitting seems like it would solve many of Greenlight’s problems.

The second would be the waiting. Many if not most games in the top 100 experience the dog leg or drastic slow down in votes.  If games are only getting 10 or so votes a day and (judging by the data) that will eventually push the game into the top 20 overall then why wait to Greenlight them? If 48% of the voters and 36% of the people who saw my page said they’d buy my game then isn’t that good enough? Or maybe bad enough that you pull the plug?

It seems everyone has a plan to “fix” Greenlight that removes the crap but allows their own game to get Greenlit… Maybe I'm just one more of those guys.