Guildsmanship: Battle-Scapes (Canceled)
Guildsmanship: Battle-Scapes (Canceled)
Turn-Based Team-Battles (TB2) for multiple networked players using the OGL-SRD
Turn-Based Team-Battles (TB2) for multiple networked players using the OGL-SRD Read more
Guildsmanship: Battle-Scapes is a turn-based team-battle system (TB²) for Fantasy Role-Playing tactical encounters. It will use the Open Game License (OGL) System Reference Document (SRD) to source its game content.
For those of you not up to speed on the past 12 years or table-top RPGs (and don't want to read the linked articles), the Open Game License (OGL) was designed to publish the System Reference Documentation (SRD) which defines the rules as used in the D20 system which defines compatibility with the 3rd and 3.5th editions of Dungeons & Dragons from Wizards of the Coast (WotC).
Keywords in a nutshell: OGL-SRD, turn-based, automated, networked, 3D perspective, lighting, vision, cover, concealment and flight.
I claim no affiliation with WotC, D&D or the D20 system license.
Classic Pen and Paper, Automated
Battle-Scapes models Classic Pen-and-Paper (CPnP) OGL-SRD rules to handle all in-game "book-keeping" such as available actions, movement modes, initiative driven game-turns, geometric-tactical conditions, characters attributes, magic, weapons, lighting, senses and awarenesses.
Automation comes in degrees. While the framework has a random dice roll value generator that you can use to auto-roll, you will be able to easily throw a switch to "roll-your-own" and provide those values when requested.
Basically, all the things that make OGL pen-and-paper gaming time consuming have been automated and emulated, including all the things that you never thought anyone could incorporate well into a computer simulation: OGL-SRD-style flight, vision senses, size limited movement, cover and lighting.
Team Tactical Head-to-Head
Battle-Scapes works like a head-to-head tactical board game (in the same vein as D&D Miniatures, but using a more faithful implementation of the OGL-SRD) without a "game-master", pitting two or more teams against each other with either player hosting, or using a dedicated host process to handle more than two players.
There will be a small variety of game-play modes (TBD) including the obvious team elimination; variations including limited re-spawning and working towards a point goal, and limited re-spawning with tactical goals such as capture the flag.
The following is an "in-framework" example of a one on one (that is one character per team) combat session using the framework test client and test server tools (don't think of this as the completed game framework, please!). This is similar to the side-by-side screens in the video, except in the video at least one of the characters had dark-vision and a great-sword.
While the test utilities are not pretty, they do show that the plumbing of the system can run combat, movement, turn tracking and action prerequisites with the host process and multiple clients. Imagine (if you will) picking characters from a team roster, controlling multiple characters, a more game-like flow, and better UI prompting and feedback on activity.
Also toying with the idea of a team (or player) aggregate isometric camera mode, as I see the value in providing the commander with a view of the whole field based on troop vision. Camera mode is already an abstraction in the client UI framework, so no big refactoring to add this in; just a little work aggregating multiple character visual knowledge, and making sure the topography doesn't occlude the view of the action.
I haven't made any test client UI to select spell actions or spell targets yet (just a prototype cell aiming overlay cursor), so I obviously haven't shown that. I do have about 70 spells complete from 0th through 2nd level for arcane and divine casters (some higher level spells are in the same family as lower level spells, such as cure and inflict). I want to make sure all the combat useful spells are represented in the game release.
Also, the UI for switching weapons will be simplified into a macro-like operation (and dropping items will probably be suppressed), while still abiding by action limits.
The system will include support features in the workshop for the creation of maps, graphic resources, characters, team rosters and equipment. There is no walled-garden in Guildsmanship.
Here's some screenshots from the base framework tools (not the workshop for the final game) to demonstrate what the level of configurability available in the framework currently is...
I'm currently working on building a character model creation utility to be released out-of-band from the Kickstarter. I've been working on making my base packaging and visualization libraries isolated from the gaming framework so I can get them on CodePlex as OpenSource for whomever wants them.
The Uzi.Packaging assembly is already on CodePlex.
Game as a Game, not as a Service
A core goal of Guildsmanship is to keep costs of the game system comparable to CPnP rule-book costs, and to allow players to generate their own content and share them across the community. In effect, compatible goals as classic pen-and-paper, but automated.
Guildsmanship: Battle-Scapes is not a centrally hosted massive community game service, it is a system of standalone programs for playing, self-hosing and managing content. The game will be distributed with a set of maps (more if you get the standalone host and workshop), a set of character models, and a set of predefined playable characters.
I played Dungeons & Dragons in the early 1980s, at about the same time that the Atari VCS was out, and I first dabbled in programming on an Apple ][+. One of the neighborhood kids father made an Atari cartridge that could accept removable chips (hmm....) that impressed upon me the idea for an adventure game system that could have additional content loaded, while the "core" of the game and one's characters could be carried over, much like D&D modules, but automated.
I am fairly certain that every programmer who ever played D&D probably at one point or another said to themselves: "someone should write a program to do this". Well, I did too, and like most people promptly waited for someone else to do it.
Return to the Temple of Polyhedral Dice
Much later, after starting a family, a chance encounter with an old AD&D book I owned led me and my kids (and brother-in-law) into a multi-year trek across a fantasy world (under 3.5 D20 rules). Good times were had, especially with an 8 year old boy, a 6 year old girl, and an occasional 4 year old girl who liked to swing great-axes at doors (she hated doors, thought they slowed down the game).
I was the game master, and had to build the "temple of polyhedral dice" as preparation work each week. Eventually, after doing the same complex preparation work by hand week after week, and seeing the group slow down as the sheer number of rules and features in play stressed everyone's active memory (everyone was about 3 years older by now), I resurrected my idea of automating turn-based adventuring realities.
If no one else was going to automate this, then apparently it was up to me.
It's been close to seven years since I first started work on the game management tools that later became my framework (after a number of restarts). It's taken so long because life gets in the way, and the scope of what I'm building is actually quite large. Patience has become built into my way of thinking, but I have often longed for the day (and began assessing possible paths to achieve it) when I could unleash myself full-time on my vision and get this project all the way out of my head.
Through I was feeling secure in the foundations and scope of what I was doing (probably by about year 3), I had no tangible (look and feel) example for quite some time. As such, I had nothing to prove to anyone else that this was possible, and that I was the man for the job. The amount of time I could spend working on this was pitifully small, but the labor was one of love.
Once I finally closed the circuit from hosted modeled fantasy world, to player desktops via character perspective and knowledge, through turn-based actions of movement and combat back to the server, (repeat per character, repeat per turn), I had what I needed to showcase the vision, just not in its final form. I toyed with finding investors, making a breakneck pace to a "finished" (game), but finally I was inspired by Kickstarter earlier this year after the success of the OOTS reprint campaign and various game fundings.
With this showcase, now I can finally appeal for assistance finding the resources to allow me to focus full-time on this project for a few months and deliver a playable FRPG experience (in tactical head-to-head form).
The Ikosa Framework tools referenced in the video (and the screenshots here), the website and my blog (as a proof of concept) were intended for testing and bootstrapping model features (in the workshop), client and server features (host and client) and user interaction (client). They show that the system is not vapor, even if not "complete" or polished (hence this project), and prone to crash or seemingly lose keyboard focus.
The tools I update for testing include the:
- Ikosa Framework Test Host (fairly simple bootstrapper for the services and turn trackers)
- Ikosa Framework Test Client (test-bed for UI interactivity, closest approach to a "game" framework I've produced so far)
- Ikosa Framework Workshop (not previewing at this time, too easy to injure one's brain using it; but some of the features can be seen in the screenshots here).
I am aiming for a more "arcade cabinet" or console like feel, with a bit more music and graphics, and quite a few less tabs and pop-up windows. Common game actions will be simplified but fully realized. Basically, less like the office product I demo in the client and screenshots and more like a game :-)
I've grown fond of the blocky characters that my son and I first plotted from a model we built in LEGO bricks back in July 2007. All of the characters have been derived from these initial measurements with tweaks and extrusions. Other character modelers will be able to define their own content (though I'll be tightening up and expanding upon the "release models" as part of this project). Model content will be expandable both through a character construction utility in the workshop, and via the published specification of the structure (WPF XAML Model3D with some extensions).
Alright, here's where I lay out what I've got to do in order to push the framework I've built so far into a playable OGL-SRD game:
- character management
- team roster and item management
- game start-up and ending conditions
- intra-team initiative ordering
- stylize harness to be less like an desktop office product
Client Usability Features
- mappable keybindings
- client implementation of effects animation
- cell targeting
- information billboards (interjected into 3D worldview)
- full and special attack action selection
- complex action selection (aim and invoke)
- OGL content citation (if player desires to see it) in game context
- full range of combat useful spells from 0th to 3rd power level, for both arcane and divine spell-casters
- special combat maneuvers and linked combat movements
- finish movement and targeting support for larger miniatures in the 2x2x2 cell range
- basic creature templates such as skeleton, zombie, sacred and profane
- service definitions of effects animation for linear, bolt-like and volumetric
- parameterized model team tags and colors on miniature base-discs
- climb and jump movement
- ethereal mechanics (Blink spell and low-level ethereal creatures)
- cloud and spread mechanics
- relax cover modifiers for barely intervening terrain
- OGL code attributes and perusal user interface
- flat artwork for UI information display and selection: weapons, armor, items and spells
- 3D artwork components for "miniature" models to provide a flexible range of choices across classes, body types, weapons and gestures
- framing and incidental flavor music
- sound effects
I'll be needing to get a code-signing certificate, don't have one yet.
I doubt my current hosting solution would handle the stress of multiple people trying to download the completed software, so I'll have to upgrade my service provider level. Such is the Internet.
Is this a Virtual Table Top?
No. The Ikosa Framework is a complete OGL fantasy world emulation framework. Guildsmanship: Battle-Scapes provides unique in-world perspective for every character (based on their senses and awarenesses).
Virtual Table Tops FRPGs show a revealed world from a game-master, and VTT tacticals show a shared tactical view with total tactical knowledge for all players.
What's Ikosa? Guildsmanship? Battle-Scapes?
Ikosa is the framework I've been building to model a complete OGL game-world. It can (theoretically) handle game play modes with a game-master, head-to-head, and automated quests. It could be the back-end to a character generator. Its a software framework.
Guildsmanship is the name of a hypothetical FRPG game system for small gaming groups run by a game-master. It is built on the Ikosa Framework. It is my "ultimate" FRPG automation goal. But first things first
Guildsmanship: Battle-Scapes would be a "brand" derivation of Guildsmanship, specific for head-to-head combat. However, since the production demands for a working tactical head-to-head game are simpler than a full FRPG, it will go out the door first.
Ideally, I'd like to get a general purpose solo-team quest system out there to see what kinds of quests people can build. Once I find the time to get serious about automated creature actions (and scripted, and plug-ins), I can worry about that. First things first.
What makes this "complete"?
"Complete" emulation is a goal. In terms of what those goals are versus what has been delivered by other games and systems using OGL rules, Battle-Scapes delivers a few things that are missing in most turn-based tacticals such as senses, awareness, calculated terrain and intervening object cover (in 3D space), concealment, hiding, flight (including maneuverability), falling, jumping and climbing.
Other features in the framework that apply more to full RPG with quest-based campaigning include polymorphing, illusions, turning undead, compulsions, information flow, detection spells, identify (and false identification), coin weight, in-game language obfuscation and a mechanism model for traps and secret doors/compartments (amongst other things).
Is this a MMORPG?
No. Guildsmanship: Battle-Scapes is multi-player, networked (no central online meeting place or servers) turn-based tactical (which is part of a role-playing game).
Is this a Real-Time Shooter?
No. It is turn-based, but since it's all combat, is loosely qualifies as a "shooter".
Is this a Walled Garden Content Platform?
Battles aren't done in gardens. Build your army, fight your enemy.
My philosophy is that even if I were to eventually build a community service, once you buy the game, you are free to use it no matter what. While I can foresee people selling models, levels, characters, etc (probably more so on in Guildsmanship than Guildsmanship: Battle-Scapes), I see no reason for that to be your only avenue to expand the content for your games.
Tabletop RPGs have moved forward as much (if not more) on the creativity of the players and game masters as they have on pre-defined content. Pre-defined content is good, and shared content is great (if you can adapt it). This framework aims for those goals.
Is this Open Source?
No. First, it's not something I'd want anyone else to build off of or "fork" in its current state. A lot of the design was ad hoc, and I already see some great places to "collapse" similar but currently distinct features.
Uzi.Packaging (the name is a long story, steeped in the history of the project) is currently available in source form on CodePlex under the Microsoft Public License. I am planning on putting some version of the visualization library there as well, once I figure out how to deal with the dependency on the WPFShader library (to which my local version has an added class or two).
And I definitely would love to produce an API reference and an e-book explaining the structure of the systems. But, first things first.
Why only on Windows? WPF?
My professional (business system) background has been in Windows development (mostly on the server-side), it's what I know best.
I had always been looking for something to make programming 3D easier, and WPF is about the best simplest on-ramp. I spent some time a few years back isolating the WPF code into a single assembly so the framework itself isn't highly dependent on WPF and may be ported in the future (first things first).
Only the XAML model structure is tightly WPF right now, and since it is XML, it can readily be translated to other frameworks as needed.
Is this a Sandbox Game?
No. The tactical local-map class isn't up to being a fully open-ended dynamic morphable system. The typical FRPG tactical map is designed by a game-master or level designer and is usually somewhat well bounded in its extents. Broader geographic concerns are usually handled at a different scale of game-play in FRPGs.
Also, there are no service-endpoints for non-game-based changes (and no epic level spells yet to reshape landscapes at scale).
I've got ideas on how to do these things both to make the editing experience better and because various spells (like Passwall and Stonewall) can alter the landscape. I also have ideas on dynamically building (and storing) tactical maps from regional physiographic data (I won't call them plans until I start working on them), but first things first.
Is this OGL, SRD, D20 and/or, D&D?
Strictly It will be OGL with optional in-game attribution and separate viewable content.
Wizards of the Coast released the SRD as OGL in order to produce D20 system games. This game does not claim D20 compatibility, but does use the SRD.
D&D is a trademark of Wizards of the Coast and they have their own gaming brand. Frankly when they went 4th edition, I haven't followed suit, since it looked like their CRPG strategy was to simplify the rules rather than up the ante on the simulation capabilities of software development (which is the route I am going for).
Risks and challenges
The main risks in getting this project done are in testing and managing test issues. The overall base framework is operational, meaning that this project's goals are to remove the challenges of not having enough contiguous time blocks (outside of normal "pay the bills" life) to get a playable game system out of my head and into players hands.
I have access to two gaming groups for testing purposes: my family group, and my son's friends. I intend to keep the development builds publicly accessible during most of the development process, but will probably go "darker" or keep focused on the people who give the *best* community feedback with the builds closer to release.
Since the core of the system is already functional, a great deal of work is expected to be in the end-to-end pathways of the more complicated combat actions, higher level spells, automated open game license attribution, and intricate class and creature features.
Given the large pool of implementable features, under a time-crunch to meet project goals certain features can be dropped without impacting playability of the game; and if fortune smiles, can be amended in post project bolstering of the game.Learn about accountability on Kickstarter
- (30 days)