Arcen Games

General Category => AI War II => Topic started by: x4000 on September 02, 2016, 05:26:55 PM

Title: AI War II: Design Document First Unveiling Is Now!
Post by: x4000 on September 02, 2016, 05:26:55 PM
Original: http://arcengames.com/ai-war-ii-design-document-first-unveiling-is-now/

This is only the beginning.  The first 36 pages of the AI War II design document are in place.  I'm sure that folks on the forums will have a lot of commentary already about this.  I'm going to be out over the weekend, just to warn you, but I wanted to leave this with you to peruse before I left.

The largest segment so far is detailing the technical advancements of the sequel (most of which are already in place).  It's actually kind of insane to see how far things have come from where we left AI War "Classic" in 2014.  It was already quite long in the tooth by our standards then, being very rooted in a 2009-based code architecture that had been remodeled enough times that we couldn't really go further with that.

earth

Squads

This document does start by going into the rationale behind ship squads, which are a change with major performance-boosting ramifications and that should be able to yield an increased feeling of giant space battles more along the lines of the pre-Unity battles in AI War Classic.  Feelings in this particular area may run a little strong since it is a pretty big shift (although familiar to many RTS games), so there's a lot of math and explanations there to hopefully make it clear just how freaking awesome this change is and why you should be happy about it.

The TLDR is that it will make your game run more smoothly even while we are able to do more complex things.

Multi-Part, But Not Modular Ships

This is the first example of something that is being changed that will have an impact on a lot of units in the game.  Based on discussions with players on the forum, we should basically have the best of what modular ships offered before (the multi-part bit), but without the fiddly interface for customizing them during the game.

Of course, given the moddable nature of the new game, you can customize ships to your heart's content anyway.  And there are space platforms that are a thing that have been designed but not yet written up, and those will also scratch that same itch...

Other Bits

There are a lot of other sections of the document that are just stubs for now, and they will be filled in next week.  First of all focusing on the largest structural changes, since those require the most discussion with players.  Then moving into smaller and smaller topics until we have a document that we feel is complete and correct.

Kickstarter

Depending on how long it takes us to reach that "complete and correct" status with the design document, and how long some of our prototypes for a few things in the new game take, we will be heading to kickstarter with this in 2-4 weeks.  The game already has a remarkably complete base in terms of the multithreading, the networking (minus transport layer), and so on.  The status of items are noted in the document above, and quite a lot of the trickiest things are already in the "complete" camp.

That said, there's still a ton to do, so it's not like the game is going to be rolling into early access tomorrow.  But the goal is for us to be able to show you the vision for what this is (visually and otherwise), concretely show you what is planned (design document), and give you an accurate timeline for completion (with appropriate buffer).

If you're interested in hearing about the kickstarter when it goes live, you can always email us at arcengames at gmail dot com.

 

I'll see you all Monday!

Chris

 

 
Title: Re: AI War II: Design Document First Unveiling Is Now!
Post by: _K_ on September 02, 2016, 05:33:52 PM
Wooo, Excitement!

I wish you guys luck and hope your financial situation won't end up forcing you to rush things too much!
Certainly gonna be interested in what fun things you'll be offering in the KS campaign.
Title: Re: AI War II: Design Document First Unveiling Is Now!
Post by: kaitox on September 02, 2016, 05:34:11 PM
Finally a game announcement worth following.
Title: Re: AI War II: Design Document First Unveiling Is Now!
Post by: kasnavada on September 02, 2016, 06:28:26 PM
Quite a long read, and possibly a bit too technical for some. Still. Interesting.

Just a point, modding should enable an unit cap from different sub-designs. That would recreate as close as possible the feeling of modulable ships within what you're calling a multi-part ship.

Title: Re: AI War II: Design Document First Unveiling Is Now!
Post by: Toranth on September 02, 2016, 06:41:34 PM
Quote
1.e.iii. Specific Areas Of Moddability
...
This form of modding could not be used to create completely new AI logic, or new hotkeys, or things of that nature.
So, no allowing mods to supply things like scripts for events?  I understand that it'd be a huge amount of work to allow someone to completely, or even partially, replace the AI, like Civ and some other recent games allow.  But I was hoping for the ability to attach small scripts to units / systems / other events.  That way, you could effectively add new mechanics in mods, just by attaching something to a "OnSystemEntry" or "OnUnitDestroyed" event in the XML.
Title: Re: AI War II: Design Document First Unveiling Is Now!
Post by: Tridus on September 02, 2016, 06:48:43 PM
Make sure to put some thought into the kickstarter pitch and the tiers. You only get one shot at that. Looking forward to it. :)
Title: Re: AI War II: Design Document First Unveiling Is Now!
Post by: chemical_art on September 02, 2016, 07:53:58 PM
The savings from using squads was brilliant. I know Chris was excited when I suggested that support units could be attached to a "mother ship" (shield bearers, X boosters, etc) so I wonder if the code will be made so a "squad" of those units can hook with several combat squads automatically. Would save a ton of micro yet actually increase potential tactics.

Also the idea of having true factions opens up all sorts of fun scenarios. You could make proper enclaves for third party units, or all sorts of other fun things.

Title: Re: AI War II: Design Document First Unveiling Is Now!
Post by: Draco18s on September 02, 2016, 09:29:56 PM
Quote
We will also use the nonsim drawing offsets of shots in such a way that shots properly come out of specific ships in the squad, visually, but actually always come from the center of the squad under the hood.  The visual and sim positions then converge via lerping as they approach the target, leading to a really nice visual effect.

Ya know, you could non-sim the destination to a specific unit in the squad, too.  So Fighter #4 looks like it's actually firing on Bomber #7.  Lerping it towards the squad's center is technically something someone would notice.
Title: Re: AI War II: Design Document First Unveiling Is Now!
Post by: mrhanman on September 02, 2016, 10:06:31 PM
Wow.  This is really happening.  :o
Title: Re: AI War II: Design Document First Unveiling Is Now!
Post by: Misery on September 02, 2016, 10:36:55 PM
Well, I for one barely understood any of that.... lots of tech stuff and math.... but it's interesting to see it anyway.  Design documents aren't exactly something I've seen very often.   And this one is going to be huuuuuuuge, isn't it?
Title: Re: AI War II: Design Document First Unveiling Is Now!
Post by: NickAragua on September 02, 2016, 11:10:06 PM
Looks solid, I'm pretty pumped up, especially re: the technical improvements. Also looking forward to seeing maybe a uniform art style?

As for the squads, I'm willing to wait and see. It's certainly true that I almost never manipulate individual units, unless they're huge, and I almost never split up a single type of ship into multiple groups.

Re: replacement of AI Progress, well, I'm looking forward to seeing what replaces it.
Title: Re: AI War II: Design Document First Unveiling Is Now!
Post by: tadrinth on September 02, 2016, 11:53:21 PM
Oooo, you have quadtrees now!

Oh god yes squadrons. 
Title: Re: AI War II: Design Document First Unveiling Is Now!
Post by: Elestan on September 03, 2016, 12:04:30 AM
Original: http://arcengames.com/ai-war-ii-design-document-first-unveiling-is-now/

"Squads" sound great to me.  I do have a question about "Multipart" ships:

Quote
Thanks to the EntitySystem infrastructure, any ship can have any number of guns, abilities, or other features on them.  These can be destroyed or added during gameplay if required, and disabled temporarily.

So, if I've got a Multipart ship, and I destroy one of its guns and add a shield generator feature to it during gameplay, how is that different from swapping out a module?
Title: Re: AI War II: Design Document First Unveiling Is Now!
Post by: tadrinth on September 03, 2016, 12:20:24 AM
So, if I've got a Multipart ship, and I destroy one of its guns and add a shield generator feature to it during gameplay

If I follow correctly, the difference is that you can't do that!
Title: Re: AI War II: Design Document First Unveiling Is Now!
Post by: Elestan on September 03, 2016, 01:05:09 AM
So, if I've got a Multipart ship, and I destroy one of its guns and add a shield generator feature to it during gameplay
If I follow correctly, the difference is that you can't do that!

The text I quoted seems to say that you can; hence my confusion.
Title: Re: AI War II: Design Document First Unveiling Is Now!
Post by: Draco18s on September 03, 2016, 01:07:04 AM
The difference is that there's no player UI to do that stuff manually.  Yes, a riot control starship can still have a shield and it can still get destroyed and rebuilt, but you don't get to choose whether or not it has one: that's defined by the XML (which you could edit, but not at runtime).
Title: Re: AI War II: Design Document First Unveiling Is Now!
Post by: kasnavada on September 03, 2016, 01:24:34 AM
So, if I've got a Multipart ship, and I destroy one of its guns and add a shield generator feature to it during gameplay
If I follow correctly, the difference is that you can't do that!

The text I quoted seems to say that you can; hence my confusion.

From what I've seen and what the document says, it seems to be a technical limitation of AI war.  The "object", or "model" that handles "ships" in AI war can only handle one type of "attack". When they made modular ship, in game, it was "modelled" as one ship that moved... and one ships for all "turrets". And basically all things in the game, from buildings to turrets to shields to ships themselves, was a "ship" as far as the game model was concerned.

Now, a single object will be able to handle subsystems on its own.
That single object will be modifiable from mods, not in-game.

That would therefore enable the player to create any modular ship "set-up" he wants, in a mod.

