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

Post

Week of January 6, 2013

#1
Sunday, January 6, 2013

Summary

Gave myself a break from interfaces today....thank goodness! Instead, spent my time finding more code to clean, and restructuring the damage system - doing it right this time. That includes shields, so the game now understands the concept of shields (although there is not yet a graphical/physical implementation of them). Actually, everything's implemented very generally, so in theory the game now understands shields, armor, hull, plating...whatever you want, really. It also features a list of damage types that can be easily expanded. Right now I just have kinetic and energy-based, but this list may expand if I see good reason to do so.

A lot of time today was spent on building an algorithm to construct the shield shapes, since I'd like to get those into the game and start playing with both the graphics and the mechanics of shields. I ended up coming up with a pretty nice little algorithm for building the shield mesh (given an arbitrary shape), so I'm in pretty good shape to get these into the game shortly!

Oh, and, not surprisingly, I ripped plenty more code out today ;) I'm quite happy to say that the code that controls "ships" - as in, the only code in the engine dedicated specifically to the workings of ships as an entity - is under 150 lines :) Great! Soon I'll be implementing stations as first-class entities (in the tech demo they were actually ships....shhhh, don't tell anyone), and hope that I can make the code equally succinct.

Hour Tally

Coding: 5.68
Internet: 3.92
Testing: 1.46
Total Logged Time: 11.06
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
Post

Re: Week of January 6, 2013

#2
Monday, January 7, 2013

Summary

Wow, what a day!!! I think my hours today reflect the fact that I nearly hit a state of coding nirvana. At one point I don't think I could feel my body anymore. It was just me, the monitor, and a swirling hurricane of code. Fun times.

I know you're all probably tired of hearing the "not much visible progress" and "ripping out/cleaning code" spiels...but I'm sorry, that's just how I am! I'm addicted to refactoring, and not really ashamed to admit it, because it's a key element of what allows me to create big, new things quickly and without much effort. Having everything super-clean and simple allows that. So, that being said, I nearly uprooted the whole darn engine today. No bloat was allowed to hide. It was a massacre. My poor codebase. The pieces that were left were trembling in fear, but I comforted them, as they were clean and beautiful, and had no reason to worry...for they would live on. The survivors emerged - shiny, sparkling, and ready to start a new life, free from the chains of the ugly demons of complexity that had scared them into hiding.

While I was at it, I also wrote a helpful module that automatically tracks memory usage, and gives me a breakdown per-object-file, so that I can see exactly where memory is being used by the game. I can also use it to quickly identify leaks. Fixed a few of those when I saw escalating numbers, and everything looks nice and stable now. It's going to be a powerful debugging and optimization tool, and I can't wait to hook it up to the new interface...I'm thinking it would be a perfect way to test out a graph widget :D

Toward the end of the day, I revisited stations, got them into the game as first-class entities, and started verifying that the engine can handle hugeness. Unfortunately, physics performance was pretty much unacceptable for the ship-to-station collision detection. It's not terribly surprising, because the station mesh is pretty large and very, very far from being convex (physics engines like convexity a lot). Since Bullet is doing a pretty awful job, and I really don't want to have to make stations less-than-epic, I had to pull out my math & physics hat and jump back into the low-level field that I hate the most: collision detection. Thankfully, I've come up with something that looks like it's going to be significantly faster than Bullet's general-purpose concave solver. Best of all, it's very simple and clean (yay!!) I'm trying not to get my hopes up, because collision detection is one of the few areas of game programming that regularly smashes my optimism....but I do think I may have a winner on my hands here :)

The next few days are probably going to be a lot of low-level work, especially hammering out collision detection and making physics run fast regardless of entity size. But if it all turns out well, it will have been a fantastic investment. Say hello to massive capital ships and stations ;)

Hour Tally

Coding: 8.85
Internet: 2.02
Testing: 1.61
Total Logged Time: 12.48
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
Post

Re: Week of January 6, 2013

#3
Tuesday, January 8, 2013

Summary

Incredibly hardcore day today, but I have great news: I'm ditching Bullet physics! Why is this great news? Because, as you should know by now, I love deleting code. And getting to delete a whole directory is just...marvelous! I'm replacing it with a few small, clean files that I worked on yesterday and today that completely replace the physics engine. Indeed, the solution I came up with yesterday turns out to work really well. With another intense day of donning the physics hat, I've optimized and whipped it into great shape. It's consistently much faster than Bullet's concave collision detector, and has a number of awesome bonus properties that I could go on for hours about :D Suffice it to say, she's fast enough for you, old man.

