Sunday, February 10, 2013

Summary

Slow Sunday alert Since Sundays are usually slow anyway, I took a lot of time today to catch up on things like emails, messages, interviews...all that fun stuff that coder Josh likes to pretend doesn't exist Naturally, I'm nowhere near caught up...and probably never will be. Nor did I finish either interview that I've got backlogged. But I made an effort, and feel slightly better about where I stand on non-coding things. Yay?

Well, let's face it, you guys probably don't want to read a boring dev log with not much excitement in it...and, frankly, there's not much excitement to tell about today...and I'd rather not write a boring dev log So, howsabout I see you tomorrow - same place, same time....more excitement?



PS ~ OK FINE, I'll admit it. Stop looking at me like that. Yes, I did it. I played some Morrowind today. I couldn't help myself. That accounts for a solid 2hrs of missing time. I'M SORRY. But not really. Very few things in life inspire me as much as Morrowind does. It feels so good to be inspired by games...I hope someday LT will have the same impact on someone out there!!!

Hour Tally

Coding: 2.72
Composing: 1.35
Internet: 3.50
Testing: 0.51
Thinking: 0.64
Total Logged Time: 8.72

Monday, February 11, 2013

Summary

Well hi there, I guess you're looking for some excitement, as promised yesterday?

Good news: there was a lot of excitement today!!! Instead of rolling around in abstractions as I've been doing lately, today I took some advice from myself - "shut up and code, Josh." So I did. And as a result, those cap ships are looking far more intimidating thanks to the now-orderly swarm of escorts! That's right, we have formations!

I decided it was a pretty dumb call to make an editor before actually implementing formations. Why did I think I needed to do that? Isn't that kind of...backwards? I mean, I certainly didn't implement the ship editor before implementing ships. Besides, implementing and playing with formations will give me a much more concrete grasp on what is needed to edit them.

Speaking of dumb things - I think I recently mentioned how formations are actually related to the interesting problem of producing a good sampling pattern on a surface. Why didn't anyone slap me and say "Josh, they're just bloody magnets"??? I should have realized the moment that I looked at formations that they were most elegantly solved by point-repulsion! Simple. Ready for the best part? Defining a formation is scarily similar to...that's right...defining a scalar field! Actually, defining a formation now consists of defining a vector field - a higher-dimensional cousin of our beloved scalar fields. It's a little creepy to think that similar technology is doing the models, the physics, the icons, and now...formations!? Sheesh, I guess soon these scalar fields will be doing my PR and marketing for me?

With this revelation in hand, I was able to quickly implement spherical/oval, box, and line formations, just as simple tests. They all work great! Best of all, under a point-repulsion model, they automatically find a nice configuration regardless of how many ships you have. 5 escorts or 100, it's all the same to this system, and the formation will look great either way.

In other news, I am slowly killing the command interface's code and replacing it with the result of all this "thinking" time I've been having lately. I must admit, I'm pretty excited and pleased about the fact that all of the "displays" in the game are now unified. I only really have two more hurdles to overcome: post-processing (gotta make those holograms glow!) and world-space icons. The former is more of a technical matter, and probably won't be bad. The latter is tough: I need an elegant way to model the fact that a ship, for example, should display an icon when viewed by something like the command interface, and, moreover, that this icon should have certain behaviors at a distance, on mouseover, etc. Not that it's a hard thing to do, but you know how I am about doing things simply/elegantly...

Another exciting day ahead?? Let's find out...

Hour Tally

Coding: 7.03
Composing: 1.12
Internet: 1.73
Testing: 1.40
Total Logged Time: 11.27

Tuesday, February 12, 2013

Summary

Not as exciting of a day as I was gunning for...but I'm going to go ahead and attribute it to the fact that getting a new phone took 2.5 (!!!??!) hours out of my day. Still, it brings my technology level back to the current decade's (interestingly, for a computer nerd, I am surprisingly low-tech, with the exception, of course, of the computer).

Yesterday, I talked about implementing icons in a clean way, and I did the preliminary work on that today. I've gotten as far as replacing the previous icons from last week's work with a new, more elegant system that does the same thing, so that's a great start! This time, however, there's only really one line of code in the command interface (as opposed to ~100), and the real work is done at the object level, which is my preferred style of organization.

Ultimately, everything that I'm doing right now is leading up to the formation editor, which will no doubt be one of the more impressive in-game interfaces. If it can be implemented simply, then I think any future interface will just be..all too easy!

