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

Post

Week of March 3, 2013

#1
Sunday, March 3, 2013

Summary

Not a bad day, considering I always have a little less time than usual on Sundays, but still feel pretty good about the accomplishments :)

Started off with working on missions again. Now I've got a rudimentary "job board" display, plus the ability to accept missions and have them correctly get linked to the pilot's profile / have them transfer to the HUD so that you can see objectives. It's all very rough, but the base is there! I quickly got derailed, however, and moved to implementing control scheme editing. Naturally, I want all of the key bindings to be configurable in a very general way. I almost finished implementing the internal machinery for that, and all that's really left is to implement a user interface for editing them. This is definitely something that needs to be done before the prototype, because I don't want to force my WASDness on everyone :roll:

I spent the rest of the day - too much, really - working on finding a good way to package up all of the non-procedural assets for distribution. This basically just includes shader code (which is not compiled into the game, but rather, lives in external files) and sound effects / music. I need to be able to package up and access these things in code without having to just copy/install a whole directory structure...because that's lazy and sloppy. So I'm looking into archive formats right now, and think I've found some good stuff to use. It's taken a long time, though, and I'm particularly unimpressed at how sparse the resources are for compressing full directory trees into archives. I mean, there are plenty of programs to do it, but far fewer libraries.

Tomorrow needs to be a massive day for code...so I'm gonna go get a jump-start on it! :D

Hour Tally

Coding: 5.89
Internet: 3.73
Testing: 0.43
Thinking: 0.48
Total Logged Time: 10.53
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
Post

Re: Week of March 3, 2013

#2
Monday, March 4, 2013

Summary

Massive day, but I'm not going to lie, it needed to be more massive... :evil: Maybe tomorrow. Part of my problem today was that my body rebelled against me, and took back the sleep that I stole from it last week while preparing the update video :? Darn, I thought I could get away with it...

Today I finished that whole archive business that I was talking about yesterday, so I now feel good about the distribution technology. I haven't thrown in compression yet, but I'm not terribly concerned with it, because compression is an easy thing to integrate, but also because the LT assets are very small compared to most games (since most of the assets are generated in code). The point is that I've got a nice way of packaging up a directory of assets and loading / using it in-engine without having to worry about any OS-dependent stuff :)

I implemented power generators as well today. Previously, the power grid was "baked in" to your ship. Now, the power grid is actually controlled by a subsystem on your ship, which takes up a generator hardpoint. Of course, it's a required subsystem, you can't build a ship without a power generator - so it might seem like there's no difference between having it as a subsystem vs. having it hardcoded. But it's cleaner this way, and also opens up the door for things like batteries, multiple power generators, etc. I really do think power management is going to be an interesting part of this game, as it's going to drastically influence how you think about constructing a ship. Choices, choices, choices...

Next up, I implemented "magazines," which have been discussed a bit on the forums, and I really love the idea. This just means that ammunition-based weapons are more interesting, because they have two different rates of fire associated with them: the refire rate of the actual projectiles, and the magazine reloading time. Having different values for each makes for some interesting gameplay - the most obvious being the ability to fire off a full magazine of missiles fairly quickly, but having to wait a good bit longer when your magazine is empty for it to reload. It would prevent, for example, that absurd barrage of missiles that you saw in the update video!

I'm currently working on a HUD component for subsystems, so that you can see the integrity, cooldown, power status, etc. of your subsystems at a glance. I hope to finish that tomorrow so as to have at least a partial HUD!

Hour Tally

Coding: 8.48
Internet: 2.63
Testing: 0.77
Thinking: 0.31
Total Logged Time: 12.18
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
Post

Re: Week of March 3, 2013

#3
Tuesday, March 5, 2013

Summary

Lots of stuff going on today, more so than yesterday even...but I still want more!!!

We now (finally) have a basic HUD. I said yesterday that I wanted to get some basic subsystem widgets going on, so that you could see the status of your laserz and such. I got a rough draft of that working today, at least for weapons. The graphical style is very simple, very clean (basically in the same style as the icons). I am using radial gauges to display information at present. Right now all I'm displaying is cooldown time and power level, but there's more to come. Even this small amount of information is helpful!

