#alpha in a sense of a program in its alpha stages—the first iteration | Explore Tumblr Posts and Blogs

etronixcenter · 3 years

Text

Energy Star Certified Uninterruptible Power Supplies

The Manhattan project truly had a relatively small number of physicists driving the program. There had been dozens of other initiatives underneath the project that every one ended up as failures that nobody really has heard about. If the plant blows up for some purpose, there's no significant radionuclide contamination. Therefore, there's little cause to require safety requirements considerably greater than those for coal vegetation . This makes it significantly cheaper, as a result of reduced materials use and development time/labor for containment, and lowered regulatory delays. The major drawback is that a big institutional effort has gone down a blind alley.

In gentle of that, Samsung's new SmartThings Energy service desires to assist customers cut back their bills, and it begins by simply figuring out how much vitality you are using in the first place. General Fusion developed plasma injector technology and Tri Alpha Energy examined its C-2U gadget. NIF achieved internet vitality gain in 2013, as defined in the very limited sense as the new spot on the core of the collapsed target, somewhat than the whole target.

A pneumatically driven fast-response single-acting device CB2 is used as a back-up CB. The present circuit in this swap is broken as a end result of harm of a contact element from aluminium alloy. To smooth voltage transients caused by contact breaking in a extremely inductive circuit (50 μH), a snubber R-C circuit is connected in parallel with the CB2. A protection signal makes the CB contacts open, introducing the resistor into the circuit. The time fixed is determined by the coil inductance and lively resistance of the discharge resistor. The described circuit became a prototype for additional PS methods, together with those employed within the T-15 tokamak and ITER.

But making it work in a prototype reactor is a far cry from making it work in a industrial reactor which must be run on an everyday basis and maintained. ITER's been going for thirteen years now, and I don't assume they're solving any of the problems that SPARC will remedy. Like the Rocket Equation, Computational Fluid Dynamics, and different features of Aerospace, we all know the parameters of the way to do it, and it is simply a matter of looking the area, reducing the parameters, by way of engineering iteration. Compared to house tech, fusion science is at the stage of 1929 sci-fi drama "Woman in the moon". That's fine but to act like new small scale experiments and designs out of date know-how that has by no means earlier than been developed at scale is foolish and albeit runs opposite to how technological and scientific progress are made.

We can’t say for certain what the future holds, but this is an extremely promising space of work. The economics of solar cells is reviewed with an eye to potential price reductions in processing, and potential markets are explored. Current Solar battery storage prices are famous to be on the highway to reaching the U.S. Continued progress will rely upon technical developments in cheaper supplies and processes, scaling up production, and the success of gross sales packages.

Mega initiatives are extra optimized for supply and leaving lesser things on luck and it is beneficial in most of the circumstances. But posters are saying given the vast scope of issues that could be tried in fusion house, mega projects probably won't be touching these. Even if the administration staff had all the time on the planet, they might not full the project on their own. It's utilized in large initiatives the world over from superconducting cables to maglev trains to numerous different things. So it is somewhat disappointing it will take 5 years to construct SPARC, after which one other 10 for ARC. Seems to me the primary issues are manufacturing and scaling elements like REBCO.

Current estimates for ARC, which is designed to be modular, so it could be easily maintained, is that the reactor walls will final about 1 yr. PWR Fission reactors have monumental footprints, averaging 1 square mile. The very nature of utilizing pressurized water means your containment facility has to be an element of one thousand bigger than the reactor vessel to deal with a flash boil over. His suggestion to look at aneutronic plasmas did not pan out, as you observe, however that doesn't save DT fusion.

0 notes

islandsdevlog · 6 years

Text

Islands 0.0.1-alpha.20190112

Added a very simple system that generates and places world objects – currently only apples, rocks, and trees – on the terrain. It tracks the objects in a tilemap data structure and updates it when objects are removed (when an apple is picked).

The goal of this iteration was to establish a baseline for managing and generating world objects. Apples are interactive items. Rocks were used to add collisions to the world. Trees to work on depth sorting. I didn’t want to spend so much time at this point on terrain and object generation, better to focus on gameplay and mechanics. Yet I still got sucked in. Though I did have to build this baseline to work from sometime soon.

