Thanks folks! A few notes:
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.
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!
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.
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.
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!
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.
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.
Also looking forward to seeing maybe a uniform art style?
Yep!
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:
@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:
Spoiler for Hiden:
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.
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.
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?
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!
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:
Spoiler for Hiden:
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.
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.
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.
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!
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.
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.
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.tu93tl7plobPlease 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.
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.
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.
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.
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!
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!
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:
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!
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.
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.
