It's Been a While

   

A few years is a long time. If you don't care to listen to a ramble about what's happened in that time, skip down to the asterisks. I've finished college, had a job as a night stocker at a local grocery store, made a trip to Canada happen, moved out of my parents' place into my own apartment, and have had a job with a small web app company for almost a year and a half. I'm a legitimate paid programmer now. It started off as being a "support technician", an assistant to the guy who took customer call/emails and made changes to the database. We also had a guy doing automated testing, and they noticed my enthusiasm for the subject. After about a month when we'd worked down the support guy's backlog and ran out of stuff for me to do in that area, they moved me over to the automated testing alongside the other guy.

    It took a long time to learn all the ins and outs of the testing suite's code base, which had changed hands multiple times over the past ten years, and grown all sorts of warts. The site code has also gone through a lot of phases. This article basically describes what my job has been. But I'm a fast learner, and grew in skill quickly. One of my biggest accomplishments was an optimization in the test code's wrapper class for working with web page elements, which literally cut the test suite run time in half. Improved handling of table navigation, upgrading the suite to Typescript from an ancient JScript implementation, adding and improving many tests. Eventually the support guy and one of the developers moved on. Between me and the other tester, the other tester was moved into the support guy's role and now I'm the lead (and only) automated tester.

    More than that though, I've improved and automated the process over my time here. The test suite used to run in one giant 8-hour overnight chunk where if anything failed or stalled, nothing would get tested until we started it again. I developed an automated system in C# that listens to our existing automated system for builds - when anything new gets built, it gets pulled down to the test environment and kicks off the relevant tests. They're on a distributed queue system, where every active machine picks up the next test in the queue, also grabbing any test code that has been checked in. There's also a web UI I made for checking on the automated testing, with progress bars and such. The process is incredibly smooth now. A developer checks in code and within a few minutes to a a couple hours depending on the extent of the changes, they can look and see if everything passed or if something broke and where, without having to fiddle with the build or testing process themselves.

    It's not just test writing though. As I've improved efficiency across the board and worked down the pile of testing To-Do list, my boss has handed me a few development style tasks. If there's a bug, he'll have me look into and fix it first, only coming to him if I legitimately get stuck and he points me in the right direction, or the fix is more of a major redo of how something works. The latest task had nothing to do with bugfixing or testing at all; instead he had me develop an internal tool to track what customer databases have had what changes applied to them. Now if there's a restored or "dead" database to be resurrected, simply running a stored procedure will necromance it up to date with the rest as if by magic. Also written in C#.

*****Adventurer News*****
    So the point of that whole ramble is to say that I've learned a loooooot about programming and C# in particular over the years, especially in the past year. Now that I've gotten more adjusted to my job, I feel comfortable in starting to work on Adventurer and other projects of the evenings and weekends when I'm not unwinding or taking care of adult responsibilities. I've already retooled how Adventurer loads in content like creatures and all the way down to atoms to use XML instead of the more difficult parsing from a text file in my own unusual format. Hopefully that will make it easier for any future modders to tweak the makeup of the universe.

    Currently, I'm working on moving off of the Tao.SDL library to MonoGame. SDL's a C# port of a C++ port of a low level C library. As such, it's difficult to work with. That attached screenshot? That's an Adventurer level being loaded and displayed in MonoGame. Anyway, I do apologize for being gone so long. While I may not be able to work on this as feverishly as I used to with a third of my life being work and another third being sleep, I feel comfortable enough in starting to make a little of that remaining third about development on Adventurer again. You can follow the project on GitHub at https://github.com/Kalasen/Adventurer. Don't forget to pick up the KalaGame library as well, where I'm starting to move the bits from Adventurer that are useful in other projects I'm tinkering with.

New Computer WOO

So I've got the new computer and it's awesome. Really, really awesome. Almost nothing lags any. You know how on most computers you'll click a menu or start a program and it will delay a couple seconds? None of that. Minecraft runs smoothly at full settings and only takes seconds to load up a world to where you can see as far as you'd like. The only bad thing is that I have to move all my awesome software from my old computer to this new one. Including Visual Studio and Resharper.

The computer comes with the full CS5 package. Photoshop, flash, other stuff. I've always wanted to learn flash but haven't because Flash CSx is absurdly expensive, like "four times the price of the computer" expensive. Just for a fairly inefficient language for moving 2D images around. But, a lot of people use it, and I'm considering becoming a flash developer on Kongregate. So updates here may be slow while I play around with tutorials in that, and get all my old software moved over. On the plus side, I may be releasing something relatively quick and simple on Kongregate.

New Computer

Hey everyone, it turns out that my webclass stuff needs me to use Unreal Toolkit 3, which my computer doesn't run, because my video card doesn't support "Shader 3". My computer's starting to get old, so it's a good time to buy a new one - and I found a good deal on a custom-built gaming computer that the guy is selling to pay the bills. I've looked into the specs on it, and it is godly for only $500. Like, "play Crysis 2 on Very High graphics smoothly" godly.

I've been messing around with OpenGL more to see if I could squeeze some more power out of my system to draw blocks with. Well, when I get the new system, I won't have to worry so much. I can optimize and port to OpenGL later on. So, more descriptive updates on what's getting done when I get the new computer tomorrow and work with it.

