Author Topic: AI War II: Design Document First Unveiling Is Now!  (Read 35362 times)

Offline Tridus

  • Master Member
  • *****
  • Posts: 1,305
  • I'm going to do what I do best: lecture her!
Re: AI War II: Design Document First Unveiling Is Now!
« Reply #30 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.

Offline Cyborg

  • Master Member Mark III
  • *****
  • Posts: 1,957
Re: AI War II: Design Document First Unveiling Is Now!
« Reply #31 on: September 03, 2016, 01:48:02 pm »
Kahuna strategy guide:
http://www.arcengames.com/forums/index.php/topic,13369.0.html

Suggestions, bugs? Don't be lazy, give back:
http://www.arcengames.com/mantisbt/

Planetcracker. Believe it.

The stigma of hunger. http://wayw.re/Vi12BK

Offline Elestan

  • Full Member Mark II
  • ***
  • Posts: 158
Re: AI War II: Design Document First Unveiling Is Now!
« Reply #32 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? 

Offline ptarth

  • Arcen Volunteer
  • Hero Member Mark III
  • *****
  • Posts: 1,166
  • I'm probably joking.
Re: AI War II: Design Document First Unveiling Is Now!
« Reply #33 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.
Note: This post contains content that is meant to be whimsical. Any belittlement or trivialization of complex issues is only intended to lighten the mood and does not reflect upon the merit of those positions.

Offline Draco18s

  • Resident Velociraptor
  • Core Member Mark V
  • *****
  • Posts: 4,251
Re: AI War II: Design Document First Unveiling Is Now!
« Reply #34 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.

Offline ptarth

  • Arcen Volunteer
  • Hero Member Mark III
  • *****
  • Posts: 1,166
  • I'm probably joking.
Re: AI War II: Design Document First Unveiling Is Now!
« Reply #35 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.
Note: This post contains content that is meant to be whimsical. Any belittlement or trivialization of complex issues is only intended to lighten the mood and does not reflect upon the merit of those positions.

Offline PokerChen

  • Hero Member Mark III
  • *****
  • Posts: 1,088
Re: AI War II: Design Document First Unveiling Is Now!
« Reply #36 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).

Offline NickAragua

  • Sr. Member
  • ****
  • Posts: 281
Re: AI War II: Design Document First Unveiling Is Now!
« Reply #37 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.

Offline Draco18s

  • Resident Velociraptor
  • Core Member Mark V
  • *****
  • Posts: 4,251
Re: AI War II: Design Document First Unveiling Is Now!
« Reply #38 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...).

Offline Aklyon

  • Core Member
  • *****
  • Posts: 2,089
Re: AI War II: Design Document First Unveiling Is Now!
« Reply #39 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?

Offline x4000

  • Chris McElligott Park, Arcen Founder and Lead Dev
  • Arcen Staff
  • Zenith Council Member Mark III
  • *****
  • Posts: 31,651
Re: AI War II: Design Document First Unveiling Is Now!
« Reply #40 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.

Spoiler for Hiden:
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:

Spoiler for Hiden:
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:

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.

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:

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.

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:

Spoiler for Hiden:
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.
Have ideas or bug reports for one of our games?  Mantis for Suggestions and Bug Reports. Thanks for helping to make our games better!

Offline Tridus

  • Master Member
  • *****
  • Posts: 1,305
  • I'm going to do what I do best: lecture her!
Re: AI War II: Design Document First Unveiling Is Now!
« Reply #41 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.

Offline motai

  • Jr. Member
  • **
  • Posts: 52
Re: AI War II: Design Document First Unveiling Is Now!
« Reply #42 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.
« Last Edit: September 04, 2016, 10:58:02 pm by motai »

Offline tadrinth

  • Hero Member
  • *****
  • Posts: 507
Re: AI War II: Design Document First Unveiling Is Now!
« Reply #43 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?

Offline PokerChen

  • Hero Member Mark III
  • *****
  • Posts: 1,088
Re: AI War II: Design Document First Unveiling Is Now!
« Reply #44 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.

 

SMF spam blocked by CleanTalk