Dirty, dirty Hermit Crab

[Nicholai Pestot]

The last Indy project I was a part of fell through recently and it looks like Scrapheap Spaceships is dead in the water.

I'm just starting on my next project (put together a quick design dock last week and a quick control prototype over the weekend) and before I head on over to my usual haunts to form a team, I thought I'd check if anyone would be opposed to me using this sub forum? I would run it as a failheap project.

I'm looking for
-another coder (c# experience a prerequisite, unity development experience a bonus. Lots of free time required)
- a 2d/3d art guy (unity workflow experience a bonus)
-a sound guy (unity workflow experience a bonus)
-as many derpy testers as I can lay my hands on. The derpier the better.

The initial game concept is pretty much hammered out (3d spaceship command survival game set amidst the crumbling of a Human empire), but plenty of the fine details are still open to interpretation for the technical people.

Game features
-Manual ship control via 3d course setting. Ship has a 'course arrow' which the player manipulates with A/S/D/W/Q/E/Z/X keys. Player ship will then move based on this course arrow – Already developed (did it this weekend gone).

-'Banks' of ship weapons with limited directional arcs. Each bank can have its own targeting priorities AI set. This works in conjunction with a 'primary target' system which certain AI targeting sets will use – WIP (primary target system done. Still working on weapon bank control logic)

-Directional shield setting. Shields are immune to all damage, but a ship does not have shields covering its front/rear. The more shields a ship is running, the slower it moves. Combat requires controlling facing, positioning and speed to get into an opponent's 'throat' or 'rear'. – Not yet started

-Survival. The players' ship continually burns resources. The players ultimate goal is to bounce from wreckage to wreckage (both found and 'created'), looting everything needed to keep the ship running. Eventual death is expected, it's all about how long you can last! – Not yet started

-Initially developed as a single player game, with the game logic setup to allow easy conversion into an authoritative server multiplayer setup (I have experience with this and access to the uLink add-on for unity) - On-going during development

-Minimal crew management system (similar to STO) to fill in time between combat. Strong focus on using limited resources to repair and maintain the players' ship – Not yet started

-Rogue like. Dead is dead. Can save status but no save-scumming allowed. – Not yet started (no save game system in place)

-Art and sound undefined. I am not an art guy. I am not a sound guy. – Not yet started.

If people are interested and me moving into this sub-forum like a dirty hermit crab doesn't ruffle anyone's feathers, I'll throw up my current, shitty, no-art control prototype for people to dick around with and give feedback on.

[Minion]

I'm having a bit of trouble visualizing this. Is it essentially a tactical FTL (where FTL itself is more focused on the strategy/choices) or something else entirely? I can easily trash your game when the time comes, but for now it seems you need to solidify the idea a bit more on paper. Maybe the prototype will help communicate it?

[Nicholai Pestot]

Yep, probably will help.


As I said, no graphics. Just a pure prototype of the movement system and a test of the primary target system (can right click on target beacons). The primary target system is mostly behind the scenes in the code at the moment - all that's hooked up visually is a flat plane graphic I was using to test functionality.

Controls are quite simple. Standard Right click n hold to move POV, scroller to zoom.

Q/E rotates course arrow
A/D turns course arrow left/right
W/S raises/lowers course arrow
Z/X increases/shrinks/throws course arrow into reverse

Controls can be customised in the download version, but there isn't much point.

I haven't bothered hooking up any sort of menu system, as its a movement prototype, so I recommend you don't go full-screen if using the download version.

The ship ( a crappy model I had sitting around from a previous project - an artist, I am not) will attempt to move to synch its position with the course arrow. How quickly it does this is defined by a set of characteristics assigned to the ship (once again - all under the hood at this point)

Download Link

My goal for the end of the week is to finish setting up the turret system, then plonk in a few arc-limited turrets in the 'hole' in that model that will "pew pew pew" at whatever is the primary target.

And yes boys and girls, this is how most games start out in week 1 of development

[Minion]

Thanks for putting the prototype up despite crazy roughness. Took a minute to figure out what was going on from the default orientation but now it makes a bit more sense and I'd liken the movement to EVE with WASD to set the vector rather than double click + relative controls.

That said, there's still the question of other basic gameplay elements. I can see shifting the shields with similar controls to the movement, and the configurable autofire(?) weapons are also imaginable. On the other hand, the crew system sounds a bit tacked on for the moment. Similarly, the resource management is probably doable but a bit too vague. For example, is it simply a timer that runs down until you get fucked if the system decides to underfeed you, or is it more about good decision making and minimizing waste (in ammunition, for example)?

[Nicholai Pestot]

Ship management system will have 3 goals

1- Post (mid) combat repairs based on salvaged components (uses resources)
2- Post combat modifications based on salvaged components (uses resources)
3- Optimisation decisions that allow fine tuning of ship performance and crew output (crew are used to enact 1 & 2, so this can be important)

Each ship management 'crew mission' will have a crew requirement (crew are returned after completion) and a resource requirement (consumed on mission initiation). Ship performance will be partially based on available unassigned crew, so these missions need to be considered and timed carefully. Some will be practical requirements during combat (and will have a low crew requirement), others will be better suited to post-combat clean-up and consolidation with long timers and high crew use.


Resources are broken down into 3 generic types

1- Consumables. An abstraction of everything required to keep your people alive. There is some suspension of disbelief here (no 99% optimal recycling systems in an age of spaceships!), but this is effectively your ticking survival clock that you struggle to push back. When its gone, game over.

2- Fuel. An abstraction of battery capacitors, emergency fuel etc. Standard ship operation does not consume this, but many combat operations will (running shields, firing ammo-less weapons, moving at higher speeds etc). Operating at peak combat capability will burn this quickly. 'Mastering' this game will partially involve learning to win while minimising fuel consumption. Some of the better weapon systems will burn fuel at a silly-high rate.

3- Specific components. Contains many sub-types. Stored in cargo. This could be anything from ammunition, to spare armour plating, to replacement electronic systems. Specific components is not something I can provide an exact list of this early in development. It's far too open to change.


Survival maximisation is going to be about picking your fights, fighting efficiently, understanding the value of different loot types, intelligently managing limited resources and dealing with any crapsack situations that get thrown at you.

[Blutreiter]

Meh, why not. If you need sound and music done, PM me.

[Nicholai Pestot]

Certainly will. Cheers Blue.

[Nicholai Pestot]

Thanks for putting the prototype up despite crazy roughness. Took a minute to figure out what was going on from the default orientation

I just realised I left an unwanted configuration setting on in that build, so you couldn't change the camera position

[Nicholai Pestot]

Right, got the turret tracking system coded.

Just setting up the ship with some turrets and doing some personal testing. Should have a test version up some time tomorrow for you all to poke holes in.

[Nicholai Pestot]

My testing showed how terrible my tracking logic was, so I re-wrote it from the ground-up. Hence the delay

Just did a quick test with one turret and I liked the results. I'm going to be producing some multi-turret configurations of different types to hammer this, but I thought I'd throw up the 1-turret prototype for people to dick around with.


I set the turret to track the primary target (whichever marker you right click on) and set it to autofire (as I haven't wired up a fire button). It has a maximum inclination/declination of 45 degrees and its maximum tracking speed is 3 degrees a second.

As I don't actually have any shooting logic setup yet, the turret simulates shooting with a nice bright pink line whenever it has a firing resolution (fabulous).

As you can see from this test, it is very possible for relative velocities to make it difficult to hit a fast moving target, or to make it difficult for you to hit something if you are moving too fast!

Download

[Blutreiter]

My testing showed how terrible my tracking logic was, so I re-wrote it from the ground-up. Hence the delay

Just did a quick test with one turret and I liked the results. I'm going to be producing some multi-turret configurations of different types to hammer this, but I thought I'd throw up the 1-turret prototype for people to dick around with.


I set the turret to track the primary target (whichever marker you right click on) and set it to autofire (as I haven't wired up a fire button). It has a maximum inclination/declination of 45 degrees and its maximum tracking speed is 3 degrees a second.

As I don't actually have any shooting logic setup yet, the turret simulates shooting with a nice bright pink line whenever it has a firing resolution (fabulous).

As you can see from this test, it is very possible for relative velocities to make it difficult to hit a fast moving target, or to make it difficult for you to hit something if you are moving too fast!

Download

So far so good. One thing that I still dislike is the controls being awkward - but this is mostly due to the free camera I believe. I have no problem controlling the vessel, but it somehow feels odd.

If it is not too much of a hassle, would you consider adding a chasecam?

[Nicholai Pestot]

My testing showed how terrible my tracking logic was, so I re-wrote it from the ground-up. Hence the delay

Just did a quick test with one turret and I liked the results. I'm going to be producing some multi-turret configurations of different types to hammer this, but I thought I'd throw up the 1-turret prototype for people to dick around with.


I set the turret to track the primary target (whichever marker you right click on) and set it to autofire (as I haven't wired up a fire button). It has a maximum inclination/declination of 45 degrees and its maximum tracking speed is 3 degrees a second.

As I don't actually have any shooting logic setup yet, the turret simulates shooting with a nice bright pink line whenever it has a firing resolution (fabulous).

As you can see from this test, it is very possible for relative velocities to make it difficult to hit a fast moving target, or to make it difficult for you to hit something if you are moving too fast!

Download

So far so good. One thing that I still dislike is the controls being awkward - but this is mostly due to the free camera I believe. I have no problem controlling the vessel, but it somehow feels odd.

If it is not too much of a hassle, would you consider adding a chasecam?

Yeah no worries. There were already 3 camera modes, I just hadn't hooked up the system to flip between them with user input.

Defaults to free rotation (the current)

F1 - Follow rotation - More limited rotation thats synched with ship rotation
F2 - Free rotation - Default rotation system thats synched with ship position
F3 - Chase cam

Download

[Nicholai Pestot]

Not much new to show off at the moment.

Just Finished

Now that the turret control system is working smoothly I've been changing how its put together to better integrate with the Unity workflow. Originally I had turret banks and hardpoints as collections of custom objects stored in a component attached to ships. I've changed them to be game objects in their own right, with a set of parent/child hierarchies and their own data components that store relative information. The functionality of the ship is the same, but it is now far easier to design a new ship.

I have created a 'ship template' prefab with 6 turret banks and a 'hardpoint template' prefab to work with it.

Creating a new ship is now just a case of dragging an externally generated ship model onto the template prefab, setting some hardpoints as children of the correct turret banks and then setting the hardpoints position + rotation so they synch up with the model. All configuration data for the ships, turret banks and hardpoints are now exposed in a format that allows easy configuration within the unity editor.

Basically, armed with nothing but a ship model and some common sense, new ships can be created in my project by people with no coding skills in a couple of minutes. Which is nice.


Next Up
Next Ill be sorting out automated programmatic attachment/detachment of turrets (I'm currently hardcoding their addition to a ships hardpoints in a fixed format). That will eventually come in very handy for ship modification by players, so I might as well do it now while I'm still in the guts of the hardpoint/turret system.


After that
Addition of a shooting system. I'm initially going with 'beam' type weapons and 'projectile' type weapons. I have a lot of un-used configuration options on my turret component that allows definition of the various combinations of shooting type/shooting durtation/reloadrecharge time etc etc that I need a system to tap into. I'll need to set it up in a similar way to the ships - creation of a turret within unity should be as easy as dragging a model onto the turret prefab, then setting a few configuration settings on the attached turret component. The result should be compatable with the automated attachment/detachment system, including some validation of turret types

And after that
Addition of a basic damage system and the next test build.

Ill be throwing up a stationary base structure with defence turrets attached and some objects around it to use as cover. The test build will have a very simple scoring system that rates your attack on the base (calculated on time taken and damage absorbed). This will allow my testers (you folks reading this) to hammer the systems I've built and identify any abuseable flaws in the game mechanics created so far.

And after that
Creation of a shield system. This probably going to require a UI for player feedback/control (which I have managed to avoid so far) which is why its being left till after shooting. I have experience with the NGUI unity package (and have actually legitimately bought it) so it won't take that long. Problem is, I have the artistic talents of your average house-brick so the interface will work fine....but look like arse.

[Blutreiter]

Not bad. Keeping an eye on the progress.