But the big work for today was all about sensors and information. You've probably noticed the god-mode thing going on where I can see everything in the command interface. No more! Visibility is now correctly implemented, so you can't see things that you haven't discovered yet. Believe it or not, this system isn't as straightforward as it sounds, because, in LT, the way that information/knowledge is handled is much more general than usual for a game. I've mentioned before that I want scanning / scouting to be a legitimate job, and for information to be a legitimate commodity that gets traded in the LT universe. That's a rather rare thing to see in a game - at best, sometimes you have the ability to purchase the location of a secret jump hole, or perhaps make an agreement with another race to share visibility, or something of that sort. But those are all really primitive mechanisms of information transfer, and are hard-coded, to some extent. Today I've done a great deal of thinking about how to implement information in LT, and have finally come to a good solution and done it!

Sadly, it'd take too much time to explain the system in depth...so I'll just say that I'm very excited about it, and I think it's going to produce some really cool possibilities. Scouting is definitely going to be a real job, as desired. Buying information is going to be a practical thing, and there are a lot of different ways that it could help - if you're a miner, you can buy information about ore-rich asteroids, whereas if you're a pirate, you can buy scan information about nearby conveys. Similarly, selling information will be possible - and potentially lucrative. There are a lot of interesting questions that come into play when you start talking about dynamic objects - i.e., objects that change in some way over time. For example, what does it mean to have knowledge of an enemy fleet? If you've got them on your sensors, then, obviously, you have pretty good information about them. But what about when you leave the system? Do you still have any knowledge of that fleet? It's a tough question to answer. Yes, in some ways, you do - you know that the fleet exists. You've seen it. You also have some general idea of where they are...but as more time passes, you become less and less certain of that, because the fleet will move on. At some point, you're not even really aware that the fleet is in existence anymore, perhaps after several years. Unfortunately, fully implementing this kind of realistic information is not feasible with modern-day computers, as it requires the game to use too much memory.

However, I've implemented some rough approximations that I think will work nicely. When you see an enemy fleet, you will retain a certain level of information about that fleet for some amount of time. During that time, your information is necessarily more valuable, because it is more current. This same information will allow you to see the fleet in the command interface. As time passes, your information will degrade and become less valuable. You will no longer have information about where the fleet is, but you'll still have information that the fleet exists (which, at some point, will degrade as well, although it will take much longer). At that point, you won't be able to see the fleet in the CI anymore. I really like this concept of information degradation, and I think it's going to introduce a massive amount of interesting gameplay! If you're a pirate and you go scan a convoy, then find that the cargo being carried is highly-valuable, you've basically got a certain window of time to find a buyer for that information before it degrades. The information is really only useful to another pirate if it is recent enough to still hold validity.

Finally, I implemented and tested the use of the archive mechanism described over the past few days. I hadn't actually hooked it into the engine yet, but now I have, and I created a program that packs up all the assets, as well as implemented the necessary hooks to make the engine pull assets from an archive rather than the file system. Everything seems to be working nicely, and LT can now run off of the archive. Great! One step closer to a distributable package.

Looking back, I guess it was a huge day for features, but let's make tomorrow bigger...

PS ~ Sorry, I feel like I was inarticulate today, probably because my mind is still very preoccupied with this whole information system...hope the log was readable :?

Hour Tally

Coding: 7.56
Internet: 2.54
Testing: 1.12
Thinking: 1.80
Total Logged Time: 13.02
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
Post

Re: Week of March 3, 2013

#4
Wednesday, March 6, 2013

Summary

Now that's what I'm talking about!!! Today is the kind of massiveness that needs to be happening everyday :D

Today, I finally faced my fears, and attacked the thing that I've been most worried about for the prototype: combat AI. I spent the whole day working on it, and I've come a long, long way since this morning. There's still loads more to do - I mean, combat AI is a pretty essential part of a space sim. But I'm feeling a lot better about it already!

I started off by doing some serious thinking about what combat AI should look like, and came to the conclusion that I've been approaching it incorrectly. Previously, I've been thinking of combat from the "what would look cool" viewpoint. That's really a terrible idea. I don't design features around "coolness," why should I do that with combat? Besides, it's entirely too subjective. So I've switched my approach to the same approach I use for everything else: make it good for its purpose. The point of combat is to destroy/disable the target. So optimize the AI for doing that. You're probably about to turn off the computer and dismiss me as a total idiot, since it's such an obvious statement. Bear with me though! I promise I have a few interesting things to say about this.

