Sunday, March 24, 2013

Summary
What a day. It was another one of those days where the code was just flying! At the end of it all, there wasn't a single element on the ambitious todo list I made this morning that hadn't been ruthlessly scratched out

Most of what I concentrated on was the mechanics and details of docking. Fully implementing it involved a lot of changes to existing code to make it capable of handling multiple "rooms." You all know that systems are essentially treated as "rooms" in LT, in that they are discrete entities, and you must move between them using jump gates / wormholes. Well, planets and space stations are also considered to be distinct "rooms" that are separate from the external environment. This makes sense for a number of reasons: namely, you don't need to simulate / draw the external environment at the full level-of-detail when you're inside one of these rooms. You might also need to cheat the space a bit, by making the interior bigger than the exterior actually is (this happens a lot in games). In general, I think it's a good idea to have things like stations be distinct rooms (I did spend a long time contemplating / debating that decision, but ultimately decided it is the right way to go). But for a game engine, "switching rooms" can be a pretty big deal, and getting it to work required improving the sound engine (to understand that sounds in one room should not be audible in another), the particle engine (for the same reason), and the simulation engine. By the end of today, everything was working!!! I can now land in a station, do what I need to do (so far just trade & grab a mission), and undock with no problems!

The nice thing about all of these changes today is that it brings LT a lot closer to being ready for planets as well as multiple systems. Even though I'm currently only using this stuff to implement stations, it's really the exact same logic that will handle planets and jumping from system to system.

I spent a lot of thinking time today on the whole universe simulation concept, especially as it relates to room switching. A few hours of thinking and a couple of sheets of math led me to some great improvements to the simulation engine that, in theory, allow it to handle an infinite universe in finite time. You might say it's impossible...but math is cool like that, it does things you wouldn't think are possible. If an infinite number of terms in a convergent series can sum to a finite number, then an infinite universe can be simulated in finite time That's brushing over a lot of the details, and, of course, in practice it's not so nice thanks to memory and other concerns. But the point is that the simulation engine is a lot better now, and definitely one step closer to being ready for the full-blown universe simulation! It can at least handle the LOD simulation of the external environment when you're in a station now (meaning, when you're docked, things are still going on outside, but in a way that doesn't slow down your CPU as much).

By the way, it shouldn't surprise you to know that there was an awful lot of exponential falloff involved today

Strong start to what will have to be a very strong week!

Hour Tally

Coding: 6.85
Composing: 0.07
Internet: 0.99
Testing: 1.47
Thinking: 1.91
Total Logged Time: 11.31

Monday, March 25, 2013

Summary

So much done today, yet so much more that I wanted to do...this is quickly becoming the story of my life, for better or for worse...

Got caught up in a whole lot of technical garbage today, Gerrymandering various engine pieces back into good shape (I know, it's not the correct usage of this absurd word, but it's been on my mind, and I felt that I really needed to use it..). Serialization came first. This is really a dark, shady figure that I've been avoiding for such a long time. Like a high-school friend that you randomly see but can't remember if you were good enough friends to warrant a hello, so instead you pretend that you never saw them to circumvent the situation altogether. This is exactly how I feel about serialization (the fancy word for loading/saving). But at some point, we're going to need to be able to save. Kind of a big deal, significantly more so than long-forgotten friends. I talked a long time ago about integrating Boost's c++ serialization library, but I've been getting an increasingly worse feeling about it since the day I did so. I think I've been missing the point of serialization. I used to think about it and think "Gee, well, I really don't want to write something that can handle transparent saving and restoration of multiply-inherited instances referred to by a base pointer living inside of an STL map, so I'll let Boost do that." But I think that's a terrible way to think about the problem. It's lazy. You need to ask yourself, why would you need to save such a complex structure? Is the underlying logical structure of the data that is flowing within the game that complicated? No! It's not! Complicated structures are usually generated by the code solely for the purpose of doing fancy things within the code...like being efficient, or keeping track of things in a certain manner - but that doesn't make them part of the "game data" (the part that needs to be loaded and saved). The game data is just a bunch of objects and a few very simple relations between them. So I spent a long time thinking about this concept today, and revising the structure of some of my code to prepare for a home-brewed serialization solution. I'm thinking and hoping that there is an elegant and simple solution to this one!

