Sunday, March 17, 2013

Summary

Alright, this week has started out strong...let's hope for an awesome week!!!

First order of business today was wrapping up keybindings / configurable controls. As I mentioned last week (or was it the week before last?) I implemented the internal machinery for formalizing the notion of a key binding, but never implemented any kind of interface support for customizing them. Today I tackled that problem, so now the controls can be modified freely via the settings menu. If Shift-Alt-Z is how you like to thrust forward, hey, who am I to judge Go for it.

I thought a lot about stations/planet locations and player storage today. The problem stemmed from a much simpler one: when you complete a mission, how do you obtain your reward? In Freelancer, the problem is completely skirted, since rewards are only in credit form. Well, that won't really suffice for LT, I'd much rather offer a wide variety of rewards. Maybe you see a mission that has a really nice turret for a reward, the likes of which you've never seen on the markets. Maybe the reward is the ability to call in a favor from a powerful wingman. Varying up the mission rewards will be a great way to keep them interesting and keep the incentives high for running missions, which will obviously be a big part of the game. But suppose the reward is a weapon. Does it get transferred to your cargo when you complete the mission? Surely not. Does it get left at the location where you took the mission? Where? In a postal box with your name on it? Storage space? Hanging in mid-space?

This sequence of thoughts led me to the conclusion that we need to have "storage" on locations (kind of like EVE). This makes a lot of sense: for one, you're going to want to drop off your loot at a station and not have to carry it all around with you. But it also yields a natural and elegant way to accept rewards for missions: they just go into your storage at the location where you took the job! It also yields a natural way to receive whatever goods you buy at the local market (especially if they won't fit in your cargo hold). I believe that I'm going to implement it such that you have to buy storage space, but once you buy it, it's permanent. You can always upgrade your storage space at a given location later for a fee. For example, really busy stations in the middle of heavily-traveled space might charge 1000 credits per tonne of storage (storage and cargo will be measured in mass; we will assume that volume limitations have been overcome by some sort of spatial compression technology), whereas a station on the edge of inhabited space will probably give it away for 50 creds per tonne or so. There may also be a limit to the amount of storage space you can purchase at any given location, dependent on the size of the location. I think this all makes sense. The only remaining question is whether you should have to pay a recurring fee - but I think that introduces too much "non-fun" complexity. I don't want to have to worry about whether my stuff is going to get repossessed because I forgot to make it to the other side of the galaxy to pay my storage fee. Boring. But I do like the idea of not just getting infinite free storage wherever you go. Getting to dump all your stuff at home base should be a reward, not a given! If you have major problems with this system, or you like it, or you'd just like to yell at me for no reason, feel free to do so in suggs.

Now then, with all that out of the way, I have a very somber confession to make to you all. Today, I must admit, I wasted some time delving into a new field of procedural goodness into which I have no rightful business poking my nose. But I just couldn't help myself. It was calling my name...and since I've never, not once in my life, done procedural synthesis of sounds, I had to try it at some point or another. So today I indulged myself. Today I finally did that magical thing of filling up a sample buffer with mathematical goodness, and hearing it come to life via these little vibrating membranes in my computer Man was it exciting!!! Naturally, I can't produce anything of value yet...my sounds are worse that 8-bit chiptunes. But I now know how to create sound with equations, and that's super-exciting! I never should have touched this, because there's just no way that I could learn enough in time to make procedural sound in LT. But someday I will learn how to do it at a high level of quality!

Hour Tally

Coding: 6.03
Composing: 0.29
Internet: 2.91
Testing: 2.14
Thinking: 0.78
Total Logged Time: 12.15

Comments on storage space.

Monday, March 18, 2013

Summary

I didn't initially intend for it to be, but it ended up being one of those performance optimization days...again! Not at all a bad thing. There are a few things that I'm feeling more comfortable about after today.

First off, the universe generation technology. It's slow, folks. Real slow. Building those high-resolution backdrops is very costly (~30 seconds on my laptop at 2048 resolution, which would be considered "high" quality). There's a whole lotta math that goes into those things, and even a strong GPU is going to feel some pain when computing them. Today I put on my shader optimization hat and took a crack at making that puppy faster. I had pretty good success, because it now takes about 15 seconds on my laptop. 100% performance gain, not bad (although the best kinds of performance gains are the order-of-magnitude ones..!) I've still got plenty of time to make this thing faster (the universe generation technology isn't going to be part of the prototype, since it's not relevant to combat, I will pre-package one or maybe a few systems for that). 15 seconds is bad, no doubt, but if we put that in the background on the engine's GPU scheduler, and allow the scheduler to run at 20% power (i.e., incur a performance hit of 20% so that the scheduler can run background jobs), then this would translate into roughly 75 seconds to generate the background. That's actually approaching a reasonable value: if you assume that the player will stay in a given system for a few minutes, then we're in good shape (assuming we can accurately guess which system then will go to next). If they start jumping to new systems every 30 seconds, then there might be some loading screens involved...but you'd have to be one heck of a scout to be hitting a new system consistently in under a minute! With some more optimization, I'm hopeful that I can get that down to < 10s. I'll be happy with that.

