The NanoFX Model Viewer is a utility that allows you to view models with the same graphical effects that will appear in Star Trek Excalibur. This latest...
Excalibur breaks the mould of traditional space simulation games by putting the player firmly in the boots of an experienced Starfleet captain. From the outset you will be able to control your character and command your ship as if you were standing on the bridge yourself. From taking direct control of the helm, to transferring command of any ship in your task force, or even calling your senior staff to the briefing room to discuss mission tactics; Excalibur is the most immersive Star Trek experience ever. Set six months after the events in Star Trek: Nemesis, Excalibur's story mode deals with the turbulent political scene caused by a decade of war and turmoil. From the second Borg incursion in First Contact, to the fall of the Dominion and the collapse of the Romulan political system; these events resulted in huge loss of life and changed the Alpha Quadrant forever.
The following article is an attempt to illustrate some of the technical and artistic design concepts that Excalibur development has gone through. Hopefully this will shed some light on the inner workings of how some things start on the drawing board, get loosely sketched into the engine, and then are remade or even abandoned in lieu of a better design. Whether it be due to a technical, functional, or useability impasse, designs for many things have come and gone during development so here's a look at one of those concepts that went through an internal trial-and-error process and was eventually replaced.
Every project starts at the table where artists and developers put their ideas down on a piece of paper. The Excalibur project is no different...
One of the main things when working on a large scale project is to break down your ideas into manageable chunks. Just as the fictional saying goes "Ideas are easy, implementation is harder". It is important for all artists to start their work with basic concepts and then determine which are good enough to be developed further.
There is a lot of thought (and even more work) being put into ideas which can turn out to be either good or bad in the end. This crucial process of the development approach takes time and only a handful of presented ideas ever make it into the working build of the game due to so many pieces having to fit together in order to sustain the overall goals and vision of the project itself, and to not break other areas of the game!
Because the concept process is usually fun and artists/developers have a lot of creativity when attempting to come up with design solutions, we think it would be fun for everyone to see some of the ideas our talented team has come up with over the years of developing Star Trek Excalibur.
Since Excalibur is still being developed, many of the concept ideas that will be shown here are either drastically changed by now (for the better) or are replaced by other solutions in general. Nevertheless, we would like to show you some of the ideas that the team started with.
Please note that these are concept images which means that most of these ideas may be drastically different or have been completely replaced.
So without further ado, let's dive into the concept work of one of the lead developers, Rob!
Name: Rob Mann aka Rob Archer
Position: Lead developer for gameplay mechanics
Responsibilities: Rob is currently responsible for the development of the game's mechanics, which is the development of the ways that the user/player will interact with the components of the game and how those components will respond. The tricky part of this is understanding the technology of Star Trek and transforming it into a gameplay mechanic.
Here are some of his concept ideas that did not make it into the game in their concept form;
"So this image is a concept design for managing the power systems. This would be the menu used to change power allocations to subsystems on a whole and it's based off of the Star Trek Bridge Commander menus. Of particular note is the submenu marked "Profiles". One thing we were (and still are) keen on implementing is having a mechanism that would allow the player to customize how the player's ship responded to a situation/mission. Rather than tweaking sliders when you need to fight in a defensive manner you could instead set the profile to be "Defensive" and the power priorities would update accordingly."
"While the command wheel showcased our minimalistic approach, this menu shows our "BC Approach". The general feeling is that Bridge Commander was an awesome game and while the UI was not the best and the game's mechanics lacked a certain level of depth, we were initially curious if we could use this as a jumping off point for experimenting with more advanced menus. This lead to the following concept image.
On the top we see the familiar power management menu with a slider for the key systems. Engines are split into thrusters, impulse, and warp drives. We also have transporters, tractor beams, and the deflector added. The power profiles menu, which has already been discussed, is also implemented.
However, a new addition to this is the "Advanced menu".
This would have allowed the player the ability to not only customize how their phasers as a whole would respond in a given situation but it would have allowed us to customize how individual weapons would behave. Allowing you to create even more complex power profiles such as "Attack Run" and "Forward Phasers 120% power". You should also note that the weapon system has the ability to be switched between "Primary" and "Secondary". This allows you to switch the weapons' power source to an alternative input (Secondary/Auxiliary Power Grids), a mechanic which still lives on. "
"Similar to artistic movements, Excalibur has also gone through a series of phases. The Command Wheel originates from our "Minimalist Phase." The concept was to condense our interfaces in such a way that they did not need to be on screen, but could still be accessed quickly. To begin with I started with the following structure: Engineering -> Transfer Power -> To Weapons. What I then did was translate this statement into a process; "Open Engineering Menu, Open Power Menu, Transfer The Power"
Since we are looking for a minimalistic approach we then minimise the actions that need to be taken by assigning the command wheel to a right click action. With it we eliminate the need for the user to move their cursor to a region of the screen to then open a menu and relocate the cursor to that menu. It also makes everything exist on a clear arc. Infact you see this right click context approach everyday when you use most windows based machines.
So why didn't we use this approach? Well, two reasons; First, it was very difficult to implement it graphically in our assigned interface mechanic and secondly, it was too simple and we had difficulty implementing our mechanics within the constraints applied to the menu."
That is it for now Captains...
We hope you have enjoyed this short presentation of Rob's ideas and hope it provides you with an idea on how things come and go within development. These could also help encourage ideas for people (you!) to mod and/or create entirely new UI interfaces based in part on past designs!
-Article by Nejc.
Latest tweets from @stexcalibur
Dec 6 2014, 8:25pm
T.co Merge remote-tracking branch 'origin/quickbattle_0.6' into quickbattle_0.6
Nov 23 2014, 5:32pm
T.co Start Of Procedural Solar System Generation Began work in progress trials for generating procedural solar systems...
Nov 23 2014, 5:32pm
T.co Filename corrections oops!
Nov 12 2014, 3:33pm
T.co Shield impact SFX Many variations.
Nov 12 2014, 3:31pm
T.co New Engine rumbles These contain a lot more bass information than the previous ones, should be cool if you’ve a n...
Nov 11 2014, 12:20pm
T.co LCARS SDK 14304.103 Update
Nov 3 2014, 2:05pm
Nov 1 2014, 11:34am
Nov 1 2014, 11:20am
T.co Free Arc Ball Behaviour added to camera behaviour toggle Updated TargetList.py to include Josh's Updated FreeArcB...
Oct 31 2014, 7:48pm