Now with more intentional pew pew, and randomly driving into stuff that doesn't need to be driven into

What's in there that you didn't see last time? A few things.

• I added in a raycast to determine if the shot that a box takes is occluded (by a static box, by a moving box, by a dead box), which makes things seem more purposeful.
• Not that you'd notice it, but there were several bugs in my collision code. One made the physics boxes twice as wide as they should have been, but only for dynamic tests, like for the paths of bullets and moving boxes. Thus the "corridor map" was out of sync with things that moved.
• Boxes target nearby boxes sometimes, they randomly pick places to patrol to sometimes.
• Boxes target nearby boxes, which may lead to one or more of them shooting them up (which, I know, you've seen that bit) or it may lead to them getting stuck in an embrace of, I want to say "death", but it's just an embrace of hostility - they're trying very hard to move into the location of the other box, which is simultaneously trying very hard to move in the opposite direction. I've seen two and three boxes get in these cycles. I could put some special case logic in there to say "oh, no, what you really want to do is engage at this ideal radius for this weapon", but I want to come back to that later, possibly with a different approach altogether.

It's getting to the point where the stuff I want to do next is largely falling under the category of "activity selection", like choosing to search for a better path for several ticks, or choosing not to patrol when a box discovers an enemy box. Also, there's stuff here I'll call "aggregate behavior" that I'd like to do, like allowing boxes to call for help, and flank their targets.

It feels like I've done a lot, and after spending a bunch of time refactoring just to fix bugs, working on this doesn't feel quite as exciting as it did before that, but things are in a better state, so that's good. I recently heard Jonathan Blow use the term "code morale" which matters on real projects and screwy little tech demos like this.

One thing you don't see in that movie is a piece I added in where I can hit a key to cycle a "selection" marker from colored box to colored box, which draws them with a little highlight, but more interestingly (to me, I don't want to speak for you good people), it dumps a bunch of debug spew to the console for just that one box. Hm, potential feature for approximately never: create debugging facilities that are keyed on the box, and a debug console that can select what feed to watch.

Now with random Pew Pew

The first thing here is that I'm experimenting with MP4 movies of my progress - I'm using ffmpeg to capture the video, since my previous method (using byzanz to create animated GIFs) had an upper limit of less than a minute. Maybe you get enough of all of this in 15 seconds, but I, for one, need more box-moving-around-time than that.

Also, I split the teams up finer. Now, we have 6 teams of 2 boxes each, in festive colors. Were the people demanding that? Festive colored boxes seems good.

Also, they can shoot at each other now. There's no intelligence involved - each tick, there's a 1% chance that a box will spawn a bullet in a random direction. Bullets check for collision with the moving boxes and the static boxes. If they hit a moving box, they apply damage. If they hit anything, they deactivate themselves.

Boxes that lose 4 points of damage become inactive.

You can almost root for boxes to survive, if you want.

TODO:
aim more intelligently
retreat from threats (when wounded?)
track weapon heat
call for help
flanking
particle effects when bullets impact

Boxes not hugging the other boxes

What you see here is the introduction of a "corridor map", a network of navigation landmarks that the boxes use to find their way around obstacles. It's an improvement over yesterday's behavior of getting stuck on walls, in that the boxes are somewhat aware of the obstacles now. They can still get stuck, so there's room for being more aware of not making progress on a plan and bailing out to try something different.

Boxes not overlapping

Adding to yesterday's demo, the boxes are now a couple different colors, still moving around. Now they bump into each other and use a simple constraint system to ensure that they don't overlap.

Also, I added some fixed boxes in the world that boxes might move around. Except they're not really smart enough to do that yet. Sometimes, they knock each other loose.

TODO: make stuff smarter.

Something a little different

This doesn't tie in to my previous posts, really. Just screwing around, getting a PyGame / OpenGL framework up and running.

There's a few boxes moving around the screen. So, that's something.

Spaceship Flying In Space

Back in college, before I knew much about anything, I gave a resume to a tiny little company called HDC Computer Corporation. That name kind of pegged them (constrained them?) to be a Microsoft Windows development house.

