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

Post

Week of June 1, 2014

#1
Sunday, June 1, 2014

Ahhh!! So intense! So close!! :shock: :D :cry: :shock: :ghost:

Almost got it all...just need...mission reward redemption and mission log! Production & research are rollin', things are generally working, and I've got a pretty sweet system picked out for the update ;) Really hoping to begin recording ASAP, but, realistically, I'm probably at least a few hours out. Likely that the update will come out this evening. Pushing as fast as I can! :geek:

I really feel awful about the short logs the past few days, but what can I say...the code needs me!! :monkey:

As much as I hate these pre-update days for the amount of gray hair that they no doubt give me, I gotta say, these are my favorite days. Just flurries of fun and code. Livin' the dream :geek:

See you soon!!! :)

EDIT : Important!
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
Post

Re: Week of June 1, 2014

#2
Monday, June 2, 2014

Yes sir, yes sir indeed. I'm glad I took that extra day :) In the past day I've been able to:
  • Fix a long-standing issue with the logarithmic z-buffer, which caused some issues with near surface clipping since the very beginning
  • Inject a bit of planetary orbital asteroid field action, just for fun ;)
  • Finish a simple but functional HUD hardpoint display
  • Finish a simple but functional HUD log message display, plus re-write the logging system for better conceptual simplicity
  • Perfect the new color grading
  • Get the mission nodes to a point where they're functional enough to use!
  • Fix an issue with pulse lasers staying alive for longer than they should (don't know if you noticed some awkward lingering pulses in the last video :oops: )
  • Implement icon transformations to allow for compositing icons (for example, generating the icon for a blueprint from the icon of the item it represents)
  • Finish basic icons for most hardpoints + blueprints and assembly chips
We're in the final stretch here! Thanks to everyone for your patience :) Very excited about this month! Hope to begin filming within the next two hours.

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

Re: Week of June 1, 2014

#3
Tuesday, June 3, 2014

Whew! Just woke up an hour ago...what a sprint that was! :shock: You know how it goes...every month's update process gets more intense than the last... :shock: :ghost:

Response to the video has actually been more positive than I expected. As I mentioned, I was a bit disappointed in it myself (again, May just not having been my best month). But you guys are so nice :) Really looking forward to June.

I want to make some observations about the video:
  • Dust clouds are an eyesore when moving at high speeds. It's a result of the tricks that I use to render them cheaply, but I'm clearly going to need to develop something better.
  • At some times, the motion felt jerky or strange because the engine was internally changing the rate of simulation to compensate for higher CPU loads. When it does so, the latency between control and response increases, and all nonlinear elements of the game become slightly incorrect (because linear interpolation is used when the game world is being rendered at a higher frequency than it is being simulated). I worked a lot on this in May, but it's clearly still not perfect. The increase in latency and the nonlinear errors are subtle but jarring (especially in 3rd person). I need to work on this more.
  • Pulse lasers have always been annoying and difficult to get right in terms of spawning in the correct position (surprisingly hard due to order-of-simulation issues). It is much more jarring when the simulation frequency is being reduced, as per above. I need to make some small changes in the scenegraph architecture to correct this.
  • On a brighter note, navigating the UI is still a joy, even with a gamepad (which I used for much of this update). Feels very nice.
  • We all know the procedural ships need a lot of work. Their time is coming :)
  • In general, I just need to spend time on polish. Loads of small tweaks and fixes would go a long way at this point in time. The good news is that they are almost all small things!
  • The colors and general aesthetic are really, really good at this point in time I feel. They look even better in-game, without video compression! LT is a lovely place to explore...it really is :geek:
Now then! I have some exciting plans for my relaxation today :D It's been a while since I've had a good hike in the park. It's been a while since I've had some good Mexican food. On top of all that, I just bought Starbound because it looks really compelling, so I look forward to spending some quality time with another awesome, procedural indie space(ish) game! :D
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
Post

Re: Week of June 1, 2014

#4
Wednesday, June 4, 2014