There’s a lot of nuance in finding the right data structure for managing tiles; there are multiple layers; some objects move, some are static; there can be objects that span multiple tiles. There’s always a trade-off between performance and developer productivity. I’ve picked one format to start with, but I’m not holding on too tightly. If things become unreadable, if I’ll need a better interface, or to squeeze more performance out of it – things will change. As long as the innards of the tile system will only be handled by select few entities and through a strict interface, changing things down the line won’t be too painful.

Thought and read on how to handle multi-tile objects. Couldn’t find an elegant solution. All are clumsy and will affect pathfinding, world state tracking, and performance. I’m avoiding this for now, even though it will be less painful the sooner it gets done.

To make the math easier, moved to using a Unity unit as the size of a tile in the tilemap. Previously each tile was 0.16 units. Changed all existing assets to work with the new setup. The highlight interactions overlap box check was hardcoded to the previous values and had to be changed. So did the offset of the interaction progress bar above the player’s head. After the change, the tiles looked worse. Changing the import settings of the assets to use a point instead of bilinear filter mode helped. I want the camera to be kept close to the player and not show too much of the surrounding area. For now, everything related to positioning is hardcoded to assume that one tile equals one unit. This was a good change to do early. It would have been much more painful later on.

Starting out, I worked on an items manager. It made sense when the only object we were dealing with was the apple. Adding rocks as an item was pushing it, but with trees it really made no sense. The items manager was changed to a world objects manager. Some of the world objects can be items, some aren’t.

Having to refactor and separate between items and world objects made me realize how cumbersome, harrowing and error-prone refactoring will be in large Unity projects. Even with static typing and reference search, sweeping changes will not be fun.

Added an ItemType struct with None and FoodItem options. Added an ItemType type property to ItemData. It’s not actually used. Added it working with one direction in mind, then switched to another. Since it will almost definitely be used at some point in the future, and since I’m not immune to feeling bad throwing away code, I’ve kept it.

Added a WorldObjectGenerationData scriptable object which references a specific prefab for the object and notes the object’s spawn probability. Created instances for the apple, the rock, and the tree prefabs.

Added a WorldObjectsLayerTile struct. An array of these is used as the tilemap for the world objects manager. It holds a reference to a WorldObjectGenerationData instance and to the object’s game object. The first is used to mark the tile while generating, the second to reference the game object that has been instantiated in a tile. It’s not the best format, and I already have some directions in which I want to change it, but best to run with it and change when needed.

Short cleanup of the TerrainTileMap generation. Used better property names. Removed a (currently) unnecessary data structure to track the tiles. Moved things from Start() to a GenerateAndRenderTilemap() function (which still gets called at the start).

Added a GenerationSettings global with a default instance. It holds the height and width of the map we want to generate. Both TerrainTileMap and the WorldObjectsManager use it when generating the terrain and placing the world objects.

Added a WorldObjectsManager class to manage world objects generation and lifecycle operations.

Based on a HideObjectsInHierarchy boolean setting, generated objects can be hidden or shown in the Unity editor.

An array of WorldObjectGenerationData is used to generate the objects. A two-dimensional array of WorldObjectsLayerTile is used as a tilemap.

At the start, it first marks on the tilemap which world objects should be generated, and in a separate step instantiates the objects and keeps a reference to them in the tilemap. Later on there will be further steps that alter object generation between these two.

When an ItemInteractionCompleted event is raised, the world objects manager removes the item in question from the tilemap. OnActiveInteractionCompleted() handles the event and extracts the item position from the event data, and RemoveWorldObject() does the deed.

GenerateWorldObjectsMap() iterates over all the world objects and on each of the tiles. At every tile it rolls a dice against the object’s spawn probability to see if it should be placed there. If so, it makes the tile with the object’s generation data. The check is skipped if the tile is already occupied. This means that objects lower down the list will have less tiles for them to be generated on. It’s a quirk, but it can be solved by storing all the objects that successfully rolled the dice at the tile and adding a sweep stage at the end of the generation process that selects one of them at random. Using probabilities gives less control to the designer but makes the implementation much easier than trying to work out the constraints of a fixed number of items. Still, some items will need to be placed in fixed fashion with strict rules, but the less of those there are, the easier it is to implement.

InstantiateWorldObjects() and InstantiateWorldObject() are then used to instantiate the objects based on the generated tilemap markers.

Added a RigidBody2D and a collider components to the player. Added collider to all world objects. Fixed the player to not rotate on collision.

