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

Post

Week of February 3, 2013

#1
Sunday, February 3, 2013

Summary

Although the hours might try to portray today as another slow-paced-Sunday, don't listen to them, because I swear it wasn't!!! Yesterday, I said I was going to start playing around with power grids. Today, I finished implementing power grids, including the foundational code, UI, and mechanics... :D

Indeed, it's every bit as fun as I was expecting! One can boost power to thrusters, for example, and the thruster trail gets bigger, redder, and the ship goes faster. It's quite fun. If you turn all other subsystems down to zero power (I.e., route 100% of power to propulsion), you can hit some pretty sweet speeds! Of course, you'll never be able to kill anyone, since your weapons are down...but man, you sure could scare them, rocketing toward them at lightspeed, pretending to be a kamikaze craft 8-)

Routing all power to weapons is equally fun. For the case of pulse weapons, they fire faster. In the case of beam weapons, they hurt more. In the case of missiles...well, I'm not sure exactly what will happen yet (open to suggestions, as always). But what's more fun than just routing all power to weapons, is routing all power to ONE weapon, and turning the rest off. So you're left with an uber-chaingun that's firing like 1000 RPM or something like that. While fun, this tactic is not necessarily efficient. I have made it so that overclocking a subsystem does not scale linearly. The scaling mechanism will most likely depend on how efficient your power grid is, but, suffice it to say, doubling power will never mean doubling output - it will always be less, perhaps by a small margin, perhaps by a large one. In that sense, if you have 10 weapons, distributing power evenly among them is always the most efficient mechanism, as opposed to taking 9 offline and routing everything to one. With this scheme, it's still advantageous to buy lots of weapons. Nonetheless, if, for example, you know that a certain weapon is very powerful against shields, and your enemy still has a shield up, then you might gain an advantage by overpowering that weapon, even if it means an overall loss in efficiency.

Anyway, even with this very simple system, it's clear to me that great depth is going to emerge quickly, and I like how it leaves the door open for players to develop their own power management style. Of course, if you never want to touch these in-depth things, you don't have to! Distributing power evenly among systems is a fine policy. In addition, if a subsystem gets destroyed, your computer will automatically redistribute the extra available power. So for players that want to keep it simple, you're welcome to do so! I'm also planning to support binding power settings to hotkeys, so that you can quickly switch between your various saved settings (for example, hit a single key to divert all energy to propulsion and make a quick escape).

On top of implementing that mechanism, I also worked on the first rendering widget, which is intended to display an orthographic view of your ship, along with hardpoint information. It's a nice way to get a graphical view of your subsystems, and the subsystems are represented by icons that tell you the subsytem type, integrity, and how much power they are receiving. Currently, I'm encoding all of that information in concentric rings. I quite like the radial icon look. It seems very slick and futuristic. Unfortunately, I'm not so sure that it's the most effective way to encode information, as I can't really tell yet whether the player will be able to ascertain the information quickly at-a-glance with these radial icons. Oh, and, since the holographic effect shown in the command interface was so popular, it will also be the rendering style used for this hardpoint/ship information view :)

Hour Tally

Coding: 4.03
Internet: 3.34
Testing: 2.65
Total Logged Time: 10.01
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
Post

Re: Week of February 3, 2013

#2
Monday, February 4, 2013

Summary

Great day, although not particularly coherent!

The ship hardpoint viewer / power configuration interface / I'm-not-really-sure-what-to-call-it is looking better all the time! At first, it started as the power routing interface, but, going with the theme of unification, I don't see why I shouldn't just turn it into an uber-interface for all your single-vessel needs. Collapsible power controls, cargo view, module statuses, general ship information, etc. I don't think we really need different interfaces for all these, so I'm going to explore unifying them. I'm really pleased with how the new interface is turning out, and it's clear to me that my frustration and earlier time investment is going to pay off in a big way! It's really easy to create functional, organized, and good-looking interfaces. I think I've found the right balance between programmer art and artsy art! :D

Speaking of programmer art, I'm finally content with missiles! (A note on Josh language: "content" < "satisfied" < "pleased" < "excited about," so "content" is really only the first stage of acceptance, but anything lower is not even given an adjective, it's just avoided in conversation at all costs, so at least we can now speak of missiles). I spent some time overhauling missiles today, because, although I had returned them to working order a few days ago, they were still ugly as...well, something very ugly. And I really like missiles, so that's just not acceptable. Now they actually look kind of pretty, so it's fun to shoot missiles again! I'm sure there will be more advancements in that graphical area at some point.

