Sunday, March 31, 2013

Summary

Today was certainly a lot more intense than the usual "off day"! Unlike in previous months, this month I didn't finish the update video until 9am (i.e., working through the morning ). But making the darn thing was just the beginning....uploading literally took from 9 am to 2 pm, and used up 4 out of my 5 cellular GBs. Luckily I managed to steal a few hours of sleep while this thing was draining my data, and woke up to finish writing the update text / taking the screenshots.

But of course, that was only the beginning, because after I had already released the update and notified all 5,449 backers that a new video was out, a YouTuber was kind enough to point out that the last three minutes had no audio. Cool. So that first upload consumed 5 hours, virtually the entire data plan, and was completely useless. Nice!!! Obviously cell is not the correct way to upload massive files. Now I know. I drove over to some family members' house to use their high-speed internet and, after another 4 hours of uploading, arrived at the second version.

So yeah, it wasn't really as relaxing of a day as I hoped for, but that's ok...in the end, I'm really happy with the update video / March in general, and I hope April will live up to the same standards

Now then, since everything is finally over, I fully intend to take my rightful "night off," and I fully intend to spend my night off in a deep sleep. Wish me luck.

Hour Tally

Coding: 3.82
Composing: 0.08
Internet: 6.07
Testing: 2.07
Total Logged Time: 12.04

Monday, April 1, 2013

Summary

Well, I had some amazingly-deep thoughts today. I realized that the ultimate form of procedural generation is dreaming, since you get to experience a beautiful, generated reality without having to put in any real effort. In light of this profound realization, I have decided that it would be most prudent to discontinue development of LT, and, instead, to go to work for a pharmaceutical company in an attempt to create a drug that will allow you to perform lucid dreaming 24/7. In this medically-induced dreaming state, you will be able to play any space simulation game you like, including LT, LT2, and even MorrowLancer: Dangerous Citizen Rebirth. This development process will be incredibly efficient compared to regular game development, since the creation of a single pill will afford you, literally, your "dream" game, and also every material good you've ever wanted in life. Infinite fulfillment of your wildest dreams all for the price of one game. Truly, that's procedural content generation at its finest.

But seriously.

I took another half day off to make up for yesterday. Didn't manage to get any Morrowind time in (too busy being asleep), sadly, but it'll make it all the more rewarding when I finally get to finish that main quest next month So, other than sleeping, napping, and thinking up crazy lies to tell you, I did get some stuff done today! I'm finally digging in to saving and loading. There's been a lot of preparation and a whole lot of thinking time surrounding this, but I believe I'm finally ready to write the code, so I'm about 25% through it now (I think). I'm hoping that a highly-focused day tomorrow might be able to bring this thing to completion! I will feel a lot better once saving/loading is implemented, because it's one of the few prototype-critical pieces that's still missing.

Naturally, I ended up implementing it in more detail than I originally intended. It seems that my general strategy with most systems has been to say "well, I'll just do a lite version of that for the Prototype," and then to go on to do it fully. By the time I'm through tomorrow, saving and loading will be working fully for all game objects, in a completely general way, which means it will be one less thing that I'll have to worry about for the final release! Just like item generation. And docking. And transferring ships. And missions. And the hundred other things that I never intended to include in the prototype

Thanks to everyone for the great feedback / encouragement / suggestions on the latest dev update! Have digested pretty much all of it, even if I haven't replied

PS ~ I am in agreement with almost all of the constructive criticism surrounding the update video. Bad ship design, overly-obtrusive HUD / target markers, lack of homing missiles, etc.

PPS ~ One of the few recurring comments that I am disagreement with is realistic sound. I really just don't have a desire for "realistic" sound in this game (i.e., to hear absolutely nothing except the vibrations of your subsystems / whatever hits you). This is one of those times when I don't like reality. When I'm in the middle of a 20-ship battle, I want to hear gunfire all around me, regardless of whether it's hitting me or not. Of course, in reality, that wouldn't be the case - sound does not propagate in space, so you cannot hear anything unless it's from your ship itself. But honestly, that doesn't sound very interesting!

P^3S ~ If you're from a country that does not recognize the foolishness of April 1st, please know that the first paragraph was not to be taken seriously

Hour Tally