{...insert more boring technical stuff here: stability of simulation under varying time differential, complicated memory leak tracking, rant about STL containers not playing nicely with memory trackers, rant about people who write bad c++ in the name of maximally-obfuscated code (like whoever implemented MSVC's version of the STL, which has a vector implementation that will make you want to burn your corneas and then go bury the ashes deep, deep underground where no bloated code can reach them), yada yada blah blah...}

Anyway, back on track, I restructured the ship viewer for the 83 thousandth time today (!?), and have found something that I like more than on the other 82,999 tries, so that's a great thing! I didn't think I'd be able to achieve a pleasing look while sticking to the side-panel style, but I am pleasantly surprised by the aesthetics of this new layout. I am overlaying the cargo / power directly on the 3D view of the ship (so to gaze at your ship in all of it's glory, you need to close the cargo and power), and a ribbon of hardpoints is docked on the side.

Improved icon rendering a lot today. They look much cooler now, because I am actually doing some simple raytracing on the underlying fields. Indeed, raytraced icons in a game...surely it's a first...LT just gets weirder and weirder by the minute (but in a good way!)

So much to do, so little time, you know the story. See ya

PS ~ Apologies for my lack of forum presence as of late...to be realistic, I will be sinking deeper and deeper into seclusion until the prototype comes out...sorry!

Hour Tally

Coding: 8.20
Internet: 0.13
Testing: 2.46
Thinking: 2.09
Total Logged Time: 12.87

Tuesday, March 26, 2013

Summary

My favorite kind of day: a math-heavy one !!

So I'll admit it, I spent entirely too much time thinking about probabilistic object generation today. In a procedural universe, how do you generate and distribute objects? That's the question. I think it's fair to spend a long time pondering it though, because the "fun" level of the game is going to be directly related to how good or bad the generating engine is. The distribution of generated objects will basically control the balance of the game...and if the balance is off, the game will be about as much fun as digging holes in the dirt in your front yard. In other words, the game would still be very, very fun, but not exceptional

The question of generating object attributes runs a lot deeper than you might first expect. First of all, you need to come up with a "utility" formula for estimating how good an object is given the attributes. That's the easy part. A very simplified utility formula for a weapon might be (damage per shot * rate of fire / shot scatter). That's just a dumb example, but you get the point. But that's not the end of the story. If I tell you that a gun has a utility of 1000, you still have no idea about the attributes of the gun. Maybe it does 500 damage per shot, shoots at 1 round per second, and has a scatter factor of .5. Or maybe it does 10000 damage per shot, shoots once every 10 seconds, and has a scatter factor of 1. And so on. As long as I only tell you that the gun has a utility of 1000, you have no idea which of the above characterizes the gun. This proves that, in addition to a utility formula, we need to define "distributions" from which the object attributes are drawn. I won't go into the heavy details, but the question of generating object attributes boils down to a constrained multivariate sampling problem. This means a problem in which we are trying to generate a "random" element from a set, given the distributions that characterize the set, but also subject to some constraint (such as, we would like the value of the gun to equal 1000). I spent at least 1.5 hours performing mental grinding on this problem, with a fair amount of success (I at least have an approximate solution). I'm not there yet, but I'm getting closer by the minute

But that wasn't the end of the math! In thinking about all of this probabilistic ballyhoo (!?), I also got back to thinking about basic probability distributions. Probability distributions are at the absolute heart of procedural generation. PCG is all about generating random numbers, and distributions control the properties of those numbers. For example, generating asteroid scales according to a uniform probability distribution looks terrible...I'll refrain from pointing fingers at key players in the industry ;| Switch it to an exponential distribution, however, and you have pure eye-candy. Given my obvious obsession with ye olde exponential, it shouldn't surprise anyone that my favorite distribution up to this day has been the exponential distribution. But there's something that I don't like about the exponential distribution: the most probable element is also the least element. This means there's absolutely no variability in the "floor" of the distribution. Meaning, if you generate asteroids with this distribution, and they have a minimum scale of 1, then 1 will also be the most common scale for an asteroid. That's not really how I would want it to be. I'd prefer if the smallest asteroid were not the most common. I want there to be a small probability of generating a really tiny asteroid, but for it to be more "common" to generate a small-ish asteroid, and then for the probability to fall off again for larger roids. But exponential does not afford this control. Looking at it another way, in terms of object value, this would mean that junky items are the most commonplace. I don't think that's right either: low-quality items should be common, but not as common as "average," items, which are slightly better. After all, no one likes junk, so why should junk be the most common? This point is debatable, I suppose, but I don't think it's true in the case of item values that the least element should be the most common.

Luckily, some quality Wikipedia time today introduced me to my new best buddy: the Erlang distribution.

As much as I hate the name (come on, if you're going to name a distribution after yourself, you need to have a cool last name like Cauchy or Laplace...), this distribution is awesome. It's got the exact property that I wanted: the peak is low, the higher elements are roughly-exponentially-distributed, but there's also a lower tail that goes to zero probability at the lowest possible element (meaning there's a small chance of complete garbage, but it is not as probable as "average"). Perfect!!! But it gets much, much better. Guess what this distribution is made of? It's magical. It's absurd. It's just too cool. You'll never guess. But you probably will.

It's made of exponentials. HA! It's literally just summing a few copies of my previous best friend, the exponential distribution. Slap two of em together and you get that beautiful, shapely PDF I've been looking for. The irony.

If I haven't convinced you by now that you can solve anything in the world with exponentials, then I fear you may be a lost cause



By the way, since I'm already boring you to death, let me go ahead and drive it home by getting this off my chest, since it's been on my mind for at least a year now. Maybe someone will share in my enthusiasm. Did you know that products and sums are "the same thing"? They are relatable by the following: exp(sum of elems) = product of (exp elem), log(product of elems) = sum of (log elem). So you can look at products as being exponentiated sums in log space (which is generally the more useful transformation), or you can look at sums as being logged products in exponential space. The more I think about this, the more my mind is blown and I am forced to retreat to my bed where the simultaneous awesomeness/scariness of math cannot reach me.

*runs away*

Hour Tally

Coding: 6.79
Internet: 1.67
Testing: 1,76
Thinking: 3.25
Total Logged Time: 13.46

Wednesday, March 27, 2013

Summary

Too much to do, too little time, long dev log yesterday, short one today, you know the drill

Started to dig seriously into item generation today, employing all of that thought from yesterday. Turns out it's still really darn hard, even with cute tricks like Erlangs and exponents and all that jazz. At this point, I'm just going to have to keep refining, refining, and refining via trial-and-error. It's good that item generation is already in place so early, and it's also good that people will get to see it fail catastrophically in the prototype At least we have lots of time to improve. Well, the same goes for pretty much every feature.

After finally getting some "reasonably" balanced weapon generation happening, I was actually able to "play" Limit Theory for the first time today. Meaning, I played it like a game!!! Started out with a basic ship and virtually no cash or equipment, perused the market for cheap-as-dirt weaponry. Already, you can see interesting choices coming in to play. For example, at one point I found a missile launcher that I could afford in the beginning that did 100 damage per shot...awesome! A low-end pulse laser is doing between 1 and 5 damage per shot. The catch? The missiles traveled at about 75 m/s. In this game, that's absurdly slow. The average pulse travels around 500m - 1km / s. Railguns travel around 5km/s. So that's why the launcher was cheap....twas a handicapped launcher. Nonetheless, I found that if I timed it really carefully, and got reallyyyy close to the target, I could make good use of this powerful thing on unsuspecting victims!

Speaking of victims, yes, I was actually hunting people today, because I finally implemented a really basic mission generator. Right now, it does not work the way that missions will work in the real game, this version is a temporary hack so that we can have missions in the prototype. It forcefully generates missions, as you would expect in a normal game (rather than having missions emerge naturally from the AI). Right now the only mission type is "assassinate," and it's really just killing one ship. But at least it's a mission! So I ran a few of these today, using the reward cash to buy better weapons and take better missions. The enemies naturally got harder as the value of the missions increased. Hey, that's real game stuff right there! Only problem is there's no repairing yet, so in the end, it was impossibly hard to last for any significant amount of time. At least I know what I have to do tomorrow!

Hour Tally

Coding: 7.70
Internet: 0.33
Testing: 2.95
Thinking: 2.22
Total Logged Time: 13.20

Thursday, March 28, 2013

Summary

Twas a day of much pewing and whirring, blasting and brrrring. But not only was I blasting my way through enemy fighters today, I was doing so in name-brand style: with my Lambda Tritium Blaster Mk III™! That's right, I've now got gazillions of cheesily-named weapons to choose from, because today, I implemented a generalized naming system. I talked previously about considering using context-free grammars for the task, and today I finally got around to writing a simple CFG engine and using it to write a grammar for weapon name generation. Thus was born the Blue Matterhammer, the Dark Proton Blade, and, of course, a fan favorite, Dirichlet's Cold Magnon Sweeper Type 3. Although the current names are cheesy and repetitive, the generating engine is quite powerful (well, as powerful as CFGs are, which is to say, pretty darn powerful), so extending it will be easy (now it's just a matter of editing text files that define the grammar). In addition, my implementation goes a bit further than the basic CFG, because it includes a "tag" system that can be used to filter certain branches of the parse tree. This can be used, for example, to use the same grammar definitions to generate all weapon types, but to produce specific nouns that correspond to specific weapon types. I successfully tested this concept today, restricting the noun "ripper," for example, to railguns, and the word "accelerator" to pulse weapons. I hope to employ this tagging system to produce coherence in the names.

