Putting the 'role' back in role-playing games since 2002.
Donate to Codex
Good Old Games
  • Welcome to rpgcodex.net, a site dedicated to discussing computer based role-playing games in a free and open fashion. We're less strict than other forums, but please refer to the rules.

    "This message is awaiting moderator approval": All new users must pass through our moderation queue before they will be able to post normally. Until your account has "passed" your posts will only be visible to yourself (and moderators) until they are approved. Give us a week to get around to approving / deleting / ignoring your mundane opinion on crap before hassling us about it. Once you have passed the moderation period (think of it as a test), you will be able to post normally, just like all the other retards.

Frontiers - Daggerfall-inspired exploration-focused indie RPG

Will you donate to Frontiers Codex Cemetery (or maybe something else)?


  • Total voters
    122

Aenra

Guest
I could not watch 50 minutes total of musically scored apologetic nerd mumbling, so someone please correct me if this isn't the case here;
He cannot release a written statement, too cliche i presume. So he resorts to making a 50minute long video.. only to state that he's basically incapable of completing the project, but still perfectly fine/justified into offering no refunds? That about it?

:lol:

Smart kid. Fifty minutes of acting for $157,381 plus Steam Early Access sales. Not bad.
 

getter77

Augur
Joined
Oct 12, 2008
Messages
861
Location
GA, USA
...Well, I guess time'll tell what exactly comes of this after his next "break" from dev is done after another month or so---but man alive what a world we'd have if people considered their actions for posterity when it comes to KS reflecting on the whole as well as, you know, a greater sense of general due diligence prior to and running a KS in the first place.
 

Higher Animal

Arcane
Joined
Aug 11, 2012
Messages
1,854
So I came to this thread from Infinitron's future RPG hype thread. I'm a ridiculous exploration/adventure faggot when it comes to RPGs and this game should be up my alley.

But the dude fucked up, and any developers who manage to run into this post should take heed of the failure this now husk of a man presents. When creating explorefaggotry, the CARDINAL sin is creating an in-game navigation system. ANY quest compass or guide system NECESSARILY ruins any and all exploration possibilities within the game. Instead of creating an INTERESTING world that makes sense in the context of the game's lore, you deprive yourself of this stress by relying on the rails that a guiding system provides. Everything created in a rails system is decoration around these rails, and they are set pieces. This is not exploration, but interactive cinemas.

Explorefaggotry is only possible when game development begins without the possibility for quest compass or guiding path style design.
 

Aenra

Guest
:necro:


I thought the "dev" had done the smart thing, ie take the money and run off try hard, beg for compassion and call it ultimately too hard to tackle on his own. The poor thing.
And then i noticed this:

Dev Streams!
25 March - railboy
pVwtNiF.png

Hello everyone! First off - the
YouTube copyright issue has been resolved. No more automated claims should be happening. Whew!

Did you know I've been doing regular dev streams of my progress on FRONTIERS recently? By now most Kickstarter backers are aware of this, but I still get lots of emails from Steam players asking how the game is going. Now you can see for yourself:
Click here for the AAD Productions dev stream playlist.