@About squads... another thing that isn't considered in the document is that moving in formation, collision, having formations collide in realistic ways would also require a lot of work. The code to handle thousands of ships already exist in AI war I. The code to handle squads ?
Title: Re: AI War II: Design Document First Unveiling Is Now!
Post by: Elestan on September 03, 2016, 01:45:28 AM
The difference is that there's no player UI to do that stuff manually.  Yes, a riot control starship can still have a shield and it can still get destroyed and rebuilt, but you don't get to choose whether or not it has one: that's defined by the XML (which you could edit, but not at runtime).

I'm trying to figure out what "during gameplay" means here:

Quote
Thanks to the EntitySystem infrastructure, any ship can have any number of guns, abilities, or other features on them.  These can be destroyed or added during gameplay if required, and disabled temporarily.

Does that mean that if you edit the XML, the game will pick up the changes live?

In any case, it's sounding like I and my friends are going to be losing one of my favorite features; the modular ships are our favorite ones to use, precisely because of their runtime reconfigurability.  Essentially, we're direct counterexamples to this statement:

Quote
Modular ships themselves are not desirable, because configuring them is a pain.

We like configuring the modular ships, tinkering and rebuilding them to optimize them for whatever our current situation is.  Yes, the UI is fiddly, but that's an issue with the UI implementation, not with the underlying concept.  Designing ships outside the game doesn't scratch this itch, because it's the in-game adaptability itself that we like.

I will say that upon reflection, I probably wouldn't want every ship to be reconfigurable.  But we really like having the Champion ships and at least a handful of others.  Perhaps we're just in the minority on this, though opinion on the topic seemed split to me.  I could also readily believe that implementing an AI that can design and use modular ships effectively is not a small task, and perhaps that's also a factor here.  That's easily solved, though:  Make the modular ships Human-exclusive.  :-)
Title: Re: AI War II: Design Document First Unveiling Is Now!
Post by: Cinth on September 03, 2016, 01:51:28 AM
Think more in terms of how Starward Rogue handles weapons.  That system can be further modified (in code) to allow us to pick and choose what weapons go in those slots.  Modular ships in a sense aren't going away.  How the game displays that to us is.

Of course, this is how I interpreted that section of the design doc.
Title: Re: AI War II: Design Document First Unveiling Is Now!
Post by: PokerChen on September 03, 2016, 02:41:07 AM
Responses to some sections:
1.a.iv. Matchmaking and/or NAT Punchthrough
The scope and length of AI War really makes the playing community behave not like RTSes but like online ARPGs, where most people are doing their own thing in their own instances, but would still like to socialise and have the opportunity to get together. Therefore, I suggest you should consider making something analogous and call it a Lobby or Global Chat, to sit apart from Steam Overlay - essentially IRC global/party channels that players currently playing can choose to join, as well as players who are not currently playing. Forcing a matchmaking model is too high-risk, and more importantly removes the engagement of people who are currently playing.

1.d.vi. Animation
Yes please, especially with squad-based implementations and multi-part ships. Not demanding for bloom when battleships fire their beams per se, but you'll need lively units to draw in the broader crowds.

1.e.iii. Specific Areas Of Moddability
I believe the phrases "modders can create new AI-Types" and "modders cannot create completely new AI-Logic" are fundamentally contradictory. Classic's definition of AI-Types is incorrect here and easily leads to wrong assumptions as you've tried to clarify. What we were changing in Classic is the assets and materiel that the AIs have, and how much they prefer pursuing precoded tactic X. Suggest more neutral terms like "AI Personalities" to frame them in the same league as the "Human leaders" feature.

2.c. Multi-Part, But Not Modular, Ships
 There are definitely still many people who like changing their ship loadouts in-game. In particular, flag-ship units like Battleships and Neinzul Combat Carriers can be made to specialise their loadout, which would strongly benefit players having flexibility.
 Are you willing to consider making an interface pre-1.0, if we can successfuly "lobby" this issue? Whether this interface sits within the game or as a separate executable entitled "Ship Editor", is less of an immediate issue. However, I would clearly like a way to make, share and download designs efficiently, in a way that I switch between vanilla, my stuff, and arbitra mod. This touches on the ability to make mod-packs.

 Using this, we can at least pre-generate major variants before the game, if not within the game itself.

2.a. Squads of Units
Homeworld 2, and Dawn of War. Easy. Note that meaningful squad numbers here range between 3 (HW2 scouts) and 12 (Orks). Advise try not to go beyond this unless it's drone warms (24, Homeworld 1 Drone frigate).

Title: Re: AI War II: Design Document First Unveiling Is Now!
Post by: Cinth on September 03, 2016, 03:29:08 AM
Responses to some sections:

1.e.iii. Specific Areas Of Moddability
I believe the phrases "modders can create new AI-Types" and "modders cannot create completely new AI-Logic" are fundamentally contradictory. Classic's definition of AI-Types is incorrect here and easily leads to wrong assumptions as you've tried to clarify. What we were changing in Classic is the assets and materiel that the AIs have, and how much they prefer pursuing precoded tactic X. Suggest more neutral terms like "AI Personalities" to frame them in the same league as the "Human leaders" feature.

2.c. Multi-Part, But Not Modular, Ships
 There are definitely still many people who like changing their ship loadouts in-game. In particular, flag-ship units like Battleships and Neinzul Combat Carriers can be made to specialise their loadout, which would strongly benefit players having flexibility.
 Are you willing to consider making an interface pre-1.0, if we can successfuly "lobby" this issue? Whether this interface sits within the game or as a separate executable entitled "Ship Editor", is less of an immediate issue. However, I would clearly like a way to make, share and download designs efficiently, in a way that I switch between vanilla, my stuff, and arbitra mod. This touches on the ability to make mod-packs.

 Using this, we can at least pre-generate major variants before the game, if not within the game itself.

2.a. Squads of Units
Homeworld 2, and Dawn of War. Easy. Note that meaningful squad numbers here range between 3 (HW2 scouts) and 12 (Orks). Advise try not to go beyond this unless it's drone warms (24, Homeworld 1 Drone frigate).

Going to give my take.

1.  As far as AI Type and AI Logic, think more like assigning a behavior to an enemy unit in Starward Rogue.  There are lots of behaviors to choose from, but you can't create more.  You can mix and match to create new Types of AI.

2.  I'd be willing to bet it would be a simple in game way to assign stuff to multipart ships from the main view.  I'd almost think like putting modules on a champ from the main screen rather than the design window.

2.a.  That's probably a safe guess on the squads.  I'd assume here that this will be a second way to abstract unit caps.
Title: Re: AI War II: Design Document First Unveiling Is Now!
Post by: Pumpkin on September 03, 2016, 03:38:46 AM
Woa. So we're far from "just remake the engine, don't touche the design". Faaar-far-far.

 ???
 :-\
 :D :D :D
Nice.
Title: Re: AI War II: Design Document First Unveiling Is Now!
Post by: Tridus on September 03, 2016, 09:49:07 AM
At the moment, everything in here sounds good. I'm pretty excited about the huge performance gains from squads, given some of my games get wildly out of hand with ship counts (and Dyson Gatlings, and Botnet Zombies, and anti-FS exos, and the AI going nuts from the SuperTerminal...) and the lag becomes noticable.
Title: Re: AI War II: Design Document First Unveiling Is Now!
Post by: Draco18s on September 03, 2016, 11:34:43 AM
Quote
Thanks to the EntitySystem infrastructure, any ship can have any number of guns, abilities, or other features on them.  These can be destroyed or added during gameplay if required, and disabled temporarily.

Does that mean that if you edit the XML, the game will pick up the changes live?

No:

(which you could edit, but not at runtime).
Title: Re: AI War II: Design Document First Unveiling Is Now!
Post by: Cyborg on September 03, 2016, 12:55:34 PM
It's getting hard to keep up with this forum! There are so many threads, and I do work all day, so I'm trying to keep up with everything that's going on. It is moving fast, lots of excitement, lots of ideas being thrown around.

I read the complete design document (so far).

I am so excited for this game. I can't think of another game I would rather play or that is more exciting than the design document I just read. We are getting AI War but.. I don't think we have ever seen a war like this. It's strategy, it's action, it's written to be a smart game but with all the exploding space sugar on top.

I have some questions if you have time. Some of them are just curiosity and some are "passionate AI war questions."

#1 Why is 3-D faster than 2-D?
I don't understand how it's faster to compute polygons than position a sprite. Not saying I don't believe you, just wanting to know why.

Passionate AI war questions using the numbers from the design document:

1.F.iii. What happens during a corrupted status file?

During AI war classic, you could fix a files when there was a bug or for other reasons. How do we fix problems here? Maybe a post release question and not for 1.0.

Your statement of purpose:
1) Great. Perfect. We like smart games.
2) Also great.
3) Hopefully the planet cracker stays? Spire? Hybrids? And I like the neinzul. Golems. The trader. Devourer. And the avenger. And showtime. And cross planet attacks. Where do we write all of the things we care about? I thought there was a thread for that… looking…

2.a. Squads of units
I'm on board. I think this is smart. You will need to fiddle with the animations or the graphics to give them a unique look in the squads so they all don't look like the same triangle rubberstamped side-by-side.

2.a.ii. The animation data for the squads would be better if it was randomized or if you computed a random pattern and used it later. Anything that is player recognizable as a pattern is not as desirable.


2.h. Replacement of AI progress
I'm on board. I think your reasoning is sound. You're not talking about removing consequences, or fun AI reactions to how we play, so I don't think we should be worried. I think this sounds like we could get more intelligent, nuanced AI.

Some of your math, it feels very informal because you change the numbers, for example some example 9999 or something. It doesn't really matter, I think you have the general math correct, but for a reader following along, if you want us to understand the math more easily, sticking with one set of numbers and going in order is great.