Next up, that darn sound engine. I swear, if it's not one thing with the sound engine, then it's something else...always something. With these 50-ship battles of late, I've been noticing some pretty serious performance problems when the sound was turned on (but no problems at all with it turned off). Now, I know it's not my code causing the problem...sure enough, a bit of profiling reveals that irrklang is being a sloth when it comes to updating volume and pan (which I have to do every frame since I'm computing the spatialization manually, as described a while back). I have no idea why it would take a long time to make those super-simple calls Luckily, the problem is easily solved via multithreading. So today I multithreaded the audio engine so that one thread can sit there and hold irrklang's hand while it takes forever and a day to update those values, so that the main thread doesn't have to stall the rest of the game.

Not really related to optimization, but I dramatically improved target trackers today (those things on the HUD that show you where to aim if you want to hit that guy). By dramatically, I mean A LOT!! They're deadly accurate now, and if you have a good weapon, and you aim where the tracker tells you to, you're gonna score a hit. Simple as that There were a few subtle details that I left out of the equation the first time. Namely, I didn't consider my own velocity. But if you're flying a fighter, then your own velocity is at least half of the story. To accurately predict where you need to aim, you need to consider both the fact that the effective speed of your projectile increases by the parallel projection of your velocity onto the direction in which your weapon will fire, as well as the fact that your velocity is basically subtracted from the enemys. With these two corrections, it would seem that the prediction is dead-on

Thanks to all for the good discussion on storage space today, I'm taking everyone's opinions into consideration

Hour Tally

Coding: 6.24
Composing: 0.60
Internet: 2/72
Testing: 1.16
Thinking: 0.56
Total Logged Time: 11.28

Tuesday, March 19, 2013

Summary

Quite a productive day, hoping to keep up this pace for the rest of the month. Almost all of today was devoted to the market interface. I'm sad that it's taking so long, but let's face it, buying and selling is a pretty big part of this game...so at least I'm knocking out a big chunk of work early on. I've finally come up with a layout that I like reasonably well for the market. This layout scales well and allows you to, for example, compare the details of several items at once in an intuitive way. Buying is also intuitive. But selling? Selling I have yet to figure out. Originally I was thinking drag-and-drop for everything, but I quickly realized that it's not as intuitive as just having a fixed-position slider and button....at least for buying. But for selling, it's a little different, because the item isn't in one place. It might be coming from your cargo, storage, perhaps even another ship. I still haven't figured out how that should work logistically. Thankfully, that's the last piece standing between me and the completion of the market interface, and I hope to figure that out tomorrow.

A pretty big change that I made to the interface today was implementing logic to dynamically update interfaces that are subject to change. For example, your inventory - if an object gets removed from your inventory while you're watching it, then the corresponding widget needs to be removed accordingly. That's a pretty tricky thing to do. The lazy way, which I took up until today, is to simply recreate the whole interface every time you detect a relevant change. For many games this is the right choice, as it will usually work just fine. But not for LT. LT's interface is completely dynamic and animated in ways that most game interfaces aren't, and the result is that recreating the interface produces a noticeable "re-growing" of whichever widget was repopulated. So it forces me to adopt the most painful, thick-chest-haired solution: fully dynamic tracking of the widgets and removal/additions that correspond exactly to external removals/additions. Just takes more code, but of course, it can be done, and now it's done

I had a lot of good thoughts today concerning how to calculate the base value of items, which led to a painfully-broad exploration of game balancing from the mathematical point of view. There were a lot of quality thoughts, but I definitely raised more questions than I answered. I'll try to approach game balance from the same standpoint as I would anything else: with math and logic. I could probably spend an hour or so giving you a treatise of my thoughts today, but I'll save those for another time, because I'm not feeling up for that kind of brain dump at the moment! Here's a very abbreviated summary: humans have no concept of absolutes, we only measure change, which is why games must continue to provide the illusion of increasing power / value / ability to gain value, which leads to the concept of "my ability to produce value is proportional to my value," which is the classic feedback loop that appears everywhere, and is formally modeled by the differential equation y' = y, whose solution is the exponential function y = e^x, which grows far too fast and is intractable, which is why most games fail to maintain interest for long periods of time. However, if we cheat it a little bit by, for example, making ability to produce value proportional to the root of value (y' = sqrt(y)), then absolute value becomes much more tractable, as, surprisingly, the solution to this differential equation is y' = y^2, which is polynomial and far more reasonable than exponential. This boils down to saying that we need value to scale nonlinearly with quality. I.e., a weapon that is twice as "good" must be more than twice as expensive / hard to find / whatever metric you want to use to keep the player from getting it, otherwise the game will not remain fun for very long. Yes, that was a very abbreviated version