At any rate, with this new algorithm under my belt, I am able to fly around (and run in to) massive space stations while maintaining a silky-smooth 60 FPS. This might not sound like an achievement, but, the thing is, unlike many games, LT uses full-precision meshes for physics/collision detection. It would be foolish to do so in a regular game, so most games use approximations like boxes, capsules, groups of convex hulls, and the like and make out just fine. But in a game where the object may be scaled up to 100x the normal mesh size, and, moreover, the player (who is 100x smaller) can fly up to and land on any surface of the mesh, you have to have perfect collision checking, otherwise differences between the physics mesh and real mesh would be obvious, and you'd find yourself flying right through solid metal, or, worse, colliding with thin air...and that'd end your trip real quick, wouldn't it? Luckily, in Limit Theory, thanks to these great technological achievements, you can expect to see your ship exploding precisely when it hits the space station's outer wall, no sooner, no later :roll: Exciting, right? Now pray that loading and saving works properly so that you can appreciate the fancy physics without losing hours of work in the explosion...

As far as hours go, there was a lot of internet time today doing research to make the algorithm perform faster, as well as looking at how to do collision resolution. Thanks to a few good articles, I've got a pretty solid (hehe) collision resolution solution, so I can no longer fly through asteroids and such. I guess it might not look like much, but it's got it where it counts. And of course, many hours of testing were required to test and profile the performance of the new collision algorithm. Hopefully tomorrow I will be able to get back to pure coding instead of all this testing/researching nonsense. The physics hat definitely makes me feel like a robot, and I much prefer thinking about higher-level gameplay problems than thinking about how I can shave some cycles off of a sphere-sphere intersection test :|

To compensate for the induced robotness, I got back into composition toward the end of the day and dreamt up a snippet of spacey ambiance. Yay?

PS ~ There are no less than three Han Solo references in this dev blog. The first person to identify all of them, and post it in a new thread in the "Everything & Anything" section gets a cookie, and eternal gratitude from me for being a fellow Star Wars nerd 8-) (But if someone beats you to it...please don't post a new thread..let's try not to burn and pillage the off-topic section..!)

Hour Tally

Coding: 5.12
Composing: 1.05
Internet: 3.73
Testing: 2.36
Total Logged Time: 12.25
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
Post

Re: Week of January 6, 2013

#4
Wednesday, January 9, 2013

Summary

A rather sad day, as I had a lot of fun stuff planned to clear out the zombiness of yesterday's math & physics madness. Unfortunately, the physics engine had other plans for me...and decided that it wanted another whole day of my undivided attention :cry:

I didn't think it would take more than a few hours to finish raycasting, which is another primitive operation that I need my collision package to support, as it's critical for many parts of the game. Sadly, it ended up taking the greater part of the day to implement it robustly. The results, however, are quite worth it. Raycasting this new acceleration structure is almost blindingly fast, which is great, because it means...more weapons on screen :D

I also worked some more on making the collision algorithm faster and more robust. It's nearing completion, although I do still have one more trick up my sleeves to squeeze just a tad more performance. But it shouldn't take long to finish. Today I was able to put record-breakingly large carriers into the game and land on them without any real performance issues, which is great! It definitely wasn't possible a week ago. It'll be very interesting to see how far I can push the scale without something breaking.

With the past few days of low-level madness out of the way, I'm really looking forward to getting back to the warm, comfy embrace of high-level gameplay design! The next time I hear a remark about gameplay or AI being harder to program than low-level systems (as I've heard several people claim), I'll be prepared with a mighty chuckle. The past few days have been absolutely mentally brutal compared to frolicking in the fields with AI.

Hour Tally

Coding: 5.34
Composing: 0.32
Internet: 3.32
Testing: 2.00
Total Logged Time: 10.99
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
Post

Re: Week of January 6, 2013

#5
Thursday, January 10, 2013

Summary

Another huge day for LT!!! On top of implementing the final optimizations on my collision algorithm (which turned out quite well, actually), I made a really big change to the way the game engine works today, and the result is a massive improvement in smoothness. So, let's talk about time steps.

In a game, you have some world, in which things are taking place. And they're taking place at a certain rate. To make things happen, you "simulate" them at a certain rate. So each frame, a bullet moves a little further, your ship turns a few more degrees, etc. An interesting, seemingly-innocent question arises: how fast do you simulate things? In other words, in your physics equations and such, what is your delta-t? The obvious answer: well, if you simulate once per frame, it's the amount of time between frames. Duh? Sure. So let's do that: let's simulate the game, each frame using the time between the previous frame and this frame as the amount of time for the calculations. Great, right? No. Why? Jerky chaos ensures. Why? Because you're using a different simulation time every frame. Frametime is highly variable, even when everyone is standing absolutely still...you just never know how long that darn GPU is going to twiddle its thumbs at the end of each frame. But if we're timing it, shouldn't the simulation time line up with real time, and everything will be fine? Yeah, sure, sounds great in theory. Doesn't work in practice. They don't align, the result is jerky at best and unplayable at worst.

