Roadmap/Way ahead?
Moderator: MOD_Command
-
- Posts: 1828
- Joined: Mon Jun 15, 2009 11:45 pm
RE: Roadmap/Way ahead?
There is a thread here: tm.asp?m=3432166 [:D]
Command Dev Team
Technical Lead
Technical Lead
RE: Roadmap/Way ahead?
I know where that is[:)]
I'm asking snowburn though what his specific issue is.
RE: Roadmap/Way ahead?
ORIGINAL: mikmyk
ORIGINAL: snowburn
an improved scenario editor?
What needs to be improved?
Mike
The ScenEdit is great, it needs a few more triggers, conditions and actions.
please see my posts at:
fb.asp?m=3519994
fb.asp?m=3521636
fb.asp?m=3665638
RE: Roadmap/Way ahead?
ORIGINAL: snowburn
ORIGINAL: mikmyk
ORIGINAL: snowburn
an improved scenario editor?
What needs to be improved?
Mike
The ScenEdit is great, it needs a few more triggers, conditions and actions.
please see my posts at:
fb.asp?m=3519994
fb.asp?m=3521636
fb.asp?m=3665638
Ah event editor stuff. Agreed. Will update these.
Thanks!
Mike
RE: Roadmap/Way ahead?
thanks! you guys are awesome!
ORIGINAL: mikmyk
ORIGINAL: snowburn
ORIGINAL: mikmyk
What needs to be improved?
Mike
The ScenEdit is great, it needs a few more triggers, conditions and actions.
please see my posts at:
fb.asp?m=3519994
fb.asp?m=3521636
fb.asp?m=3665638
Ah event editor stuff. Agreed. Will update these.
Thanks!
Mike
- AdmiralSteve
- Posts: 288
- Joined: Mon Mar 28, 2011 2:32 pm
- Location: Red Bluff, CA
RE: Roadmap/Way ahead?
Oh God. My family would leave me for sure.ORIGINAL: severe7
Woho! Command for Xbox with Kinect! Nothing could possible be more asked for than the ability to flail around our arms in panic to aim a Phalanx CIWS. [:D]
But could you imagine CMANO on XBOX though? And on a huge plasma screen!?
Where's the drooling smiley at?

“There are no extraordinary men...just extraordinary circumstances that ordinary men are forced to deal with.”
Admiral William Frederick Halsey Jr. 1882-1959
Admiral William Frederick Halsey Jr. 1882-1959
RE: Roadmap/Way ahead?
Something that would be very neat would be scripting for missions. While I think that Command is turing complete as it is, it would be wonderful to be able to have the control that integrating a scripting language into the editor allows. This would allow mission designers to create complex scenarios more easily, and simplifies creating complex behaviour.
There are a number of options for a language. One promising one now is C# using the Roslyn CAAS, though Lua bindings for .NET also exist. I don't think it would be that difficult to make it secure, and the additional functionality would be amazing.
There are a number of options for a language. One promising one now is C# using the Roslyn CAAS, though Lua bindings for .NET also exist. I don't think it would be that difficult to make it secure, and the additional functionality would be amazing.
RE: Roadmap/Way ahead?
The thing i want the most is SAR, after that maybe expanded ground warfare.
RE: Roadmap/Way ahead?
ORIGINAL: ckfinite
Something that would be very neat would be scripting for missions. While I think that Command is turing complete as it is, it would be wonderful tble to have the control that integrating a scripting language into the editor allows. This would allow mission designers to create complex scenarios more easily, and simplifies creating complex behaviour.
There are a number of options for a language. One promising one now is C# using the Roslyn CAAS, though Lua bindings for .NET also exist. I don't think it would be that difficult to make it secure, and the additional functionality would be amazing.
Interesting idea CK, care to elaborate?
Thanks [8D]

