Return to “[Archived] Daily Dev Logs, 2012 - 2015”


Week of October 19, 2014

Sunday, October 19, 2014

YES! Lots accomplished today!! :D

NO! No time for a devlog today!! :shock:

WHAT? Time-sensitive life events (whose nature will remain undisclosed) have put me in a situation at this moment where time is the enemy!!! I must away my friends, I must away with great haste! :crazy:

I'll be back tomorrow, when time will once again be my friend! :thumbup: :geek: Wait for me!! :?

PS ~ Today & yesterday we got press on both RockPaperShotgun AND TheMittani!! Update #20 rocking it! No time for links it! :ghost:
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford

Re: Week of October 19, 2014

Monday, October 20, 2014

Really haven't gotten as much time as I would have liked to devote to LT today, once again due to life events whose nature will remain undisclosed. The good news: time really is once again our friend, and I expect huge amounts of productive work from the rest of the month (and year, of course :ghost:). I burned the day a little longer than I should have today (as you can see from that absurd devlog deficit) in hopes of making it into a normal work day, but, as we all know, there's only a certain amount that one can compress time (much to every programmer's dismay) :roll:

In the time that I did squeeze out of today, I finished the grid widget implementation (again, to be used in the cargo display / trade interface / as many other places as possible :roll:). Still no button to switch between grid and list view, but that's coming very very soon! It's nice being able to watch AI players mine again (from both the game as well as the overhead testbed!)

Another exciting piece of low-hanging fruit that I nabbed today was the texture widget (mentioned two days ago). Along with it I had to expose some texture and location functions to LTSL. 'Location' is just an abstraction for reading / writing data from / to different sources -- you can load a texture from different disk locations (like the compiled resource map, as detailed a few logs ago), the procedural asset cache, memory, or even the web (note - I may implement something that automatically marks mods using web / network functions as 'high risk' / 'requires network access' so that users know if a given mod is going to be trying to download or send stuff over a network. Anyway, it was a fairly simple thing to implement, but I love the results. The first thing I did with this new toy was to replace all of the testbed backgrounds with game screenshots :geek: Now I can see my UI, menu, AI, overhead, colony, and HUD testbeds as if they were actually brought up in-game (because they're overlaid on a screenshot). Really awesome both for making sure the visual style fits as well as just being hyped about the game's graphics :D It would be even cooler to randomly select a background from the screenshot directory... :think: Coming soon!

Good but short day...luckily tomorrow will be a full behemoth of a day! And enough with the deficit :shock:

“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford

Re: Week of October 19, 2014

Tuesday, October 21, 2014

Yes 8-) Now that's what I'm talking about folks! 12+ hours deep today...just the way I like my coding :monkey:

It's yet another day where I feel the list format to be most appropriate. I guess that makes sense, since development these days is more about pushing out content and less about big pieces of technical elegance that require long-winded explanations...I'm sure some of you are relieved about that :roll:
  • Added smooth target tracking to the map widget
  • Working on adding infinite grid visuals to the map widget for giving a better sense of zooming and camera motion
  • Added more detailed profiling information to the game's renderer (I'm starting to prepare for the final optimization pass before release!)
  • Continued work on bringing the 'play' task into LTSL. Proving to be slightly trickier than initially expected, but still approaching completion.
  • Started work on the exciting new PlateMesh editor widget!
  • Continued work on implementing the 'render' widget for rendering game assets outside of the context of the full game
  • Implemented a small-ish new feature in LTSL (one that I've really wanted for quite some time) that allows member variables to be automatically initialized with a custom initialization statement (written directly after the member variable is declared). Definitely something that most of us C++ programmers have always wished we could have (and in theory, I think we'll get it with C++11...someday...)
Yes, it's all exciting, but I'm most excited about two of those things: first, the render widget. As I've been mentioning frequently this month, once I get that puppy in place, I'll be in tremendous shape to pump out the last of the graphics content. Next, the platemesh editor. Yes, yes, and more yes. Remember the paradigm: what starts as a dev-ish widget morphs into a piece of game content...can you see where this one is going? ;) It will start as a widget to view PlateMeshes (the format that ships and stations use to generate their geometry). That piece of tech in and of itself will be used to rapidly iterate ship and station algorithms. But then it will be upgraded to an editor, such that PlateMeshes can be tweaked in real-time by adding, moving, re-shaping, or deleting pieces. And then? It will be polished for usability, made to fit into the game with immersion, and it will become...the custom ship and station editor :ugeek: It's been an awfully long time since we saw that really basic ship editor in 'Gameplay Demo 2,' and I'm sure you're all excited to see what we can do nowadays with the latest LT graphics and UI :) I am too! :D