They managed to get some of their stuff bundled into Windows-286, if I recall correctly, including a little space shooter game called "HDC Rocks". Yes, it was about shooting rocks in space. Also, the title was a gag and tongue-in-cheek motto.

The Internet doesn't seem to remember that little nugget, but maybe it will now.

What you see here is the rebuilt version of as far as I had got on my "Space Rocks" demo - a little space ship moving around on the screen, rendering in OpenGL 2.1, with a window provided by SDL2.

Nothing's particularly exciting about it - the pathfinding, if you can call it that, is "move horizontally, then move vertically". There's no real obstacles. It doesn't have a lose condition.

But it's running again, OpenGL commands, as issued from my language, sent through a C shim to a vanilla OpenGL implementation.

As I mentioned in my previous post, I had lost a file (failed to check in my work) called gl_tools.c, which contained that layer, so the effort necessary to reproduce it was simply(?) a matter of exporting GL calls down into my library.

Sort of. The time management code is coming from SDL, so that took a little more attention. The initialization of an OpenGL context isn't quite as simple as I had recalled. I made use of Lazy Foo' Productions' SDL/OpenGL tutorial to figure out what bits I really had to rebuild inside my shim library.

And there you go, it's working again. And checked in, besides.

I even made myself a little convenience tool that launches the program, records frames of it rendering, then compresses that into an animated GIF all in one handy script. I could make it slightly cleverer, by forcing the window to open up at a particular point on the desktop, which would keep you from looking at my emacs window in the background. But maybe emacs makes you comfortable. I wouldn't want to deprive you of that.

The cursor, though, not so sure about that. I could easily suppress the cursor.


So. The demo is back up and running, and the thing I was running into back in July when I last checked stuff in (I don't remember this stuff, but GitHub does) was that I wanted to have a solid story about what I was doing with arrays of complex objects (like structs, say, like you might need to have for a bunch of asteroids floating across your screen). Would arrays have to be statically allocated? What's initialization like? Am I going to have pointers to these things? Python and Java don't have pointers, except that they do, but you don't see them. Is that what I want?

I want to avoid copying complex objects except by explicit deliberate action. It feels like there are a few other choices that can come as a result of that, but I haven't really meditated deeply enough to make it obvious how things ought to work. Perhaps the next step is to try some stuff, and be prepared to roll back if I don't like how things are working.

Setbacks, and starting not from scratch

So, it's been a while since I've posted about my compiler project. Projects being what they are, you don't always have steam for everything.

And then, a few months ago, the laptop where I had been doing my development was taken. I can curse the darkness, but it's not as bad as it might have been - I had most of the project checked in to two offsite locations. So, that's nice.

At the risk of Pollyanna, this is an opportunity to verify that I don't have hidden dependencies that I wasn't aware of. So, I'm starting on a new machine, and hopefully, I'll be back to productivity soon.


I've added a Prerequisites page to my development Wiki. (Is that external? I forget. Probably not, or I'd link here.) It's the stuff you'd expect:

• LLVM 3.6
• libedit-dev
• enum34
• llvmlite
• PLY
• emscripten
• SDL

Ok, maybe not all of that is expected. I think llvmlite's dependencies could be tidied up. And maybe I don't need SDL for everything, but for the Pong sample app, I did.

Once I got stuff installed and cloned the repo down onto my machine, I built the pong demo as a local executable, and it worked great.

I haven't yet rebuilt the web version, but you can play it here, if you like: http://bigdicegames.com/BDGRT/Pong/pong.html - I just link it because I keep forgetting where it is, so this is a bookmark for my own purposes. Also, I notice that that doesn't play nicely with my (current) version of the Chrome browser, but it does in Firefox.

Looking back through my checkin log, I see that I had been doing work on my Asteroids tribute sample, but when I try to build it, it looks like gl_tools.c never got checked in, so I get to rewrite that. How hard can that be? Just wrapping stuff like gl_begin and gl_color3f. I should be able to knock that out in short order, maybe tonight.

I'm also noticing that building emscripten targets (like the web version of Pong) is failing, probably due to not having installed certain bits of emscripten.

But, I'm delighted to say that my little test programs for computing factorial and Fibonacci stuff worked just fine.