The first thought that comes immediately when you start thinking about optimizing combat is "let's not get hit by the enemy." How to do that? A few options: first, you always want to maximize lateral movement. Heading straight at the enemy is an awesome way to take plenty of bullets to the face. Second, you want to be smart about the distance that you keep between yourself and the enemy. If the enemy has point defenses that will rip you to pieces at 500m, but you've got homing missiles that can work well beyond 5KM, why on earth would you ever get close? Conversely, if you're attacking a slow target with massive turrets, you might take advantage of the tracking rate of large turrets, and try to get as close as possible to the target so that the turrets can't keep up with your angular movement. So the question of "optimal range" is really a very big part of combat. It gets even more interesting when you consider weapons with magazines. Maybe you'e got a short-range rocket rack with 16 shots that takes 1 minute to reload. The optimal range then become time-varying: you want to get close, launch your rockets, then get back out of range while you wait for your magazine to reload.

Believe it or not, however, the first observation of lateral movement actually does a lot to help us solve the problem. In fact, if you consider the "optimal range" to be a constant, then it is a mathematical fact that the ideal behavior would be to fly on the surface of an imaginary sphere surrounding your target, where the radius would be the optimal range. This is a fact from differential geometry, that the sphere is precisely the surface whose tangent plane is always aligned with the "view" vector from the origin. It means that if you're flying on a sphere around a target, then you've maximized your lateral velocity with respect to the target. Intuitively, you know this to be true. Just think of the simple case of flying circles around your target (circles lie on a sphere) - this is obviously a good strategy for not getting hit! So really, combat AI reduces to the problem of determining an "ideal range." Once we find that ideal range, then we simply fly on the surface of a sphere of equivalent radius. We will, of course, add some randomness to make our path less predictable, and also to break the appearance of a mathematically-perfect flight path. We can very easily handle the notion of dynamic ideal ranges: all we do is increase/decrease the radius of the imaginary sphere on which we're flying!

Of course, there's more to it than that. After considering those basic things, we also want to start taking into consideration more complex ideas, like the fact that certain angles of approach are visible to less of the enemy's turrets than others (if they have lots of topside turrets, we obviously want to stay below them), etc. To get really fancy, we can even start to take into account the surroundings, perhaps using asteroids as bunkers while we wait to reload.

Today I have just done the basics described above, nothing very fancy yet. Already, however, the AI is quite effective. It's very challenging dogfighting them, especially in numbers. I must say, it's already pretty fun to play! I spent quite a while today dogfighting with the AI (I hope you'll excuse the testing time, since, after all, I was trying to build a good combat AI today...)

I did a lot of other stuff as well, but it all funneled into combat. One of the bigger changes was making turrets track linearly, rather than using my prized exponential falloff. Exponential is so great for so many things...but not for turrets. You want your turrets to track at a constant angular velocity. As I found out today, doing so makes aiming wayyyy easier. I'm not sure why I ever thought that falloff was a good idea in the first place. Along with this, I added an attribute to weapons: tracking speed. I'm sure you already expected this to be in the game, but now it's officially there. You'll need to pay careful attention to this attribute when you're purchasing weapons, especially if you're a big ship. A big ship must rely almost completely on its turrets' tracking ability to hit enemies. Whereas in a fighter, you can maneuver the ship itself along with the turrets to obtain a fast lock on the target, with a cap ship it takes too long to change the direction of the entire ship. So if you want to be well-defended against fighters, you're going to need to make sure that you have some weapons with fast tracking and fast munitions.

Speaking of capital ships and their ability to defend against fighters...that's what I'm working on right now! I'm implementing per-turret target prioritization and tracking, using some of the mathematical secret sauce that I previously referred to as "p_hit". Already, even with fairly simple calculations, cap ships have become quite good at prioritizing targets. You can see, for example, that they will immediately punish any fighters that make the mistake of flying directly at the ship - such fighters become high-priority, because they are very easy to hit. It's really nice to see all the turrets picking their own targets...really makes for an epic combat scene, as fighters are exploding all over the place. I've currently got 50 fighters attacking a battleship, and am using this as my test scenario to perfect turret prioritization and tracking. So much fun!!! :D

Phew, big log today...sorry, it was such an exciting day, and combat is one of those things that's super fun to talk about :)

Hour Tally

Coding: 8.17
Internet: 1.97
Testing: 3.52
Thinking: 0.80
Total Logged Time: 14.46

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

Re: Week of March 3, 2013

#5
Thurday, March 7, 2013

Summary

Massive log yesterday == I'm off the hook for today, right? :roll:

Really, it was another great day for combat, but I don't have too much new material to talk about. I spent the day continuing yesterday's work. The AI is getting better all the time, and, for better or worse, it is getting to be entirely too much fun to watch / partake in battles (as the hours indicate :cry: ). It's very exciting...seeing a battleship nailing fighters out of the sky with 12 turrets blazing...watching your wingmen in a squadron of 50 getting picked off like flies as you make your initial approach to the battleship, then breaking off and swarming around the thing as you get within range, watching you and all your friends try as best they can to pull enough Gs to miss the autocannon fire by a couple of centimeters. It's pretty insane. The sound of fighter shields exploding at least once per second, letting you know that you won't be able to sit back and win this one easily. The deafening roar of autocannons streaming energy bolts at 60RPM toward the pilots you know and love. Hundreds of missiles from your far-away long range destroyers pounding into the shield of the battleship, making little more than scratches in the immense surface of energy. Yeah, it's something you'll talk about next time you're indulging in a beverage at the nearby trade station.

Aside from combat, which, as I said, I'm starting to feel pretty good about, I turned a lot of focus to the command interface (and the interface in general). I'm continuing to improve the interface as a whole, and am, overall, really happy with it. It keeps getting better and better, and it's just awesome how quickly I can build functionality ever since that epic battle against the Kingdom of Interfacia so many moons ago :)

The next few days need to bring immense improvements to the command interface. We need tools for assembling squadrons/formations, selecting and grouping units easily, issuing commands quickly and intuitively, planning out routes, managing power levels / subsystems of your fleet, etc. In short...need more command in the command interface 8-)

