Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Topics - Mark

Pages: 1 2 [3] 4
31
Development & Discussion / Universe or Nothing - A Renaming
« on: June 13, 2016, 05:56:59 PM »
Hi all,

UNION started life as a series of ideas and prototypes, mostly based around the concept of a multiplayer bridge simulator, but it has since evolved beyond that.

While it still has much of that bridge sim heritage, UNION is developing into a more rounded game with a greater scope and a focus on narrative structures.

We like the name UNION, but it has some major drawbacks; it doesn't grab people's attention and it is very poor for search results ("union" is very generic and "union game" will get you American Football results). In order to get better search results we added "Spaceship Command" to the name, but "UNION Spaceship Command" does not excite any passion. It is a "what it says on the tin" kind of name.

So, we decided to find a new name for UNION, and we decided to focus on a name which would pique people's interest and hint at a deeper narrative.

That name is Universe or Nothing. As part of the name change we are also working on re-branding the game, and here is an early concept of that (on our new domain): http://universeornothing.com/

The name is also a statement of intent for the game, as it basically means the same as "all or nothing". UNION, the faction you will still be playing in the game, are an all or nothing group as well. They believe that the only future for humanity is by expanding as far across the universe as possible, and that they are the best chance for that to happen. It isn't the usual kind of game name, but we feel like it will stand out in game lists, like on Steam.


We would love to hear your feedback.

Thanks for reading!

Mark

32
Hi all,

I've finally reached a point with the move to Xenko and the addition of a mod scripting API that I'm happy to push on with development of the "vertical slice", a version of the game which has fully playable Engineering and Tactical roles. This build of the game will give us a better understanding of the strengths and weaknesses of our game design, and we can use video and screenshots from it to seek funding.

My first goal is to finish Engineering, and to do that I need to complete the UI design for it. The first part of that is some refinements to the "Power Wheel", to make it easier to read and better incorporate the Technician slots.

That refinement is not yet complete, but I have two concepts that I'd like to get feedback on:



I have moved the Integrity/Health (green), Heat (red), and Instability (orange) bars out of the "slice", they are now floating on the black background which gives them a greater contrast. They are also slightly larger, with the Integrity bar being the largest of them.

In the top image the Technician slots floats outside of the "slice", just above the system's power node. In the bottom the slot is inside the slice, beside the system's icon.

I will probably work on better integrating the "power node" (the circle which you make power connections to) into the system's "slice", at the moment it is floating on it's own.

I'd love to get your feedback on all of this.


Thanks for reading!

Mark

33
Hey all,

An issue in Noesis, our GUI library, has required some alterations to the Xenko engine renderer. The issue caused some graphical artifacting on some of our more complex UIs. The changes have been made though, with help from the Noesis and Xenko developers, and the issue is resolved.

Other than that I have been working on the mod scripting system. All mod scripts will be written in C#, using the latest version of the language and .NET libraries. It may seem early to be working on this feature, but we will be using mod scripting to create almost all of the game content functionality (weapons, ship systems, etc.). This will give modders the best possible access and feature-set. It's a rather complicated piece of work, but worth it.

We have been having some good weather here so I spent the weekend kayaking on Lough Corrib with a friend. We camped on Inchagoill, the largest island on the lake. A good work life balance is important. :)


Pádraig and I have also been working on the marketing direction for UNION, in preparation for an upcoming press release (which will be our first). Although the best expression of the UNION game will be in multiplayer/cooperative, we feel it is important to emphasise that the game is singleplayer too. You won't have to find/engage friends in order to play UNION, and we feel it's best to focus on that in the marketing of the game.


Thanks for reading!

Mark

34
Development & Discussion / [Progress - 17th April] Engine Work
« on: April 17, 2016, 11:35:56 PM »
Hi all,

I have completed the move from the Unity engine, which we outgrew, to the Xenko engine. Xenko is an open source engine which is written entirely in C#, using the latest software and techniques.

The move to Xenko has allowed me to upgrade the UNION code base and architecture, improving performance and extensibility  (making it easier for me manage systems and add new features).

Before the move to Xenko I had started on the modding system in UNION. I have continued that work as part of the move, and made significant progress. All of the asset (models, textures, UIs) and configuration (factions, entities, spaceships, equipment) systems are complete, with just the programming API (for adding new ship and equipment behaviours) left to do (I will be working on it next). We are front loading all of the modding system work so that we can build all of the game content as a mod. Creating the game this way means that you, our community, will have access to everything we use to create content.