In the player’s check that selects an item interaction to highlight, only objects tagged as an interactiveItem will now be considered. Tagged only the apple as such. Tags might not be the best way to do the filtering, but it’s okay to start with.

The player’s movement is now done using its RigidBody2D velocity rather than changing its transform directly. This was done to prevent the camera from jittering when colliding with objects.

Put the sorting layers into order. Added two scripts to all world objects and to the player to manage their depth sort. DynamicDepthSort is used for moving objects and StaticDepthSort is its counterpart. The scripts look very much like the one described here.

Added a FadeObjectsInDirectLineOfSight script to the main camera. On every frame, it uses a raycast to find all objects (with a collider) directly in front of the camera. Any that are not the player are faded out to be half transparent so that the player can be seen. Previously faded objects are tracked and set to full transparency before we run the check again. Had to add a second, trigger, capsule collider to the top of the tree to make this work. I’m not completely happy with this interaction, but it will do for now.

Tweened the fade out and the fade in using Surge. I don’t much like to use packages from the Unity asset store, but this one seems to do the trick, has a decent API, and keeps to itself. We’ll see.

Created a docs folder and a checklist for adding new world objects and items. It’s surprisingly long for this stage of development.

Added RequireComponent attribute to scripts as needed. Forgot it exists.

The GameEventsLog now ignores and does nothing for any event other than an ItemInteractionCompleted event. A bit of defensive programming.

0 notes

symbianosgames · 7 years

Link

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community. The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.

Cogmind recently made it through a second whole year of its pre-Steam early access program, and as this period comes to an end I'd like to take the opportunity to, like the first year, share some data and pretty graphs :)

This is an interesting milestone because it more or less coincides with the completion of Cogmind's primary content, represented by the Beta release just last month, meaning it took around two years of work to bring the game from Alpha 1 to Beta 1. And it's still amazing that support has been sufficient to maintain full-time development for this long--Cogmind's lifetime revenue passed the $100k mark in April :D. So a big thanks to everyone who has helped it reach this stage!

@'s celebrate the Beta :)

For a more general summary of late-alpha progress you can check out the data in my 2016 annual review, whereas this article will instead be mostly looking at revenue and pricing. And while the first year of sales data was neat simply because it was seemingly the first time anyone in this genre has provided so much open data, the second year is much more interesting due to tier and pricing changes.

Let's jump right in: Cogmind made US$ 40,325 in its second year. Looking purely at the numbers, that's only two-thirds of what it made the year before, but it's important to note that a $25k chunk of year 1 revenue was earned in the first month of alpha alone, the result of pent up interest from two years of open pre-alpha development prior to that. In that light, the second year has technically been a little better than the first in terms of revenue, an 8% increase from $37k to $40k.

Cogmind Year 2 daily gross revenue, annotated (Year 1 graph here). (Click on any image in this article to see at full size.)

Year 2 started with a minimum price drop, from $30 to $24.99 (albeit by adding a new lower tier without any perks, and keeping the old price as an option). This naturally sparked a good number of sales in the short term, which eventually died off as player growth returned to normal once those who'd been waiting for that to happen got their hands on it. At this point the price change didn't seem to have any long-term impact, but we'll get to data on that later.

The next noticeable bump coincides with the Roguelike Celebration, an awesome event at which I gave a talk and news about Cogmind subsequently made the rounds. The effects of that alone lasted for a good couple weeks.

Then the obvious spike is obvious :P. RPS has been following Cogmind since pre-alpha and I hadn't expected to see anything more until after alpha, but it was a nice surprise to have a sudden article about my work arrive the following month.

Starting mid-November, buyers in the EU could finally get Cogmind "VAT-free," which basically boils down to a loss for me though it's technically the industry norm to include VAT in the list price. Considering I was still losing money throughout development it took me a year and a half to reach a point where I was willing to eat a 20% cut in revenue from those regions. Since I made that change, between November 15 and June 6th $5,085 of actual revenue received originated from EU countries, meaning $1,271 went to extra taxes (a low estimate). That's all money I could've kept for development if Cogmind was available before 2015 when the EU introduced VAT for online purchases!

For New Year's day I made an ASCII fireworks gif (actually the first iteration of the one shown at the top of this post) and that garnered some attention, which pretty much always translates to more sales. That's not why I made it--it was just a fun side project to see if it was possible with the engine, but it's nice that it had that side effect :)