Tomorrow I really want to nail post-processing inside UI viewer widgets, which will be the last and final step that I need in order to replace the normal rendered view of the game with a UI widget that does the same thing. Although this won't have any tangible effect, it's a pretty awesomely-clean architecture: your view into the game is just a normal UI widget like anything else, not some special-cased rendering view that has code written specifically for it. To make sure that this gets done, I'm telling you all about it, so you can hold be accountable If I don't have this done by tomorrow's dev log, then you can consider me, all of my work, and this whole project a failure. Demand a refund, email me death threats, freeze me in carbonite, etc. Yes, I do work well under pressure

Hour Tally

Coding: 5.01
Internet: 2.20
Testing: 0.97
Thinking: 0.93
Total Logged Time: 9.11

Wednesday, February 13, 2013

Summary

Carbonite time I guess....

Just kidding!!! Today was a fantastic day!!! Yes, I made good on my promise, and finished post-processing on UI views. But I did a lot more than that, as, I am very happy to report, I had a lovely revelation today about the rendering architecture. In particular, I finally figured out how opaque/transparent views, holographic views, icons, particle rendering, postprocessing, and more can all fit together in the same architecture in an extremely clean way. Perhaps more importantly, I finally realized how and why all of this can be totally separate from the thing that is viewing the world (the viewer/eye/camera).

Thanks to these revelations, I am finally really pleased with the rendering architecture! Not only is it effortless (as in, one line of code effortless) to perform things like blooming, vignetting, antialiasing, etc. in any UI widget, but it is also equally effortless to specify, for example, that the command interface should show a holographic view of the world, with a faded-out starfield in the background, plus a glow effect on top, and, finally, ship icons on top of all that. I think the graphics code in the command interface is about as tiny as it's going to get (the bulk of it consists of about 5 lines).

So yes, today was a fabulous day I've been searching for the right solution to these problems for a long, long time. My search for the right solution to the "opaque vs. transparent" rendering problem dates back to, literally, the first month of LT's life, and has been solved today. The icon problem dates back a few weeks, as you can probably remember. It has been solved today. The problem of post-processing inside alternate views was nothing more than a dream a month ago (I assumed that I would never implement something so fancy), and it has been solved today. What a great day

Sorry to disappoint those of you who were already drafting those death threats or contacting Cloud City to arrange a freezing procedure. Maybe next time

Hour Tally

Coding: 7.39
Composing: 0.09
Internet: 2.73
Testing: 1.20
Total Logged Time: 11.42

Comments

Thursday, February 14, 2013

Summary

Lukewarm day, although I'm embarrassed at my hours for this week Honestly guys, if anyone figures out how to create more hours in the day, I'm all ears

Riding on the glory of yesterday's rendering engine advancements, I spruced up the command interface in countless ways. I'll be honest...it's looking pretty good I got a lot of positive feedback on it from January's video, which I was rather surprised about, because it was still extremely rough in that video!! If you liked January's command interface, I think you'll love February's A neat graphics advancement that I slapped together today was motion blur. It took about 15 lines of code to implement with this new system. Well, that was easy...! It definitely adds a cool, subtle feeling to the command interface. I like it.

I then proceeded to continue working on my icon system, creating new mathematical shapes, and using them to define icons for each of the ship classes that I have tentatively laid out. Overall, I'm actually really pleased with the look of them! They're all simple shapes - circles, rings, and wedges. But they get the point across, and I don't think it will take long for you to start recognizing and fearing the battleship icon Larger ship classes obviously have larger icons, but, more importantly, the icons for larger ships are also more complex. A fighter is a simple dot - kind of what you'd expect. Go all the way up to a carrier, and you've got the same central dot as a fighter, but now surrounded with a ring, overlayed with four radial wedges. The ring denotes capital ships, and the four radial wedges signify that the carrier is the largest of the capital ships (although there is still one larger ship in the game ). The two smaller capital ships have just a ring, then a ring + two radial wedges, respectively. I think you get the idea - the icon visual is strongly tied to the class of the ship, which should help you quickly and intuitively identify ships on your radar. I really like the radial shape look, I think it's sleek, simple, and gets the information across with no fuss.