Coding: 4.40
Internet: 2.42
Testing: 0.09
Thinking: 1.20
Total Logged Time: 8.12

Tuesday, April 2, 2013

Summary

Whole lotta code today As I said I would yesterday, I did spend the whole day on saving/loading (serialization). I had some good fun doing it, since it's a nice technical thing, which is a bit of a break for me considering all this gameplay engineering lately. Since serialization is a system that affects basically everything in the engine, it's also a good chance to revisit a lot of code that never gets visited anymore, and to re-think the structure of certain pieces.

Serialization really isn't so hard, but it's definitely an exercise in reading compiler errors. I'm usually pretty fast at understanding compiler errors, since I speak to compilers more often than I speak to humans these days...but anything involving real usage of c++ (meaning templates) is bad news for compiler errors. It's like the people who wrote them just stopped trying at some point...

Anyway, I'd say I'm about 70-80% there at this point. It was a little ambitious to want to finish full-blown saving and loading in 1.5 days, but it looks like I can do it in 2.5. Again, I'm very relieved to have this almost done, as it's been a moderate stress in the back of my mind for a long time!! I'm also really glad that I went ahead and wrote my own solution, because I'm pretty sure the save files are going to end up being a lot smaller thanks to some of the tricks I can play with my insider knowledge of the engine

I'm working on getting my first successful load right now. Hoping to get it sometime within an hour or two...

Hour Tally

Coding: 9.04
Internet: 1.83
Testing: 0.66
Thinking: 1.57
Total Logged Time: 13.10

Wednesday, April 3, 2013

Summary

I reallyyy need to get moving here, but technical things keep sucking me into long hours of no-visible-progress coding, which really leaves me uneasy at the end of the day...even though the hours are great, I can't say there's a lot to "show" for it. But someone has to do the dirty work I guess...

So yeah, I pretty much finished up loading and saving today (I say "pretty much" because I got derailed at about 90% or so). But I've been concerned about the engine's memory usage, and have noticed that it appears to be leaking a substantial amount. Not good. Since I was already deep in technical waters today, I decided to go ahead and revisit the memory issues for a while. I haven't been as rigorous about memory as I should have been up until now. But that started changing today! I went back and improved a boatload of systems to make them extremely cautious about memory. Even after a solid half-day of work with the memory system, it still seems that I've got some problems, but definitely not as bad as they used to be. I still need to stabilize the leakage for the prototype, though. Memory is a really tricky thing to handle...it's much harder to measure than performance bottlenecks, no matter how much code-fu you bust out.

The good news with all of this technical work (which is being hastened 10 fold by the pressure of needing to get the prototype out ASAP) is that the Limit Theory Engine is, honestly, way more mature than I was expecting it to be at this point. I mean, really, I am feeling pretty darn good about a lot of stuff. By the time the prototype is out, there will have already been so many technical challenges conquered, and even a few gameplay challenges as well! Every day I feel better about this game and the code upon which it sits, and that can only be a good thing Probably the biggest remaining technical question mark in my mind is porting to other platforms. In theory, this will be an effortless task, since all of my code is portable, including the external libraries. In practice, since I have no experience with this process, I do expect at least a few snags. I really just need to order a Mac soon and get an early start on tackling whatever problems arise.

PS ~ (WARNING: this PS for programmer geeks only) Ultra-quick technical rant because I don't want to lose my head over this, but could probably rant for several paragraphs about it. People at StackOverflow continually assert that autopointers and STL containers don't play nicely. And no matter how many times they assert it, this generalization continues to be only partially true at best. In particular, there is absolutely no reason why any sensible vector implementation should have a problem with the semantics of an autopointer. I can't speak for all implementations, but Visual Studio's STL vector has no problem whatsoever storing my personal autopointer class, and I regularly exploit this. It's completely sane to have a vector of self-freeing pointers! Completely sane, and completely convenient. And hey, you can say "it's not portable" all you want, but if your platform, for some strange reason, does not play nicely, then it is very easy to write a custom vector implementation that works with your autopointers. C++ Yoda says "The boy is reckless!"

Hour Tally

Coding: 9.93
Internet: 2.00
Testing: 1.81
Thinking: 0.95
Total Logged Time: 14.68