Valve pre-announced the end of Greenlight in February, and since I 1) wasn't sure whether I'd like what would replace it, 2) know that having a little Greenlight campaign is itself at least worth some exposure, and 3) already had all the required media on my own website anyway, I decided to put Cogmind up for voting. There was literally only two days between the time of this decision and hitting Publish :P. It was greenlit not long afterward, but that wasn't really the point--notice that nice little spike in the graph... it's nice to have some free exposure from Steam when people who'd rather not wait can already buy from my site! Putting Cogmind on Greenlight clearly contributed an instant $750 or so to revenue :D

In April I again lowered the price, to its current and final base price and the level at which I've always planned to sell Cogmind once the main game reached completion. In that sense the price change came a little earlier than expected, since the Beta release wasn't to happen until early the following month, but sales had been flagging over the previous six weeks and I couldn't let revenue fall too much since I'm relying on it to get by before bringing a mostly complete Cogmind to Steam. (Other reasons: It was also a good excuse/opportunity to do a little advertising that didn't overlap with the upcoming Beta release, and I also wanted a longer buffer between the price change and Cogmind's upcoming Steam debut.) I actually silently lowered the price a week before even announcing the change, just to see what kind of impact it would have on random visitors. It seems to have been beneficial, though one week is too short a period and there are too many other factors at play to really draw any conclusions. (I'll share more data below to shed light on conversion rates.)

The most recent mini-surge surrounded the Beta release, a pretty big milestone considering it allowed me to declare Cogmind essentially complete by multiple metrics. A number of people were waiting to hear that, and the price had already been lowered the previous month, factors that combined to generate a decent amount of revenue for May.

Another factor that I find valuable in examining daily revenue graphs, but that you might not immediately notice above, are "zero days." Any day during which there are no sales at all is a zero day, and too many of these, especially in a row, can honestly start to get demotivating. On the other hand, ongoing streaks of anything-but-zero days are quite motivational--even if just one or two sales. I always keep an eye on that sales number (it's easy to follow because I receive an email for every purchase, and I don't look at them but each one increments a label-based counter in my inbox :P), and if I start to see zeroes it means I'm not quite doing enough outward-facing development, like sharing my progress across social media. I always work harder when there are continued sales every day, so getting into a routine of posting updates is a nice long-term self-reinforcing cycle--especially when I wake up in the morning and get to see how many there were overnight! That's been a ritual wake-up habit for the past two years now...

The all-important Order counter :P

Throughout Year 2 I made a more concerted effort to ensure there was always something to show at least once every week, and I believe this is reflected in the relative number of zero days: Year 1 was 9.8% (36) zero days, compared to 4.9% (18) in Year 2. In fact, the improvement is technically even better than that: notice a third of Year 2's zero days occurred close together over summer 2016--that was during my one-month vacation. No work, no pay xD

Cogmind Year 2 revenue zero days.

Looking at revenue on a monthly basis, there's been a clear positive trend over the past year. (May passed $3k with its Beta release, though isn't shown here as it technically extends into the third year.)

Cogmind monthly gross revenue, annotated.

I've labeled a few of the larger effects already discussed earlier, though I can find no reasonable explanation for March. The graph includes Year 1 for comparison, though I didn't annotate those months--that stuff was covered with the first year's data.

Cogmind Year 2 monthly gross revenue by country.

By country the revenue data doesn't hold many surprises. Comparing to Year 1's country revenue graph, the only notable difference is that Germany overtook Australia, somewhat interesting because as an English-only game Cogmind is assumed to mostly sell in native English countries. Of course, Germany does have plenty of English speakers as well as three times the population of Australia, and (perhaps more key here) more than one German LP'er picked up Cogmind over the past year. (Plus there was the mentioned VAT change in November!)

That graph would be far more interesting if there were localization, but at least this gives you an idea of what an English-only fairly text-heavy game can achieve in an international sense. Localization is a great idea for any game that can manage it, but sadly it's simply not possible with Cogmind.

But we do have some extra interesting data to analyze for Cogmind's second year of sales, now that we've been through multiple tier and pricing adjustments!

At the beginning of the year I wrote a lot about Cogmind's first price change in 2016, including some common and not-so-common variables factored into my pricing decisions. Here I'll add to that discussion with some final results of that change and the most recent third phase.