Can't believe we're over halfway through the month Gotta slow down time people!! Help me tug at it!!

Hour Tally

Coding: 7.21
Internet: 2.43
Testing: 1.89
Thinking: 1.56
Total Logged Time: 13.10

Wednesday, March 20, 2013

Summary

Moderately good day. I finished the market interface (or, at the very least, a "preliminary version" thereof) today! Buying, selling, it's all there I also added a selection box that allows you to choose where purchased goods are delivered (storage or cargo). This can be expanded in the future to more advanced options like having things shipped to certain places (especially useful for remote orders).

Next up was cargo transfer - the ability to move stuff between whatever stuff-holding places you have available. Currently the only places that exist are storage and ship cargo, but I can imagine there being more in the future. This is definitely the right place to use drag-and-drop. Using it for buying/selling would have been a little bit sketchy, but here it makes total sense. You want to move a weapon from your ship's cargo to your hangar storage, what better way to do it than to drag the corresponding widget from one container to the other? This system took a little more work than I was expecting to implement. The only other place where I used drag-and-drop so far was in the hardpoint boxes, to allow fitting of weapons. But the system was a little messy, and it needed improvement. Things are looking much cleaner now! The implementation will work regardless of what containers are available, it's not at all specific to cargo/storage, but it does allow one to transfer between those location.

Drag-and-drop transfer of cargo, however, led me to one final problem, and this one I have yet to solve: the ship viewer needs to fit in with the rest of the interface. It used to just pop up and lay on top of other things as a sort of individual window. This is in stark contrast to all of the other new interfaces, which are implemented either as stacked horizontal bars, or sliding vertical panels that fit snuggly into the other widgets. Since the ship viewer blatantly ignores the other widgets, it ends up occluding them in some cases, making drag-and-drop impossible, because you can't see your storage container. I've known for a while that I was going to have to do something about this problem, but I haven't managed to figure out a good solution yet, even after some serious thought today. I re-implemented it as a vertical panel, but, as I expected, it just doesn't look as good. I'm still working on trying to find a layout for the viewer / cargo / power configuration that looks good, feels good, and fits in naturally without occluding other widgets. Spent quite a bit of time online today looking at other game interfaces for inspiration...but still haven't found anything that resonates with me.

Tomorrow, I'd really like to hit missions as hard as I can. The current implementation is pretty incomplete. I need better notifications of mission acceptance / completion / failure, I need rewards, and I need a better job board for perusing missions. Surely all of this can be done in a day... ? Bonus points for also implementing a wide variety of mission types. Ok Josh, you've been given your mission of implementing missions. Complete it and I'll...well, wait...rewards aren't implemented yet. Well, just do it anyway.

Hour Tally

Coding: 6.84
Composing: 2.67
Internet: 2.73
Testing: 1.24
Thinking: 1.14
Total Logged Time: 14.63

Thursday, March 21, 2013

Summary

Didn't get quite as much done today as I would have liked...but packing up all my belongings took a little bit longer than I anticipated. Packing?? What? Yes indeed!

So it turns out that I'm actually moving tomorrow. Not in the usual way that I move, like moving to the refrigerator to get a meal or a Diet Coke, or moving from my bed to the computer chair to start my workday, but rather, the intense kind of moving, where boxes and packing materials are involved, and long, cross-country car drives test one's patience, and so on. Tomorrow I'll be moving to Tennessee, where I'll be spending the rest of the development time!! I'm super excited about the move. TN is my favorite place to work, because it's chock-full of natural inspiration, and overall just a fantastic place for creative thought and secluded working. It's also the place where LT was born last summer!