Ok, fine, next try: let's use a constant amount of time each frame. Great, now everything is consistent! Yeah, not really. Because your friend over there, with a GPU twice the size of yours and a framerate 4 times higher, is playing the game literally 4 times faster than you. His ship is moving 4 times faster, his bank account is filling up 4 times faster, and the sound of him taunting your slow computer is probably at least 4 times more annoying than it was with a variable time step. Instead of lighting your friend's computer on fire, let's think up a more clever solution.

What if we smoothed out the frametime a bit...say, took some kind of exponentially-decaying average over a number of frames, and used a variable timestep? That way, we would cure the jerkiness, but could also prevent our obnoxious friends from playing the game faster than us. This is a fairly good idea, and is what LT was using until today. The result is certainly playable, and mostly pretty nice. It does, however, result in noticeable time distortions when frametime starts to change quickly. The result is not jerky, because we're smoothing...but you may notice, for example, time seems to slow down ever so slightly when you get really close to the surface of an asteroid (because the physics starts doing a lot of work). It makes for...a weird, somewhat disconcerting experience. Most of the time it's fine, but if you're in a dogfight where bullets are flying everywhere, it might become a bit jarring to keep feeling the tug of time dilation.

What do we do? The golden answer: decouple simulation and rendering. Let's say that we'll always simulate at, for example, 60 FPS. But we'll render at whatever frequency the GPU allows. This is a sure-fire win, right? Right. But the tricky part is immediately clear: what if we can render at 120FPS, but still only want to simulate at 60FPS (or, if you're uncomfortable going above monitor refresh rates, let's say 60/30)? Then we'll be rendering twice, but the simulation won't have moved: we'll render the exact same thing! Hence, we'll waste our energy. What to do? Well, we could just lock the rendering at 60FPS (or 30). A lot of games do that. But there's a better solution. What if we take the previous world state, and the current world state, and render a blended version, depending on when the render step occurs? Then, we could get a smooth animation of the world even if we're rendering at a frequency much higher than we're simulating! This is really an incredibly beautiful solution to the problem. And I have good news: it works magnificently well.

So, sorry for that massive summary, but now you understand the rather tricky little subject of time steps! I spent most of today rewriting all of what needed to be changed in order to allow the world simulation to keep track of a previous state, and allow the renderer to interpolate the state. It wasn't very hard, thanks to all this code cleaning I've been doing recently :geek: But it took a lot of time to test all the various aspects of it.