Title: Re: AI War II: Design Document First Unveiling Is Now!
Post by: Cyborg on September 03, 2016, 01:10:36 PM
Would someone please point me to the "stuff I care about" document?
Title: Re: AI War II: Design Document First Unveiling Is Now!
Post by: Aklyon on September 03, 2016, 01:15:00 PM
I haven't finished reading the whole thing yet. But from what I understand of what I've read of the technical bits, ti sounds like we might not have inevitably-slower-as-it-progresses multiplayer games anymore? Cool.

It's getting hard to keep up with this forum! There are so many threads, so I'm trying to keep up with everything that's going on. It is moving fast, lots of excitement, lots of ideas being thrown around.
It really is quite busy!

Therefore, I suggest you should consider making something analogous and call it a Lobby or Global Chat, to sit apart from Steam Overlay - essentially IRC global/party channels that players currently playing can choose to join, as well as players who are not currently playing. Forcing a matchmaking model is too high-risk, and more importantly removes the engagement of people who are currently playing.
Star Ruler 2 does this with an IRC channel, if chris wants an example of this. You can open it up and it'll connect, and you can hide it in its own little tab-button-thing on a side of the screen when you aren't looking at it. Entirely ingame.

Editborg: http://www.arcengames.com/forums/index.php/topic,18997.0.html (http://www.arcengames.com/forums/index.php/topic,18997.0.html) Here you go.
Title: Re: AI War II: Design Document First Unveiling Is Now!
Post by: Draco18s on September 03, 2016, 01:19:01 PM
Quote
#1 Why is 3-D faster than 2-D?
I don't understand how it's faster to compute polygons than position a sprite. Not saying I don't believe you, just wanting to know why.

Unity is weird in some places, and it has to do with--in this case--sending textures from RAM to VRAM across the bus.  What Chris is talking about is removing textures entirely (using only "flat" colored polygons) which involves sending only a handful of floats from RAM to VRAM--(x, y, z, r, g, b)--which would have to get sent anyway, plus a texture.

The slowdown comes from having to switch textures. Aka what is also referred to as "batching" or "draw call" (the three things are all related: one draw call is the best because it means everything is drawn on screen all at once, batching "groups" objects to reduce the number of draw calls, and "unique texture" causes more draw calls).*