Ok, but back to what I did today. I guess the biggest part of today was reworking the job board interface. It looks much better now! In the process of doing so, I had to spend some time implementing a new UI widget type, the multi-line text box (which is surprisingly-complicated compared to a normal, one-line piece of text). I've needed to do that for a while, but have put it off until today. But mission descriptions are no doubt going to be longer than one line, so I finally sucked it up and put in the time. Speaking of mission descriptions, I started thinking about / working on the foundation of a natural language system today for generation of things like mission descriptions. It's an interesting problem to generate descriptions for missions, because, really, it lies at the center of a thousand different questions. How are missions generated? Who is posting the missions? What is their motivation for doing so? How much does the player need to know? Of course, for the first two questions, the answer, ideally, is that the missions are natural consequences of needs that arise in the AI, and the missions are posted by individual NPCs or whole factions in order to fulfill a need. But how do you take something like "[Predicate: Safe <Ship @ 0x10F800>]" (internally, this is the kind of thing that the AI is thinking about) and make it into a description? Well, converting it into "Escort the given ship" is easy...but what about "We need you to escort our convoy to the waypoint. We've been monitoring pirate activity in the system for some time now, and don't like the odds of a lone freighter, so we're bringing on a few wingmen in case things get hot. Keep your eye on the nearby asteroid belt, as our intelligence would seem to indicate that a hidden smuggling base therein is generating a strong pirate presence in the area." Now that, my friends, is a bit of a tough problem I've certainly not even come close to solving it yet (then again, I haven't tried), but I'm slowly laying down the foundation for the language processing that I'll need to be able to create that kind of fluency from the AI. I hope to see descriptions of that caliber for missions at some point!

Tomorrow, I won't be able to work because the drive from here to TN is ~11hrs, so I'll be on the road most of the day, and probably unpacking for the rest. If I don't post a log, it might be because I don't have internet access, but if that's the case, I'll get it sorted out ASAP. So the point is that tomorrow's dev log is an iffy afair, but there should definitely be one soon after, if not at the usual time tomorrow.

Can't wait to get to my new residence and get in the zone...I have a great feeling about this, I think it's going to be just what I need for a strong finish to the prototype!

Hour Tally

Coding: 5.81
Composing: 0.27
Internet: 1.75
Testing: 0.44
Total Logged Time: 8.27

Friday, March 22, 2013

Summary

A very intense day of driving (I suffered what seemed to be monsoon weather for the first 4 hours or so...), but in the end, I made it. Regrettably, I was unable to perform any real deep thinking concerning LT while driving, as I found it excessively hard to concentrate on not hydroplaning while simultaneously trying to think about gameplay design. You can probably guess which one I chose to focus on, which explains why I'm alive to write this log right now

I'm really happy about the move, the only caveat is, it turns out I don't have internet at my new residence. Actually, I have neither internet nor a mailbox Indeed. Country life can be a bit of a shock. But both of these things can be amended soon enough. Until then, I'm going to make my internet time as scarce as possible (which, in all honestly, is probably a good thing, for the most part). For the time being I'll be using my phone-generated hotspot to write the dev logs, since doing so doesn't use up too much data. Gotta stop using so many smileys though, they probably cost a few kb each Oh well, I think it's worth it I hope to get internet set up within the week. Definitely going to need it to upload a 1080p update video...

With any luck, tomorrow will be a normal work day, although there's still some unpacking to be done. Now then, time to see what kind of magical coding inspiration these beautiful mountains can induce

PS ~ I'm sorry that this log had nothing to do with LT Better to document the happenings than to skip a day completely, I think.

Saturday, March 23, 2013

Summary

Yes, yes, and more yes. I think this place is going to do nicely Only one day in and I'm feeling the motivation kicking up a notch. Today was great, even though the hours weren't at the usual level (I spent several hours getting things set up and getting groceries). I can tell that being here is going to really encourage my codethinking balance, as it's so darn nice outside, it's almost impossible to resist going out and walking around. Which happens to be a great time to do some deep thinking, and I must say, the thinking is going very well! Somehow, I keep forgetting how important it is to think before coding, even though I say so time and time again. But here I won't be able to forget.