I also started on a generalized configuration system, to allow customizing the game. I want LT to be insanely customizable, but also for that customization to be quick, easy, and intuitive to access. At the same time, I want to be able to code things quickly and not always worry about exposing parameters. So I built a system that allows me to perform a simple call into the configuration engine to "tag" a variable as configurable, and it will automatically generate a configuration widget for that variable in the appropriate category of the configuration menu. Cool! But I then arrived at a point where I wanted to make a color configurable...which, naturally, led me to..

...color wheels! You know, those things where you click to select your color. They're kind of the obvious choice for...picking a color. So I implemented an interface widget for them. Sadly, I had way too much fun doing so, and the result is...a very futuristic and stylish color wheel, if I do say so myself. It goes well with the holographic interface :P Who would have thought that picking a color could feel as sophisticated as configuring the exhaust manifolds of a warp core?! 8-)

Hour Tally

Coding: 7.79
Internet: 2.11
Testing: 1.81
Total Logged Time: 11.72
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
Post

Re: Week of February 3, 2013

#3
Tuesday, February 5, 2013

Summary

Today, I was, yet again, all over the map. The day started with more work on the power/ship/hardpoint interface, but, at some point, I got hit with a few issues from the UI engine and had to set out on a debugging trail. Upon returning, I spruced up the command interface some more, and proceeded to perform many more generic tasks :P