Ostensibly it sounds like this would create much more basic looking units (there's only "so much" you can do without a texture) but I look forward to seeing what he plans on doing so that the visual fidelity we're used to doesn't disappear.

*Extra details:
For point of reference, for mobile games you want as close to 1 call as you can get, ideally under 5: "skybox, opaque, transparent, UI" whereas PC games tend to be fine until you get past about 200 draw calls plus or minus based on how powerful the computer is and what your "goal" is.

There's two kinds of batching: static and dynamic.

Static is defined before compiling.  These objects are "merged" to create one massive, unchanging, static object that is very fast to draw and compute hidden geometry (occlusion).

Dynamic is done at runtime, finding all objects that share the same properties that can all be rendered in one go.  For a sprite based game, this is "every unit with the same texture."  For a sprite sheet game, this is "all objects using the same sprite sheet."  There's a few other things that break batching, as well, but general case, think of it as "anything that has a different texture file applied to it."

This is why "realtime dynamic shadows" are such a hot thing to see in games: every dynamic light creates a texture at runtime that is then applied to geometry, called a Lightmap.  Every additional dynamic light doubles the number of lightmaps and the number of draw calls.  That's why most dynamic shadows are very low quality (keeps the resulting texture size small and speeds up the additional draw calls) and only so many dynamic lights are rendered at a given time (capping out usually at about 4).
Title: Re: AI War II: Design Document First Unveiling Is Now!
Post by: Tridus on September 03, 2016, 01:22:07 PM
Would someone please point me to the "stuff I care about" document?

You mean this one? https://docs.google.com/document/d/1E78-KtgIKyAExd9VpIKe2aXEKFO14A8b9zRLwRENkRk/edit#
Title: Re: AI War II: Design Document First Unveiling Is Now!
Post by: tadrinth on September 03, 2016, 01:40:44 PM
On modules:

Currently, when you kit out a champion, you do it in the game. If I read the design doc correctly, with the multipart ship system, the plan is to allow a particular ship to have different variants, like the preset Riot Control loadouts, or like the different Champion racial hull types. You can design as many variants as you want in the XML.  Then, in game, you can build whichever variant you want, and presumably there will be a way to switch to a different variant without having to scrap and rebuild.

That does mean you can't encounter a situation, and immediately in-game go come up with the perfect combination of modules for that situation and swap to it. I think you'd have to save, exit, make a new variant in XML, then load your save and switch to the new variant.  You could even rebuild the current module editor interface as a standalone app to make it easy to make new balanced variants by appending them to the existing definitions in the XML. 
Title: Re: AI War II: Design Document First Unveiling Is Now!
Post by: Tridus on September 03, 2016, 01:47:52 PM
On modules:

Currently, when you kit out a champion, you do it in the game. If I read the design doc correctly, with the multipart ship system, the plan is to allow a particular ship to have different variants, like the preset Riot Control loadouts, or like the different Champion racial hull types. You can design as many variants as you want in the XML. Then, in game, you can build whichever variant you want

Yep.

Quote
, and presumably there will be a way to switch to a different variant without having to scrap and rebuild.

That hasn't been stated that I've seen.

Quote
That does mean you can't encounter a situation, and immediately in-game go come up with the perfect combination of modules for that situation and swap to it. I think you'd have to save, exit, make a new variant in XML, then load your save and switch to the new variant.  You could even rebuild the current module editor interface as a standalone app to make it easy to make new balanced variants by appending them to the existing definitions in the XML.

Yep. Wouldn't be surprised if a fan decided to make a simple app or website for building ship design XML, given that it could be a matter of pick the base ship, then add/remove parts along with editing stats.
Title: Re: AI War II: Design Document First Unveiling Is Now!
Post by: Cyborg on September 03, 2016, 01:48:02 PM
Would someone please point me to the "stuff I care about" document?

You mean this one? https://docs.google.com/document/d/1E78-KtgIKyAExd9VpIKe2aXEKFO14A8b9zRLwRENkRk/edit#

Great, thanks, working on it.
Title: Re: AI War II: Design Document First Unveiling Is Now!
Post by: Elestan on September 03, 2016, 02:21:44 PM
Currently, when you kit out a champion, you do it in the game. If I read the design doc correctly, with the multipart ship system, the plan is to allow a particular ship to have different variants, like the preset Riot Control loadouts, or like the different Champion racial hull types. You can design as many variants as you want in the XML.  Then, in game, you can build whichever variant you want, and presumably there will be a way to switch to a different variant without having to scrap and rebuild.

That does mean you can't encounter a situation, and immediately in-game go come up with the perfect combination of modules for that situation and swap to it. I think you'd have to save, exit, make a new variant in XML, then load your save and switch to the new variant.  You could even rebuild the current module editor interface as a standalone app to make it easy to make new balanced variants by appending them to the existing definitions in the XML.

Hmm...I'll take it, if that's the only way to do it, but that just seems like addressing the "changing loadouts is clumsy" issue by making it even more clumsy.  If you're going to allow changing loadouts on an already built ship, what do you gain by making players leave the game and edit XML files to change them? 
Title: Re: AI War II: Design Document First Unveiling Is Now!
Post by: ptarth on September 03, 2016, 02:57:33 PM
The pure XML approach to object creation is great at single entity design (e.g., build a ship with weapons). However, when you are trying to interact with groupings of entities (e.g., ship balancing), it quickly falls apart. In SBR the flat files (e.g., buildings) were great. For SR I've half built a set of tools to extract and format the XML so I can compare across things (and eventually when I finish life will be great (and exportable)), which has made balancing tons easier. Spending some time building a system that allows for a combination (or converters) between XML and flat files would be a good time investment that will make later balance and unit organization much more straightforward. With such a system one could build units using the XML, but then balance and compare units via the flat file/spreadsheet interface.
Title: Re: AI War II: Design Document First Unveiling Is Now!
Post by: Draco18s on September 03, 2016, 03:00:04 PM
Hmm...I'll take it, if that's the only way to do it, but that just seems like addressing the "changing loadouts is clumsy" issue by making it even more clumsy.  If you're going to allow changing loadouts on an already built ship, what do you gain by making players leave the game and edit XML files to change them?

It isn't meant for changing loadouts midgame.  It's meant for designing ship presets.
Title: Re: AI War II: Design Document First Unveiling Is Now!
Post by: ptarth on September 03, 2016, 03:12:28 PM
re:Sound System
I had a hard time following the proposal in regards to the new sound system, and I haven't looked at how Unity does it. However, would it be feasible to create a moddable index (i.e., in xml or whatever) that maps sounds to sound files? (e.g., laser-blast-01 -> AssetBundle001 "/weapons/small/laser_blast001.mp3"). Then if the index file is part of the overriding mod system, the main game could be updated without impacting the mod files. Modders could then build their asset packages separately and not have to rebuild.

Then again, it is unknown how many people would actually use a deeper modding system or even this particular set of features.
Title: Re: AI War II: Design Document First Unveiling Is Now!
Post by: PokerChen on September 03, 2016, 05:10:08 PM
Then, in game, you can build whichever variant you want, and presumably there will be a way to switch to a different variant without having to scrap and rebuild.

I would hope so, although behind the scenes it would be destroying the unit, then replacing it with a copy at the same HP level.* Let's wait until Chris fleshes it out some more.

* Compare classic modules, which destroys and replacees each turret/FF (themselves essentially separate ships glued on to the host ship).
Title: Re: AI War II: Design Document First Unveiling Is Now!
Post by: NickAragua on September 04, 2016, 12:14:21 AM
FWIW, NAT Punchthrough is a major barrier to entry for coop, especially for folks who don't have admin access to their router or don't know what they're doing with said router, but I don't think that matchmaking with random folks is necessary at all. As others (and the design doc) point out, if you're going to be investing many hours in a game, you're not going to be doing that without any prior negotiation.
Title: Re: AI War II: Design Document First Unveiling Is Now!
Post by: Draco18s on September 04, 2016, 11:28:52 AM
FWIW, NAT Punchthrough is a major barrier to entry for coop, especially for folks who don't have admin access to their router or don't know what they're doing with said router...

Or people like me who do know, but doing it doesn't actually let it work.  I've previously had to set my desktop as the DMZ to bypass ALL THE SECURITY so I could get one game or another to connect (and then more recently I was doing something and even that didn't work...).
Title: Re: AI War II: Design Document First Unveiling Is Now!
Post by: Aklyon on September 04, 2016, 01:17:19 PM
FWIW, NAT Punchthrough is a major barrier to entry for coop, especially for folks who don't have admin access to their router or don't know what they're doing with said router...

Or people like me who do know, but doing it doesn't actually let it work.
Are you sure your router isn't actually slightly broken?
Title: Re: AI War II: Design Document First Unveiling Is Now!
Post by: x4000 on September 04, 2016, 01:24:20 PM
Thanks folks!  A few notes:

Quote
Just a point, modding should enable an unit cap from different sub-designs. That would recreate as close as possible the feeling of modulable ships within what you're calling a multi-part ship.

Good point, that is now in the document.

2.c.ii. Multiple Sub-Designs Sharing A Unit Cap
Status: Theoretical
Risk Level: Low

The idea here is to have several designs for something we might call a “riot starship” (as one example), and no matter which design you choose to build, it is counting against the central riot starship unit count.  Aka you don’t have six different unit caps that you pull from, you have one with six different designs, in that example.

Quote
So, no allowing mods to supply things like scripts for events?  I understand that it'd be a huge amount of work to allow someone to completely, or even partially, replace the AI, like Civ and some other recent games allow.  But I was hoping for the ability to attach small scripts to units / systems / other events.  That way, you could effectively add new mechanics in mods, just by attaching something to a "OnSystemEntry" or "OnUnitDestroyed" event in the XML.

I highly doubt we will do any scripting ability at all.  However, there's a lot of stuff you can do to drive behavior by adjusting data, and being able to control certain reactions and whatnot should be possible.  If you look at the way that units act in Starward Rogue, that's pretty data-driven.  Frankly so are the races in TLF, although that data is hardcoded into the code (in separate data classes of course) rather than being in external files.  Doing custom script parsing is not my idea of a low-risk thing, and is something that can cause a whole lot of cascading issues in general.  There's definitely several reasons that Civ runs like a dog in the late game.

I've added this into the document, thanks!

Quote
Make sure to put some thought into the kickstarter pitch and the tiers. You only get one shot at that. Looking forward to it

Absolutely -- it is something that we're going to be working on increasingly, and soliciting feedback on.  First I'm trying to wrap up the big design document things, since that impacts the pitch, and there's a topic about the tiers already.  I am going to need some help on that for sure.

Quote
The savings from using squads was brilliant. I know Chris was excited when I suggested that support units could be attached to a "mother ship" (shield bearers, X boosters, etc) so I wonder if the code will be made so a "squad" of those units can hook with several combat squads automatically. Would save a ton of micro yet actually increase potential tactics.

Thanks!  And yep, there's actually a completely separate thing with the attached units (that you described) that is separate even from squads.  Those will also have a lot of benefits.

Quote
Quote
We will also use the nonsim drawing offsets of shots in such a way that shots properly come out of specific ships in the squad, visually, but actually always come from the center of the squad under the hood.  The visual and sim positions then converge via lerping as they approach the target, leading to a really nice visual effect.

Ya know, you could non-sim the destination to a specific unit in the squad, too.  So Fighter #4 looks like it's actually firing on Bomber #7.  Lerping it towards the squad's center is technically something someone would notice.

I had meant for that to be implied, but it was very unclear.  I updated the document to fix that, thanks!

Quote
Well, I for one barely understood any of that.... lots of tech stuff and math.... but it's interesting to see it anyway.

I led with the most technical part.  That won't be how we introduce the kickstarter, obviously, but for those sorts of people who want to dive into the kickstarter it is a useful prelude.  And I think a lot of the sort of audience for this game can follow a lot of the document, hopefully.

Quote
Design documents aren't exactly something I've seen very often.   And this one is going to be huuuuuuuge, isn't it?

Pretty much, yeah.

Quote
Also looking forward to seeing maybe a uniform art style?

Yep!

Quote
So, if I've got a Multipart ship, and I destroy one of its guns and add a shield generator feature to it during gameplay, how is that different from swapping out a module?

Oops, that was super unclear, and I've fixed it now -- thanks for catching that.  Here's how the document changed:

NB: From an underlying technical standpoint, these can be destroyed or added during gameplay if required, and disabled temporarily.  However, from a gameplay standpoint things like simply having them destroyed and then replaced would be more the goal.  Right now there wouldn’t be any plans for adding things dynamically during the game, but the capability would be there for potential in the future.

Quote
@About squads... another thing that isn't considered in the document is that moving in formation, collision, having formations collide in realistic ways would also require a lot of work. The code to handle thousands of ships already exist in AI war I. The code to handle squads ?

It's implied, but you're right it could be more explicit for sure.  Added this:

Collision Footprints
Another thing to note is that the “bounding circle” (collision circle, selection circle) for squads would be much larger than what you saw in AI War for small ships, and would be something that all of the smaller ships in the squad are based in.

Aka, if you have a group of 10 fighters, they might have a collision footprint that is along the lines of a large starship from AI War Classic.  But it’s just one footprint, and of course recall that that footprint “is the unit.”  The ships themselves, when traveling in any sort of formation, would all be sure to stay inside said footprint so that they don’t overlap strangely with nearby ships.  When sitting at rest, same deal.  When circling around in an idle fashion, they might move out of that circle a bit, but not a huge amount.

In other words, as noted above, all of those visual things are just visual things that happen when they are on your screen.  Beyond that they are just a simple circle in space that has stats and so on.  This is perhaps not the most exciting way to conceptualize the data, so hopefully you will forget about this as you play. ;)  But it’s true in many ways for a lot of games.

Quote
Quote
Modular ships themselves are not desirable, because configuring them is a pain.

We like configuring the modular ships, tinkering and rebuilding them to optimize them for whatever our current situation is.  Yes, the UI is fiddly, but that's an issue with the UI implementation, not with the underlying concept.  Designing ships outside the game doesn't scratch this itch, because it's the in-game adaptability itself that we like.

I should clarify: SOME people like that, others don't.  A ton of people seem to just use the defaults in this game and many others, from my unscientific survey.

Quote
The scope and length of AI War really makes the playing community behave not like RTSes but like online ARPGs, where most people are doing their own thing in their own instances, but would still like to socialise and have the opportunity to get together. Therefore, I suggest you should consider making something analogous and call it a Lobby or Global Chat, to sit apart from Steam Overlay - essentially IRC global/party channels that players currently playing can choose to join, as well as players who are not currently playing. Forcing a matchmaking model is too high-risk, and more importantly removes the engagement of people who are currently playing.

It's a possibility, but it winds up increasing costs a lot over time, potentially.  We would have to investigate this a lot.  Is this in the ideas subforum at the moment?

Quote
I believe the phrases "modders can create new AI-Types" and "modders cannot create completely new AI-Logic" are fundamentally contradictory.

Your wording on that was great in terms of what you suggested instead, and I've added that in place almost verbatim what you said.  Thanks!

Quote
There are definitely still many people who like changing their ship loadouts in-game.

It's true, I misrepresented things accidentally in the document as being more universal than I intended.  Thanks for the catch there.  I've added the following new section:

Clarifying A Few Points About Modularity
There are a few things that folks have brought up that are excellent points that we should address:

Comment: Some people legitimately do like actually changing ship loadouts and so on.
This is true, and the document above accidentally makes it sound like nobody does.  So this is worth definitely conceding as a point. :)
That said, the number of people who actually like doing this sort of thing seems to be a small subset of the total number of players based on completely-unscientific anecdotal evidence and impressions relating to AI War Classic and other RTS games in general.
Based on that, and the cost of implementing this, it seems like a smart candidate for cutting.
Question: if enough people want this, could this be done pre-1.0?  Aka, can we lobby for this?
Overall one of the things we have to be careful of is scope creep derailing project deadlines and other core features.
Modular ships were not a part of AI War Classic at all until AI War 4.0 or 5.0 (can’t recall which), and the game was plenty fun without them.  It’s true that a lot of the later expansions had modular ships in places of prominence, but those were also often more of the complex features for newcomers to deal with.
To properly give something like this the attention it is due, both in terms of interface usability and general learning curve and functionality and so on, this would probably cause unfavorable things to happen to the 1.0 schedule.

Given that this is something that some unknown subset of people desire, and yet it is also a moderately-risk thing to do (huge amounts of interface work and possible confusion), this seems like the sort of thing that from a project-management standpoint needs to not interfere with 1.0.

Version 1.0 itself is not the end of the game, or the end of the kickstarter-funded feature set, however.  We’ve noted this a number of places, but if there are stretch goals we add for the kickstarter, those would all be post-1.0 documents with their own specs and budget and timeframes.  This seems like a very good candidate for a kickstarter stretch goal, given all of the above.

