PhaseShift Functions

Development Blog

0 notes

Starships!

I’m back! And I’m back at Starships!

My contract project is coming to an end this month, which means my home development time will be refocused back at Starships. 

Whats changed? Well, when I last left it, I had discovered flying the full, physical ship around was dreadfully impractical. So I’m going to have to be clever. 

Each ship will have a simplistic version that carries the physics. I can weigh the chunks appropriately to make the ship feel just as heavy. 

The real ship, in the meantime, will be off on the side somewhere, with NO physics. This will be much faster, though it presents some interesting challenges, like:

1) What happens when a ship collides? 

2) What happens when chunks are blown off?

3) What gets rendered and when, especially in a MP situation?

It’ll be an interesting challenge, but I look forward to it. 

1 note

Torque 2D Game

I’ve started a small project to keep myself busy in between projects. Don’t have a lot of time, so going super simple, just a fun 2D game. So started looking at 2D engines. Torque 2D looks like a great place to start.

It’s going to be a simple sprite based superhero game, using Box2D as the primary physics engine. 

I’m probably going roguelike, where you aquire random powers as you play. Mixmatching combinations of powers should be fun. Powers will include:

Flying, super jumping, teleporting, health regen, hi health, invunerability, slow time, freeze time, super strength, super speed, Fire lasers from eyes, fire kinetic energy from chest, etc. Basically any X-Men power.

It will be 2.5D with 2 levels, street level and building level. I’ll probably make buildings semi-distructable.

0 notes

Oh hi, didn’t see you there

Welp, its been a while, hasn’t it?

What have I been up to? Well, bad news first: Starships is on hold. It’s not binned, and I will come back to it, but I think doing it alone is a bit too ambitious. The resources alone are going to be a heck of a task. 

I have another project I’m on, but when that’s done I intend to start another game, a simpler project. No hints until I can show you something. It’s completely different, however.

1 note

Components and Parts

You know how, in Star Trek, the lead engineer is always yelling things like “We have lost the port side flux capacitor!”? I want you to feel like yelling that when you play.

Components (engines, weapons, generators) are the large parts of the ship. Most are single component. Some might be larger (engines, for instance might have 3 or 4 chained components that make up the full engine). 

That’s not the smallest resolution I want to go. I want each Component to be made of smaller parts. This parts will be mostly virtual, but can be swapped out, upgraded, damaged, etc. Each part will actually do a certain task. If this task is interrupted, the component will react in different ways.

What these tasks are, I haven’t necessarily nailed down yet. I’m thinking each task is essentially a conversion from one resource to another, with an optional waste resource generated.

For instance, a Generator part will take in raw simple fuels, turn out hi voltage raw power, with heat waste. Another part will take in heat and destroy it, depending on if the component has coolant, provided by another components part. 

In this way, you can have a logical damage state and possibly some pretty cool emergent gameplay scenarios. Smart players can make components do completely different things by changing around parts. 

This, I imagine, is going to be the core mechanic of the game.

0 notes

Fluid Dynamics is Expensive as Shit

One of the larger issues I have to deal with is simulating “Air Pressure”. I want you to deal with air leaks, airlocks, good/bad air, things like that. Problem is, even in a very low resolution simulation like mine, simulating this, which is essentially a fluid dynamics simulation, is extremely expensive.


If you have 2 ships of max size (currently 30 on a side), then that is 1800 cells to process every cycle. Even a single 150 cell ship calculation results in a significant FPS hit.


So we need to make a couple of simplifying assumptions.

1) A single room, no matter the size, will always have uniform pressure.

This is safe enough, though if you create an extremely elaborate, long hallway, then it becomes noticeable unrealistic. BUT, that means that instead of 1800 cells, you go down to say 60, if you have 30 rooms per ship. FAR more realistic to calculate.

2) No leaks exist. As they are created, I can actively simulate them.

This means that an intact ship has next to nothing to simulate. This ALSO means that as a ship gets more damaged, it becomes more and more expensive to calculate. STILL cheaper then doing 2 checks for each cell.
Doors will be counted as leaks for simplification.

The benefits of this approach massively simplify calculations. Pressure can be easily calculated using room size.

0 notes

Possible Changes

For quite a while I had planned the game to be primarily First Person. That is to say, when you are not operating a ship system you are in FPS mode.

I’m starting to think that is the wrong way to go about things, for many reasons.


1) Its a fundamentally 2D game. 2.5D if you are generous. a FPS view would make this more obvious then I might necessarily want.

2) Art assets. I am the first to admit that I have no art skills. FPS games require higher fidelity artwork.

3) Sorta belongs in #1, but if you have a 2D game, things like jumping, shooting, and other physics effects become superfluous.

So now I am considering eliminating the FPS view altogether, moving to an above view third person view. This would allow a more symbolic art style, and probably gel with the gameplay better.


I’ve not decided yet, but I definitely see benefits to going that way.

0 notes

Update

So, refactor is going well. Absurdly well, in fact. The ship editor is a million times better then it was, and the new data structure will be FAR easier to update and modify.