I promise, I'll try to spend less time in-game tomorrow... :?

Hour Tally

Coding: 7.22
Internet: 2.30
Testing: 4.33
Thinking: 0.22
Total Logged Time: 14.07
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
Post

Re: Week of March 3, 2013

#6
Friday, March 8, 2013

Summary

Plenty of hours, but today didn't feel nearly as productive as the past few days :? I think I'm running into a conceptual wall with the command interface. There are so many design decisions to make all at once, it's rather overwhelming. To think through the ramifications of every single decision, try to determine if it's the right decision, not to mention design an elegent way of implementing it...well, it's a lot. I really just need to buck up and do it though...this is probably one of those things that I should try to implement roughly and then refine over time.

As far as what I DID get done today, there was still plenty! One of the nicer things is that we now have hotkeyed selection groups for the command interface (a standard RTS feature). Drag select some units, hit ctrl-1 to save them to group one, then bring them up later quickly by hitting 1. I also implemented tracking of arbirary groups of objects. Whereas previously, the command interface camera either followed a single object or was in free mode, it now has the ability to follow any number of objects (it just tracks their average position). Additionally, double-tapping one of the numbered selection groups will automatically track that group. So it's become a whole lot easier to keep up with units during battles!

I do hate to admit it, but I spent several more hours on the interface today. Gah, I swear, it's almost over!!! :roll: (I guess you've all learned to see through that lie by now..) But really, I *think* I've got every feature that I wanted in the interface system now. Today I implemented the equivalent of CSS margin, padding, and float properties. The interface is now almost as powerful as CSS when it comes to building layouts, which is pretty great! I've used this to dramatically simplify the code for several interfaces (including the ship viewer, top bar, and command interface).

Ok, let's have a strong finish to the week! Just gotta get in there, gun down the command interface, and get out :ugeek:

Hour Tally

Coding: 6.84
Internet: 2.51
Testing: 1.77
Thinking: 2.38
Total Logged Time: 13.50

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

Re: Week of March 3, 2013

#7
Saturday, March 9, 2013

Summary

Assets and the HUD. That pretty much summarizes the day :)

In the morning, I worked on a "My Assets" viewer/interface, where you will be able to see and manage all of the major assets that you own - ships, stations, factories, etc. I'm playing with different layouts for this at the moment. A listview would probably be the traditional way to go about it, but I'm thinking it might be interesting to have a tile grid instead, where you can see a lot more all at once, but to get details on any one thing you need to expand it. Not really sure which will work better, but I'll play with both. Despite what you may think, I swear, I'm not avoiding the command interface! :roll: One of the biggest features that I need to add to the CI is the ability to form squadrons. When you form a squadron, you need a way to specify which units are going to be a part of it. From my perspective, there are two ways to do that: select them directly in the world in the command interface and drag them into the squadron box, or find them in your asset list and drag them from there. You need both, because the first is way faster when you can see the units that you want to manage, but that's not always going to be applicable - sometimes you will want to add an out-of-system ship to a squadron, for example, and to do so you will need to grab it from the asset viewer. See, it's relevant, I promise! :D