Onward into the sunset! Onward, my friends!

PS ~ Pushing that devlog deficit beast back! Back from whence ye came, foul demon of the temporal underworld!
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford

Re: Week of October 19, 2014

Wednesday, October 22, 2014

Couldn't help myself. It needed to happen. I dropped all day into the PlateMesh editor (and related concepts). It was worth every penny :)

This is honestly the most exciting work that I've had the opportunity to do thus far with the new UI. It's definitely pushing LTSL and the UI to their respective limits, which is a good thing :) It's by far the most advanced widget we've seen so far - it comprises all of the standard bits of tech, but pushes much further than that, requiring dragging and manipulation of widgets that are positioned in 3D space, holding recursive widget structures, and drawing simplified representations of a potentially-complex geometry.

Since I haven't actually said much about the mysterious PlateMesh structure up until this point, I'll go ahead and elucidate it a bit now. In essence, it's a hierarchical box mesh. Don't fall asleep just yet -- it gets more interesting, I swear :) Every PlateMesh is a group of 'plates,' each of which comprises a center, scale, rotation, and bevel (yes, plates are just transformed, beveled boxes...but for some reason, I prefer to use the terminology 'plate' in my head). That alone can get you some interesting, boxy geometries. But it's not enough.

The part where it gets interesting is that every PlateMesh also has a group of mathematical transformations that act on the entire mesh structure to transform the geometry in some way. There are things like point repulsors and attractors, planes that produce exponential cusps and folds, etc etc. In theory, these transformations can be any mathematical transformation that takes one point in 3D space to another (i.e., modifies the position of a point in space). In practice, combining a small group of basic transforms gives enough flexibility to produce most of the interesting shapes that you would ever really want :) Finally, every PlateMesh has a group of sub-PlateMeshes (it's a recursive structure). The transformations of one PlateMesh act on all children (which gives a nice 'global' feeling to the geometric warps).

So ships and stations are actually built up recursively from pieces that are 'glued together' under various bits of math. The process continues for as many levels of hierarchy as you like, until you arrive at the final mesh. It's rather simple, yes, but I assert that it's an intuitive way to arrive at virtually any (artifical-looking) geometry you might want.

Now, in the editor, this means that we've basically got three types of operations to think about: plates, transformations, and hierarchy. We need to make it easy to add / move / scale / rotate plates within any given PlateMesh node. We need to make it easy to add / move / change the properties of the transformations that are applied to any given PlateMesh node. Finally, we need to make it easy to change the connectivity of nodes - to add one as a child of another, or to break a node off of its parent.

Today I've got the first bit of this working - editing plates at a given level. It's a pretty intense learning experience as I delve deeply into the LTSL...but it's also rewarding, seeing what all of this tech can do for us :geek: IMO, the most challenging part of all of this is going to be visualizing the final product at interactive speeds, taking into account all the hierarchical math that's going on. To do this, I'm planning to split the widget into two windows: on the left, you will perform manipulation. On the right, you will see an approximate view of the final product (created by rendering a certain density of points over the surface to give an idea of the geometry) which will respond in real-time to the changes that you make in the editor.

Once again, I'll reiterate the obvious, which may actually be not-so-obvious: despite it looking like an editor, this little tool is going to help me immensely to visualize and iterate on the PCG algorithms that build the artifical geometries of LT. It's going to be a joy :D

(Whew, got a little carried away with that log :shock: Well, I think PlateMeshes are exciting :geek:)
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford

Re: Week of October 19, 2014

Thursday, October 23, 2014

Excellent day!! That said, it really did, unfortunately, have to be a technical one :monkey: Sorry folks! I've got to get this asset caching mechanism in place, as it's starting to drive me crazy that the overhead testbed takes ~5 seconds to load / reload. I know, it might sound crazy, but that's just enough of a latency to break my flow (it's a whole different ballgame from, for example, the UI testbed, which is basically instant). Yes, that's the first and foremost reason that I'm being driven to make the change now, but, as I've said before, it's something that must be done before release.