Developer "Command: Modern Air/Naval Operations" project!
RE: Roadmap/Way ahead?
The existing mission system is quite limited in terms of what logic you can do - representing state is really hard, with typical systems using dummy scores for different sides and complex triggers to represent where the player has gotten to and done etc. Logic is also quite difficult, as requiring a chain of events to happen, say, is annoying to set up.
Furthermore, the types of things that can be detected are limited, and non customizable to a large degree. One example that was mentioned earlier was a "on ballistic missile" trigger. This trigger is valuable, but only to a limited number of people, and adding every trigger or action of this nature leads inevitably to an explosion of thousands and thousands of triggers, all useful to a limited set of people and taking up space. Not adding them, though, limits the flexibility of mission designers.
A better way to do it would be to let end users define their own triggers, actions, and conditions programmatically. Integrating a scripting language, and exposing the necessary APIs, allows end users to have whatever trigger or action they can do, and even have persistent state within missions.
One example of what's possible is the perennial question: how do I drop troops from an aircraft? Right now, you have a one-shot trigger that fires, teleporting the troops in from the north pole. However, with a scripted system, you can have an event that simultaneously changes the transport loadout, makes a entirely new unit, and places it at the right place.
Adding this mechanism gives mission designers substantial extra flexibility, while simultaneously reducing support workload. The downside is that the implementation is complex, mostly for security and performance reasons. Triggers would probably be best left predefined, solving the major performance problem, but security in these systems is tricky and platform dependent.
Assuming that you want to stay within .NET land, my recommended language to integrate would be C# under Microsoft's new Roslyn compiler as a service architecture. While you'd have to back off a little bit on dotfuscator, Roslyn and C# provide a high-performance, well supported scripting and runtime execution architecture that already work within your programming environment. Lua bindings also exist, but aren't quite as well supported. If you're on .NET 4, then the security model isn't that much more complex either.
Compilation-wise, you have a few options. The best would be to compile the code on the mission designer's computer, then ship the compiled assembly as part of the mission. Another path would be to send the source code and then compile it on the player's computer, but this incurs a substantial performance penalty for not a lot of gain.
I do hope that we could have a scripting language inside Command. There's a wide array of things that I want to do with the game that I can't do now (without spending waaaay more time on reverse engineering), and a scripting language would let me do many of them.
Furthermore, the types of things that can be detected are limited, and non customizable to a large degree. One example that was mentioned earlier was a "on ballistic missile" trigger. This trigger is valuable, but only to a limited number of people, and adding every trigger or action of this nature leads inevitably to an explosion of thousands and thousands of triggers, all useful to a limited set of people and taking up space. Not adding them, though, limits the flexibility of mission designers.
A better way to do it would be to let end users define their own triggers, actions, and conditions programmatically. Integrating a scripting language, and exposing the necessary APIs, allows end users to have whatever trigger or action they can do, and even have persistent state within missions.
One example of what's possible is the perennial question: how do I drop troops from an aircraft? Right now, you have a one-shot trigger that fires, teleporting the troops in from the north pole. However, with a scripted system, you can have an event that simultaneously changes the transport loadout, makes a entirely new unit, and places it at the right place.
Adding this mechanism gives mission designers substantial extra flexibility, while simultaneously reducing support workload. The downside is that the implementation is complex, mostly for security and performance reasons. Triggers would probably be best left predefined, solving the major performance problem, but security in these systems is tricky and platform dependent.
Assuming that you want to stay within .NET land, my recommended language to integrate would be C# under Microsoft's new Roslyn compiler as a service architecture. While you'd have to back off a little bit on dotfuscator, Roslyn and C# provide a high-performance, well supported scripting and runtime execution architecture that already work within your programming environment. Lua bindings also exist, but aren't quite as well supported. If you're on .NET 4, then the security model isn't that much more complex either.
Compilation-wise, you have a few options. The best would be to compile the code on the mission designer's computer, then ship the compiled assembly as part of the mission. Another path would be to send the source code and then compile it on the player's computer, but this incurs a substantial performance penalty for not a lot of gain.
I do hope that we could have a scripting language inside Command. There's a wide array of things that I want to do with the game that I can't do now (without spending waaaay more time on reverse engineering), and a scripting language would let me do many of them.
RE: Roadmap/Way ahead?
Multiplayer 

My Top Matrix Games 1) CMO MP?? 2) WITP/AE 3) SOW 4) Combat Mission 5) Armor Brigade
Twitter
https://twitter.com/TacticWargamer
https://twitter.com/TacticWargamer
RE: Roadmap/Way ahead?
ORIGINAL: ckfinite
The existing mission system is quite limited in terms of what logic you can do - representing state is really hard, with typical systems using dummy scores for different sides and complex triggers to represent where the player has gotten to and done etc. Logic is also quite difficult, as requiring a chain of events to happen, say, is annoying to.... [snip]
Thanks CK, this is a fun concept but as you say might be very difficult to implement. And user support would probably be hell hehe. Anyway I'll keep it in the back of my head and discuss it with the others. I expect we'll be able to give you at least 80% of the complex mission stuff via the advanced mission planner. I'm hoping to resume design work on it after the Christmas holidays, when fully re-energized