But most of today was about the HUD. Slowly but surely, it's beginning to look more like an actual game with stuff going on, rather than some pretty 3D demo or something! Today I began working on displaying boxes and information around objects of interest (in particular: ships within sensor range). Sure, it seems like a stupidly-easy problem. But the underlying concept of maintaining a spatial correspondence between the 3D world and the 2D interface is a bit more subtle than you might expect, and, as is proper for subtle things, I will now embark on another painfully-abstract digression! Skip the next paragraph if you prefer concrete things :)

I've been struggling with the concept of world-to-interface correspondences for a while now, not because I don't know how to draw a target box around ships, but because, as usual, the "elegant solution" is of great interest to me, and it's not totally clear how to go about it in this case. The immediate thought is to treat any HUD information that the object needs to display no differently from the way that you would treat the 3D model of the ship: when the ship gets drawn, also project some information at the corresponding screen location. This was my first thought, and it seems clean enough. I'll take a shot in the dark here and say that it's probably what most games do in this kind of situation. I implemented a component for projecting icons during drawing, and created a render pass that invokes this component, just like the main render pass invokes the component that draws the 3D model. After some careful consideration, however, I've realized that I was wrong, and that this is not the correct approach! Doing this is equivalent to treating the HUD display as if it were part of the world. It's not! You might call it semantics, but really, I think there's a very critical and subtle distinction here. The information that the HUD is displaying is part of the world. That's part of the object. But the icons? The target boxes? These are not owned or managed by the world, nor should they be. They are an artificial means of interpreting the world. They belong to whatever artificial interface is performing this interpretation. There are a lot of subtle ramifications of this, and it's hard to explain why it's a big deal without sounding stupid and crazy. But it's a big deal :) So the result of all this is that I'm now managing ship icons / target boxes in what I feel is the most elegant way possible: by having an interface widget that is dedicated to maintaining the mapping between objects and widgets.

All technicalities aside, there are some practical implications of all this nonsense: 1) I feel a lot better. 2) Ship icons, target boxes, and whatever else we dream up are all the first-class widgets, and receive the benefits accordingly. This means you could, for example, make a ship icon draggable, and I imagine I will do exactly that to allow you to easily drag ships into a squadron, as mentioned above! 3) Everything is unified ;)

PS ~In a very odd coincidence, I logged exactly the same number of internet and testing hours today...that's not a mistake. Weird.

Hour Tally

Coding: 6.27
Internet: 2.58
Testing: 2.58
Thinking: 1.56
Total Logged Time: 12.99
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
Post

Re: Week of March 3, 2013

#8
Week Summary

General Sentiment

There's no doubt about it: this was an intense week. I'm not positive, but I'd say it was probably the most productive week so far. In terms of combat and the command interface, it's not even the same game that it was a week ago! But there's really no time to rest or be proud of these hours. I need to keep upping the pace in order to get that prototype out...this was a great start to March, but it needs to keep getting better. I'm burning through the pre-prototype-release TODO list, yet, the blasted thing gets longer each day. How does that happen?? :|

March Madness has officially begun, and we must hope that the madness will only continue to escalate from here!

Major Accomplishments
  • Implemented resource archive for distribution of assets
  • Implemented power generators as first-class systems
  • Implemented scanners + scanning technology, also designed and implemented the accompanying "knowledge" framework
  • Implemented basic HUD subsystem widgets for displaying cooldown, power status, ammo, etc.
  • Implemented AI target prioritization / "threat rating" computation / basic hit probability computation, used it to achieve independently-tracking turrets
  • Implemented quick group creation and selection in command interface, as well as intelligent camera tracking of groups of units
  • Started on "job board" implementation, added ability to take missions
  • Started on target boxes
  • Started on "my assets" viewer
  • Re-wrote combat AI, yielding immense improvements in combat
  • Polished a lot of the internals of the interface, resulting in a more responsive & smoother feeling!
Combined Hour Tally

Coding: 50.43
Internet: 18.25
Testing: 14.53
Thinking: 7.54
Total Logged Time: 90.75
“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 4 guests

cron