Not surprisingly, I've had the prototype on my mind a lot lately. I'll be honest, getting it out it March is going to be a challenge, but I'm grinding as hard as I can to do so. The good news is that, even if it takes slightly longer than that, I'm going to be delivering substantially more in the prototype than I initially planned for. Yes, it will still fundamentally be a combat prototype. No trading, no landing on planets, no inter-system travel. Nonetheless, it will be more than just a deathmatch arena, which was really my initial intent - barebones, nothin-but-combat. After doing some thinking today, I realized that combat alone, taken out of any context, seems very hard to make fun, so I'm thinking the prototype will be more than just a deathmatch arena. I'll leave you with that, for now

PS ~ New category today, "Responding" - I was responding to an interview. Finally finished one that I had backlogged, with one more to go, hoping to get it done tomorrow. I've decided I should get to log these hours though, as they really do take a chunk of time.

Hour Tally

Coding: 4.01
Internet: 2.91
Responding: 1.39
Testing: 1.65
Thinking: 0.92
Total Logged Time: 10.87

Friday, February 15, 2013

Summary

Today was an excellent and productive thinking day!

As far as code goes, the day was fairly uneventful: I reworked a bit of the rendering engine to change and simplify the way that rendering to a viewer widget works. It's now far cleaner, but I paid a slight performance cost for this cleanliness. Well, at least, in theory I did...but benchmarking afterward yielded no visible slowdown, so that's great! I'm absolutely thrilled with the past few days' advancements, now that it takes only a few lines of code to set up an interface widget that displays a beautiful 3D world

The rest of the day, however, I spent whittling away at a few difficult thinking problems. I think I've just about got the solution to most of them! The first is concerning objects and how they are represented by the game. Consider a weapon. If the weapon is attached to your ship, then it's got quite a good bit of data attached to it: how long before it can shoot again, how damaged it is, what direction it's pointing in, etc. That's the most detailed representation that a weapon can possibly have. Now, on the other end of the spectrum, there are weapon "types," which are the opposite: they're the most abstract representation that a weapon can possibly have. They just define the properties that are common to every single weapon of this type ever. In-between, however, there's this strange land that we need to define in a game in order to be efficient. Consider weapons that are in your cargo, but are not equipped. It would be horrendous to store things like direction, position, remaining cooldown time, etc. for these weapons. They're in your cargo, you're not using them, so why would you store all of that! On the other hand, you do need to store more data than just the type. What if the particular weapon is damaged? We need to remember that, otherwise repairing would be as easy as un-equipping a weapon then re-equipping it! We might also want to know things like to whom the weapon belongs (perhaps it is stolen), if it has been upgraded in some way, etc.

So the question is: how does one handle this fact elegantly? By elegantly, I mean that there should be a formalized way of reasoning about and distinguishing these "lite" objects from their full-blown versions. Furthermore, code that deals abstractly with these objects (i.e., does not care about position or something like that), should be able to operate on either the full or lite version without requiring duplication. It's an interesting question, and I have a few solutions. Unfortunately, this is one of those questions that does not reflect a deep question from reality...it arises because we need to optimize. In reality, every instance of an object is a full instance, whether it's in your cargo hold or attached to the ship. I guess in a decade we'll have enough RAM to not have to care about making these kinds of optimizations, but for now, I've run some numbers, and it's necessary. It's a shame, because I'm not big on solving organizational problems that don't have any real-life meaning.

Another big question in my mind today was the ship interface (displaying hardpoints, power distribution, cargo, ship stats, etc). Finally, I think I've come up with a design that I like. Sadly, it will require a bit more interface technology than I've got at the moment, which led me to my next logical question: how to cleanly handle draggable / droppable widgets in an interface. Naturally, I want to be able to drag weapons directly from cargo to hardpoint slots when I'm docked, as it's definitely the most natural way to equip a weapon. Drag/drop isn't trivial functionality, though, although I think I'm converging on a clean implementation

On the music side, I'm still trying to figure out how to get the blood pumping. I can do ambient pretty well, and I'm decent with suspense. But when it comes to full-blown combat music...I'm having a lot of trouble getting something nice. If you've got some game combat music that you particularly like and that you think would be helpful for me to study, post a link!

Hour Tally

Coding: 5.32
Composing: 1.32
Internet: 2.17
Testing: 0.74
Thinking: 2.10
Total Logged Time: 11.65

Saturday, February 16, 2013

Summary

Today's story was one of war, triumph, misery, sadness, lust, virtual inheritance, and partial template specialization (...??).