(I've been linking those videos to my Steam profile so they should also show up under 'videos' in the community section, though you may need to browse a bit to find them.)

Live Streams

Those are all archives, of course - if you want to see me developing LIVE you can subscribe to my channel here:
Click here for AAD Productions on Twitch[www.twitch.tv]

I announce streams a few minutes ahead of time
here. I'm trying to stream once or twice a week, though it will vary depending on my schedule (crazy right now due to upcoming VR releases) and what part of the game I'm working on.

What About Spoilers?

Fear not - I try to stay away from spoilery material while streaming. (Right now I'm doing stuff related to the Behemoth mission.) The downside is you won't see me working on Act III stuff, but as we all know there's still plenty to work on in the first two acts.

Hope to see you all at the next stream! Feel free to bring your bug reports. :D

Cheers,
- L


http://steamcommunity.com/games/293480/announcements/detail/843670355339199643


Notice the present and future tenses. Is he back at "work"? His last update, excluding some inbetween Youtube copyright bullshit that had nothing to do WITH game development, was centered on his basically calling it quits.
Railboy any comments?
 

Burning Bridges

Enviado de meu SM-G3502T usando Tapatalk
Joined
Apr 21, 2006
Messages
27,562
Location
Tampon Bay
LOL, what a scumback. Those kickstarters and EA have ruined gaming more than it was in 2012. I can now no longer look at a game developer and not think that he is most likely another asshole.
 

Heretic

Cipher
Joined
Dec 1, 2015
Messages
844
It lives!
https://www.kickstarter.com/projects/railboy/frontiers-explore-discover-survive/posts/1774057
February Update - New Project Incoming!

I've started a new project
You haven't heard of it yet - heck, I didn't even know about it until pretty recently! But it's going to be taking priority in a few months so I thought it was important to share with you all.

Ready for a screenshot? Here you go:

a1d62650cbc72bc416a38777c227c83f_original.jpg

Not a bad start!

Keep in mind this is a WIP - it's super low-poly, texture quality is terrible and the AI is practically nonexistent. But the release date isn't until May so we've got plenty of time for polish.

That's right, I decided that game development wasn't NEARLY hard enough, so Hannah and I are having a kid to bump the difficulty from 'Hard' to 'Nightmare.'

Steady Money - No Longer a Luxury
Since FRONTIERS started I've steered clear of contract work for obvious reasons but steady money is no longer optional. Diapers are expensive, yo. So I'll be picking up contracts regularly from now on.

I was able to land my first gig quickly thanks to none other than FRONTIERS terrain designer and AAD alum Given. (Isn't it nice when a ghost from your past appears bearing gifts instead of new horrors?) For the next few months he and I will be teaming up to create machine learning environments for the Allen Institute for AI, which is as weird and interesting as it sounds. The majority of the project will be open-source so I'll be sure to post a link when it's finished.

Rob is a busy bee
Speaking of money - in the last update I introduced our new marketing director Rob, and boy oh boy has he been busy. In just a few months he's made a huge impact. Not only has he taken an insane amount of work off my plate - marketing & whatnot can eat up a third of my work-week, easily - he's done wonders for AAD's revenue.

It's amazing how much of a difference it makes to have someone, you know, selling your games to people. It's going to take another few months to evaluate whether AAD is up to the standard I'm striving for but we're certainly off to a good start. Go Rob!

Stepping away from Ironsong Forge
Contract work and FRONTIERS is more than enough to fill my plate, even with all the time Rob has freed up. So I'm stepping entirely away from Alpha Wave's latest VR project and leaving things in Ryan's capable hands. Up until January I was contributing mainly as an art director and prototype programmer, but at this point the project is more than half-finished and no longer needs my input. (I'll continue to post updates a la The Next World, of course.)

FRONTIERS gets a big upgrade
Remember when I vowed never to upgrade from Unity 4 to 5? When 5 first landed I tried to update the game just to see how it went - I was appalled at how unstable & flakey the new engine was. No thanks!

But that was a year ago (jesus...) and Unity 5 has come a long way. Recently I decided to give it another go with 5.4, and - amazingly - I had the base game up and running in less than a day. The frame rate has improved dramatically and I was able to tear out the wretched, ancient Oculus plug-in support in favor of native VR support.

This also means that FRONTIERS is finally a proper 64-bit application. (Unity 4 had 64-bit builds but they were so buggy and unpredictable that I stopped releasing them.) That's going to cut random crashes by about 90%.

Alongside this upgrade I've also been working on a new suite of mission testing tools & modes. After re-watching some of my old dev streams I noticed lots of opportunities to weed out inefficiencies with the implementation and testing of missions. That's the bulk of my workload at the moment so every minute saved helps. (Unity 5's scene management tools alone will help me save a lot of minutes.)

It feels good to see a big, tangible improvement after all these months of tiny, nibbling changes.

Getting Older
Having a kid really drives home the fact that I'm getting older, which in turn drives home how incredibly long this project has been stretching on (and on, and on). I've said it before but it's still shocking - you can literally watch me age on camera in my update videos & dev streams. (An even more sobering thought - depending on how much longer it takes you may even see my kid do the same!)

But it also strengthens my resolve to keep working, because eventually my kid is going to grow up and hear about dad's first big game project. And that's going to be a whopper of a story. It'll be about a guy who took a huge risk and bit off way more than he could chew, failed spectacularly over & over in front of thousands of people, nearly went bankrupt, and felt like giving up more than once - but he kept trying and struggling and slowly improving until he climbed out of the hole he'd dug & finished what he started. That's a good example to set, I think.

Alright that's all for now - until next time!
And it's updated to Unity 5.
 

Heretic

Cipher
Joined
Dec 1, 2015
Messages
844
New update - reworking the interface and inventory.

Developer PSA: Don't buy FRONTIERS for a little while
Thinking of buying this game? Here's why you may want to wait:
FRONTIERS is in the middle of an overhaul (which I'm calling v1.7) that addresses many of the bugs and performance issues that exist in the current version.

Everything is changing - the visuals, the interface, the inventory system, the save game system, etc. Most of these changes were driven by player feedback so a big thanks to anyone who took the time to play & post.

So what's the problem?
So far so good - unfortunately this overhauled version won't be in a releasable state for a while yet, and there's an uncomfortable disconnect growing between the game that's available for download and the game that's actually being developed. Right now the impression you'll get from the screenshots, forum discussions and bug reports won't quite match the finished product.

So if you're thinking of buying, DON'T. I encourage you to WAIT until 1.7 is released.

Just to be clear, the game isn't morphing into a Candy Crush clone or something - the core experience will be consistent. But in the past my mantra has been 'read the forums before buying!' so I want to err on the side of caution in this situation.

Bug Reporting
To anyone who already owns the game - hold off on posting new bug reports. The reports you've made for previous versions have been invaluable, but the systems that produced most of them have been replaced. Conserve your energy!

Humble Bundlers
To anyone who got this game in a bundle - this announcement is obviously coming on the heels of your purchase, which is slightly awkward. For what it's worth the changes in the visuals & gameplay didn't emerge until fairly recently - hopfeully you'll all love them. Fingers crossed!

Forum Housecleaning
I've moved a lot of the outdated bug reports into a forum called Archived Bug Reports (Pre v1.7) which you can view here. I've also moved some other topics like the Official Favorites Thread since they could be considered selling points.

There's still potential for confusion with this setup but this seemed cleaner and more transparent than just deleting stuff.

Alright I think that's everything. Thanks for reading, and thanks for your support!

Cheers,
- L
 

Burning Bridges

Enviado de meu SM-G3502T usando Tapatalk
Joined
Apr 21, 2006
Messages
27,562
Location
Tampon Bay
In other words this developer is saying, Frontiers is a scam that will never get the work it needs, but I do want you to agree with that and buy it anyway.
 

Heretic

Cipher
Joined
Dec 1, 2015
Messages
844
A new promising update
End of Year Update

Strap yourselves in - this is going to be a long update! We've got almost 6 months of development to cover, and I think you're going to be surprised by how much has changed in that time.

The State of FRONTIERS
As you all know, FRONTIERS has undergone an overhaul. It's now keeping pace with the latest Unity version (currently using 2017.3.0f3).

f6c6c2801a88f17c2222a5b91e08c7a9_original.PNG

New logo!
After upgrading to Unity 2017 many, many pieces of the original architecture became irrelevant, as they were in place to overcome Unity 4.x limitations. With those limitations gone I could remove a great deal of complexity, and with it, a great number of bugs. So what does that actually look like, in concrete terms?

Let's start with the first big change - the new Item system, which spearheaded the game's new look. The new look will probably be controversial (as would any major change made so long after release) but after reading I'm sure you'll agree that it was necessary.

New Item system - simplicity and performance
After taking stock of what assets remained to be finalized, I saw that we still had around 30 inventory / world items to model and texture, and well over 60 that needed to be touched up. That was on top of the assets I still needed to finalize for Act III and the climax, which were partly gray-boxed.

More importantly, there were performance issues with the finished assets - existing world items used meshes and materials that were dragging down the frame rate with unnecessary draw calls. Bad performance has been the #2 top complaint, so that wasn't going to fly.

The top spot belongs to bugs of course. You've seen them when placing, equipping, dropping, picking up, displaying, saving, loading, whatever - there are little bugs on every level. And a huge number of them were a product of the complexity and interdependence of the world item system, the downsides of which I've talked about at length in past updates.

So I took a deep breath, chucked the world item system and wrote a new class called Item.

Lines of code isn't always an indicator of complexity, but it's a pretty good yardstick, so here's a side-by-side comparison of the two:

f45970f0b971f30b1f88995086ac5989_original.png

I may have gone too far in a few places.
That block of code to the left is a travesty, and that's just the world items themselves - what about the code dedicated to managing those world items? Here are several more classes that I have eliminated entirely and have no plans to bring back:

ad85f0eded72d5c1913136d59e9cac67_original.png

Fun fact: I got bored taking screenshots of code so this isn't even all of it.
So why is Item so much simpler? Easy - it uses sprites instead of meshes. Instead of dealing with pivots, scaling, interface dopplegangers, bounds, materials, textures, etc - all of which can be configured incorrectly and produce bugs - items just use sprites. All of those sprites use a single sliced texture, so we can render hundreds of items with a single draw call. We lose graphical complexity but we get simplicity and performance in return.

(There were other gains in the loading & saving department, but I'll talk about them in the serialized data section.)

1755ca776dccf0b4da76ec9ad25065be_original.PNG

Old school sprites - now we're Daggerfall-ing it up
There are some objects that still use meshes - eg, boxes and barrels and other containers, as well as some artifact objects that have to remain in 3D for story purposes. But the vast majority will just use 16x16 sprites - we started with a generic sprite sheet collection and we've been customizing them as we go. Now if we need to knock out a new item, we can do it in minutes instead of hours.

Losing the work we put into the original mesh objects hurts, but at least the work we put into the gameplay elements remains (stats, descriptions, scripts, etc). And honestly, we never had the budget to let artists really go nuts with them anyway. I don't mind letting them go.

First Domino - Interface Overhaul
Overhauling the items has had a domino effect on the art style of the rest of the game, since pixel art doesn't mesh well with high-res art. Thankfully these other changes are equally beneficial.

The first domino to fall was the interface. NGUI is gone - it's been replaced with Unity's built-in UI system, which is much simpler and faster. (To be fair to NGUI, Unity's UI has a lot of performance problems as well, particularly around layout groups and scroll bars. But I've avoided those in favor of pagination whenever possible.)

With the help of pixel artist Savannah McKendree we've updated the interface art to match the look of the items.


Log interface



Inventory interface (includes crafting, clothing, bartering, etc)



World Map


For the most part, inventory assets use the same 16x16 icons as the items themselves, so we only need one icon per item. One exception is the book reader, which uses 64x64 versions of our book icons. I imagine you'll recognize these types from the book kits:

a97b2d1b11ef074575e807267343df87_original.png




Book icons in use


Second Domino - Terrain Overhaul
For the most part the terrain didn't have to change much to accommodate the new look. The main change was setting textures to point filtering and resolution to a level that felt congruent. These are pretty cheap tricks, and if we have time we may go back in and update the textures by hand to really make the low-res versions work. But for now it'll do.

However, this minor change paved the way for significant optimization. Reducing texture resolution made it possible to unify materials for all terrain features, which means all terrain features can be rendered with a handful of draw calls, provided they're batched properly. The next step is to statically batch the terrain feature meshes (since the individual meshes are too large for dynamic batching). Now that Unity has added support for 32 bit index buffers for meshes, this process won't be nearly as painful as it would be in 4.x.

So that's the terrain features. What about the terrain? Well, I had the opportunity to pick the brain of a former Unity employee who now works at Microsoft. After a long conversation about their terrain system he finally persuaded me to ditch it altogether. It was the right move. Terrain has been replaced with simple sliced / LOD'd meshes and the performance boost has been incredible.

ee39a50d77ad5a9e073aeea5d788be4a_original.PNG

Take THAT, frame rate!
Another benefit of unifying terrain and terrain feature materials is that we can implement global features by editing just a few shaders. One example is nice fade-out fog without deferred rendering. Here are the three primary shaders - terrain, foliage and terrain feature, all fading out in sync:

4266da4546a2d54a1d2b1c55b343694c_original.jpg

All done using forward rendering
Now that the old terrain system is gone, so goes the old tree system! Good riddance. (If you follow my updates you can guess that this took less persuasion.)

I've implemented my own tree system using instanced meshes. It's smart enough to only draw the trees you're looking at, but it can actually render every tree in the entire world at once and still get better frame rates than Unity's old system. Sheesh.

Grass needs to be re-implemented as well, but since this has absolutely no effect on gameplay it's on hold at the moment. I'm not concerned though, since I've seen systems that render grass using existing terrain data, and it's the kind of self-contained job that's easy to outsource.

Third Domino - Data Serialization
The original world item system mixed its state data (eg, damage) with its shared properties (eg base price), and this data lump would be loaded or stored as a single XML file. This meant that any value in an item's state could change, and would be saved, but it also meant massive duplication of global properties and many, many opportunities for bugs.

What if one particular apple's base price accidentally got set to $10,000 before saving it? This was a constant problem, especially when I would push updates that changed the shared properties of an object to fix a bug. Everyone's save games would retain the old, erroneous values for any items that had been spawned before the fix. What a nightmare.

So when I ditched world items, I also stopped using XML states for shared properties and started using ScriptableObjects, which piggyback on Unity's built-in serialization. I also stopped saving state data for all items by default - why bother when I can set values in the scene directly? Now I only store state data for an object when it has been changed by the player.

Items aren't the only thing that I switched over to this system. Books, conversations, blueprints - all major data structures are now serialized with ScriptableObjects and only use XML to save state data. Eg, conversations save an XML list of exchange IDs to track which exchanges have been completed, but everything else is serialized in Unity.

To understand why this is so beneficial, let's go over each step of debugging a formatting error in a single book using the old system:

  • Edit a text file of book contents using custom markup
  • Import file using FRONTIERS importer, which interprets markup and generates an XML object
  • Save XML object in editor
  • Start game
  • Load XML object at runtime
  • Display book and check for errors
  • Find error, repeat
If something displays incorrectly, how do I know what went wrong? Was there a stray character in the text file? A bug in the importer? In the loader? In the display? When you're dealing with hundreds of books tracking down formatting errors can take hours.

Now let's look at what it's like to deal with a serialized ScriptableObject in the editor:

  • Edit book contents in Unity editor while game is playing
  • Display book and check for errors
  • Find error, repeat
2d7a805eb7d8f13855c95bca154c5b23_original.jpg

Note the use of sub-objects for individual chapters. Fancy!
It's also easier to write little tools that make the data more human-readable. Here's what it now looks like to edit a crafting blueprint:

14b90f035929aa9b8931508c6c1d9c1d_original.PNG

Complete with preview of in-game appearance
Note that while editing these objects I can actually create direct links to other serialized objects. This is obviously impossible when you're importing objects as separate XML files - you have to preserve references as strings that you can resolve with a search of some kind.

See those links in the Row1 / Row2 / Row3 arrays? Those are references to ScriptableObjects containing Item properties. If I change the name or the icon in the item properties, the blueprint will automatically be updated. So many opportunities for bugs are eliminated this way.*

The downside of this approach is that modding is harder. Not impossible - I can still generate or alter ScriptableObjects via XML at runtime - just harder. I'm still committed to making the game moddable, and after release if people feel constrained by this approach I will write tools that help them modify the data. But let's be real, nobody is going to want to mod a game that isn't functional to begin with.

*(Note: this is obviously common practice in most projects. It just hasn't been common practice in THIS project until now.)

Fourth Domino - Structure Generation
Thanks to unity being 64 bit, structures are now just meshes, and those meshes are just loaded in a single scene. I don't have to generate them from an XML template at runtime, and I don't have to destroy them to free up memory when the player can no longer see them - I just deactivate / reactivate the structure object.

Yeah, I know, I can hardly believe it myself. Want to know how much code this eliminates? Gaze in horror:

0c6d4036d4466f7fbe3519cff9d882bd_original.png

Look closely and you can see the switch statement where I lose all hope
That doesn't even include any of the code other objects had to deal with the inconveniences of structure loading, nor does it include the code for the multi-mesh combiner we had to write.

This means that the most-complained-about bug of all time - the buildings failed to load bug - is truly dead forever.

Fifth Domino - Object Spawning & Randomization
At this point all terrain is pre-generated and can be opened in a single scene, and all structures are pre-generated and can be opened in a single scene. So far so good.

What about the items that we spawn inside of structures? You may recall we had a fairly complex spawning system that used sets of flags applied to locations, structures and individual items.

That was a necessity before, because a single structure template might be used to generate multiple structures in multiple locations. But if you can just add those structures to the scene, then you can just, you know, put the items in the same scene. Goodbye randomized spawning, and goodbye even more complexity and bugs.

After generating all the structure meshes and placing them in the scene I wrote a script that did a one-time randomization setup in two passes - first it instantiated prefabs for all furniture (which still use 3D meshes), then it instantiated items on / in all furniture that would previously spawn items at runtime (eg book cases).

There were lots of cases where an inappropriate item was spawned, but it was no big deal - I would just delete or replace it and save the scene. CRAZY, RIGHT?

This takes so much guesswork out of placing important items in the world. I don't have to worry that a bug will cause no copies of an important skill book to be spawned, for instance. I just, you know, put it on a shelf.

Sixth Domino - Character & Creature AI
FRONTIERS has never been an AI-focused project, though I have put plenty of effort into making it at least passable. A major limitation has been pathfinding. How do you establish paths in a world that's constantly being created and destroyed? I came up with an arbitrary waypoint system for roaming characters and ignored the question altogether for creatures.

But hey, we've got a static world now! So I've ditched the old (now-unsupported) RVO solver I was using in favor of Unity's navmesh agents. I get pathfinding for free, and it's more performant to boot. I was able to generate a single unbroken navmesh for the entire terrain - yes, Unity actually supports navmeshes of that size, though there's some cheating behind the scenes - and sub-navmeshes for underground areas.

b0f08a81a52fe06dbbfdde164daa3dda_original.PNG

Navmeshes = awesome
Now creatures can follow you around intelligently. Most importantly, orbs can follow you around intelligently. (You had no way of knowing this, but the pathfinding limitations were really hurting orb-related parts of Act III.)

Seventh Domino - Making it EASY TO TEST
You know what really, really sucked about debugging 4.x versions of FRONTIERS? You basically had to load an entire game to test something. At one point I created a utility for testing character dialog, but it never worked well because conversations constantly try to modify objects in the world.

So if I wanted to really test a mission, I had to load the game world, then activate the mission, then... well, play the mission. And I couldn't cheat and skip around the map because of the volatile nature of the game world streaming - if I did, I might skip bugs that the player would encounter, or introduce bugs they would never encounter. It was a painful process.

As I rewrote all these pieces I kept entities self-contained. Characters and items aren't generated at runtime - they're prefabs with references to ScriptableObject properties. If I want to test a mission, I just drag all the mission-related characters into a test scene and talk to them one after the other. I can do this without fear that the objects will be generated in a different state in another situation because that's the whole point of prefabs. Here's a scene where I test out a set of related conversations:

2400230e1841e229cdec75f0dde0513d_original.PNG

Skeld? In Benneton? NOT CANON.
Testing an animal den outside the context of the entire game world was impossible before - a den is tied to a location, which had to be generated at runtime from XML data, etc etc. But now, I just drag a reference to the location properties onto the den, drop it onto some terrain and try it out:

3eb76a9b552cb01fcdf72edfcace0b8a_original.PNG

Cows adopt a hoplite phalanx formation in response to wolf attacks
Eighth Domino - Simplifying Gameplay
(Note: This isn't really a direct result of the other changes, so I'm stretching my domino analogy a bit. But screw it, I've got a theme and I'm sticking to it.)

As I was converting skill states to ScriptableObjects I took the opportunity to simplify skills, status variables and bonuses. Stats in FRONTIERS have always been over-complex and the relationships between different numbers has always been muddy. When a stat would change there wasn't always a clear difference and it wasn't always represented visually.

Now all stats follow a simple pattern - they're a number between 0 and 7. Health, Energy, Reputation, Magic - all 0 - 7. Edible food restores 0 - 7 units of energy. Medicine restores 0 - 7 units of health. An attack by a creature takes 0 - 7 units of health (minus 0 - 7 units of armor). A weapon deals 0 - 7 points of damage to that creature. And so on.

Why 7, you ask? Because I experimented with putting different numbers of dots in a row and settled on the number that was easiest to take in at a glance.

1267dbb5794d0ca378642d13b1d2e6f4_original.PNG

Learned skills show a level of 0 - 7


7250e27791da35e399104c4945e3bb86_original.PNG

No more color-based stat indicators
There were also some systems that were inherently confusing, like status conditions, weather / clothing and potion-based modifiers. I've either ripped those out entirely or replaced them with something more straightforward.

Clothing no longer modifies a separate set of clothing-related stats - it just affects the level to which your primary stats regenerate. So if you're wearing clothing with a combined +4 energy, your energy will automatically regenerate up to 4 over time without having to eat food.

Reputation doesn't regenerate like other stats - it only changes based on discrete actions - so reputation modifiers work a little differently. If you have a stellar reputation of 7 but wear a jacket with -2 reputation modifier, your reputation will be 5 until you take it off. Pretty simple.

afdb5b727adee646f2874c9885a300f9_original.PNG

'Well-Dressed' is a bonus - I'll get into those in another update
Creature stats follow the same 0 - 7 pattern. Their stats can be discovered / viewed through the Examine skill - here's a chicken's stats viewed with a maxed out Examine skill:

0041a0f980654023d5a683cc12de2e7e_original.PNG

Don't make chickens mad
There are other changes & simplifications, especially in the way that skills are used in the new interface, but this update is already running long so I'll go over them another time.

Ninth Domino - Multiplayer
At last we come to the great unknown quantity, multiplayer.

I can't overemphasize how much simpler multiplayer becomes when you're dealing with a single, fully loaded scene. No more struggling to transmit the bloated XML state of live objects. No more weird edge cases where parts of the world are loading or unloading as they're being synced. No more waiting for a structure to finish being generated on one player's machine before allowing another player to enter it. It's like waking up from a nightmare.

Oh, there are still challenges, don't get me wrong. But it's an order of magnitude simpler than what we were facing before.

State of FRONTIERS: In Conclusion
FRONTIERS is in a pretty decent place, given the risk of upgrading at this stage. This overhaul has enabled me to incorporate all the things I've learned from the other titles we've worked on. It always felt a little unfair that all the games you guys didn't back would benefit most from the early failures on this project. So I'm glad I can bring that knowledge full-circle.

Summarizing all these changes and going over all the ways I've saved work for myself has been energizing - it's easy to forget how much I've actually accomplished given how stressed out I've been these past months.

That leads me to:

The State of AAD
The last time I posted Olive was just 6 weeks old and could barely wiggle. Now she's 7 months old and crawling around, trying to kill herself by chewing on live wires. This has been without question the toughest 7 months of my life. I've never been more exhausted, stressed, or confused. I've never had to make choices that affect the life of someone who depends 100% on me to think for them. These 7 months have felt like an eternity and like the blink of an eye, all at once.

d2f417107a40ed1a1608ce70853bfe7c_original.jpg

Obligatory baby photo
What does all this have to do with AAD Productions?

Well, frankly it's time for me to settle down. I feel it in my bones. I've been doing full-time mixed-reality contract work for Microsoft for a while now and I have every intention of making that (or a similar) position permanent. I'm proud of what I've accomplished with AAD but it can't produce the kind of dependable income that we need. (Not to mention health insurance...)

I'll keep working on FRONTIERS, as always - if the past 7 months prove anything, it's that I could find time for this project in a bombed-out bunker during WWIII - but once I've delivered everyone's backer rewards, I won't be developing any more indie games.*

I may still publish the occasional game under AAD - Ryan is still working on smaller titles - and Rob will continue to find ways to sell our titles. But I'm no longer pursuing Q.U.I.C.K.L.Y as a strategy.

This shift in priorities has been evident for a while even if I haven't expressed it as such, and that has clearly disappointed some backers. I'll admit it's a reversal - all I can say is I'm as surprised as you are. Before Olive was actually born I intended to continue AAD's transformation into a profitable full-time indie game business. And if I were a deadbeat dad who was comfortable offloading the parenting onto my wife, I could probably still make that happen. But my interest in that possibility has evaporated. My primary concern now is making a living while still having enough time to watch my kid grow up.

*At least not until Olive graduates and I have my mid-life crisis, lol.

Q & A
Some questions were posted in the comments section so I'll answer those now:

  • Will the new Unity upgrade be compatible with all the old tools for backer content?
Yes - plants, blueprints, books and so on have all survived the transition intact. There's no need for backers to re-submit anything.

  • Why hasn't Rob made an appearance to try and take pressure off you? Does he no longer work for you?
Rob's role was originally going to be more community-oriented, but once I decided to stop production of new titles and sunset AAD Productions that's taken a back seat to finding ways to sell our games. (His latest was a set of deals on Chrono, which went really well.) He still handles the majority of the red tape we deal with - key requests, deal offers, contracts, etc - and he's responsible for traveling to trade shows to meet with people face-to-face. That still saves me a ton of time.

  • What are your plans with future employees?
I'm hiring contractors for individual jobs as they come up - pixel art, asset optimization, website creation, cutting trailers, stuff like that. We may not have the money to hire full-time employees but Rob has made it possible to hire folks for odd jobs. I always try to outsource anything that doesn't require specialized knowledge of the project or a ton of day-to-day coordination.

  • Is the positive feedback loop based on incoming revenue still attainable?
It might have been but it's a moot question now that I'm no longer attempting to make AAD Producitons a full-time gig.

  • Based on historic dev blogs, news posts, updates and live streams you handled everything yourself. Do you plan on continuing to do everything yourself?
Pretty much, apart from the one-off jobs that don't require a ton of coordination like the ones mentioned above.

  • Do you think handling everything yourself is negatively impacting the project?
Undoubtedly. The whole point of trying to make AAD sustainable was to climb out of that hole and develop our projects with full-time employees. But again, the question is moot at this point. Whether it's hurting the project or not, there's no alternative - it's on me to see it through to the end.

Next Steps
I want to get the new version of FRONTIERS pushed to Steam as soon as possible - when that will happen is anyone's guess, so don't hold your breath.

I want to do dev streams again as well - I've made several abortive attempts but none have panned out. After 10 minutes of setup and maybe 10 minutes of development, I'm always interrupted by something work or kid-related. But as Olive gets older and starts to break out of her 2-3 hour cycle of napping / eating I'm hoping this gets easier.

Is that everything?
I think so. I'll check comments for questions.

Thanks for reading, and happy holidays!

- L
 

Baron Dupek

Arcane
Joined
Jul 23, 2013
Messages
1,870,765

At least he's trying and didn't just abandon his KS project like that fucking Yogscast thing

Are you talking about these YT Minecraft-manchildren who gave all their money to the shady "artists" who barely worked on their project and run away because they know shit about business?
No wonder they abandoned it if they lost dosh.
 

As an Amazon Associate, rpgcodex.net earns from qualifying purchases.
Back
Top Bottom