Quote
Woa. So we're far from "just remake the engine, don't touche the design". Faaar-far-far.

Yes, that was a completely different concept. :)

Quote
At the moment, everything in here sounds good. I'm pretty excited about the huge performance gains from squads, given some of my games get wildly out of hand with ship counts (and Dyson Gatlings, and Botnet Zombies, and anti-FS exos, and the AI going nuts from the SuperTerminal...) and the lag becomes noticable.

Awesome, thanks.  And yeah, we can do a lot more interesting things if the raw ship counts aren't eating the CPU constantly.

Quote
I am so excited for this game. I can't think of another game I would rather play or that is more exciting than the design document I just read. We are getting AI War but.. I don't think we have ever seen a war like this. It's strategy, it's action, it's written to be a smart game but with all the exploding space sugar on top.

Squee! :D

Quote
I don't understand how it's faster to compute polygons than position a sprite. Not saying I don't believe you, just wanting to know why.

It's a good question, and a tough one to answer with any brevity.  If you search for the exact text I quote above in the design document, there is now a detailed response that also includes a handful of links to other sources.  If there are any further questions on that, or if anyone wants to correct anything I misstated, please let me know. :)

Quote
During AI war classic, you could fix a files when there was a bug or for other reasons. How do we fix problems here? Maybe a post release question and not for 1.0.

You kinda could do that, but it really took a lot of knowledge of what was in there for the most part.  In this instance, I think that the emphasis should be on keeping more save files around, so that you can go back to them more easily.

Quote
Hopefully the planet cracker stays? Spire? Hybrids? And I like the neinzul. Golems. The trader. Devourer. And the avenger. And showtime. And cross planet attacks. Where do we write all of the things we care about? I thought there was a thread for that… looking…

There's a thread about this document, and if you want to give your commentary on things in that document that would be appreciated!  https://docs.google.com/document/d/1E78-KtgIKyAExd9VpIKe2aXEKFO14A8b9zRLwRENkRk/edit#heading=h.tu93tl7plob

Please bear in mind that I want to focus on getting an awesome core in there in a reasonable timeframe and budget, and some of the things may wind up needing to be pushed to post-1.0 depending on how they look cost-wise and if they are under consideration for a revamp for some reason.  I have not even remotely begun to sort through all of those things and think all that through, which I know is not the answer you want right now.  ;) 

I've just been trying to kind of chew outwards from the core of the game to the more esoteric stuff, though.  Basically looking at how to make the best overall foundation for mechanics in general, and then looking back at older mechanics from AI War Classic and seeing how that fits in.  Then revising as need be, and repeating, and so on.  And lots of discussion as we go all along the way, of course.

Quote
2.a. Squads of units
I'm on board. I think this is smart. You will need to fiddle with the animations or the graphics to give them a unique look in the squads so they all don't look like the same triangle rubberstamped side-by-side.

Awesome, thanks.  And yeah, Blue can do a huge number of things with animations and whatnot here.  That's not really a giant worry, because it's totally offloaded to the artist side and the amount of data is a couple of KB, heh.

Quote
2.a.ii. The animation data for the squads would be better if it was randomized or if you computed a random pattern and used it later. Anything that is player recognizable as a pattern is not as desirable.

I think you'll be surprised what we can do, but in general ships flying in certain formations is not exactly a new thing.

Quote
2.h. Replacement of AI progress
I'm on board. I think your reasoning is sound. You're not talking about removing consequences, or fun AI reactions to how we play, so I don't think we should be worried. I think this sounds like we could get more intelligent, nuanced AI.

Awesome. :)

Quote
Some of your math, it feels very informal because you change the numbers, for example some example 9999 or something. It doesn't really matter, I think you have the general math correct, but for a reader following along, if you want us to understand the math more easily, sticking with one set of numbers and going in order is great.

Yeah, my mind kind of goes numb after a while, and I accidentally switched up the numbers of which side had more.  And I figured I'd show a more extreme number of ships in the squads side to just show that even with larger-looking battles you'd get far fewer pieces of logic having to happen.  But point taken, for sure.  I'm kinda going a mile a minute with this at the moment!

Quote
But from what I understand of what I've read of the technical bits, ti sounds like we might not have inevitably-slower-as-it-progresses multiplayer games anymore? Cool.

That is a chief goal!

Quote
and presumably there will be a way to switch to a different variant without having to scrap and rebuild.

This is a good point, and not something that I had thought of -- good catch.  Never assume that I thought of something: if the spec doesn't say it, it's not part of the design at this time.  I've now updated it to include this:

Switching to a different variant without having to scrap and rebuild
This is an interesting idea from the forums that I had not thought of, and that would really allow for some cool flexibility in these sorts of modular ships.  The ability to switch their selected blueprint on the fly, perhaps with a “please wait… retrofitting…” time period where the ship is unable to fight or whatever (but can still move so that it’s not annoying) would be interesting.  Not having the waiting period and making it instant would also work, but might be seen as cheesy?  Deserves more discussion.

Quote
Hmm...I'll take it, if that's the only way to do it, but that just seems like addressing the "changing loadouts is clumsy" issue by making it even more clumsy.  If you're going to allow changing loadouts on an already built ship, what do you gain by making players leave the game and edit XML files to change them?

Editing xml files during the game is not something that is intended to ever be done!  Those would be edits for modding type purposes between games, not during them.  If there's part of the document I still need to clarify on this point, please point me to it.  Thanks! :)

Quote
The pure XML approach to object creation is great at single entity design (e.g., build a ship with weapons). However, when you are trying to interact with groupings of entities (e.g., ship balancing), it quickly falls apart. In SBR the flat files (e.g., buildings) were great. For SR I've half built a set of tools to extract and format the XML so I can compare across things (and eventually when I finish life will be great (and exportable)), which has made balancing tons easier. Spending some time building a system that allows for a combination (or converters) between XML and flat files would be a good time investment that will make later balance and unit organization much more straightforward. With such a system one could build units using the XML, but then balance and compare units via the flat file/spreadsheet interface.

I've brought this up with Keith.  You're really right, I think.  For anything design-related (visuals, broad behavior), having that in the xml is fabulous.  For anything that has to do with the explicit balance of ships, being able to read that from excel files like in SBR is a big deal for usability.

Quote
re:Sound System
I had a hard time following the proposal in regards to the new sound system, and I haven't looked at how Unity does it. However, would it be feasible to create a moddable index (i.e., in xml or whatever) that maps sounds to sound files? (e.g., laser-blast-01 -> AssetBundle001 "/weapons/small/laser_blast001.mp3"). Then if the index file is part of the overriding mod system, the main game could be updated without impacting the mod files. Modders could then build their asset packages separately and not have to rebuild.

That is fairly-vaguely the idea.  I have to investigate the specific format of asset bundles and their requirements more, but something along those lines is the idea.
Title: Re: AI War II: Design Document First Unveiling Is Now!
Post by: Tridus on September 04, 2016, 02:41:16 PM
Quote
and presumably there will be a way to switch to a different variant without having to scrap and rebuild.

This is a good point, and not something that I had thought of -- good catch.  Never assume that I thought of something: if the spec doesn't say it, it's not part of the design at this time.  I've now updated it to include this:

Switching to a different variant without having to scrap and rebuild
This is an interesting idea from the forums that I had not thought of, and that would really allow for some cool flexibility in these sorts of modular ships.  The ability to switch their selected blueprint on the fly, perhaps with a “please wait… retrofitting…” time period where the ship is unable to fight or whatever (but can still move so that it’s not annoying) would be interesting.  Not having the waiting period and making it instant would also work, but might be seen as cheesy?  Deserves more discussion.

This is a good idea because it's one of the things that modular ships can do, so with this and having multiple templates that count against a single ship cap, you've effectively recreated what's needed for Riot/Protector Starships/Spire Cities and most of the other modular stuff, except without the UI.

I would impose a retrofitting time, though, primarily because it could be open to abusive behavior if you can instantly change the design on the fly. If a FF is 95% gone, do you want someone able to instantly swap to a non-FF design, effectively losing nothing because it was almost down anyway? That's not a behavior the design should encourage, and a retrofit time that disables the ship's "parts" would solve that case pretty easily.
Title: Re: AI War II: Design Document First Unveiling Is Now!
Post by: motai on September 04, 2016, 10:55:39 PM
https://dungeondefenders.com/1/topic/129258/

even though its not really the same niche examining this moba/td challenges to matchmaking can be very educational to doing it better.

to skip to the end of the story they decided to take a step backwards and revert to their matchmaking working more like dd1 had evolved into because it works better for community involvement.
by hosting their lobbies publicly, wether or not they are locked/filled being set by the host/players, they could show that the game was not dead. even now there are dead times but their game oddly from the same timeframe as aiwar1 still is lively and its argued wether the sequel is better or not. They made a choice to run their severs themselves for antihacking concerns(mostly bypassed regardless). i have seen no end reason they could not have run them with steam integration(since dd2 is fuly steam intergrated). i hope steamworks and experience with starward rogue has not burned you on steam as a support platform for networking. it is at the least convenient for players to use. i am not sure of the business concerns for intergrating with their platform. despite the naysays that veto everything steam i would suggest to not discount the matchmaking ideas in your core.