After having a bit of fun acquiring loads of weirdly-named weapons, I overhauled the hardpoint system. I've been scared of it for a while, because the previous implementation was looking too complex all the time. Specifically, the fact that *everything* was a hardpoint (save for the core "hull"), was just too overwhelming. This would require, for example, that you find the appropriate thrusters to power your capital ship before you can even really pilot it. Doing so would be at least twice as difficult as simply acquiring the ship itself. Today, I realized that, honestly, hunting for the proper equipment just to make your ship "functional" is not fun. Not at all fun. What's fun is hunting for "upgrades" to make your ship even better. But you expect it to be functional when you buy it! To that end, I rewrote the hardpoint system to incorporate the notion of "fixed" hardpoints, i.e., things that are factory-installed and cannot be replaced or removed. These fixed hardpoints will include a hull, thrusters, a basic sensor, and a basic power grid. This means that when you buy a ship, you can rest assured that you'll be able to move, you'll be able to take a bit of fire, you'll be able to pick up objects on your nav computer, and you'll be able to route power between your subsystems. These are all extremely basic functions, and it doesn't seem like any ship should come without them. IMO, it's just no fun to think about having to acquire these items just to get a workable ship (which is how it used to be). Given this, I've changed the "expansion" hardpoint slots to the following categories: generator, structure, and weapon. Generators can be used for shields, extra power supplies, cloaking fields, propulsion boosters, scanners, sensor boosters, and so one. Structure is used for armor, perhaps cargo expansion, perhaps damage mitigation systems, etc. And, of course, you know what weapons are I think this layout works reasonably well for now, and I'm already enjoying the lower complexity of this system than the previous. As usual, lambaste me with your criticisms in the suggestion forum, as I'm sure this line of reasoning raises many questions and potential holes in gameplay ;| Let's hear them!!