I then took some time to do a lot of serious thinking about combat and AI. In particular, I'm still trying to come up with the best way to make the AI smart in terms of how it assesses and handles threats. Today I think I came up with most of the equations that I need to implement this in a powerful and simple way. However, I am still left with one big unknown. I call it "P_hit". It is the probability that a shot coming from a particular weapon will be able to hit a particular target. This is, perhaps, the most critical calculation required to make the AI "smart," and, additionally, to make the out-of-system simulation code work well. I think it's also the place where games generally fail pretty hard (well, I'm actually not sure if they generally factor such a variable into their combat simulation equations, but, in theory, they definitely should). Calculating P_hit is not easy. It must take into consideration many factors: the distance between the weapon and the target, the speed of the projectile, the uncertainty in the projectile's motion (how accurate the shot is), and the target's speed, maneuverability, and size, along with the uncertainty in the target's motion. I'm working on cracking this one, but it's tough, and I'm sure it's one of those things that I'll have to keep refining. Thankfully, all other calculations in the combat system are basically trivial, and it's fairly easy to see that they are optimal.

After noodling around a bit more in the code, I decided that my codefocus wasn't quite right today, so I laid down the coding sword for a while to turn to composition. That's one of my favorite things about doing it "all" - you've never got an excuse to be bored! If you get tired of coding...just move on to composing. If that gets tiring, peruse the forums, work on the design doc, work on the images/wallpapers/logos, work on the website...so many alternate activities from which to choose! And today I chose composing. Thankfully, that ended up leading me back into the coding zone!

I know that I've talked about my desire for a dynamic music system in a previous dev blog, and today, I'm hoping to make that a reality. I've rendered out two versions of a new test track (in the final game, I think I will have three versions of each track), and am writing the code now to fade smoothly between them based on a "tension" input. It should be very cool/immersive if it works :)

Hour Tally

Coding: 6.61
Composing: 1.85
Internet: 2.25
Testing: 1.07
Total Logged Time: 11.78
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
Post

Re: Week of February 3, 2013

#4
Wednesday, February 6, 2013

Summary

Very cool developments today - the dynamic music system is in place and works like a charm! Well, that was easy... :D Although I could make it seem like a big deal and convince you all that I've slaved to implement this feature...I'll tell you a secret...I finished it last night about 30 minutes after I wrote the dev log :P

But really, there's not much to it, after all. Music crossfades between different versions of the same piece depending on whatever variables you want. Right now I think only one variable, "tension," is sufficient. Even though I tested with only two versions of the same piece, the result was still very encouraging. You could definitely feel the tension building as the crossfade happened. Now, all I need to do is wire that up to some "tension detector." I guess that part's going to be a bit more interesting, but probably not hard.

I then proceeded to take on an odd and somewhat random endeavor: making a launcher for the game. I'm not exactly sure why or how I'll use it, but every game needs a launcher..right? :| I'm thinking the main purpose will be to detect hardware compatibility issues before the game launches, and to set the graphics options. I was successful, and I now have a launcher. I haven't added anything to it yet, but the main idea is that I have a stand-alone executable that doesn't invoke any of the core LT engine, so if there's a compatibility issue, the launcher should still be able to run even if the game can't.

Now, let's talk about formations. I started to launch into writing a formation editor, but, thankfully, I pulled myself back and stopped to think about it for a while. I realized that I'm not actually sure how to implement formation editing in the most simple, intuitive, yet powerful way. The obvious answer is to just...place markers in a 3D viewer widget, and have those markers define where your ships are going to be. But I don't like this approach. It's dumb, and it doesn't take long to see the problem: how many markers do you place? Suppose you want to create a wedge formation. Are you going to create variants for 3 ships, 4 ships...100 ships? No, I don't think you have the time to place 100 markers. So...is the wedge going to be a "special" pre-defined formation, because it can intelligently support infinite ships? What about your custom formations? What happens when I add a 12th member to your formation that has 11 markers? Where does he go? Random choice? Follow one of the 11? Try to extrapolate from the pattern that you designed? Clearly, formation editing isn't as immediately-obvious as I thought.

Thankfully, math comes to the rescue yet again. The more I think about it, the more I am convinced that a formation is nothing more than a (set of) 3D surface(s) in space. Units are some kind of sampling pattern over that surface. Wedge, for instance, is two rays. Or, better yet, one ray, mirrored about one of the cardinal axes. Box formation is...a box! Sphere formation...a sphere! Line formation...a line! Indeed. Seems that 3D surfaces are the natural way to represent formations, and they are extensible, since a surface is continuous, not just a bunch of discrete points. So I think I will proceed by allowing you to place different "shapes" that will define the formation, and then perform operations like mirroring (if you want a symmetric pattern). I think this will cover most formations that you would want to make, and it has the nice property that it doesn't matter how many ships you put in formation, it will naturally extend without a problem.

This raises the tricky question of what constitutes a "good" sampling pattern over an arbitrary 3D surface. This is actually a much deeper question than you might imagine, and invokes lots of ugly math symbols that no one wants to look at. I don't have a perfect strategy yet, but I do think I'm close to a nice solution that uses a bit of fractal fanciness to cover surfaces in a nice way, so that your ships will appear orderly no matter how many of them there are :geek:

Hour Tally

Coding: 4.13
Composing: 1.79
Internet: 3.04
Testing: 0.27
Total Logged Time: 9.23
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
Post

Re: Week of February 3, 2013

#5
Thursday, February 7, 2013

Summary

A hardcore and highly-productive day, although with absolutely nothing exciting to report! :| I mean, not exciting to most people, at least :D

Thinking about building a formation editor led me to thinking about the graphical display, which led me to thinking about how I would like to use a holographic-style display, similar to the command interface, just like I used for the power management display. But that scratched at a wound that I've been ignoring for too long: it took too much code to implement the command interface's graphics, and, consequently, too much code to implement the power management graphics. Even worse, a large part of this code was duplicated between the two, because no good mechanism existed for reusing that part of the graphics code. Implementing a formation editor in a similar style would mean a third area of somewhat-duplicated, too-long-for-my-tastes code. This is always a sign that something is wrong - that the architecture is not as beautiful as it should be.

Yes, I knew it was highly-flawed when I wrote the command interface graphics, but, at the time, I could not see a better solution. The problem is that of abstracting the process of "displaying" a world. This problem runs pretty deep, because, at the object level, you're generally not thinking about alternative ways that an object could be displayed - just the most straightforward one. Yes, I expect this asteroid will look a lot like a big floating rock...so I'm going to write code that does that. But what happens when you want it to be a shimmering, blue hologram depicting a rock, rather than something that actually looks like a rock? Tough question, and requires a very flexible rendering architecture to do it in a clean way. More flexible than I had yesterday.

As you might expect, my work today consisted of changing that, and now we have no problem supporting arbitrary ideas of what it means to "display" an object, all in a very clean way :) But this problem led me to a more general re-work of a lot of the core rendering code. Problems tend to be like that...you clean the mess in the kitchen, but once you're done, can't help but notice some dust in the other rooms...might as well nail it while you've got the cleaning tools out.