The first order of business today was fixing acceleration gates. As embarrassing as it might sound, I've been struggling with those darn things from day one. They seem simple enough, right? Just big rings that propel you forward...well, they're actually trickier than you think to get right. If you want to do it "the right way," that is. The problem is with collision. Intuitively, the way you want to implement acceleration gates is by causing any object in contact with the gate to be accelerated. Duh? Yes. Ok. But what about the final gate? It needs to be a special "stopping" gate, to bring objects down from their high speeds. Without a stopping gate, the acceleration lanes are really no more than planetary splatter cannons. Where the thing being splattered is you. Great, so let's just make the final gate a big de-accelerator. So you code that up, and, low and behold, even with the stopping gate, somehow your acceleration lanes are still acting as Planetary Splatter Cannons. Hmm. The problem is in collision. You've probably heard before that we programmers have trouble with fast-moving objects. Indeed, they are problematic, because we usually like to implement things the lazy way with respect to physics, meaning we perform discrete collision detection rather than continuous. In discrete collision detection, we only check the current state of the world each frame for collision, disregarding whatever happened in between. For slow objects, this is no problem. For someone being accelerated at high speeds through a lane, it means that one frame they'll be on one side of the stopper, the next frame they'll have cleared the other side, and our dumb little physics engine, much to the chagrin of the poor pilot being hurled at breakneck speeds toward an increasingly-threatening-looking sphere of solid rock, does not realize that the stopper and the ship ever interacted. That's only one of the many problems that acceleration gates breed, but I'll spare you the rest. Here's the point: I had enough insights today to finally implement them cleanly, correctly, and robustly, so that you'll never find yourself comfortably buried in the mantle of the planet on which you were hoping to do business.

As a side-effect of implementing gates the right way, I now have the internal machinery to handle things like temporary boosters (recharge batteries, shield boosters, ...), special weapon effects (draining capacitors, inhibiting warp, ...), and the like. Cool!

Although it took a few hours of work, it's not interesting enough to go into detail about, so I'll just throw it at you in all caps and move on: SCROLLBARS. Bam.

Now then. Fleets/squads/formations/groups/I-don't-even-know-what-we're-calling-them-anymore. They are a problem. They confuse me. Every time I start thinking I'm ready to crack down on them, I realize that I have no idea what I actually want. This is a problem. Another solid hour of thought today revealed one major thing: I need to simplify. I need to start thinking about how people would want to control their fleet most of the time. I realize that everybody has huge dreams for fleet control and the insane level-of-detail that could be feasible in a game like this, but I really need to optimize for the most common cases. The most common cases are going to involve one pilot in one ship. Expanding that to a few pilots in a handful of ships covers even more ground. 100 ships hierarchically arranged into 8 levels of sub-fleets with distinct orders, target priorities, and formations, being assigned and reassigned by a commander who is 2 systems away, and attempting to escort and join up with a trade convoy in an entirely different region...this is probably not the right case to be thinking about right now. It's great to think about the full magnitude of complexity, but right now, the simple cases must be hammered out. So for the time being, I'm going to focus on what I think I'll personally be doing the most: simple, RTS-like control. I.e., grouping via dragging & clicking, assigning groups via control key + number, assigning a formation via an option box, etc. Let's get that implemented, get the game feeling smooth & robust in your standard RTS way, and then, later on down the road, we can start piling stuff on top of that. But right now, I need to stop thinking about things in such complex ways! The same goes for all systems, but for some reason, I've been really bad so far about getting caught up in complexity with respect to fleet management. Long story short, today I sketched up the basics and finally hammered out a lot of what I want things to look like, and also went on to implement the grouping system (which replaced the previous, primitive grouping system that was built in to the command interface).

Ah! It's starting to rain outside now, which means I need to go out on the porch and search for inspiration, because rain is my favorite Hope tomorrow proves to be even more inspiring!!!

Hour Tally

Coding: 6.69
Composing: 0.67
Internet: 0.24
Testing: 1.32
Thinking: 1.99
Total Logged Time: 10.91

Week Summary

General Sentiment

It was a good week, and I really got a lot more done in terms of interface functionality. I'm particularly excited to have the market up-and-running, which means trading is now functional. Feels a lot more like a game now that there's actually money involved! Lots of other small stuff, but frankly, I would have liked some more "really big" improvements this week. However, I'm excited to be developing from a new and more inspiring location now, so I'm hoping this will pay off in the long run.

Very interested to see what happens next week (I really hope I can get internet...)

Major Accomplishments

• Started on per-location storage implementation
• Implemented market (both buying and selling)
• Implemented configuration engine (for tweaking game parameters via text file)
• Implemented generic cargo transfer
• Improved job board
• Optimized background generation, yielding 100% boost
• Optimized sound engine, yielding large framerate boost during sound-intensive battles
• Fixed acceleration lanes
• Packed and moved all of my personal belongings to a new state in only 1 day

Combined Hour Tally

Coding: 40.59
Composing: 6.00
Internet: 18.49
Testing: 10.65
Thinking: 6.04
Total Logged Time: 81.77