My suggestion is to move away from aiwar 1 and its fixed player numbers to be n ( 8 ) player slots and allow jump in commanders as long as the host allows or even only from steam friend list in a steam hosted matchmaking method. this has worked successfully for both dungeon defenders 1+2 as well as for borderlands. i feel this type of being able to even just watch gameplay would be very valuable both for matchmaking and for advertising and outreach purposes. having even 4 slots dedicated to people observer only could be useful in teaching and sharing the game. having your camera as an observer lockable to a player would be a nice feature if you went this route. I'm assuming in game chat would still be an option. also by using steam integration steam has chat servers built in for communication rather than building your own.

with you mentioning how music and sound often get s moved to a seperate thread anyway i was wondering how difficult issuing commands to the steam music player from inside the game was.... but enough of my musing.

so hyped and breathlessly awaiting the new game i can get my friends to try someday.
Title: Re: AI War II: Design Document First Unveiling Is Now!
Post by: tadrinth on September 05, 2016, 12:59:22 AM
Switching to a different variant without having to scrap and rebuild

For champions, swapping modules requires an engineer to assist and being out of combat, but is pretty much instant. Switching hull types requires respawning back at base. I think retrofitting to a different variant should probably be a happy medium between those.  Maybe, it has the same costs and reqs as repairing to full health from zero?
Title: Re: AI War II: Design Document First Unveiling Is Now!
Post by: PokerChen on September 05, 2016, 01:47:29 AM
1. Socialose in game

What about an official Discord channel? I've edited this into the relevant thread in Ideas sundown now.

2. Swapping variants

I imagine it would be engineer + time + resource difference. The last option allows for price difference to be accounted within the variants.
Title: Re: AI War II: Design Document First Unveiling Is Now!
Post by: Jabberwok on September 05, 2016, 01:49:40 AM
My only worry is that, upon release, this will be compared to the first game with its years of expansions and improvements, and found wanting.
Title: Re: AI War II: Design Document First Unveiling Is Now!
Post by: kasnavada on September 05, 2016, 01:55:23 AM
Good point, that is now in the document.

Cool, one of my suggestions made it directly in the design document !
With the ability to switch on the fly, it sounds really good conceptually.

Quote
the rest

Awesome ideas & answers there.
Title: Re: AI War II: Design Document First Unveiling Is Now!
Post by: PokerChen on September 05, 2016, 02:26:33 AM
My only worry is that, upon release, this will be compared to the first game with its years of expansions and improvements, and found wanting.

Happens with every duckin' game/movie on Earth these days. People don't realise how much of a birch it is to update a monolith of old code, rather than obsolete it and start afresh.
Title: Re: AI War II: Design Document First Unveiling Is Now!
Post by: ptarth on September 05, 2016, 02:34:48 AM
From a side perspective, it seems (using SR language) that ships are entities and systems are systems. Then at the next step up, a module ship, is just the same, a ship with some number of fixed systems (e.g., missile, primary, energy). Obvious enough sure. But, you can also extend this to groups, a group entity then has attached ships/systems (each of which is a ship). And then up to the larger level of fleets which either has attached groups or just attached ships. In essence everything is one giant stack with a single major representation in game.

I suppose then the major question is then, when do individual ship actions take place. Do you want to have a wing of fighters than you can separate from a main fleet to go do a job, or is this level of micro too much? I really don't know. I don't have a good idea where the desired level of micro when it comes to invasion should be. Perhaps a discussion of how players would like to spend their time when attacking a system would address the question;.
Title: Re: AI War II: Design Document First Unveiling Is Now!
Post by: Tridus on September 05, 2016, 06:49:34 AM
i hope steamworks and experience with starward rogue has not burned you on steam as a support platform for networking. it is at the least convenient for players to use. i am not sure of the business concerns for intergrating with their platform. despite the naysays that veto everything steam i would suggest to not discount the matchmaking ideas in your core.

What happened with Starward Rogue and Steamworks?
Title: Re: AI War II: Design Document First Unveiling Is Now!
Post by: Misery on September 05, 2016, 07:04:21 AM
i hope steamworks and experience with starward rogue has not burned you on steam as a support platform for networking. it is at the least convenient for players to use. i am not sure of the business concerns for intergrating with their platform. despite the naysays that veto everything steam i would suggest to not discount the matchmaking ideas in your core.

What happened with Starward Rogue and Steamworks?

Wondering this myself.  I don't remember anything related to Steamworks?   Though when I think about it, I'm not entirely sure what Steamworks is.  Which probably sounds really dumb, but my memory is awful.
Title: Re: AI War II: Design Document First Unveiling Is Now!
Post by: Tridus on September 05, 2016, 09:27:33 AM
i hope steamworks and experience with starward rogue has not burned you on steam as a support platform for networking. it is at the least convenient for players to use. i am not sure of the business concerns for intergrating with their platform. despite the naysays that veto everything steam i would suggest to not discount the matchmaking ideas in your core.

What happened with Starward Rogue and Steamworks?

Wondering this myself.  I don't remember anything related to Steamworks?   Though when I think about it, I'm not entirely sure what Steamworks is.  Which probably sounds really dumb, but my memory is awful.

Steamworks is the Steam library & services that games on Steam can use to add things like achievements, matchmaking, leaderboards, and such. It does quite a lot, for free. Most likely, it's what put Gamespy's services and Games for Windows Live out of business, because it was both better and cheaper. It's also why so many games require Steam to work, no matter what store they're sold on (if it uses Steamworks for multiplayer, it requires Steam for multiplayer).

AI War, for example, has the ability to use Steamworks if it's there (mostly for Steam achievements), but continues to work if Steam isn't there (you just don't get Steam achievements). Civilization V uses Steamworks for multiplayer, so the game doesn't function properly without Steam.
Title: Re: AI War II: Design Document First Unveiling Is Now!
Post by: x4000 on September 05, 2016, 11:20:57 AM
I would impose a retrofitting time, though, primarily because it could be open to abusive behavior if you can instantly change the design on the fly. If a FF is 95% gone, do you want someone able to instantly swap to a non-FF design, effectively losing nothing because it was almost down anyway? That's not a behavior the design should encourage, and a retrofit time that disables the ship's "parts" would solve that case pretty easily.

Yep, that makes a lot of sense to me.  In the case of that example, whatever it is that is 95% dead in that slot potentially should be 95% dead in the retrofitted version, too, though, in either case.  Retrofitting shouldn't be a way to heal your ship, heh.

to skip to the end of the story they decided to take a step backwards and revert to their matchmaking working more like dd1 had evolved into because it works better for community involvement.
by hosting their lobbies publicly, wether or not they are locked/filled being set by the host/players, they could show that the game was not dead. even now there are dead times but their game oddly from the same timeframe as aiwar1 still is lively and its argued wether the sequel is better or not. They made a choice to run their severs themselves for antihacking concerns(mostly bypassed regardless).

I am not aware of anyone thinking that AI War Classic is a dead game, but it's also not multiplayer in the same sense as DD1.  It's more "play by yourself or with friends," which is something that really can't "die" per se.  Not like an FPS game can, if you're depending on a large pool of random other players for your enjoyment.

i hope steamworks and experience with starward rogue has not burned you on steam as a support platform for networking. it is at the least convenient for players to use. i am not sure of the business concerns for intergrating with their platform.

Thanks for the reminder to add something about Steamworks integration into the design document.  There's now a section about that in third-party components, which I've copied here:

1.g.iii. Deeper Steamworks Integration
Status: Super-Duper Theoretical
Risk Level: Extraordinarily High

We get asked about various forms of Steamworks integration all the time.  We are not C++ programmers, however, and we really loathe trying to work at that level.  The worst bit is trying to write code that works well on linux, osx, and windows, which are three pretty different platforms and require the use of unfamiliar-to-us IDEs in order to do anything.  This winds up eating up tons of time, and frankly drives us a bit batty.

There have been various C# wrappers for Steamworks in the past, and we’ve had bad experiences with all of them.  The official bindings from Valve were experimental and have never actually been compile-able.  The older Steamworks.NET wrapper that we use in most of our games at this point had a ton of broken things in it that we had to work around in really nasty ways.  Our prior experience before that was us doing our own p/invoke into dlls/so’s/dylib’s that we created ourselves (shoot us now on those).

None of this is really a criticism of the Steamworks API itself, which seems like it is set up well.  However, it is very C++ in nature, which makes p/invoke hard to do against it given that that is more aimed at C-style method calls.

All of that said, there is a new (relatively) Steamworks.NET project on github that we have yet to try, and that we hear good things about.  We will investigate this and see what we can do within a certain time budget, but we want to make sure we do not become overly dependent on Steamworks features in general, since that would be to the detriment of DRM-free and GOG versions of the game (hey, those folks deserve all the cool features, too).

My suggestion is to move away from aiwar 1 and its fixed player numbers to be n ( 8 ) player slots and allow jump in commanders as long as the host allows or even only from steam friend list in a steam hosted matchmaking method. this has worked successfully for both dungeon defenders 1+2 as well as for borderlands. i feel this type of being able to even just watch gameplay would be very valuable both for matchmaking and for advertising and outreach purposes. having even 4 slots dedicated to people observer only could be useful in teaching and sharing the game. having your camera as an observer lockable to a player would be a nice feature if you went this route. I'm assuming in game chat would still be an option. also by using steam integration steam has chat servers built in for communication rather than building your own.

Locking the camera to another player would be very impossible since all of those things are done locally.  There's a reason that there is a delay lag on services like twitch.  If someone is looking to teach others by letting them watch everything, then I would say twitch is by far the best way to go.  In terms of having some folks jump in and either be silent watchers of one player or equal-parts-helpers on that same team, that is something we're talking about in terms of feasibility.

with you mentioning how music and sound often get s moved to a seperate thread anyway i was wondering how difficult issuing commands to the steam music player from inside the game was.... but enough of my musing.

I've never used it, so I'm not sure honestly.

so hyped and breathlessly awaiting the new game i can get my friends to try someday.

Thanks! :)