As a result of today, the command interface has shed about 200 lines of graphics code, which is a fantastic thing. Furthermore, the code for displaying things in a "holographic" way is now a first-class, formalized idea/system, and can be reused by whoever wants to display a hologram. Should be very easy to implement the formation editor in the same style. I'm also close to being able to do postprocessing in sub-windows, which will be a very cool thing, and will allow for some really beautiful UI widgets!

And now, a bit of philosophical garbage concerning my approach to this game :roll:

Over the past few days, I've come to realize that I'm not nearly as efficient at "grinding code" as I am at "thinking about code" / abstracting it / making it more beautiful. When I have to sit down and actually implement an interface - as in, figure out what instructions to feed to what system to make it look good/work/whatever - it's never that exciting for me. What's more interesting to me is, how can I design a UI / rendering engine / whatever that facilitates the construction of this interface in the minimal possible lines of code? As you can see, when that's the task, I have no problem devoting almost all of my waking hours to it. That's what I find to be most fun. I've decided that I should try to embrace this trait as much as possible, because I think it's a positive one. Part of what has made LT successful so far, I think, is my obsession with this process of abstraction and minimization, which has allowed me to do fairly complex things in short amounts of time. As I continue to press into new territory with respect to gameplay, I hope that I will always be able to find the most elegant, clean, and small solutions to problems...and I hope that I will always have days where I get to tell you "sorry, nothing exciting for you today, just loads of beautifying"!

PS ~ Another thing I have discovered today is that you can watch people play games online!!! How was I not aware of this phenomenon :o I've been using this site to watch people play Skyrim: Dragonborn, since I can't do so. And, hey, it's almost as good as playing it! Plus, you get to sit back and watch while they do the hard work of playing...AND you get to work at the same time! Part of my great coding hour count today was thanks to the fact that work is much easier and faster when someone is playing Skyrim on the screen beside you :D At the risk of sounding a bit crazy, I actually think this will be a brilliant productivity tool for me. If any of you have Skyrim feeds...lemme know :geek:

Hour Tally

Coding: 8.27
Composing: 0.02
Internet: 2.88
Testing: 0.96
Total Logged Time: 12.13
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
Post

Re: Week of February 3, 2013

#6
Friday, February 8, 2013

Summary

Not as productive of a day as I would have liked :| I accomplished two main things: icons and tooltips. Icons are going to be a big part of various menus, and I wanted a formal system for creating and using them. Of course, in most games, this system consists of...loading an image file! But, as you should probably have already guessed by now, icons in LT are procedural, defined only by some math in a pixel shader :) So I've implemented an icon system that has knowledge of the math required to make particular shapes, and will allow me to define new icons very quickly. Unlike normal icons, the icons created by this engine are easily-scalable (they are more like vector graphics than raster graphics), and it's also very easy to make them interactive (changing color, shape, etc), which will be a nice feature! As for tooltips, I don't think there's much explaining required - when you hover over a UI widget for a while, it has the option of displaying some helpful info. Details like that are going to go a long way towards making LT seem user-friendly, which I really want! As I've said before, I never want playing LT to be like figuring out how to perform a very complicated job. That's not a game!

