A Bold Maneuver in Real Time Tactics
FleetCOMM : Operation Vigrior (pronounced vig-ri-or) is a multi-platform real-time strategy game introducing a novel gameplay mechanic. Instead of fumbling over disorganized blobs of units, the player controls a synchronized squad of ships. This group acts as a cohesive unit; a Fleet. The ships follow maneuvers that are created and designed by the player with our game engines fleet formation tool.
We’ve designed this game following military doctrine. Our lead engine programmer served in artillery, ending his enlistment as a Corporal of Marines. His current mission with this mercenary crew, is delivering a unique combat interface.
We feel that strategy games have turned off most gamers, especially when it comes to combat controls and maneuverability. These gamers should be given an evolved interface, and a chance to show their strategic thinking. They should also have the opportunity to learn strategy games with the power of military precision.
Below, we demonstrate 2 prototype videos of our project, including a live demo, the whole set is our proof of concept. These prototypes do not represent the whole game, they are merely building blocks for the completed beta we want to finish by mid August, 2012.
Offering Commanders a novel advantage, and a refreshing challenge: design unique battle formations, synchronize combat maneuvers, and execute them in one click.
With our system, we give the player the means to create and store a number of fleet formations by dragging, dropping and rotating ships. The fleets you create and store will be ready for deployment on your next mission. Their associated formations deploy on the fly. Shift your tactics with a single click or finger tap, in response to the changing battlefield.
We owe Ender’s Game for the inspiration, while we made this combat prototype. We’ve dreamed of creating the fleet maneuvering games taught in the books fictional Battle School. We make a modest attempt at achieving that vision through our story, engine and art direction.
However, we still need YOU, Commander. You will be the one creating the next generation of combat maneuvers.
This is our mission in Operation Vigrior.
CORE GAME MECHANICS
This project is a 2D Real Time Tactics game. It will feature playable campaigns either solo, two-player, or four-player co-op. The player can create unique battle formations as they progress through the series of campaigns, increasing the size of their fleet, upgrading weapon systems, tweaking navigation controls and creating new fleets for their armada.
The game focuses on maneuvers and combat, with no infrastructure management. Your fleets, and your moves, nothing else.
The campaigns and story arc will be created by Santa Cruz’s Most Notorious Dungeon Master, Andrew “Deadman” Lucas.
So far, he envisions the campaigns as “Horde vs. Hero.”
GAME ENGINE : DRAUPNIR
Mercenary Games operates with independent technology. We are not beholden to external interests, nor marketing entities. We make games from the ground up.
We also use a mixed set of open-source and closed-source tech originating from other independent crews; GLFW, Pyro, AntTweakBar, enet, OpenSteer
As of this writing, our engine is approaching an alpha state, and requires at least 4-5 months of full time development to create a playable beta in a PC environment.
Why do we want to port this engine? We feel that this kind of strategy game needs to be seeded in gaming environments outside of the PC realm. Mobile devices, game consoles, and tablets have limited complexity of interface. These devices cannot accommodate the full spectrum of a traditional strategy game environment. A few of the problems we have researched include limited screen space, the lack of a keyboard and mouse, and being bound to the limits of a console controller. Mercenary Games attempts to solve these interface issues with our game engine, our fleet editor tool was designed to operate in as many environments as possible.
Our porting targets include the following digital oceans. These also represent the order where we will be porting our engine;
– Windows XP / Vista / 7, our engine is stable in 32 & 64 bit versions. Our goal is to create the game on these systems first, and to spread to the next set of systems once our engine is in a beta state.
– Linux (currently testing 64 & 32 bit versions) and Mac OSX (in development); Part of our porting efforts include these operating systems! Linux is close to our
– iOS; supporting the first-gen iPad, and possibly iPhones.
– Android; through the Android NDK or through Google Native Client.
– PlayStation3; our programmers have experience developing on the studio developers kit. We honed our engine skills at UCSC’s PS3 academic program. Porting to this system will not be easy, and will most likely make us hire a few more mercenaries.
UPDATE : we are now officially supporting Linux as part of our public beta release.
Unfortunately, we will need a good amount time to port our engine. We can guarantee a Windows + Linux Desktop PC release with our initial goal. However, if we significantly surpass this goal, we can commit our time and effort to releasing to other digital platforms.
As of this writing, our engine, including all our particle effects and sprites, measures at a very lean 115MB of memory (including our own internal game engine editors and modding tools), while only occupying 30MB of drive storage space. We’ve also tested and operated on the oldest, and most unreliable systems we can find. We designed this engine to take a beating, and survive. We intend to keep our systems lean, and with your support, this engine can fly through all digital channels.
The 64 bit version for Linux should be ready for testing once we are approved. A 32 bit version is just a matter of time.
If you have the time, we’d love to show this off to the Linux community. Please spread the word, and we hope to have a large armada of Penguins! 🙂
EDIT : an explanation about our porting process, so the Linux community can be clear about our efforts.
So far, our build compiled and ran under Linux, and most of the effort required package management and also porting over sources mostly AntTweakBar, GLFW and Pyro. The rest of our sources are all C/C++, and have no further dependencies that are operating system specific.
For us, it’s a matter of completing the base build porting over, the rest of our code is trivial to port, and the grunt work is mostly un-mangling system specific stuff.