Great day! Slept for more of it than I intended to... :cry: :roll:

I guess the high point was Starbound! I'll be honest, that's just an awesome game. Really inspiring to see how relatively simple mechanics & graphics can be put to such powerful use and coupled with proceduralism to deliver an awesome (and addictive :oops: ) experience. Loved every minute of it :clap: Played for many hours today! So much so that it never even crossed my mind to pay a visit to Vvardenfell. Do I feel guilty? A bit :oops: But I have faith that Almalexia will forgive me :ghost:

Other than that, I had the distinct and unique pleasure of capturing a rather large black racer (or something of that nature) that decided to pay my house a visit today. Not sure how he found his way in, but I guess he heard that there was going to be some exciting relaxation going on today. Poor guy just wanted to play some Starbound with me I guess :) Definitely the strangest thing to happen to me in a long time :shock: I would prefer if visitors give me forward notice in the future... :lol:

Well, what can I say...I'm excited for June!! That being said, I will still take half of the day off tomorrow, since I spent half of today paying back my sleep debt.

...or maybe that's just an excuse for a few more hours of Starbound :oops: :monkey:
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
Post

Re: Week of June 1, 2014

#5
Thursday, June 5, 2014

Oh man. I'm excited for June. It's going to be an intense month :shock: :ghost:

As usual, I spent the last half of the second post-release day doing my monthly planning. This month I'm going to be a lot more orderly and intentional about development than last month, which just kind of seemed to slip away. I've gone back to the trusty old planning tree and have tagged some important nodes with pretty harsh deadlines. There will be pain involved :shock: The major two focuses of the month will be, not too surprisingly...

Content, Content, Content

As I mentioned in update #17, we've reach a point where I feel nearly all of the fundamental algorithms that power the game are in place. With those puppies providing the power that sets everything in motion, it's time to start feeding in more content. That applies mostly for the AI and the player-side gameplay mechanics, but it's also about time to turn to the remaining content generating algorithms (ships...stations...). The good news is that this is always easier work. The bad news is that it's less interesting (IMO) :P Alas, not every moment of gamedev can be riveting.

Polish and Playability

I'm getting tired of prefacing everything in my updates with 'this is placeholder' or 'this is dev-ish.' Let's make that go away, shall we? Polish and playability will be a major focus for June as we prepare to take LT out into the world :)

---

Alright ladies and gents, here we go!!!

PS ~ During the first half of the day (the remainder of my day off), I decided to be crazy and just went out and bought a keyboard (the kind you play music with, not the kind you type on) (with non-KS money of course ~ don't know why I feel the need to clarify that, but so be it). I had a whole lot of fun already and I'm pretty sure it's going to provide an excellent release of stress for the month of June :D :clap:
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
Post

Re: Week of June 1, 2014

#6
Friday, June 6, 2014

Yes sir, June is already in full force :geek:

Externalizing Content

For so long I've been avoiding and beating around the bush when it comes to the topic of the data editor and modding. I've been able to get away with it, too, since modding is about changing the content of the game rather than the algorithms that power it (although, some content can still be functional :crazy: ). We haven't had much of that yet, so I've been able to get away with little placeholder pieces of content without actually formalizing any of it into a moddable data format.

I've got a lot of little pieces of this worked out. I showed the data editor quite some time ago. That demonstrated that I've got an architecture capable of introspecting on itself and modifying internal content data. Good. I developed the UDF data format for an easy but effective way to externalize this data in text format for loading, saving, and external editing. Cool.

But I'm still not totally ready for content. I think the last big hurdle here is functional data. Therein lies quite a beast. I need to actually be able to create and edit a piece of data that provides instructions for system asteroid placement, ship properties and model generation, item property generation, etc. I need data that describes function. That sounds a bit startlingly like a programming language :shock: But I've zero interest in going there or reinventing any wheels. I need to find the fastest (as in, least development time), most intuitive, and most flexible way to create function from data in such a way that the content algorithms can be made malleable.

Today I worked on that problem. I started to create expression structures that will be the way that the game encodes functional data. I've already got similar things lying around the engine, but none are simple enough to work well with the data editor (because they're all pieces of generic programming, meaning they're functions themselves which are called by the engine to create pieces of data that encode functions (are you lost yet? Me too :crazy: )).

Creating the expressions that will govern the content in LT is mostly a problem of structure. What's the best way, for example, to frame the problem of generating an asteroid field? Should we think of it as a function taking in a system and putting out a list of asteroids? Then we need lots of expression structures for manipulating asteroids (or objects in general). Should we simplify it and think of it as a function giving a list of positions, scales, and rotations? Something else? There are so many choices that would work, and they span a spectrum of generality. The key is choosing the level of generality that gives the optimal intuitiveness * flexibility product.

---

Personally, I'm very much looking forward to having this work done (which I hope to achieve within the next few days), as it will mean that I can feel much more comfortable authoring the content of LT.

I foresee a month filled with content :geek:
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
Post

Re: Week of June 1, 2014

#7
Saturday, June 7, 2014

I'm in the middle of some intense (but exciting) work and should be achieving my first results shortly...! :)

Exposing Internal Functions

I wrote a while back, when developing the reflection system for the LT engine, about 'function' reflection - giving the engine the ability to understand the properties of the very pieces of code that make up LT. Just as I am automatically able to expose data types in the data editor, so I can expose functions in a function editor (sound a bit like editing code? ;) ).