As a reminder, Cogmind's base price was $30 for the first 12 months, $24.99 for the 11 months following that, then $19.88 for the last month of the second year (and on through today). In the context of daily revenue above I already talked about some of the more immediate effects of those price changes, but the bigger picture holds a few more details. One element I finally have enough data to explore is Cogmind's conversion rate.

Cogmind lifetime conversion rate (2015.5 ~ 2017.5) based on buy.html visitors.

I wouldn't read too much into that graph because there are a lot of factors at play here, so many that this data is not quite as meaningful as it appears, but it's fun so I wanted to talk about it anyway :P

First of all, notice that it's specifically the buy page! Unlike most other indie developers, I don't put a buy link on Cogmind's main web page. In fact, I also don't even put it front and center at the top of the buy page itself! I prefer to 1) avoid generating impulse buys and 2) manage potential player expectations. Thus I intentionally force visitors to wade through other stuff before finding a link to actually buy the game :). Yes, it's counterproductive from a marketing standpoint, but I don't care, I'm here to build a good game and foster a healthy community, not rake dollars from random people on the internet.

Thus this source data definitely skews the conversion rate higher, because anyone arriving on that page already has a somewhat higher interest in purchasing than the average visitor. (Note that based on general industry data, those rates are high.) For comparison I did the same with /cogmind/index.html.

Cogmind lifetime conversion rate (2015.5 ~ 2017.5) based on index.html visitors.

Part of the problem with sourcing stats from main page hits is that they're filled with referral spam which can't always be completely distinguished from real visits (which, like incessant referral spam, may simply leave without visiting other pages :P). This is why using the buy page provides nicer metrics, because it doesn't get referral spam--we just have to remember all the additional factors that feed into the buy.html stats.

Getting back to those factors, Cogmind's exposure comes primarily via roguelike-focused channels, so new visitors coming to the buy page are already going to be of a rogueliking disposition and even more likely to buy :)

Also specific to the fact that I prefer basing data on the buy page, there are a lot of people who have followed development for a long time, even years, who eventually make the decision to buy when it's right for them, whether due to a lower price, the right timing, or a combination of other personal factors. I believe there's a fairly steady stream of people who fall under this category, and they'll naturally just go to the buy page and... buy. This is often after having mostly obtained information about the game through one of the other channels I frequently use, like Twitter, r/Cogmind, the forums, the dev blog, TIGS, Bay 12, Facebook, etc...

Regarding what appears to be an upward trend in the conversion rate, while it makes some sense when paired with the fact that the price comes down for each period, I think that trend is much less meaningful on breaking down the average number of daily visitors and thinking about where those numbers are coming from. For example in its first year of release Cogmind had the greatest exposure on a number of major websites, so naturally visitors from those sites were less likely to be among the target audience. That was the highest average at 71.8 visitors per day. The second period, during which there was much less general exposure, saw a significantly lower 47.5 visitors/day. And the most recent period with the lowest price, albeit shorter, recorded only 43.5 visitors/day, yet had the highest conversion rate.

Of course, knowing this doesn't negate the fact that Cogmind's website and my frequent (if minimal) outreach efforts are fairly effective at selling the game to those who are interested. And on the reverse side, supporting the likelihood of an improving conversion rate, obviously during each consecutive period Cogmind was closer and closer to completion with a longer and longer history of steady releases. That helps convince anyone just discovering the game that it's both a substantial and promising project.

One of the buyer behaviors I've really been looking forward to quantifying is the percentage of those opting to pay more than the minimum price, and how that changed along with the tier adjustments.

Percent of Cogmind buyers opting to pay more. (This data just looks at the two lowest tiers for a given period, since the higher tiers are more complicated and aimed at group buys. The Prime tier and each respective basic tier are more directly comparable.)

After Cogmind's first year, during which $30 ("Prime Tier") was the lowest price, I added a new perk-less Alpha Tier for $24.99. For the next 11 months, buyers could decide whether they just wanted the game, or if they could afford and would like to contribute a little extra in return for having their name in the credits. Surprisingly 13.8% of individual buyers still chose the Prime tier!