So, this month has been pretty great. What do I have left to do tomorrow before the monthly video? Hmm, let's see. Shipyards, ship transferal, squad formation, squad order handling, asset viewer, pilot information / stats viewer, better station graphics, more in-depth mission generation, better mission balance, better item balance, armor type generation, player-usable shields, a "real" repair system, fixes to the mission board, more sound effects...I guess it's going to be a pretty nice day, huh? Should probably get going...

PS ~ My take on the "magic silver bullet" of programming a game (or, for that matter, doing anything successfully in life..): double your expectations of yourself every day. This is a good practical example of the exponential function in action

Hour Tally

Coding: 7.34
Internet: 1.30
Testing: 1.81
Thinking: 1.72
Total Logged Time: 12.17

Comments on Fixed Hardpoints

Friday, March 29, 2013

Summary

Well, naturally, I couldn't do it all today, but I'm pretty happy with what I did get done. I finally came up with a unified ship switching / buying / repairing system that I am happy with. In brief, it is a list of all ships that are docked at the location where you're docked. You can click on any element to view the ship. If it's your ship, you can choose to order a repair, or, if it's your ship but you're not currently piloting it, you can switch to it. If it's someone else's ship, you will be able to see whether the ship is for sale, and, if it's for sale, you can buy it. In addition, in the future, you will be able to use this same interface to contact the pilots of other ships, and in this way, you'll be able to chat with NPCs where you're docked. I really like the unification of this scheme! I was searching for a way to make ship-related things feel good, especially buying/selling. One option would have been to buy/sell through the same interface as the market. But this feels too boring, and trivializes ships a bit too much. If you think about it, going to a car dealership to buy a car is pretty different from picking up eggs at the grocery store, and I would like to maintain that difference in game. So I implemented a lot of the groundwork for this system today, although it's not yet possible to buy other ships. But that's just about an hour or so away from being a reality