Switching to a different variant without having to scrap and rebuild

For champions, swapping modules requires an engineer to assist and being out of combat, but is pretty much instant. Switching hull types requires respawning back at base. I think retrofitting to a different variant should probably be a happy medium between those.  Maybe, it has the same costs and reqs as repairing to full health from zero?

At this point I think this topic deserves its own discussion in the ideas subforum.  It's basically getting into the level of design that won't be in the design document, because any one of these approaches is reasonable enough on paper, and quick to implement, so it's a matter of doing some talking about it, finding what sounds the best, then testing that out with players and seeing if that actually matches our expectations of it.

My only worry is that, upon release, this will be compared to the first game with its years of expansions and improvements, and found wanting.

I actually just added a new "Rationale For Scope Decisions" section to the design document, because I feel the same sort of worry.  Funny we had the same thought, although I suppose it's not all that funny a thought.

My opinion on the way to combat that is basically a clear communication of the roadmap, and what things cost to make and add, etc.  Plus there's a whole heck of a lot of new things that this new game can do that the old one can't in terms of having all manner of types of units and so on just by the very nature of it being data-driven, so hopefully that will offset things to doms degree.

Good point, that is now in the document.

Cool, one of my suggestions made it directly in the design document !
With the ability to switch on the fly, it sounds really good conceptually.

Awesome. :)  And yep, I imagine we'll be seeing more of your ideas in there... ;)

My only worry is that, upon release, this will be compared to the first game with its years of expansions and improvements, and found wanting.

Happens with every duckin' game/movie on Earth these days. People don't realise how much of a birch it is to update a monolith of old code, rather than obsolete it and start afresh.

My chief hope is to combat that with communication and detail.  A lot of games and movies and whatever don't actually explain anything and just hope for the best, and so of course people don't understand.  I'd rather give people the cold hard facts instead.  We shall see what happens.

i hope steamworks and experience with starward rogue has not burned you on steam as a support platform for networking. it is at the least convenient for players to use. i am not sure of the business concerns for intergrating with their platform. despite the naysays that veto everything steam i would suggest to not discount the matchmaking ideas in your core.

What happened with Starward Rogue and Steamworks?

Wondering this myself.  I don't remember anything related to Steamworks?

Wondering that myself, too -- I also don't recall anything related to it, and that would have been me. ;)
Title: Re: AI War II: Design Document First Unveiling Is Now!
Post by: Nuc_Temeron on September 05, 2016, 12:18:45 PM
A few thoughts on AI War II:

a. AI War is a magical thing. It's this amazing formula that's unlike anything else, a timeless classic. While I'm glad to hear that you're working on AI War II, I'm also concerned. Remember when Star Wars Episode I-III came out and they were so atrocious that it made everyone like the first Star Wars trilogy less? Don't pull a George Lucas.

b. Regarding removing AI Progress: I do not particularly like that idea. I think AI Progress is part of the backbone of the game, and removing it would be a huge departure from the current gameplay.

c. Make it a remake, not a sequel. If you make basically the same game with a new engine and new maths and a more modern look, I would be thrilled.

d. Squads sound great. My fleets moving in a realistic formation instead of a ball would be wonderful.

e. The ability to play a much shorter game somehow, scaling the difficulty so I could reasonably play a tiny map in a day, would be nice.
Title: Re: AI War II: Design Document First Unveiling Is Now!
Post by: x4000 on September 05, 2016, 12:35:02 PM
Splitting AIP bothers you?  I suppose this could be considered high risk.  Hmm.
Title: Re: AI War II: Design Document First Unveiling Is Now!
Post by: chemical_art on September 05, 2016, 01:20:55 PM
I would consider splitting AIP high risk. The weakness of being so singular (and the resulting lack of options that go with it) is also a strength of sorts due to its relative simplicity.

Perhaps keep a "base" AIP, but allow secondary options to influence it? Like temporary sources that increase/decrease it? Not sure. But changing it does involve risk.
Title: Re: AI War II: Design Document First Unveiling Is Now!
Post by: x4000 on September 05, 2016, 01:33:23 PM
Agreed.  I have made shifts to the document since writing that with new notes at:

Section 3: Graveyard of Discarded New Ideas
3.a. Replacement of AI Progress

and then

4.a. Temporarily Added AI Progress
Title: Re: AI War II: Design Document First Unveiling Is Now!
Post by: Tridus on September 05, 2016, 01:40:23 PM
Splitting AIP bothers you?  I suppose this could be considered high risk.  Hmm.

I don't think it's low risk, at least. You (and others) identified lots of things that could be improved about AI Progress, but in identifying problems and things people want to to do improve it, it's easy to gloss over what's good about it. A single number is easy to understand, especially when people get the idea that bigger = more aggressive AI response. It creates easy to understand trade offs between figuring out if doing something is worth the AIP increase, makes alternative means to do things potentially very attractive to avoid AIP increase (see: hacking), and gives you reason to go after potentially far flung objectives to cause AIP decrease (co-processors, data centers, etc).

In the haste to do something better, there's a risk of losing the parts that honestly work pretty well.

That's not to say that it's not worth trying, but there should be an awareness that this is a core thing to the game and it's not broken to start with.

edit - I guess it's a moot point now since it's off the table. I think that's the right decision for now. You could come back to this later, but it's a big thing for 1.0. :)
Title: Re: AI War II: Design Document First Unveiling Is Now!
Post by: kaffo on September 05, 2016, 03:59:08 PM
Created an account to post here after I saw the announcement! So excited! :D

Splitting AIP bothers you?  I suppose this could be considered high risk.  Hmm.

I think it's moderate risk.
Also I while I love the idea of the sub systems, I also like the idea of a 'global progress'. Maybe have global AIP shown on the tool bar, then on hover it shows the different components of it and how they are contributing to the total?
That way players can choose to ignore the sub systems for a one glance "oh christ..." or go and really dedicate some time to knocking down the AI's logistics, for example, if it's spiralling out of control.

Still I think the subsystems idea needs to stick about.
Loving the rest of the doc too!
Title: Re: AI War II: Design Document First Unveiling Is Now!
Post by: Nuc_Temeron on September 05, 2016, 04:55:26 PM
A few more thoughts:

f. No whimsy, please. The Last Federation has a whimsical AI voice, and I love it in that game, so I'm not strictly anti-whimsy; just not for AI War. The serious tone fits. Please call me tedious and insignificant again! Perhaps you could use the same voice actor. It adds such mood, context and character with one simple word.

g. Please don't use animations to move from screen to screen, like they did in XCOM. It looks nice the first 20 times, then it becomes an annoyance.

h. I typically ignore lore pickups in games, but in AI War, I would actually read them. I'd like to know more about the story. I'm glad you've decided to add this.
Title: Re: AI War II: Design Document First Unveiling Is Now!
Post by: NickAragua on September 05, 2016, 05:21:31 PM
Well, what's the point of AIP? It's basically to determine the level of opposition (in terms of offensive and defensive capability) that a player faces.

The thing is, that there are already about ten other different "gauges". You've got "hacking progress", you've got whatever it is that drives counterattacks for the spire expansion, you've got something that spawns a bunch of jerks in response to you having a champion. The challenge here (in my opinion) isn't "splitting" AIP, it's clearly communicating to the player what AI behaviors are engaged, at what level and in response to what. In AIW, there's quite a bit of it that's kind of nebulous (and maybe intentionally so, but it doesn't help a player to understand why there's suddenly a swarm of large capital ships pounding on their command center).
Title: Re: AI War II: Design Document First Unveiling Is Now!
Post by: PokerChen on September 06, 2016, 03:39:39 AM
Hmm.. I think AIP itself was too authoritative, and oversimplified how players engaged with the AI. The strategy discussions we used to have, had a lot of focus on keeping a single number below certain thresholds ( for non Fallen Spire) - it really didn't matter what exactly we did or did not do as long as the total sum did not exceed X before we were prepared for it.

It all boiled down to the equivalent of shopping on a budget with AIP reducers being coupons you'd have to fill out surveys for. In that context, splitting the AIP wouldn't have helped at all (turning your money into UN food stamps versus clothing stamps).

Hence I was advocating its complete removal and replacement in the other thread. It's a medium risk operation IMO, but this is one of those risks I would definitely  take a gamble on because reasons.
Title: Re: AI War II: Design Document First Unveiling Is Now!
Post by: eRe4s3r on September 06, 2016, 08:21:55 AM
The big problem with AIP with stepping behind it is that beyond a certain level (whatever makes MK3 planets to core worlds) it is essentially game over if by that point you haven't killed all the shields and at least 1 homeworld + survived the response. Especially since this applies to ALL worlds, which if you hit the first "stepping" of AIP, can lead to the fastest game over ever, as you could face core ships in actual regular attack waves before you even have more than 1 MK3 ship unlocked.

####

