Pixel and I face off in the latest build of Valley of Bones (with control points!), and despite being pinned down at my base for most of the match, I pull off a stunning upset!

Watch the clip on twitch.tv.

As you can see, the development of Valley of Bones is coming along quite nicely, I’ve added a new “Sniper” unit and I’m currently experimenting with control points (the towers in the video above). So far, I think the game is quite fun and interesting, but I suppose I might be biased.

Anyway, the control points build is in the nightlies (still experimental) here.

And you can also check out the “weekly” stable release here, though it doesn’t include the control points.

Until next time!

Remember that one time I said I was going to stop releasing a new game every month and focus on iterating on one game? I lied. Or maybe was just “mistaken.” Technically, I did spend some time iterating on Legend of Rogue the first couple weeks of April. Then, with the Ludum Dare coming up I was inspired to take some old code I had laying around for a space RTS and do a massive overhaul to turn it into a small multiplayer turn based strategy game. I’m pretty happy with the result, which I call “Valley of Bones:”

Valley of Bones

Again, I’m planning to further develop this in May, but who knows when and how inspiration will strike, so no promises! Anyway, the game is quite simple: you start with a home base that looks very much like a castle. The base provides an income of $100 per turn and allows 15 supply (you can see your current money/supply in the top right corner). On your turn, you may build, move, and attack with units in any order you’d like, though you only have 1 minute to do so.

If you select a unit, an information panel will pop up at the bottom of the screen to show the unit stats including:

•  health
•  attack damage
•  range
•  armor
•  moves per turn
•  attacks remaining this turn
•  moves remaining this turn

Those last two symbols also appear on the unit itself when there are attacks or moves remaining that turn – to make it easier to tell which units you can still work with.

If you press ‘b’ or click on  in the lower left corner, this will bring up the build menu, which only displays building options that you can currently use. Mouse over these options to see the money and supply costs.

The game ends when one player destroys the other player’s home base. To play multiplayer, one player or the other will also need to run the server that is packaged with the game.

I’ll try to write up another post this week detailing my future plans for the game.

Enjoy!

Download Valley of Bones

Well, I’m going to participate in my first game jam…and for charity!

The guys over at Ludum Dare have organized a mini-competition to create games as a benefit for the Make-A-Wish foundation and Kiva (micro loans for small businesses in impoverished areas). If you’re interested in participating, donating, or playing the submitted games, check out: http://charitygamejam.com/

Oh, did I mention the theme is 8-bit retro (NES-style) games? Pretty cool.

I’ll probably tweet with updates on my progress.

So for November/December I’m going to work on a number of side-projects, I believe, in the ‘style’ of http://experimentalgameplay.com/ … ie: spending only a short amount of time (hopefully a week or less) on  these projects.

Anyway, I’m also interested in working with multiplayer/online programming, so I thought I’d remake an old classic…Pong. Or, in this case, NetPong. Anyway, the idea is quite simple: a Pong game where you play against an opponent over the network. I’m using LibGdx for the engine and KryoNet for the networking (which only supports client-server, if you’re curious).

So, as you might imagine, in order to keep up with everything in real time, the server runs the network code and the game logic in separate threads. So, after coding the basic client and server apps and making everything update over the network…I got a super-laggy looking game. Boo! Well, having never worked in a multi-threaded environment before, it took me awhile to realize the problem: since the game update is running in a separate thread from the main application, it was calling update multiple times in the same frame. Since I’m using the LibGdx builtin Gdx.graphics.getDeltaTime() to measure time, this caused huge problems! The server was running way faster than the client!

Of course, once I realized this, the fix was easy: only update when there’s been a new frame drawn. So now the ball moves smoothly, at least. The paddles still need some work, but that’s all right. Screenshots will be forthcoming.

Check out the newest release of Space Domination here!

Sorry I haven’t posted anything in awhile, I had to get motivated to move the dev blog over here first, and that takes time away from programming! Anyway, here are the major new things in the release:

Redesigned HUD

Well, if you played any previous version of Space Domination, you know the HUD was…well…clunky to put it mildly. It was basically just a bunch of text in the bottom right corner of the screen. Anyway, I was inspired to make it better! Specifically, to create some vector drawings in a cartoonish style to display the weapon and ship states. You can see the result in the screenshot below:

Release 0.3.1 – Check out the new HUD!

As you can see, there are nice cartoon drawings of lasers and a missile in the bottom left, with filled/unfilled boxes to show the status of the weapon. The yellow weapon is selected (in this case missiles). The weapon pills will be red when the weapon cannot be fired, but more on that in the next section.

Weapon Overheating and Burst Firing

One of my friends, testing out the game, gave me some feedback. Turns out, in the previous release, it is nearly impossible to dodge incoming laser fire because the AI ships just turn toward you and start shooting seemingly endlessly. He suggested that maybe they could fire in bursts rather than constantly.

That reminded me of the weapon overheating/cooldown systems present in some FPS games, such as Battlefield. So, I figured that would be a nice mechanic to implement and kill two birds with one stone: limit the number of times the AI can fire and adjust the difficulty of the game back up.

See, if I only implement that for the AI and the player can still shoot constantly, that’s a huge advantage for the player. But, this way, both the AI and player are bound by similar conditions. Basically if you fire your lasers enough times to end up below a certain threshold of ammo, it ‘overheats’ for a certain amount of time, and you cannot fire. For now, I have it set such that the player can normally fire 5 shots (x2, since the ships fire two lasers each shot) and the AI can fire 3.

Coming Soon to Release 0.4:

My wish list, which I am working toward, is to have a ship upgrade system and a campaign mode in place for the next release. I have some basic functionality for these things now (you can check out the upgrade system in the profile menu, but I disabled the Campaign menu option for now), but I’m not happy with them, so I want to rework the way these operate and how the player interacts with them before I include them in a release.

That said, I’ll try to post updates here more often, though I think I am going to start dividing my time because I’d like to learn some network programming and work with LibGDX (Java library for multi-platform game development), so I’ll post details on that stuff as well!

All right, so I’m basically just testing out categories and things on the site, but I’d like to plug a pet project of mine, Space Domination. It’s an in-progress top-down 2d space shooter. Don’t worry, a newer version is in the works (hopefully I’ll post a “3.1″ version to show off some new features in the next few days) and a major revision (cross your fingers) by the end of the month.

With that, hope you all are enjoying the new site layout.

Thanks,

AHS Unmei

EDIT: Now that I’ve imported the devblog, this isn’t the ‘first’ post anymore.