Developer "Command: Modern Air/Naval Operations" project!
RE: Roadmap/Way ahead?
I apologize for being unclear, I wasn't thinking of the mission planner, rather, I was thinking of scenario creation. The problem is that in the existing system state is incredibly hard to represent, as turing complete systems (I almost have a proof of existence scenario done) require either new sides with scores to store state or units moving in specified ways. Furthermore, even if you do add in a state mechanism, it's really hard to reason about program flow and execution to avoid race conditions in a FSM-like system like this.
Given turing completeness, I could write a compiler from, say, brain**** to Command scenario, which then controlled scenario state and execution, it's not a lot of fun, and doesn't provide that much extra flexibility. I like the code-based approach because it provides more power (while the same things are computable, per se, the programming language can represent them in ways that can be described as sane) and it also potentially reduces your workload. At the moment, if we want a new event that interacts with game events, we have to ask for it, and it has to be manually added. If we instead had access to a scripting environment that allowed interaction with the game, these complex actions could be designed by the scenario creator instead.
The system would also allow for scenario author defined enemy AI, which would improve a number of scenarios substantially. At the moment, we are limited in how assets can be moved between missions and what control we do have more or less requires pre-planned actions. User defined scripts allow user defined AI, fixing this problem.
If you provide for "trusted" scripts, with access to file IO and networking, then one can go even further. One example would be "true" multiplayer, where the mission scripts automatically synced platform state across instances, or automatic AAR export to the web. The security model for this is much more complex, however, as with great power comes great risk.
In reviewing what's been written about .NET's security model, it doesn't seem like it's that hard to do at least the "level 1" sandboxed scripting, as there's easily usable functionality for sandboxing. Exposing proper interfaces wouldn't be that hard - in my experience with the dotfuscated bytecode, the interface layout is sensible, if it takes some getting used to, and, in my experience, the majority of support for extension mechanisms like this comes from the community.
In my estimation, adding a scripting mechanism to the scenario editor would provide a lot of power and capability at comparatively little development cost. Allowing extensions like this has worked out for a lot of other games, and the results have generally been fantastic.
Given turing completeness, I could write a compiler from, say, brain**** to Command scenario, which then controlled scenario state and execution, it's not a lot of fun, and doesn't provide that much extra flexibility. I like the code-based approach because it provides more power (while the same things are computable, per se, the programming language can represent them in ways that can be described as sane) and it also potentially reduces your workload. At the moment, if we want a new event that interacts with game events, we have to ask for it, and it has to be manually added. If we instead had access to a scripting environment that allowed interaction with the game, these complex actions could be designed by the scenario creator instead.
The system would also allow for scenario author defined enemy AI, which would improve a number of scenarios substantially. At the moment, we are limited in how assets can be moved between missions and what control we do have more or less requires pre-planned actions. User defined scripts allow user defined AI, fixing this problem.
If you provide for "trusted" scripts, with access to file IO and networking, then one can go even further. One example would be "true" multiplayer, where the mission scripts automatically synced platform state across instances, or automatic AAR export to the web. The security model for this is much more complex, however, as with great power comes great risk.
In reviewing what's been written about .NET's security model, it doesn't seem like it's that hard to do at least the "level 1" sandboxed scripting, as there's easily usable functionality for sandboxing. Exposing proper interfaces wouldn't be that hard - in my experience with the dotfuscated bytecode, the interface layout is sensible, if it takes some getting used to, and, in my experience, the majority of support for extension mechanisms like this comes from the community.
In my estimation, adding a scripting mechanism to the scenario editor would provide a lot of power and capability at comparatively little development cost. Allowing extensions like this has worked out for a lot of other games, and the results have generally been fantastic.
-
- Posts: 51
- Joined: Sun Apr 19, 2009 5:33 am
RE: Roadmap/Way ahead?
Roslyn / C# would be an option.
For my ColdWarSubSimulator project I'm using IronPython (Python for .NET) as scripting language. The syntax is easier for guys not familar with the .NET world. And everybody can install the Visual Studio Python IDE for free (includes code completion and debugging).
I think the integration and providing some events (game loop etc.) is not tough.....Most of the work would be defining interfaces / creating an API, which exposes your internal runtime artifacts....like accessing units etc.
Maybe you just create a poll if there is enough interest (people who are able and interested to script) to see if it is worth the effort?
For my ColdWarSubSimulator project I'm using IronPython (Python for .NET) as scripting language. The syntax is easier for guys not familar with the .NET world. And everybody can install the Visual Studio Python IDE for free (includes code completion and debugging).
I think the integration and providing some events (game loop etc.) is not tough.....Most of the work would be defining interfaces / creating an API, which exposes your internal runtime artifacts....like accessing units etc.
Maybe you just create a poll if there is enough interest (people who are able and interested to script) to see if it is worth the effort?
RE: Roadmap/Way ahead?
We're actively considering scripting for at least one aspect of our product however our challenge is making it accessible to people who don't code which means some mindfulness on our side (UI work, error handling etc). Stay tuned. We'll keep you update on how it goes.