Writing the modding API will mean making changes all over UNION's code base, but it is totally worth it. The earlier I implement the API the lower the cost to implement it is (in terms of development time).

While the move to Xenko is complete, in that the game is now running in the engine, there are a number of things which need to be rebuilt. Chief among these is the effects system (laser beams, shieldo visual effects, explosions). I expect to move onto these once the modding API is in place.


Thanks for reading!

Mark

35
Hi all,


So there has been a lot happening on UNION these past few weeks!

I have primarily been working on the modding system, which really impacts on all areas of the game. That work is mostly done, but at the end of it I came to a realisation, that Unity is not the right engine for UNION. I'll explain why a little further down!

The other piece of news is that over the past few weeks we've been working with Isaac Hannaford on the spaceship designs for UNION. Isaac is a brilliant concept artist and art director, whose body of work includes Halo 3, Halo ODST, Reach, Destiny.

Here is an illustration by Isaac containing his first two ships for UNION, the UNION Kite class frigate in combat against two Centauri Alliance Takuba class frigates:


We're keeping these ships low-key at the moment as we'll be putting out a press release with them over the next week or two.

Back to the engine issue. Unity has many positive attributes, but when you start pushing it in directions it wasn't designed for, you run into a lot of issues. The latest of these has been random crashes caused by dynamically loading textures while the game is running. This is an important part of modding, allowing people to reskin ships or add completely new ones. The crashes occur randomly and are caused by something inside of Unity's code (which I have no access to), so I have no simple solution to them, There have been many other issues, but I have overcome (worked around) them. This latest problem is the final nail in the coffin though, I can't risk getting to release only to find we have random crashes.

For that reason I have decided to move UNION to a new engine, called Xenko. The primary reasons are that Xenko is entirely written in C# (which is my preferred language), it is code-first rather than editor-first, and I have access to the full source code for the engine. The full source means that if there are issues I can identify and fix them myself, rather than hoping Unity will find and fix them for me.

The main downside is that Xenko doesn't have the ease of use that Unity offers, with it's mountain of community content (like tutorials, libraries, plugins, forums with info). That is not a major issue though, and I do enjoy a challenge. :)

This does mean further delays before we can show more in-game footage, but it is a positive development for the game.


Thanks for reading!

Mark

36
Development & Discussion / [Progress - 27th March] OBJ Mesh Importer
« on: March 27, 2016, 10:26:53 PM »
Hi all,

Just a quick update.

I'm still full steam on the modding system, and making great progress.

I have just completed the OBJ mesh importer, which is used to dynamically import models from active maps.

I chose the OBJ file type because it is easy to work with and it is supported by all major modelling applications (Blender, 3DS Max, Maya etc.).

Next I'm going to work on the Material/Texture system, which is  one of the final steps required to have all entities in the game (spaceships, equipment, environmental stuff) defined in mods.


Thanks for reading!

Mark

37
Development & Discussion / [Progress - 18th Feb] Cry(Engine) No More
« on: March 18, 2016, 12:08:44 PM »
First of all, sorry for the terrible pun in the subject line. ;)

I have been busy working on the mod system, specifically making it so that every part of a spaceship can be configured in mods.


Two days ago Crytek announced the release of CryEngine V. It is free, open source, and supports programming in C#. This was very exciting news. CryEngine has a brilliant rendering engine, and getting full access to it for free is great. Also UNION is coded in C#, so this opened up the possibility of moving UNION to the CryEngine.

I spent the last two days reviewing the engine, testing out different parts of UNION in it to see how it performs.

Sadly, I found the engine lacking. It's C# implementation is modern (great) but it's C# API is very poor compared to it's C++ API. There are many things you can do in C++ which cannot be done in C#. The source is available, which would allow me to extend the C# API, but that is too much overhead for me. Coupled with that issue is an extreme lack of documentation.

These things may be improved later on, so I will check again in a few months to see what has changed.


UNION is developed in such as way as to be independent from any one game engine. It has it's own entity, physics, UI, and networking systems. These can be then plugged into any engine/framework which has robust C# support. Right now that means Unity, MonoGame, and Xenko.