Despite the lack of apparent progress, I did a lot of quality thinking today in an effort to figure out why my productivity seems to bounce back and forth so much - some days seeming like massive coding jams, other days (like today) seeming slower than tolerable. I think I've come to the conclusion that I need to start defining and thinking about my problems more carefully before touching the keyboard. Not that I don't usually think before coding, but, as you can probably tell, I went into this project with a very strong mentality of "log as many coding hours as possible." Thinking more about this, however, I realize that, sometimes, I sit down to log some coding hours without having a clear idea of what I need to accomplish. Today was an example. Although I really need to build the formation editor (because it's the thing blocking me from implementing formations, which is the thing blocking me from extensively testing combat AI, which is the thing blocking me from making combat fun, which is the thing blocking me from releasing the prototype, which is the thing blocking me from fulfilling the first of my KS obligations, which is the thing blocking me from finishing the game), I don't yet have a clear picture of what I want it to look like. I think this has led to procrastination. Naturally, when I sit down to code something that doesn't have a well-defined form, purpose, or function...non-coding activities suddenly seem far more appealing. It's led me to what some might call the least profound revelation ever: you can't solve a problem that you haven't defined.

So, that being said, I'm going to try doing a better job of clearly thinking through and defining my problems before being so gung-ho about the coding. Maybe it was a mistake to set my goal at 11 hours of coding per day (which, as you probably have noticed, I have still not managed to hit...). Maybe I should have set my goal at 11 hours combined coding + thinking time per day? Many days I do feel like I could go for 11 hours...but those are the days when I have a strong sense of purpose and a vision of exactly what I want to see happen. Today, I didn't know exactly what I wanted to see, because I didn't know what I want this formation editor to look like. How could I possibly expect my codemonkey side to code it if I don't even know what I want it to be? :? I don't care how good of a coder you are...coding an undefined feature is pretty tough!

I guess I should have known that all along? Perhaps it's because I'm not really used to having a poorly-defined goal. I come from the world of graphics, and, to be honest, we are pretty simple-minded: we like for things to look pretty. Getting things to look pretty is usually a fairly well-defined goal, and the results are immediate and easy to judge. It will take some work to re-orient myself toward this world of game programming, where the goal is often more abstract than evoking the "oooh, shiny!" response. Anyway, when I hit submit, I'm not breaking out my code editor...I'm breaking out the notebook, and I'm not touching the keyboard again until I have a well-defined formation editor :)

Hour Tally

Coding: 5.02
Internet: 2.04
Testing: 0.70
Total Logged Time: 7.76
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
Post

Re: Week of February 3, 2013

#7
Saturday, February 9, 2013

Summary

Yep, I think I figured out the secret 8-) Today, as I said I would do, I thought carefully through everything before I started coding. And the result was an immensely productive day - at least in terms of conceptual ideas! Sure, I don't have a lot of concrete code progress to show, but I've got at least ten pages of notes on everything from why the command interface and the normal display are actually the same thing, to an elegant way to attach icons to in-game objects, to a unification of about 5 different interfaces under the same system, to ...yeah, it was a productive day :)

I find that my ability to concentrate on code is greatly heightened when I'm surrounded by sheets of notes on what I could implement and why it would make things better. Conversely, when I'm at a loss for something to implement, it's easy to just break out the notebook and lose myself in the abstract world of inky thoughts, hoping that they will somehow find their way back down to a concrete revelation that will make everything easier (and, believe or not, they do so quite often!! :) ).

This is the kind of day that creates more tasks than it closes...but I like it that way. I have a lot to do before I can even touch the formation editor, but once I do, it will be easy, and so will numerous other possibilities.

I have a very good feeling about my new development style. From now on, I am changing my target to 11 hours coding + thinking time. I will continue to distinguish the two in my logs for the sake of precision, but you should only consider the sum. It's what really matters - I have found that neither activity is more important. One without the other is inefficient. Today I easily achieved 8 hrs coding + thinking time, and I felt that it was quite a light day. For the record, 8 felt pretty heavy in the past. With this cycle of think/code, I believe I will be able to get much closer to, if not hit, my goal :D

Onto another, more well-thought-out week!!

Hour Tally

Coding: 6.17
Internet: 3.10
Testing: 0.45
Thinking: 1.74
Total Logged Time: 11.47
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
Post

Re: Week of February 3, 2013

#8
Week Summary

General Sentiment

Looking at the list, I'd say it was a very productive week! I can feel myself getting more efficient with my time, which is good, and has led to more accomplishments in the same amount of time than usual. I hope to see this trend continue for a long time to come. Other than the numerous little developments of this week, I think, for me, the most important was the somewhat stupid realization towards the end of the week that I really need to think about my problems more carefully before I attempt solving them. I guess the more profound part of that realization was that a lot of my inefficiency stems from it - without a clear problem to solve, I'm far less efficient with my time. I'm looking forward to trying to be more deliberate about this in the future and, hopefully, start squeezing even more out of my hours!

Major Accomplishments
  • Implemented power management and the accompanying interface
  • Implemented UI widgets that can render 3D views of things
  • Implemented general customization interface
  • Implemented color wheels, icons, and tooltips
  • Implemented dynamic music system, created first test piece with great success!
  • Improved missiles
  • Made the skeleton of a game launcher
  • Lots of great changes and cleaning to the rendering engine
  • "You can't solve a problem that you have yet to define" not-so-deep revelation + accompanying change in work habits
Combined Hour Tally

Coding: 42.02
Composing: 3.66
Internet: 18.76
Testing: 7.91
Thinking: 1.74 (Well, I only started logging today...I do think on most days :P )
Total Logged Time: 74.09
“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 2 guests

cron