mindx2
Codex Roaming East Coast Reporter
Further parts can be found here: https://www.kickstarter.com/projects/railboy/frontiers-explore-discover-survive/posts/1370080
Is this a KS update or a therapy session?! My goodness....
Further parts can be found here: https://www.kickstarter.com/projects/railboy/frontiers-explore-discover-survive/posts/1370080
And it's updated to Unity 5.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:
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!
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
Developing your own game as an indie is not really comparable to working at some big studio as a devRemember when people could father children AND maintain a job/work at the same time?
Developing your own game as an indie is not really comparable to working at some big studio as a dev
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).
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:
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:
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.)
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:
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.
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:
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:
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.
- 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
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
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:
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:
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.
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:
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:
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.
Learned skills show a level of 0 - 7
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.
'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:
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.
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:
Yes - plants, blueprints, books and so on have all survived the transition intact. There's no need for backers to re-submit anything.
- Will the new Unity upgrade be compatible with all the old tools for backer content?
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.
- Why hasn't Rob made an appearance to try and take pressure off you? Does he no longer work for you?
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.
- What are your plans with future employees?
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.
- Is the positive feedback loop based on incoming revenue still attainable?
Pretty much, apart from the one-off jobs that don't require a ton of coordination like the ones mentioned above.
- Based on historic dev blogs, news posts, updates and live streams you handled everything yourself. Do you plan on continuing to do everything yourself?
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.
- Do you think handling everything yourself is negatively impacting the project?
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
At least he's trying and didn't just abandon his KS project like that fucking Yogscast thing