I rewrote electrifying and air pressure. Took all of 20 minutes to finish, super simple. Turns out I was over complicating, I expect this will be much more performant.

I’m currently working on what my data files and saves will look like. I would LIKE to use Google Protocol Buffers, since I am familiar and comfortable with them. They are good for network as well. Problem is, both implementations I have come across seem to not work with Mono 2.8. I might need to write my own, though I definitely do not want to do that.

In any case, the ship editor is very nearly done. Just about time to get into the game engine itself. I expect I will throw out the included character controller since I don’t need most of the complexity. Gravity, for instance, I do not use.

In any case, I’m also at a point where I need to start with graphics. Which means I need to decide on a graphical style. If I do an alpha release with donations or something, maybe I can pay an artist, but until then I need to keep it in my capabilities.


I’m kinda thinking a doom style 2D sprite effect might look pretty cool in first person mode, with a more symbolic icon system in god mode? Not sure yet.

1 note

I’m Alive!

Wow, I let this slip, shame on me. Update time!


So basically for the entire month of January I have been out of town on business. My workplace has little access to the outside world, so I find myself thinking about what I want to do with my game.


I’ve come to the conclusion that current progress is unsustainable. I know the current backbone is flawed, and and more work I do will make refactoring more and more difficult.

So that’s what time is is! Refactor time! Starting from scratch I believe, with a firmer plan then what I started with, will make progress much faster the second time around.

Planned changes:

I want to more tightly marry the editor and the game engine. My current setup allows adding new components easily, but there is a LOT of places where I rewrite code. Plus I want to allow dynamic changes to the ship, and this will allow it.

I’m going to drop CPU cycles as a distributable resource. Its pretty repetitive anyways. CPU upgrades will simply give more functionality, and allow more devices.

Going to create a proper save data format. I was simply using txt and ascii last time.

Going to start a proper artstyle. Not the final product, but not the simplistic shape and texture thing I was doing before. Going to add things like changeable floor and wall patterns.

Going to change the 4 wall cell system I currently have, to support ceiling and floors properly.

And I am going to start looking at how multiplayer is going to look, and design with it in mind.

So this weekend, I’m pressing File -> New.

0 notes

Project Update

Well I’ve been busy at work, and the stuff I have added on the weekend isn’t really “sexy”, but here is an update.

I’ve added animated doors, and windows. This brought up 2 problems.

1) Editor is ugly and a pain in the ass. I basically have to code everything twice, once for editor and once for game. I should refactor, but that would be a big, frustrating undertaking.

2) Closing doors, which closes a collider, will actually push the ship if the player is in the way. I can resolve that by making it non-kinematic, but then I get wierd drift issues with the player when the ship moves or rotates quickly.

I have added the tactical view, where you maneuver your ship. Currently just applying force to the rigidbody, but not sure that it is suitable, for the reasons mentioned above. I don’t necessarily need a physics model at that level anyways, so might just write my own.

Up next, I would LIKE to get weapons firing, so I can shoot something in tactical mode, even just idle defense satellites or something.

The editor needs better feedback, but I will look at refactoring, folding the editor into the main game first.

0 notes

Damage Considerations

As per last post, I am going to be adding weapon effects and damage shortly. But first we need to figure out HOW we are going to do damage.

I dislike hit-points on spaceships. An arbitrary value where your ship suddenly explodes is too simplistic, too, well, arbitrary. Ships don’t just explode. Generators explode. Engines might explode. you might slice parts off. A sufficiently large object might pulverize it. But you wont just explode.

You damage a ship in several ways. Hitting the hull hard enough will leak air. You can suffocate a crew that way. But ships will have space suits available, and with enough materials almost all breaches can be sealed, so its not reliable.

Burst damage weapons, like guided plasma, torpedoes, and missiles, Can damage components as well (assuming they get through armour and shields). Sufficiently damaged components can not be repaired. Some explode catastrophically.

But what is a damage value going to be? Well, walls have something already. Leak values, between 0-5, control airflow. Is that enough? Do we want walls to be damaged, but not enough for a leak?

Here is my idea. External walls have armour. Armour has a chance at absorbing a certain level of damage each hit. Absorbed damage dissipates entirely. Non-absorbed weakens the armour permanently, or at least until it can be repaired.

There is a chance that a hit will bypass armour entirely, which will cause a leak.

So lets make us some numbers.

Level 1 torpedo hits level 1 armour. Level 1 torpedo does 3 damage. Level 1 armour has 80% chance of absorbing 2 damage. So at best, you get 1 leak on affected cell, 1 damage to armour. At worst, 3 leak, 3 damage. That cell is then at risk of any further hits damaging components and crew.

Shields will come in 2 varieties. Kinetic shields stop physical damage, Entropic shields (apparently this name is used, but for now it works) dissipate plasma and beam. Shields can be modulated on the fly to be more effective against 1 vs the other.

Explosive weapons can damage components if armour doesn’t dissipate them. Plasma weapons will probably cause an EMP effect on hit. Lasers will likely have good piercing. This gives each weapon type a use.