Btw, I hope we get some deeper scripting ability than just XML for modding.. the game begs for LUA integration with hashing applied so that mods can work together in MP.. don't hardcode your campaign core logic if at all possible and allow us to add dialog boxes and if/else triggers + some more logic based scripting (count ships in planet X, do Y if number is Z, display popup box, modal dialog with image AAA and then play sound file whatever*)... it was already what killed modding in many previous Unity games not just by Arcen. This is especially important as the Unity engine is a huge detriment to modding if you don't expose core API elements. (ie, allow us to sideload DLL's with decent documentation) ala KSP.

If you do not plan on adding scripting beyond XML, then at least consider allowing sideloading of DLL's that interact with core game logic and can extend various things, like a script extender (which in turn allowed sideloading DLL's into Skyrim. It would require good documentation and a build guide, but it would also allow for vastly better and more awesome mods, especially if the game gains any mass market traction

Ps.: Though it obviously requires you to add code based triggers for advanced scripting as the one I exemplified above ;P
Title: Re: AI War II: Design Document First Unveiling Is Now!
Post by: Mánagarmr on September 06, 2016, 06:04:23 PM
Working my way through this document still. Will come with feedback once I've read it.
Title: Re: AI War II: Design Document First Unveiling Is Now!
Post by: Toranth on September 06, 2016, 07:33:28 PM
Btw, I hope we get some deeper scripting ability than just XML for modding.. the game begs for LUA integration with hashing applied so that mods can work together in MP.. don't hardcode your campaign core logic if at all possible and allow us to add dialog boxes and if/else triggers + some more logic based scripting (count ships in planet X, do Y if number is Z, display popup box, modal dialog with image AAA and then play sound file whatever*)... it was already what killed modding in many previous Unity games not just by Arcen. This is especially important as the Unity engine is a huge detriment to modding if you don't expose core API elements. (ie, allow us to sideload DLL's with decent documentation) ala KSP.

If you do not plan on adding scripting beyond XML, then at least consider allowing sideloading of DLL's that interact with core game logic and can extend various things, like a script extender (which in turn allowed sideloading DLL's into Skyrim. It would require good documentation and a build guide, but it would also allow for vastly better and more awesome mods, especially if the game gains any mass market traction

Sad panda:

Quote from: Design Document
No Scripting Abilities In Modding, At Least In The 1.0 Spec
We highly doubt we will do any scripting ability at all (ie like the python scripting that drove much of the AI and so on in Civ 4 or SupCom 1).  That means unfortunately no creating AI logic from whole cloth as part of the modding, by its very nature.
Title: Re: AI War II: Design Document First Unveiling Is Now!
Post by: Mac on September 06, 2016, 07:50:13 PM
"The players would be able to see this currency of the AI (the "reinforcement currency"), probably?  At least in a tooltip of AIP, most likely."

  I would like the option to turn this off in the game lobby settings, or to have a different way this happens.  I just believe that it would be slightly unrealistic for us to be able to see the AI's budget at all times. (mabey have the currency as some type of intel that the scouts or something similar can discover?)
Title: Re: AI War II: Design Document First Unveiling Is Now!
Post by: tadrinth on September 06, 2016, 09:43:24 PM
Sad panda

In a different thread, he said that the tutorial is almost entirely data and would therefore be quite customizable by modders.  So, it sounds like hooks for triggering popups will be available in some form. Does that help at all?
Title: Re: AI War II: Design Document First Unveiling Is Now!
Post by: chemical_art on September 06, 2016, 11:31:09 PM
"The players would be able to see this currency of the AI (the "reinforcement currency"), probably?  At least in a tooltip of AIP, most likely."

  I would like the option to turn this off in the game lobby settings, or to have a different way this happens.  I just believe that it would be slightly unrealistic for us to be able to see the AI's budget at all times. (mabey have the currency as some type of intel that the scouts or something similar can discover?)

I would be fine with the "reinforcement" numbers being something only scouts could discover.

By that measure, "scouts" could be renamed as "spys" in that they can discover unique data.
Title: Re: AI War II: Design Document First Unveiling Is Now!
Post by: eRe4s3r on September 07, 2016, 05:11:29 AM
Sad panda

In a different thread, he said that the tutorial is almost entirely data and would therefore be quite customizable by modders.  So, it sounds like hooks for triggering popups will be available in some form. Does that help at all?

Modding (With Unity 5 anyway) can only happen with DLL sideloading which is the way to do "external" lua scripting, that's the only way you can do things "beyond" the design scope of a game due to how the Unity API and memory management works...)

We'll have to see how it works in detail anyway... popups would be a good start, but you'd need some kind of data structure to store (read/write/save/load) variables. It doesn't mean changing unit stats isn't nice, but the real modding only starts when we can fundamentally alter AI responses, add complex scripting for background calculations beyond the scope of the game etc and new weapon systems that behave in new ways.

The thing is I feel like AI War 1 already missed the modding train so vastly that it hurts. It's gonna take some really well done documentation and utilities from the get-go to get a real modding community going. And obviously Nexus and NOT JUST STEAMWORKSHOP

Steam Workshop is modding DRM ^^
Title: Re: AI War II: Design Document First Unveiling Is Now!
Post by: GiftGruen on October 02, 2016, 07:29:42 AM
I am not entirely sure about the squads, particularly the part about ships being reconstructed by engineers on repair: wouldn't that mean you can only construct a squad of fighters as a full squad and not individual units? That would make it seem like you just cut down on the number of ships, when that impression is exactly what you want to counter. Why not make every fighter a squad of its own on creation, but let them consolidate into as few as possible on every move order if the number of squads is too high (an iteration over every squad's number of ships, one division per ship type in the selection, and addition) or individually if they happen to collide with another squad that still has enough space for them? That would mean that you already have 10-squads on your fighters if you just send them all to a rally point (due to collision) or give them orders when they are on their way there (due to move order). And it doesn't seem like a lot more computation than the whole move order itself and all its position offsets etc.
Title: Re: AI War II: Design Document First Unveiling Is Now!
Post by: PokerChen on October 02, 2016, 08:46:15 AM
Yeah um, you should also read the design doc on how squads are animated. Chris's intention is to give some freedom to squad members so they will look semi independent and reassemble like a bunch of ships (possibly decreasing as the squad takes damage).
The second thing is, you might not know this, but dynamically splitting and merging entities like you suggest is superfluous - because the computer then has to constantly update who is leading and who isn't, decide when to switch over, etc. Note that Classic already has a system where units steal movement and targeting information from others wherever possible, which is similar but minutes the banding logic.
Title: Re: AI War II: Design Document First Unveiling Is Now!
Post by: GiftGruen on October 02, 2016, 10:23:20 AM
I did read that document, but I did not suggest being able to split squads unless to immediately give over all the squad members to other squads. You do not have to keep track of individual ships as anything else than an integer in the squad data with this approach. Example:

You have the following fighter squads:

 - 1   4/10 squad
 - 3   10/10 squads
 - 16 1/10 squads
 - 8   8/10 squads

When you select these 28 squads and give them a move order, the following happens:

The move command iterates over all squads in the selection (which it would have to do already anyway), and counts 1*4+3*10+16*1+8*8 = 114 ships, but more than 12 squads. It then selects one of the squads (either random order or ideally the one with the least amount of units in them) and gives all its members to other squads and repeats this a total of 28 - 12 = 16 times. With 150 1/10 squads, it would be 150-15=135 passes, or generally O(n).

With squads just being able to replenish lost members with only the use of engineers, you not only paint yourself in a corner lore-wise (we need to pilot our ships manually because AI is against us, but engineers can just assemble a new ship and add it to a group, can they assemble a pilot?), you also lose a lot of the "individual units packed together" feel when you never actually see them being packed together. They just feel like a big unit with comparable stats to many other units when they can just be repaired back to full health, and having a unit that loses permanent health at certain cutoffs (100% -> 67% -> only 70%) without reinforcements also makes them behave a lot more like the individual fighters from Classic: Brought 200 fighters in transports, but 60 of them died in the battle? You now only have 70% of your original firepower even if you brought engineers to repair the ones that survived.
Title: Re: AI War II: Design Document First Unveiling Is Now!
Post by: Cinth on October 02, 2016, 10:28:42 AM
That's all assuming you can repair to that degree in the field.  :)
Title: Re: AI War II: Design Document First Unveiling Is Now!
Post by: GiftGruen on October 02, 2016, 11:20:02 AM
Quote from: The design document
When a squad is being repaired, how are further ships reconstructed in it?  (Presumably they are reconstructed by engineers during repair of the squad to full health -- anything else gets tedious fast for many reasons easily seen in other RTS games.)

I was referring to this part, Cinth, and tried to come up with a different solution. And if you can't repair squads to the point where you would get new ships when they're out in the field, great. If you don't like the consolidation idea (even though it would decrease the number of actual combatants in any follow-up fight, which is the same intent as the one behind the whole squad change), fine. And I can easily overlook the "how does the pilot get there" issue when it's on a controlled planet. It's just not shown, but they can be assumed to travel there from one of your buildings or the planet or whatever.

And only having full squads available to be built is probably also no big deal, if you even plan to do that, even though it feels like the game loses some variety at that point, because they're just more of the big ships, with a unique look and mechanics, sure, but every other big ship has those too.
Title: Re: AI War II: Design Document First Unveiling Is Now!
Post by: Cinth on October 02, 2016, 12:07:37 PM
I was talking about replacing lost ships outside of your area of control.  There's still some big unknowns about how some of this stuff is going to work out.

Consolidating just feels like it's complicating things for relatively minor gains in the end. 
Title: Re: AI War II: Design Document First Unveiling Is Now!
Post by: GiftGruen on October 02, 2016, 01:32:44 PM
Okay, can live with that. Sorry if I was sounding rude before.
Title: Re: AI War II: Design Document First Unveiling Is Now!
Post by: Cinth on October 02, 2016, 01:46:52 PM
Okay, can live with that. Sorry if I was sounding rude before.
Not at all.  There's a few mechanics that are going to interact here and none of it is set in stone so to speak.