In implementing this, however, I had to really upgrade the detail of dockable locations. To make this thing work, we obviously need to give the other docked ships a spatial location within the docked place, which is more detail than I was ever planning on including...but I've gone ahead and done that today, and I really like it. Definitely adds a lot of immersion to feel the other ships around you. In the future I imagine we'll see motion as well...since the ships are not fake (they are actually representative of real ships that are really docked at the location), they will be coming and going from time to time. It'll definitely be neat to watch that happening when you're docked. And just think, you might spot one of your own freighters coming/going as well, if you own an automated empire! Cool

Worked on the ship generator as well. It's still a placeholder algorithm, but now it's a placeholder algorithm that scales to all ship classes, so I can finally start playing with destroys, frigates, etc. instead of always flying a fighter and having one battleship in the background. It also generates factory equipment now. I'm still working on the balance - some things are easy, but some things are not. Propulsion is always the hard one. Getting the mass / thrust / torque balance right is tough. You want bigger ships to feel big, but you don't want it to be impossible to play with them!

Still got lots left to do, so excuse me while I get things ready for that video

Hour Tally

Coding: 6.38
Internet: 2.05
Testing: 1.45
Thinking: 0.43
Total Logged Time: 10.31

Saturday, March 30, 2013

Summary

CRAZY DAY

But it's not over yet! This day just keeps going and going and going. I still haven't made the video, which means I'm behind compared to previous months, so I'll have to stay up all night. But MAN did I get some stuff done today. I think I implemented a solid half of LT today. Or at least, that's how it feels...even though we're still a ways off. But I'm really excited about everything that I have to show for the video. No one will be able to say that I've been lazy this month

List of things I did, since I'm under time pressure and need to get back to work!

• Finished ship market, can now view / buy / repair ships
• Can swap between owned ships (this was a big one, allowing the player to change ships has some serious ramifications from the engine's standpoint)
• Totally re-done armor system
• Working armor that can be bought and adds extra protection to your hull!
• Much better random jobs!!
• Basic procedural ship name generator
• "Distress call" job type, where you have to save some people that are under attack
• Implemented mission failure conditions (to make distress call missions work; you lose if all of the friendly ships are destroyed)
• Implemented non-weapon hardpoint viewers so that you can see the integrity/power status of your hull, sensor, power grid, armor layers, etc.
• Implemented repair

Probably forgot half of the things I did, but I think you get the point: it was a good day.

PS ~ IT FINALLY FEELS LIKE A GAME!!! A really rough one, but a game nonetheless

PPS ~ "Weekly Summary" will have to be delayed till I finish the video / update, so it won't come quite as soon as usual (but hopefully still before tomorrow's log)

Hour Tally

Coding: 9.43
Composing: 0.05
Internet: 1.58
Testing: 4.09
Total Logged Time: 15.16

Week Summary

General Sentiment

Not sure what to say about this week, really...I'm still a bit confused about the fact that it was a week. It felt like a month. Well, yesterday alone felt like a month. And that's good news Suffice it to say, I'm very pleased with the progress this "week"!

Major Accomplishments

• Implemented docking
• Implemented LOD universe simulation mechanics
• Implemented context-free grammar engine for generating item names
• Implemented shipyards for ship buying/selling, repair, pilot transfer (!!! this is like 3 major bullet points rolled into one...)
• Implemented widgets for indicating status of non-weapon hardpoints
• Improved look and layout of ship viewer
• Worked on asteroid station interiors
• Started on procedural generation of ships, weapons, armor
• Started on a few basic mission types for testing purposes
• Third successful monthly update! IMO, the best one yet.

Combined Hour Tally

Coding: 52.70
Composing: 0.14
Internet: 8.04
Testing: 15.99
Thinking: 11.62
Total Logged Time: 88.48