Thursday, April 4, 2013

Summary

Super tired tonight, so I'm gonna make this quick and I hope no one will mind! Today was pretty frustrating, but I guess it comes with the job I spent way more time than I ever wanted to figuring out how to distribute the Prototype. Seems like a private, secure download for a group of customers should be a pretty easy thing to arrange, right? Well, you'd be surprised how hard it is to do in a practical way. I think I signed up for 10 different services today, only two of which I am happy with. The good news is that, in the end, I triumphed, and I now have a satisfactory number of options for distribution. My primary hope at the moment is Desura, but I'm currently in contact with them, and am somewhat underwhelmed with it so far. Hopefully things will pull together shortly, but if they don't, I've got two proven contingency plans thanks to my internet-based labor today. Also, more good news is that I now know way more than I ever wanted to know about e-commerce. I'm definitely more than capable of setting up an independent distribution system now for when it comes time to sell the game! This makes me feel really good, as I can rest at ease knowing that I have a solid mechanism for delivering the game (DRM-free) in a professional manner, and even supporting royalty-free sales in a nice way as well. I know most people won't choose that way (I'm hoping to offer both Steam and Desura, possibly others as well, which I imagine will be the most popular avenues of purchase), but at least I know how to offer a sales mechanism that totally circumvents 3rd-party cuts of the profit (but don't get the wrong idea, I am not really concerned with the profit, just hoping that I can earn enough to keep developing full-time for a long time!)

Other than that logistic garbage, I did make some serious headway with the memory situation today! So serious, in fact, that it appears memory usage has been stabilized, even in very intense situations like massive battles! This eases my mind a lot In rooting out these memory problems, I also improved a lot of the engine infrastructure (as I mentioned last time, this is particularly relevant to the AI engine). Overall, I'm feeling much better about this situation, and about the engine in general. Phew!

So, it's true, not as much actual code progress as I was hoping for today, but two major stress factors are now gone, so I'm that much closer to releasing the prototype

Hour Tally

Coding: 4.24
Internet: 6.03
Testing: 0.55
Total Logged Time: 10.83

Friday, April 5, 2013

Summary

So something pretty exciting happened today. I shut down the game.

AND THEN opened it up again, five minutes later, to the SAME STATE!!! Yeahh baby, that's what loading and saving is all about. Works like a charm. A somewhat buggy charm that sometimes fails and sometimes crashes. But a charm nonetheless. Like most technical things, it will just take some hammering over time. But it's working! And the save file seems to be in pretty good shape size-wise: we're at 1MB for a save containing 1 system. But it's saving in the dumbest possible way at the moment, not taking into account the fact that certain parts of the system are generated procedurally (like the asteroids). Once I account for that, we will see at least a 10x reduction in the size. Compression scheme should throw in another 2x reduction or so. Put that all together, and we're looking at an optimistic 1MB per 20 systems, which seems more than efficient enough. That sure was a lot of handwaving in one paragraph By the way, I'll probably just end up using zlib like most sane people, but I'm really really tempted to write the compression from scratch, as it could be a very fun learning experience to learn how to implement DEFLATE (the ZIP compression algorithm). In a parallel universe where I announced a 2015 release date of the game and a 2014 release date of the prototype, I am currently having fun implementing compression algorithms

Made a bunch of small cosmetic changes today too. Some people mentioned that the target indicators were too obtrusive in the recent video, and I completely agree. I have just switched to a solution that I quite like for now: the ship class icon is shown for ships that are very small on-screen, and this transitions to the classic target box for ships that are large enough to warrant a box. The class icon goes away when the box appears, although maybe I should just make it small and put it in a corner. But I like the minimalism of this approach, and I think it works very well visually. It works the same way in the command interface as well, so in many cases you will be seeing fighters as solid dots, which is nice, because they would be too hard to see normally, but you'll be seeing bigger ships as the real model + a target box.

Also worked on targeting a bit, now you can target the object nearest the cursor, which is very convenient. I still need to allow cycling through targets, but I imagine that "target nearest enemy" and "target object closest to cursor" are probably going to be the two most-frequently-used targeting tools.

Speaking of the command interface (!?), I need to do a lot of work on that sucker. Hoping to make tomorrow a very commandish day!

Hour Tally

Coding: 6.90
Internet: 1.42
Testing: 1.04
Thinking: 2.08
Total Logged Time: 11.44

Saturday, April 6, 2013

Summary

Been having some unusually slow days here lately, but I'm starting to pick back up today, and am hoping to just accelerate on through to the prototype release! I'm kind of all over the place in a frenzy of code at the moment.

My favorite part of today was implementing targeting assistance. As you probably noticed from the latest video, I was really struggling to hit my enemies. Today I implemented a "smart targeting" system that makes your weapons snap to the target when you position the cursor relatively close to the target lead indicator. This is basically the same thing that Freelancer does. I really like this method because it's unobtrusive (you're not really aware that you're getting assistance unless you pay very close attention to your turrets), and keeps the combat very tactile. You still get the feeling that you're doing some work in choosing and aiming at your target, but your weapons just happen to hit a lot more accurately than they'd be doing if you were really controlling by hand. Of course, nothing is faked, the hits are still subject to the accuracy of your projectiles...but your weapons are aiming more accurately than you could achieve with manual control. Another advantage of this is that it's simply not feasible to aim and lead all of your weapons correctly at the same time, since you may have some railguns that require virtually no lead, some pulses that require a moderate lead, and a missile launcher that requires a big lead. With manual aiming, you're pretty much helpless, but with target assistance, your weapons can intelligently track your target, taking into account the projectile speed. Very handy Overall, the game has become much easier today! Maybe I will have to make it a bit harder in other areas now...! But combat feels a lot better now...I don't think lining up the shot should really be 100% of the focus when you're piloting a futuristic space ship. I will still include even more automated control (i.e., full-on automated turrets) at some point, since we will need definitely need it for larger ships.

Hammered some more on saving today, and it's getting more reliable and thorough by the minute. Started on saving AI state today, which is, to be honest, something I never had even considered that I would have working for the prototype release, but, as you know by now, I am very bad at implementing things partially. As I keep telling myself, it's one less thing that you have to worry about at release I'm also working on throwing together a loading/saving interface to manage savegames.

I did start giving my old friend the command interface some attention today, and I'm sure it will get even more tomorrow. It's going to be my primary focus over the coming week, as it's probably one of the last things that I need to shape up for this prototype!

PS ~ Can you believe I still don't have real internet? I'm going to go ahead and namedrop here and tell you that Comcast is a truly unimpressive ISP. It has been nearly two weeks since I first called, and I still have seen neither heads nor tails of anyone coming out to help me get internet set up, even after two follow-up calls. It's really killing me. I don't know what I'm going to do if I don't get it before the prototype launch The downsides of rural life, I suppose. They're basically my only choice for high-speed internet Rawr.

Hour Tally

Coding: 8.46
Internet: 1.71
Testing: 1.19
Thinking: 1,79
Total Logged Time: 13.15

Week Summary

General Sentiment

Mixed feelings. I never really wanted serialization to take up so much of the week, but, to be fair, it is no small task to save and restore state in a game as complex as LT, especially given that it's running in a custom engine...so all the work falls to me. In the end, like everything else, I'm happy that I wrote the system myself, and feel very in-control of it all, which is a great feeling. I'm also not particularly happy about the amount of time that I had to spend improving the engine with respect to memory usage, but, on the flip-side, I feel much more comfortable knowing that my engine is being conscientious. In general, I'm feeling really good about the solid foundation upon which LT is being built - as I mentioned, it's just a lot more mature than I would have expected by now. On the other hand, engine maturity isn't what people are going to be concerned with for the prototype, which is why next week needs to be the most hair-graying week I've ever had! (In a good way!?)

Major Accomplishments

• Implemented custom serialization engine from scratch (enables loading/saving)
• Implemented assisted targetting
• Implemented nearest-to-mouse targetting
• Significantly improved memory handling within the engine, resulting in many resolved leaks and stabilized usage during long play periods
• Improved targetting visuals
• Figured out how to distribute the prototype, including several contingency plans

Combined Hour Tally

Coding: 46.79
Composing: 0.08
Internet: 21.49
Testing: 7.40
Thinking: 7.59
Total Logged Time: 83.35