OpenGL D:

I worked with openGL some. While I can work with it, I can tell that development would be much slower due to having to fuss with it more than XNA. Which isn't to say that openGL is out of the question. In fact, my plan is to write the game that I am now thinking of calling Open World, in XNA. And once sufficiently far along, port it to openGL and hence allow other operating systems in on it, while possibly getting a gain in efficiency.

That was part of what I was doing. The other part was research. Which is to say, playing Minecraft and attempting to play Infiniminer (which didn't want to run right). I play Minecraft survival multiplayer. What I like about Minecraft is the dual nature of resource gathering and using the resources. If you spend your time doing stuff like mining, then you might as well build something huge with all the stone. If you go around killing cows and farming, you might as well explore caves or stay out at night. What I don't like is how in single player you get to the end of the development tree quickly - once you've made a rail system, there isn't much else worth doing. If you're going to spend your time on megaprojects, might as well do it on multiplayer so others can see. Also block lag - I've died to blocks I've placed disappearing out from under me, only for them to reappear. It's like the server says "Okay, you've placed a block. Oh wait, you might not have. Okay, now I've gotten confirmation that you have." Don't undo an action until you're sure, server.

Ahem yes, all research. I haven't been a total waste of the past two days, either. I worked on Open World more, found out openGL is hard but not impossible to work with, and then did something else. I redid the world to hold data on a near-infinite span of land, only limited by running out of integer indexes. The draw code for it hasn't quite caught up to speed though - I exploded blocks outward when it should have been drawing all chunks offset by the chunk position. I'll work with the math on that. When it works, it'll be screenshot-worthy.

If I can get that and some basic collision physics going without bogging down the system too hard, I may do the first release.

Threading. OpenGL?

I experimented with threading and am pleasantly surprised with the results. The only irritating bit was that the most obvious way of doing threads only takes methods with no parameters. It's a bit more esoteric to do a method parameters, but the end result is just one line extra. It let me place or dig blocks and keep on moving while the world recalculated everything.

I am becoming increasingly aware, though, that XNA may not be the best choice for this. I'm trying to render a million blocks, after all. The alternative is to work with DirectX directly, or to use OpenGL. If I stick with XNA, I can run things on the Xbox. If I go with DirectX, I'm stuck Windows-only. If I go with OpenGL, I can run cross-platform. So, I'm going to attempt to learn and use OpenGL.

If openGL is anything like SDL was with Adventurer, it'll be a nightmare to work with. But damn fast. So I'm going in expecting the worst. It really should be the most blindingly fast thing I can do, though, since openGL is made for drawing 3D primitives.

And if that's too much of a headache, I can go back to XNA. Infiniminer was made with XNA, after all.

Threading?

I'm in the process of changing up how chunks are stored so I can have a practically unlimited amount of them, and hence space in the world. Stuff like travelling between chunks, too, and figuring out an efficient way to do chunks that are far away.

But I'm also looking into the concept of threading. I hadn't looked into it before because I thought it was only useful for multicore systems. Apparently that was multithreading I was hearing about, where you run multiple threads simultaneously. Plain old threading is when you tell two different blocks of code to run together, taking turns with the processor. Of course, you can't have one rely on the other.

I think that will help resolve the temporary lag I was having, followed by long stretches of good processing speed. Spread the process out over time, while still allowing regular game play to go while the computer works. The only thing I'm going to have to work out is that vertex buffers ^are^ critical to drawing and hence the flow of the game, so I'll have to do something to smooth the border.

Anyway, I'll get threading worked out at some point so that I can improve practical efficiency. For now, I'm working on having a large world, and multiple textures.

First Person, Digging, Placing

Whew. I did a lot of work today. I fixed that bug I was having with the world disappearing - I had set it up to work with multiple vertex buffers, and to make a new one whenever it crossed a 65000 vertex border. I had neglected to tell it to also make a new one to put the leftovers in.

So, with that done, I was finally able to see pits being dug. The picking was a little bit misplaced, but I adjusted and got the ray lining up exactly where I wanted. That was awesome. I went ahead and added code for placing blocks, too, and that worked out. The only bad thing about the whole thing is that there's some lag when doing it, because it has to refresh all the vertex buffers. I'll be optimizing that, as well as making it to where I can do varied textures, so you'll have stuff like dirt on the sides and bottom of grassy blocks.

The other major thing I did is first person camera. It's no longer free flying. It also is controlled by the mouse rather than keys. What's the big deal about that? Well... First thing is that with control done by mouse rather than keys, it feels very intuitive. Just move the mouse around to move your view, just like other first person games. With it no longer free flying, it means you won't get your roll messed up and lose your sense of balance, and you're pretty solidly on the ground. Muuuch better.

Next thing I'm working on is preparing for multiple textures, and optimizing the speed of things. Multiple textures because duh, that's important for knowing what you're dealing with in a world of blocks. Optimization because there's a fair amount of initial load time with just 64x64x16 blocks, and yet more lag whenever you change the world due to all the recalculation. It's a little different than the whole turn based thing I'm used to.

But this is definitely starting to come along.