In the wee hours of the morning, in the name of the Royal Limit Theory Kingdom, I declared war on several provinces of the great empire of User Interfacia, under information from my most esteemed double-agents that some unwelcome codebloat fugitives were hiding there. We sent all our best men into battle. After slaughtering several hundred lines of the enemy's codebloat soldiers (they were more numerous and well-armed than we anticipated...), we had vanquished the small insurrection. The battle was over. Another easily-won war, I thought to myself. Ha. Was I in for a surprise.

Midday was enjoyable. It brought the sweet fragrance of dragging and dropping. Yes, I said yesterday that I enjoy such things. Today, I ordered my finest gardeners to sow seeds of draggings and plant trees of droppings, and, as a result, reaped a bountiful harvest of a clean, drag-and-drop-capable interface implementation. The result was glorious, and I had marvelous fun as I gleefully dragged around things that no man should be allowed to drag (like buttons and text labels).

And then night came. We were unprepared. No one saw it coming. How could they? How could I have known? I had received word from my scouts that a few of the villagers in our very own RenderEnginasia province had become disease-ridden, carrying the dreaded code duplication disease. I had seen it many times before. Usually a simple cure - just a quick application of the old mage's remedy of deep thought and refactoring elixir. I thought this time would be no different. I couldn't have been more wrong.

I'll spare you the gory details. I haven't the time nor the stomach to recount the hours of my night. Suffice it to say that the remedy, this time, was an implementation of what one could call a generic programming system, in which the archer shooting his arrow cannot be sure that he is holding a bow, nor that such a thing even exists in the world, but rather, that he does have some apparatus for firing an arrow, whether it be a bow, modified M16, or carrier pigeon. Winning this battle was not easy. The enemy took from me numerous hours and brain cells as they washed over my land with hundreds of cryptic compiler errors. But in the end, we won.

All laborious medieval-speak aside, I'm very happy with these developments. As difficult as this generic programming/generic types system was to implement (it requires dealing with many of the more esoteric features of c++), it now allows me to very easily create functionality where I say "I need an X, I don't care how you give it to me or where it comes from, but as long as I get an X, I'll be happy." It's a bit more involved than that, and perhaps harder to explain, but the basic point is that pieces of code can be agnostic to data details in a very clean, general way, without requiring any extra work from pieces of code that already use them in a straightforward way. The underlying problem of how to set and retrieve data arises in many places. For example, when you set a variable in a shader, you may just pass in a value, or perhaps you want to give a callback function that will be evaluated when the shader binds, or perhaps other, more complex possibilities. The point is that it's extremely useful to be able to specify different ways for the shader to obtain data, and doing so in a general and powerful way saves a whole lot of code later on down the line.

Yeah, sorry, that dev log was kind of all over the place

Hour Tally.

Coding: 8.35
Composing: 1.40
Internet: 2.26
Testing: 0.62
Thinking: 0.09
Total Logged Time: 12.72

Week Summary

General Sentiment

On the surface, it looks like a pretty uneventful week - but it's hard to put a price on the handful of conceptual breakthroughs that I had this week. I'm really happy with my new style of increased thinking time and less coding time. Even though I logged less than 5 hours of pure thinking time, I could certainly feel a difference in the quality of my work thanks to having concrete plans drawn up before touching the keyboard. In some cases, just working on the paper allowed me to see simplifications and opportunities for elegance that I think I would have missed without dedicated thought time. I'm going to continue to push this style, hopefully converting even more of those coding hours into thinking hours in the future.

On the technical side, I'm just ecstatic about how beautiful a lot of the code is looking with respect to the rendering of the world and the interaction between rendering and the interface. But the thing I like about this beauty is that it's not just a theoretical beauty - the beauty of this code translates directly to the beauty of the game and interface! I'm already able to create awesome 3D displays in interfaces, the likes of which I never would have thought I'd be able to do (especially so early on in development).

Major Accomplishments

• Implemented preliminary formation mechanics + a few basic formations
• Implemented icons and icon rendering (procedural/math-based, of course!)
• Implemented drag-and-drop functionality for interfaces
• Implemented motion blur
• Created icons for all ship types
• Created concept for unified ship interface, started implementing
• Dramatically changed the way that the rendering pipeline works internally, with a huge improvement in cleanliness, and the added benefit of allow post-effects in interface widgets

Combined Hour Tally

Coding: 39.83
Composing: 5.27
Internet: 17.50
Responding: 1.39
Testing: 7.09
Thinking: 4.68
Total Logged Time: 75.75