It's a bit harder because the function reflection system is less mature than the data reflection system. I have to do some more legwork before I will actually be able to call functions from UDF.

I've opted to go with a reflection-based approach rather than building those 'expression' structures of which I spoke last time. With reflection, I can maintain a unified, simple interface for function data. Everything should just work automatically, rather than requiring me to do any real work to set up the function interfaces. Well, that's the theory at least..it will be a few more hours until I can test :geek:

UDF : Mixing Data and Function

Yesterday, I mentioned all the craziness related to function / data and their differences. I've decided today that I want to treat UDF (the format LT uses to specify moddable data) as a functional data language. This means that, instead of specifying a data type, every UDF file actually specifies a function that generates a given data type. This paradigm actually goes beautifully with the very essence of proceduralism!! Proceduralism is all about leveraging function to create data.

Now, it gets pretty awesome when you start thinking about the implications here. A few observations: first, constant data is still easily-specified. You can think of constant data as simply calling the constructor of a type with constant arguments. E.g. Vec3(1, 6, 7) is calling the constructor function of a Vec3, and passing in 3 constant integers. It's really just data, but we can easily think of it as a function. On the other hand, consider Vec3(Rand(1, 5), 6, 7). Now we have a constructor being called with one non-constant parameter. This is no longer constant data - it's a function, and we can call it repeatedly to generate new vectors.

One of the fantastic insights that I had today was to think of every request for a T as being a function, rather than data. That applies recursively to every level of the data, not just the top-level. The above example demonstrates this: when you construct a Vec3, you require 3 numbers. But! We will actually construct and call 3 functions to generate those three numbers. Another way to understand that is that, in the game code, if we have a function F that takes an X and a Y (X and Y are types), then in UDF we will actually call F using functions that return an X and a Y. Again, those functions can be constant, but the point remains that we are thinking of everything as function. Very nice.

---

The flexibility afforded by this architecture should be insane. I'm almost foaming at the mouth just thinking about it. Best part is it should be working in a few hours, and I should be well on my way to content authorship :)
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
Post

Re: Week of June 1, 2014

#8
Summary of the Week of June 1, 2014
  • Implemented mission accepting, mission log, and reward redemption!
  • Fixed a ton of outstanding minor issues
  • Implemented a boatload of new icons
  • Enjoyed many hours of Starbound during my day off :D
  • Implemented first basic function calling in UDF!
  • Implemented new technology to expose engine functions to UDF
  • Survived the 17th development update (just barely :ghost:)
“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 2 guests

cron