At the moment we are using Unity as our engine. It has a very good and easily accessible rendering engine, but it also has many issues and downsides (including an ancient implementation of C#/Mono). It is my intention to move UNION to the Xenko engine after it leaves Beta. Xenko is a very modern engine, with a much better API than Unity. It is also open source, which makes things easier for me as a developer (and that speeds up development).


Now I am back to working on spaceships in the mod system. We are holding off on the next DevLog until that is completed, with all this work on code there are no new visuals to show. In the next DevLog the basics of modding in UNION, creating a new mod and adding new spaceships to it.


Thanks for reading!

Mark

38
Development & Discussion / [Progress - 13th March] The Mod System
« on: March 13, 2016, 08:45:21 PM »
Hi all,

There are major changes happening under the hood in UNION, and that is because I am implementing the mod system.

In order to make modding as flexible and robust as possible all of the game content in UNION, including ships, equipment, UIs, maps and missions, will be be packaged as mods. UNION will come with a UNIONBase ("UNION Base Content") mod which will contain all of the content we create for the game.

Mods can require, and use the content of, other mods. So people will be able to do things like create their own mission pack mod which uses content (like the UIs, maps, ships and stations) from UNIONBase.

In the case if UIs, the game doesn't care which mod they come from as long as all UIs exist between them. Mods have a priority setting, with conflicting content (like UIs) being taking from the mod with the highest priority. UNIONBase is set to the lowest priority by default.

I am at the point now where mods are loaded into the game at start. At the moment they only contain spaceship templates (spaceship definitions) but I will be adding UIs and maps soon.

I am currently integrating mods with the server, so that clients can only connect to a server if they have all of the mods that the server is using.

There's nothing visual to show at the moment, so here is the current mod config file contents (all config/data files will be JSON):

Code: [Select]
{
"Key": "UNIONBase", /* Each mod must have a unique key */
"Version": 12, /* The mod's current version */
"Priority": 0, /* This mod's priority. If there are conflicts with other mod content the mod with the higher priority "wins" */
"MinimumUNIONVersion": 43, /* The minimum UNION version (release number) required by this mod */
"Title": "UNION Base Content",
"Description": "This  contains all of UNION's standard content, including spaceships, equipment, maps and missions.",
"IsEnabled": true,
"RequiredMods": [] /* A mod key and minimum version for each mod which this mod requires */
}


As always I'm more than happy to answer any questions.

Thanks for reading!

Mark

39
Development & Discussion / [Progress - 9th March] Spaceship Templates
« on: March 09, 2016, 05:59:02 PM »
Hi all,

I finished the pause system on Sunday, it allows the Captain to pause the game's simulation while still allowing all of the ship's systems to be interacted with.

I have intended to work on the armour system after that, adding the armour condition display to the Engineering UI, but decided to put it on hold while I implement Spaceship Templates.

The spaceships in UNION are modular, but up until now configuring those modules has been hardcoded into the game. That meant you had to modify the source if you wanted to change or add a spaceship, which is important for modding the game. I decided that before I made more changes to the spaceship system I would move spaceship definitions into external editable "Spaceship Template" files.

I has initially thought I would use the XML format for these templates, but XML is so a verbose and difficult to read, so instead I have opted for the JSON format.

To give you an idea of what these Spaceship Templates will look like, here is a snippet of the work-in-progress file:
Code: [Select]
/* UNION Spaceship Template v0.2a */
{
"ClassType": "Frigate",
"ClassTitle": "Kite",
"HullIntegrity": 6540,
"Parts": {
"Reactors": [{
"PowerWheelRotation": 0.0,
"MaxPowerOutput": 9
}, {
"PowerWheelRotation": 60.0,
"MaxPowerOutput": 9
}, {
"PowerWheelRotation": 155.0,
"MaxPowerOutput": 9
}, {
"PowerWheelRotation": 205.0,
"MaxPowerOutput": 9
}, {
"PowerWheelRotation": 300.0,
"MaxPowerOutput": 9
}],
"Systems": [{
"EquipmentType": "Turret",
"Name": "Forward Turret",
"PowerWheelRotation": 0.0,
"Class": 3,
"LocalPosition": {
"X": 0.0,
"Y": -1.185,
"Z": 0
},
"LocalRotation": {
"X": 0.0,
"Y": 0.0,
"Z": 180.000015
},
"HullSectionIndex": 0,
TurretMinXRotation = 270.0f,
TurretMaxXRotation = 0.0f,
TurretMinYRotation = 215.0f,
TurretMaxYRotation = 145.0f
}, {
"EquipmentType": "Sensors",
"Name": "Sensors",
"PowerWheelRotation": 22.5,
"Class": 3,
"LocalPosition": {
"X": 1.05,
"Y": 0.365,
"Z": 1.35
},
"LocalRotation": {
"X": 0.0,
"Y": 0.0,
"Z": 315.000031
},
"HullSectionIndex": 0
}, {
"EquipmentType": "TorpedoLauncher",
"Name": "Rear Torpedo Tubes",
"PowerWheelRotation": 47.0,
"Class": 3,
"LocalPosition": {
"X": 0.0,
"Y": 1.16,
"Z": -2.635
},
"LocalRotation": {
"X": 0.0,
"Y": 180.000015,
"Z": 0.0
},
"HullSectionIndex": 0
}],
"ReactorConnections": [{
"ReactorIndex": 0,
"SystemIndex": 8,
"DefaultPower": 2,
"MaxPower": 9
}, {
"ReactorIndex": 0,
"SystemIndex": 9,
"DefaultPower": 2,
"MaxPower": 9
}, {
"ReactorIndex": 0,
"SystemIndex": 0,
"DefaultPower": 2,
"MaxPower": 9
}]
}
}

Everything, from the systems on the ship to the models and textures, will be configured in these Spaceship Templates.

Thanks for reading!

Mark

40
Hey all,

I have nothing visual to show today, because my work over the past week has mainly been on adding the ability to pause all simulations in UNION. I have the pausing itself working, and am in the process of adding the ability to the UI.

I'll get into the details in a minute, but first I wanted to explain why this feature exists and that is singleplayer. We believe that UNION should be a rich experience for anyone who wants to play it solo. In UNION any empty roles (stations, in Artemis speak) will be filled by AI crew members (this can be disabled in the game options). These AI crew members can be given simple orders by the Captain, like plotting a path on the navigation map and ordering the Helm to follow it, ordering Helm to orbit a target, ordering Tactical to lock or fire on a ship, or ordering Engineering to go to Silent Running mode etc.

At any point a player can jump into any of these AI controlled roles for full control, then leave it again and allow the AI crew member to take over.

This is not meant to replace multiplayer, but to exist alongside it. At any time a person playing singleplayer can invite other players to join their game as crew members. It also serves as a nice training platform for new players.

So back to pausing. Pausing is only available if there is only one player-crewed ship in the game, so if a second player-controlled ship joins then pausing is no longer available. Pausing can also be disabled in the game settings.

Only the Captain can pause the simulation. I say "pause the simulation" because the crew can still interact with all of their UIs, changing and tweaking all of their systems. While the simulation is paused Engineers can reconfigure power, use coolant, reassign Technicians, Tactical can modify weapon groups, lock new targets, and so on. Obviously none of this has any effect on the simulation until it is un-paused. This pause functionality allows a single player, or a minimal crew, to manage a whole ship.

I realise pausing could be used as a crutch for a crew, removing urgency, but that is their choice. We will recommend in-game that pausing is disabled in cooperative games.

Oh also, speeding up the simulation is not feasible for us as it would require a lot of extra work to implement and support. So the speeds are normal and paused.

I'd love to hear your opinions.

Thanks for reading!

Mark

41
Development & Discussion / [Fiction] Without A Scratch
« on: March 04, 2016, 09:49:25 AM »
View original post.
Quote
Just a little tale from the frontlines to give you some more insight into the world of UNION.

Sparks still flew from overloaded power conduits on the command deck, but it was clear that the battle was coming to an end. A Game of Chance had taken significant damage during the encounter - one whole bank of directed energy weapons had been knocked offline, and Helm Officer Marriat was complaining of uneven maneuvering thruster output - but the tide of the battle had turned when a well placed torpedo shattered the enemy's forward shield generator. Apparently unable to get it back online, the Centauri Alliance frigate had turned tail in the hopes of using their rear shield array to cover a hasty retreat. However, this slashed their ability to direct fire towards Chance, as most of the weapons systems were mounted with their arc of fire covering either the front or sides of the vessel. Recognising this, A Game of Chance’s captain had ordered all power diverted from their own shields to weapons, seizing the opportunity to land a crippling fusillade of fire on the enemy ship. The result of this now filled the view screens, as the enemy ship listed helplessly, atmosphere venting in icy plumes from a dozen holes across her hull. Lieutenant Kalt was even now negotiating terms of surrender with the surviving CA crew - UNION policy dictated granting full amnesty to enemy combatants, both out of humanitarian concerns and a desire to encourage a willingness to surrender among the enemy.

Within moments, Kalt had finished both his negotiations and local scans, indicating no further threats in the vicinity. Lifeboats from the crippled CA ship were quickly being directed to an aft docking port. Tactical officer Bedford was already en-route to meet them, with a unit of marines in tow. The ships would be scanned carefully for explosives, then the occupants brought over in small groups to minimize the security risk. If Bedford had her way she would likely have left the CA lifeboats for their own people to find, but that simply risked these same spacers crewing some other enemy ship down the line, which was not something UNION command was willing to risk. The alternative to capture was to blow the lifeboats out of the sky, and while this had been floated as an idea more than once, Bedford knew things weren’t so desperate that UNION would put aside its ideals in such a way. At least, not yet.



Within seconds of the Captain signaling permission to leave battlestations, Chief Engineer Spalding was off the bridge and scampering down the access shaft to the main engineering decks, moving with a speed rarely seen since his days working the power conduits himself. Moments later, the captain was hot on his heels, leaving the rest of the somewhat stunned bridge crew alone on the command deck.

“What’s wrong with them?” Asked Helm Officer Marriat, as soon as she judged it safe to speak freely in the captain's absence. “We just kicked CA ass up here, and the ship barely took a scratch!”

“Check your notifications, Marriat.” Suggested Kalt, his face stoic. “It wasn’t flagged as high priority for you, so you may have missed it.”

Marriat scrolled down through the flashing multi-hued notifications until she found the one Kalt had referred to, blinking pale and translucent on her display.

“Oh no…” she whispered.



The Engineering deck was in chaos. The initial volleys taken from the CA frigate had been devastating, the extent of the damage underestimated by the bridge crew simply because of how well contained it had been by the ships technicians, operating under the direction of Chief Engineer Spalding. A spray of plasma from a ruptured fuel line had ignited stored supplies a deck below, and only the quick thinking and bravery of a nearby tech had prevented the fire from spreading. That tech was now being placed on a ventilator by medical staff, having inhaled far too much of what were likely quite toxic fumes. Spalding took note that the man would likely need medical attention at a station, and flagged the matter for the Captain to consider before continuing briskly through the length of the deck.

Spalding also noted that elsewhere whole power conduits had been manually rerouted, with meters of ominously sparking cable running the length of one corridor, carrying power from the long range communications array to an aft weapons hardpoint. The quickly installed cabling was clearly being operated far past their rated capacity, but whoever had stuck them in had installed transformers at either end to minimize the still substantial risk. These transformers still bore the branding and burn marks that indicated they had been pulled from a capacitor in a damaged weapons array. Commendable innovating under pressure, thought Spalding, and made a further note to find out who was responsible to mention as much in person. That, and to make sure the thing was shut down before someone was electrocuted.

The worst of the damage was, however, situated to the rear of the ship, near the starboard hydrazine shunt. The highly reactive chemical was a necessary component in the backup maneuvering array, but was also notoriously dangerous, maintained only as a last resort fuel supply should the fusion reactor be knocked offline. The whole thing was a lethal anachronism, in Spalding’s opinion, but the chief engineer also appreciated the need for multiple redundancies, and so had not drained the system as some other ship’s engineers had done. In front of him, wrapped around the emergency shut off, the burned and twisted form of Technician Bradley stood as testament to that lethality. The man had died patching the shunt, just as he was ordered to, likely preventing the whole deck from being contaminated by the highly reactive substance. Spalding was vaguely aware that another technician in a haz-mat suit was attempting to ward him away from the site of the accident, but he pushed by regardless, eventually acceding to having an air filter quickly strapped across his face. He dropped to one knee by the corpse, meeting the open eyes of the dead man, noting the blackened uniform and raw burns across the body.

‘Thank you for your service, Arthur.’ he murmured, in that quiet voice only the dead can hear.

With a gloved hand the chief engineer reached out and palmed the blue eyes closed.

42
Hi all,

Last night I finished off some animations on the Power Wheel Presets, the current preset button now "lights up" and a label with the new preset's title appears over the Power Wheel for a second. I wanted to provide clear feedback on which preset had been switched to.

You can see it in action here:



Next up on my development list is Technicians, these are the crew which the Engineer will be assigning to systems on the ship, boosting performance, increasing stability, fighting fires, and repairing systems.


Thanks for reading!

Mark

43
Development & Discussion / [Progress - 25th Feb] Bug Fixes
« on: February 25, 2016, 10:09:59 AM »
I fixed every known bug in the game yesterday, it's not a long list but that's because throughout development we have kept a process of continual testing, bug fixing and polishing, ensuring that each stage of development provides a stable base for the next.

Changelog
  • Fixed clicking on servers in the local servers list on the Connect screen.
  • Fixed an error when a player clicks the Create Crew button on the Create Crew screen before data has been received from the server.
  • Fixed a crash in the Engineering UI which happened if the number of systems or reactors on your ship is modified (the number systems and reactors are modified, to zero, when your ship is destroyed).
  • Fixed torpedoes not applying damage.
  • Fixed ships not triggering destruction when hull integrity is zero.
  • Added null checks to the camera code to avoid errors being shown on disconnecting from a server.
  • Added a "graceful exit" system on application quit, where if the server player quits by closing the game window all clients will be disconnected first.


Thanks for reading!

44
Development & Discussion / [DevLog #2] Engineering Power Wheel Presets
« on: February 23, 2016, 04:21:38 PM »
Hey all!

Here is our second video DevLog, where we show our progress since the last DevLog, two weeks ago. The big item is the Power Wheel Presets.


Our plan is to record one of these every two weeks. We're completely new to doing videos, but we're working on improving our technique. :)

For those who missed it, here is our first DevLog.



Thanks for watching!

Mark

45
Development & Discussion / [Progress - 21st Feb] Engineering UI/Game Design
« on: February 21, 2016, 02:57:20 PM »
Hi all,

As mentioned before, our focus is very much on Engineering right now. We're going to make it fully functional before moving onto Tactical.

I wanted to share our current Engineering design, and get feedback on it. It's not complete yet, I'm still working on the Equipment Status panel which will have options/settings, info and graphs for the current selected equipment on the power wheel.

Take a look at the picture first (click for a larger version), and I will talk a bit more about it below:


Engineers
The biggest thing there that we haven't even announced yet is the Engineers, who you will manage by assigning them to sections/equipment on the ship.

Engineers are like crew members in FTL. They have stats which will provide boosts to the equipment in their section, they'll put out any fires that occur in the section they are in, and if there is damage and the section they are in is powered down they will attempt to repair it. They will also improve the Stability of the section they are assigned to, reducing the chance of an overload (this is important if you want to put a lot of power into a section). Up to two Engineers can be assigned to each section, giving an extra boost to the equipment and further improving Stability.

Small (scout) ships will have 2 Engineers, medium sized ships will have 4, and large ships will have 6 Engineers.

Engineers take a fixed time to travel to and from their assignment, so keeping one or two Engineers unassigned will allow you to get to fires, and do repairs, faster.

Bottom bar and Ship Status
Along the bottom of the screen is a "bar" of items. From left to right they are Chat, Crew Members, and Ship Status. These items are shared with all UIs. Having a Ship Status overview for all roles will help keep everyone clued into what's happening with the ship, especially if they are playing online. Most things there are self explanatory, but the orange circle made of four parts, with the target reticule to the left of it, probably isn't. That displays the number of other ships who have locked onto yours. Knowing if and how many ships have targeted yours gives you a general idea of how much trouble you are in.


I know this isn't a very detailed explanation of all of these things, but I am mega busy with development at the moment. We want to show some new things in Tuesday's DevLog. :)

If you have any questions or suggestions, I'd love to hear them.


Thanks for reading!

Mark

P.S. The Engineer profile pics are placeholders, borrowed from another sim I love. :)

Pages: 1 2 [3] 4