The result is that Limit Theory now plays really smoothly (and I'm still on my laptop...)!! Man. It's really great. I can't stress how happy I am with the feel of the game now...it's just so responsive and smooth (thanks to the interpolation), but also stable - no more time dilation when the physics engine starts grunting! Furthermore, I found that I don't even need to simulate the world at 60 Hz. For now, I've stepped down to 30, and it seems just fine! This means that LT will run even faster than before. With this improvement, the bottleneck is almost completely the GPU, which is awesome, and means that I'll have plenty of room to grow when I start consuming massive amounts of CPU simulating an infinite universe!!!

Alrighty. Sorry for going a bit crazy with that log :D

Hour Tally

Coding: 6.59
Composing: 0.01
Internet: 3.80
Testing: 3.10
Total Logged Time: 13.49
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
Post

Re: Week of January 6, 2013

#6
Friday, January 11, 2013

Summary

To make up for yesterday's ridiculously long dev log, I guess I get to post a short one today :D But really, I will...today was another great day, but not in the usual way. I logged very few coding hours, but not because I wasn't working! I had ordered a really epic pack of virtual instruments to use for composing, and they came in today! Hoorah! So I spent the whole day installing and then playing with my new musical toys, trying to make some great space music. I wouldn't say I produced anything truly astounding, but I will say that I'm learning quickly, and, like every other problem, I think composing a fitting soundtrack can be solved with enough time and effort. I started 6 different tracks today, roughly two or three of which will probably get polished and make the final cut.

I also started toying with the idea of a dynamic music system like in Freelancer, where the music gets more suspenseful as enemies get closer, and breaks into action music when the fight begins. In my opinion, it worked really well and greatly enhanced the tension of fights. One of the tracks I wrote today was written with this kind of system in mind, and I made peaceful, suspenseful, and action versions of the piece. Presumably, the engine would blend between these three versions of the piece based on the situation. I'm looking forward to trying that at some point to see if it works well :)

In other news, my shipment came today, so I got all my stuff back from school. This is great, because it means I have my desktop machine back, as well as two more monitors. You know what that means...more visible code!!! :ugeek:

Hour Tally

Coding: 2.45
Composing: 5.71
Internet: 1.99
Testing: 0.32
Total Logged Time: 10.46
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
Post

Re: Week of January 6, 2013

#7
Saturday, January 12, 2013

Summary

Man, a lot of big days for LT this week! Today I had a few pretty cool revelations about the engine architecture, and it culminated in many, many more dead lines of code. The two main areas that I touched were the way cameras/rendering work with the world (I really solidified my understanding of the interface between the game/simulation and the rendering). As a result of this work, it will be absolutely painless in the future to build things like rear-view cams, picture-in-picture monitors so that you can see views from the cockpits of your other ships, etc. The other big realization is a bit of a philosophical one concerning "game state": there is no game state.

When I say "game state," I'm really talking about some global state that gets passed around pretty much everywhere to keep track of what's going on in the game. When I first started, I thought this was a pretty good and easy way to keep track of state. With all this cleaning and beautifying that I've been up to this week, I've noticed that the amount of stuff in the GameState structure has been dwindling...and I started to wonder if, maybe just maybe, game state is really an illusion. Sure enough, today I took a closer look at each and every access to this shared state, and decided that each access could be replaced with a cleaner, more appropriate access framed in terms of the accessing entity itself, or the access of a globally-visible subsystem (like the renderer or particle system). Indeed...as it turns out, there is no game state, only objects and subsystems. The entire game state is captured in the state of the objects, along with the state of subsystems like the renderer. Beautiful!

The result? As has been the trend this week, very little visual change. But the game compiles faster (because there is no shared linkage to the game state anymore), theoretically runs just a teensy bit faster (but not really), but, most importantly, is immensely cleaner and more organized in my mind. It's really a whole new way of looking at things.

Unlike many software projects that grow more and more complex with time, it would seem that LT is doing exactly the opposite. I'm starting to think the final code is going to be shorter than pong...

Also, in an effort to actually make a bit of visual change, I improved/fixed one of the texturing techniques, and it will result in higher quality of lighting on surfaces. I posted an entry in my personal blog with technical details for the curious.

Oh, almost forgot to mention that I also ripped out and replaced the audio engine. SFML, while an excellent library in many, many ways, just isn't ready for the big leagues when it comes to audio. I should have known when I first had to go in, make changes, and recompile just to get the 3D spatialization to work in real 3D. But I kept my faith. This morning, when I switched back over to my desktop, SFML started randomly causing a crash on exit, which is totally unacceptable. I've also noticed crackling in the spatialized sound effects when the camera moves, which is also, in the words of Seven of Nine, "unacceptable." Thankfully, I found irrKlang, which is minimal, portable, and, I must say...absolutely beautiful in the simplicity of the interface. It's probably the first library I've ever been able to integrate on the first try. Kudos to them for making it so easy! Best of all, it works perfectly - the spatialized audio sounds a whole lot better, no crashing on exit, and it also supports mp3, which is a big win.

Hour Tally

Coding: 7.89
Composing: 0.00
Internet: 2.38
Testing: 1.13
Total Logged Time: 11.40
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
Post

Re: Week of January 6, 2013

#8
Week Summary

General Sentiment

Truly an epic week. From physics engine replacement to fixed time step conversion to new music, it has just been a week of massive progress for LT. The game runs faster, feels smoother, and even looks a bit better. Moreover, on the inside, it's at least twice as beautiful as it was last week! I'm really pleased with how this week went :) I finally hit the 80+ hour mark, although it's still too low of a code-to-other-things ratio, but I'm working on improving that.

Major Accomplishments
  • Implemented an algorithm for generating shield meshes
  • Implemented debug memory tracking system
  • Developed custom-tailored algorithm for collision detection, used it to replace Bullet and obtain fantastic speed gains in physics engine
  • Fixed collision resolution to the point that it is acceptably-realistic-looking, surfaces now actually seem hard
  • Decoupled simulation/rendering architecture, switched to fixed-step simulation, implemented state interpolation for smooth rendering of simulation frames
  • Drastically improved triplanar bumpmapping for more accurate lighting on surfaces
  • Composed 6 new rough idea pieces, probably 2 or 3 keepers
  • Integrated irrKlang for sound engine
  • Ripped out and simplified even more code than last week
  • "There is no game state" philosophical revelation
Combined Hour Tally

Coding: 41.92
Composing: 7.09
Internet: 21.16
Testing: 11.98
Total Logged Time: 82.15
“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 1 guest

cron