next »

[pnch]

@marcgfx Thanks for the feedback, that's a problem then

@Kris Thanks for the encouragement!

By rotational inertia you just mean the ships have angular momentum, right? Doesn't seem like it'd be too hard to handle.

That's it. It takes some minutes for fresh players to adjust, but VERY young players kicking asses in the game a long time ago discarded any worries I might have had about the added difficulty. Also, the new ship is definitely easier, so sticking to these for now.


I'm back to work after the holidays. With some free time on my hands I advanced more than in the entire last year combined I think. Lots of stuff to show so I'll go back to the recap format of the early posts. One of the rather basic things I did over that period was setting up...

Update #70: Version Control

I dabbled with that in the past (so check this out if you're not sure what's that) but what I found was a bit overkill for my needs at that moment, and kept using manual backup once in a while.

Since I was planning to change some code that was pretty much used all over the place (mainly terrain stuff), and to start writing external binary files to disk (with the potential risk of them becoming unreadable in the future if I lose the read methods), I decided to give Version Control another try, and went with Mercurial (and TortoiseHG, its default UI).

Why? Three things caught my eye:
Mercurial isn't built around the idea of a Main repository. As a solo dev, keeping a main repository separate to my own didn't make much sense, and I can still do one later if the need arises (or if I raise a team later).
It manages changesets, not versions, which makes everything way nimbler.
Finally, TortoiseHg is pretty similar to TortoiseGit, which I was familiar with.

This time everything went pretty smoothly, and I've been using this method for some weeks.
What's more, having all of my changes logged means I can go back to whatever version I want to post updates from

[pnch]

#71: Capture Em All

One of the simpler ideas I tried, since all the needed systems were in place:
One hit from a decoy and an enemy drone becomes a friend.

 It's far easier to kill a drone than to hit it with a decoy but, if you capture it, it may take shots and even take down other drones / players for you.

As a player, and in the middle of combat, you have to make the short term / long term bet, while trying to stay alive  .
Also, in local multiplayer, a skilled player may get to piss its friends by sending them a horde of drones in the face.

[sidbarnhoorn]

This keeps looking better and better. Really reminds me of the games I used to play when I was a kid like Star Hammer, Solar Winds and Solar Jetman. :D Groovy!

[pnch]

@sidbarnhoorn: Woot, Solar Wings, that's something! I love when through just some gifs you get titles I loved as a kid, thank you!

#72: Smarter Enemies

This must be the most substantial update in a while, and it's been quite some time in the making so here we go:
The AI code that the drones were running was pretty minimal and efficient, but I knew from the beginning that at some point it would become quite hard to maintain. One day, while realizing the pain I would go through to stack a simple new feature on top of the structure, I realized I reached that point. As I sailed through the web looking for a better way to structure the AI, I stumbled upon an article from Chris Simpson (Project Zomboid) about the Behavior Tree model and decided to give it a try.

There are commercial plugins that do just that for Unity, but as you may have already seen, I'm avoiding plugins like the plague so far  .

For the UI Side, I already had a basic (read crude) node editor setup, which I was using for quests. Adapting it to AI wasn't too hard. The AI implementation by itself was also running in a few days. What got me almost stuck for a while was Serialization, the ability to make these data structures persistent between sessions and levels - That means, say I get to an interesting brain while toying with the editor, I wouldn't be able to save it for future use without this. I discovered there's something called Serialization Hell for Unity users, not a pleasant sight, that eventually forces you into not optimal code structure.
Once I sort of tackled that, stacking and prioritizing behaviors became infinitely easier:

Here's a view of the current version of the drone's brain. 

Say I want to quickly try prioritizing Shooting to Stabilizing the ship, it's now just a matter of rewiring two nodes instead of analyzing whether I should just change a function or so some refactoring. Most importantly, I now have the peace of mind that I have a the foundations that will allow me to set up brains complex enough for future entities, let's see where that takes us 

[pnch]

#73: Integrate Destruction

Remember the destructible terrain I built for the asteroids a while ago?
Well, terrain objects could be either destructible or solid as a whole. Of course, the idea was to be able to make parts of a terrain destructible and parts of it breakable, so integrating both was a step to take.
Consider it done! But it would be useless if I couldn't easily edit which parts of the terrain will be breakable, solid, etc.
Time was up for ditching the external editor approach and starting to build my own. Here's the first iteration:
-A brush that either adds or removes terrain with a given radius.
-Another one to designates cells as either solid or breakable
-Basic save / load support
-Debug tiles

[pnch]

#74:Level editor rev II

I´ll cheat: Lots of stuff was added since the last update and most of it doesn't make for interesting reading. I´ll do a bit of a fast forward. Here we go:

(UI weirdly formatted to fit the small gif)

The in-game level editor now has three modes: Terrain, Decorations and Objects.
*   Terrain-- draw the actual walls and structure of the level.
A bit of this I showed already on the last post. From there on, I added support for right angles and different looks on the walls.

*   Decorations-- draw the backgrounds and foregrounds.
Pick a tile from a palette and draw it at different predefined "layers", allowing you to draw multiplane decorations.

*   Objects-- Add or remove objects, edit their properties and relationships.
You can choose from a palette of objects, or select from those already placed on the level, and edit their properties.
I can easily mark properties to be editable by the user. Therefore, you can place for example a lot of bots and set their "team" property to different numbers and you got instant space war.
A "Power Source" mechanism was also added: Plug a door (or many) to a lever, for example, and the door will open whenever the lever is pulled.

All this stuff is now properly saved / loaded to disk.
As you can see, it's all pretty standard stuff, but it had to be done. I hope this will enable me to play your own levels in the future

 Of course, if you´d like a bit more detail on any particular stuff, feel free to ask!

[pnch]

#75: Tethers

In zero G, stuff just keeps floating around. Most of the time that's OK, but say you want to, for example, keep your spaceship from drifting away?
Say hello to tethers, now automatically deployed when you eject from a ship facing something rigid, and removed as soon as you board a ship again.

master space-towing

space parking

and random-stuff attaching

[BudPico]

This game looks like it could be really great - love the ship towing idea   

[foofter]

The sense of depth almost induces vertigo - which is awesome, fun, and impressive for such simple graphics. Nice idea and design!