Part of the equation here would be the relatively low difference in price, percentage-wise. Only 20% more for some extra perks and to support a project they like? Why not? Compare to the rate after the price was lowered to $19.88, which means a 50% (!) increase for Prime, and the ratio of buyers choosing that option was basically halved. Many of the long-time fans interested in paying more to back the project will have already done so anyway. (Though also note that data for the latter period was only collected for about a month, because the Prime tier was removed as of the Beta release. That said, I don't suspect we'd see much of a difference if I continued to sell that tier--it was removed primarily because development was entering a new phase, and keeping the "early supporters" tier active for much longer didn't seem right.)

In the end I'm very glad I chose to handle tiers and pricing the way I did, because otherwise Cogmind wouldn't have gotten nearly as much pre-Steam development as it has! Lowering to $19.88 sooner also probably would've been a bad move based on what I'm seeing now, since over the long term there's been no noticeable increase in the raw number of buyers. Anything in the $19-$30 range really falls into the "too expensive" category for a lot of people, even more so if it's not on Steam where the convenience of purchases can take some of the edge off a price, or where there's more likely to be some sort of discount to provide additional impetus. (I'm still not working at getting more exposure to make up for the loss in revenue per player--it's just the same old social media channels--but that's why I chose April/May to do this, around when it's time to transition to Steam.)

However, I certainly wouldn't claim that sticking with $24.99 would continue to generate a proportionally higher revenue. Conversion rates would likely drop if the price remained unchanged. Each time I've reduced the price over the past two years, I was already feeling that sales were starting to flag and would likely continue to do so if I didn't take action. Even if that may not have come to pass, I also knew that there was already pent up interest in a lower price, and it was about time to lower the gates a bit further and let more fresh players in.

So where does this funding go? Well, as a solo dev with relatively low asset costs, much of it naturally goes to pay my meager salary, and my job is to both create and sell Cogmind :)

As always I've been maintaining my detailed records of development time, which show that compared to 3,065 hours of pre-alpha development and 2,177 hours for the first year of alpha, Year 2 continued at a stable 2,192 hours of work. These numbers aren't too pretty, because it shows that this is a lot of work for the amount of revenue coming in--certainly not worth it in an economic sense, but that's okay for now as long as it's been sustainable.

Cogmind development time, July 2013 ~ April 2017 (excludes 2012 7DRL work).

There's always more coding to do along with any new features, so that has of course continued its long-term upward drive, and community-related efforts are finally starting to catch up to it as I spend a little more time on promotional stuff as the core game approached completion. Content-focused development accelerated significantly over the past year, which is what ate into coding time.

Comparing only the major development categories of Year 1 and Year 2 more directly, the shift from code to content is clear, while other areas stayed more or less constant.

Cogmind Alpha development time breakdown by major categories.

Because "what's a good percentage of time to spend on outward-facing efforts?" is a common question among newer gamedevs, let's also look at the major category breakdown for the project as a whole so far.

Percentage of Cogmind development time invested in each major area, July 2013 ~ April 2017 (excludes 2012 7DRL work).

So altogether it's 66.7% game stuff vs. 33.3% community/marketing. This is really a bare minimum, which I can get away with because the traditional roguelike community is pretty tight knit with a small number of key places to stay in touch with players, making that part of the job easier. Other experienced devs will say literally half or more of your effort needs to be some kind work that helps get your game noticed (or in my opinion just as valuable: serves as time spent interacting with the existing player base).

I have much more behind-the-scenes dev stats and dedicated analysis to share once Cogmind is complete, though wanted to share a little of it in this article to give the revenue more context. (There's also a month-wise breakdown of development hours in the latest annual review.)

Aside from dev time there have been a number of other expenses, but they account for less than 6% of the total budget (which doesn't really have room for anything more xD). Music is something I've been thinking about, but how much money can be budgeted there is still an unknown for something that may not be entirely necessary and for which there are multiple valid approaches at different cost levels.

Cogmind still hasn't broken even, but the hope is that it will as soon as it's launched on Steam.

It's been a good two-year run of alpha releases (see history), and the ability to extend pre-Steam EA development has been wonderful for fleshing out the original vision--some of the stuff I've been adding, even entire maps, was totally not planned from the beginning! And as a result of sufficient support despite the previously higher prices, the player base could be kept from growing too large and distracting (as mentioned in my pricing article) while still getting constant feedback on new features and mechanics.

Now that the Beta is out and further development is mostly optional fun stuff, it's time to seek out more exposure and put Cogmind on Steam :D. Performance there will be extremely important for the future of Grid Sage Games... so hopefully it can make a splash.

Making a splash.

(This article was originally published here, on the Grid Sage Games dev blog.)

#IFTTT #Blogger