I've broken off bits and pieces of the problem before, but today I've built a full road-map of everything that must be done, and started to grind through the absolute most-challenging bits. It's a beast that goes deeper than I ever imagined, but, like most deeply-rooted beasts, solving it has a vast landscape of positive implications for other systems! :geek:

Most of the work lies in unifying and simplifying the key structure that underlies all rendering operations -- the renderable class. The diversity of ways in which various bits and pieces are rendered at the moment presents a serious problem for a unified treatment of graphics assets, which is a requirement for a unified caching mechanism. The thing is, at the end of the day, every graphics asset ultimately comes down to a mesh (the geometry that's rendered) and a shader (the program and program data with which that geometry is rendered). Hence, there's really no reason for graphics assets to be as diverse as they are now. The complexity must be compacted down to simplicity, but, as always, doing so requires finding the perfect insights.

Today I have developed what I believe to be the total set of insights required to remove the beast, and have already successfully applied the biggest one to solve one of the most deeply-rooted problems: the problem of special-case renderables that require data to be retrieved each frame from a game object (this applies to basically all 'dynamic' effects like weapons, thrusters, missiles, etc.) As a side-bonus, I've actually managed to do something today that I've always wanted to be able to do: draw a big wall of separation between the LT rendering engine and the Limit Theory game :geek: That is, the rendering engine no longer knows anything about the game. That's how it should be, and the fact that I was able to do it today is a really good indication that I've made a leap in the right direction.

At the end of this process, we'll be left with a lot more than really fast asset caching. We'll also gain an elegant, unified geometry pipeline that will be trivial to manipulate in script. We'll gain (well, already have gained) a powerful mechanism whereby world objects can pass data through the render pipeline (in fact, rather similar to the way that widgets can pass messages through the UI!) Perhaps, above all else, the collapse of so much complexity will inevitably yield performance benefits. Shader programs will become much more simple and faster to bind / unbind, renderables will lose several levels of indirection (making all geometric operations faster), and the less-abstract memory layouts will make it easy to perform a vanishing act on those slight stalls that occur occasionally when an unloaded renderable comes into view.

Remember: the tech and the content live in a harmonious dance. We must do what we must do to reach LT enlightenment (AKA 1.0!) I'll make it as fast and painless as I can, and will be sure to continue allocating plenty of time to content as I go :)

On a (more!?) abstract note, I'm starting to finally develop some unified, confident outlooks on many of the programming ideas that I've been struggling to understand over the past two years. Building something as large as a game engine and game, especially when done alone, affords an incredible opportunity to see and try to understand general patterns in software architecture. Over the years I've come to better and better understandings of those patterns, oftentimes writing about them in the dev logs and performing the resulting 'code-ripping' to embody the ever-increasing elegance of my understanding of those ideas. Today I happened to glance over a manifesto of data-oriented design, and, despite my opposition to the near-religious zealotism of those who seem to be pushing this style of coding nowadays, some connections did start to click in my head with really, really general patterns that I've been trying to understand. Things like sparse properties, component-based composition, parallel processing, property lookup trade-offs (virtual tables vs. dynamic maps), easy serialization of pointer-laden memory constructs, etc. It all started to come together into a unified picture of something very beautiful. Now is not at all the time to explore this beauty. The LT Engine is largely finished, and I will perform no more gratuitous code-rippings. But the future is looking brighter and brighter as I accumulate ever-more ideas to bring to bear on future works (like LT2! :geek:) My walk with code has been a long, sometimes-arduous, but always-rewarding experience. It's far from finished -- I doubt I'll ever be truly satisfied with my understanding of this elegant world of computation. But every year, at the very least, I'm glimpsing more and more of the underlying beauty and unity that exists somewhere out there in the ether of the code-that-could-be. What an exciting life. I really do love my job :)


( a bit carried away :shock:)

PS ~ Only as I was writing the devlog did I realize that the insight implemented today actually finally affords an elegant solution to distant object fading! Wow!! Can't wait to try it with asteroids ASAP!!! Awesome! :D
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford

Re: Week of October 19, 2014

Friday, October 24, 2014

Gonna go easy on the log today, as I've been getting carried away lately :lol: Another good day without any central theme :roll:
  • Implemented an LTSL-based random screenshot picker for my testbeds! May seem like a gimmick, but honestly, I'm finding it really productive to see old screenshots in the background while I'm working in my testbeds. Sometimes they'll actually inspire me ("ah, you know, that system looked really good because XYZ" or "hmm, that metal texture looks a bit better than the one I've got now"). It's helpful to be able to review the 2-year development of LT in picture form as I work on it...kind of allows for all the ideas I've ever had to stay integrated and remain inspirational :) Also, this is a great little tool for a loading screen -- show the player random screenshots of where they've been before!
  • Implemented a new procedural component to system generation that ties in with the renderer's color grading post-process effect. Every system now has an even more distinct 'feel' because it can actually change the way that colors behave. Not at all realistic, but I'm already finding it amazingly-effective at giving subtle, unique vibes to different systems :D Very cool!
  • Finished a new texture testbed, wherein I can create, generate, and filter textures in LTSL using GPU shaders. Excellent tool for iterating the asteroid texture generator, metal texture generator, colony terrain texture generator, etc. I'm expecting serious leaps in the quality of these generators very soon, thanks to rapid iteration capabilities! :)
  • Fixed an error in the bloom saturation algorithm that was causing some subtle artifacts in very dark parts of the screen
The month is coming to a close at what seems to be a freakish pace, but work continues onward at an equally-freakish pace. We will fight until the end! :ghost:
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford

Re: Week of October 19, 2014

Saturday, October 25, 2014

Excellent day. It wasn't what I thought it was going to be, but it was, without any doubt, an excellent day. There are days when a gust of inspiration just takes you by surprise, and you've no choice but to follow the wind. It's days like these that I live for :)

Today wasn't supposed to be about graphics. In all honesty, it wasn't about graphics...not really :shifty: Maybe on the surface :monkey: But today was really about exploration. It was about getting back to the heart of what inspired me to go after Limit Theory in the first place: that magical feeling of gazing upon the unknown.

Yesterday I mentioned the implementation of a feature that gives systems a distinctive 'feel' to them by procedurally-generating the parameters of a post-process color transformation (called color grading). Today, during the normal course of my work, I thought I would take a few minutes to extend the color grading algorithm to use a full-3D lookup texture, such that it can represent literally any color transformation, whereas the previous one was limited to 5-point bezier curve wherein each color channel was independent. It didn't take long to implement. It was interesting, sure. It didn't take long to add a little debug feature to allow me to hit a key and generate a new color transformation for the system. But after that...after that, it took an awfully long time to stop gazing at the results. Suddenly, I found myself sitting in a multitude of different ambiances...shifting into a new one with every press of the key. Not even just a multitude of different ambiances -- no, with arbitrary color transformations, it almost seemed as though I was shifting into different games entirely.

I traveled around systems, shot at things, watched ships shuttling to and fro, gazed at transfer beams, and sat in front of wormholes...all the while hitting my little F6 key every few minutes, ripping me out of one distinctive feeling and into another. I just couldn't get enough. I'd seen it all a million times -- the same procedural content, the same game. But through an infinite number of different lenses, it somehow felt equally new each time.

I continued to play with the generator. Ultimately, I whittled it down to three one-dimensional lookup tables instead of a three-dimensional one (so that each color channel is modulated independently of the others). It seemed to give more coherence to the feelings. The magic lasted a full day :geek: :squirrel:

My work with color grading over the past two days has been an incredible eye-opener for me. As a graphics programmer, it's always very interesting when I come to new understandings of how the eye interprets different pieces of math. But I never would have guessed how tremendously-impactful a seemingly-minor color transformation could be. Of course, I already grasped some small idea of that when I invented the 'magical' color grading algorithm that's been with us for a few months. It improved the visuals by an astonishing amount, despite being a really tiny little post-process effect. But seeing the procedurally-generated color grading algorithms over the past two days, and especially today, has just blown me away. It's absolutely unreal how dramatically they can change the entire feel of the game in beautiful ways. This is an awesome new piece of LT tech that I believe will go a long way toward making sure that the infinite universes don't become boring quickly. With careful variation of the grading algorithms over systems / regions / clusters, players will get a very real sense that they are exploring procedural systems that go well beyond randomly-generated backdrops. For me, LT has always been and will always be about exploration of infinite, procedural content. The explorer in me is just thrilled with this work :)

PS ~ There was plenty of other progress today, but you know how that goes -- sometimes one star shines so brightly that the rest just seem to vanish :geek:
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford

Online Now

Users browsing this forum: No registered users and 1 guest