Your browser does not seem to support JavaScript. As a result, your viewing experience will be diminished, and you have been placed in read-only mode.
Please download a browser that supports JavaScript, or enable it if it's disabled (i.e. NoScript).
That's what I was thinking. You need to know what establishments offer what kind of missions. The Golden Pony might be a good place to pick up courier missions. The Fluffy Duckling might be a seedier joint where you're more likely to find someone looking for a smuggler. The Black Hole might be a place where your character gets in a random bar fight and has to pay 100 credits for a disorderly conduct ticket. Fun and enhancing gameplay without getting overly complicated.
@krugeruwsp, on 16 March 2012 - 10:06 AM, said in Your game functionality wishlist:
The Black Hole might be a place where your character gets in a random bar fight and has to pay 100 credits for a disorderly conduct ticket.
Screw that. I want the option to, instead of paying the fine, blast my way out of the spaceport and become an outlaw.
Here's a small thing that might be useful: an O test expression that can determine not only whether you have a certain outfit, but how many. So you can be declined for a mission for not having enough ammo, for instance, or get nabbed for being over the legal limit.
I think the only one that gets a really vehement "yes" from me is the electronic warfare (many other points I agree on, and some I disagree with, but none as strongly on either side). Of course you could end up with absurd levels of ECM and ECCM and ECCCM and E=CM^2, but done well (read: not overwhelming) it could add a lot of depth – both flavor-wise and gameplay-wise. One of the things that I liked about the Earth-Minbari war in Babylon 5 was that the Minbari were so far advanced beyond any technology humanity had developed that EarthForce couldn't even target the Minbari ships. That just puts things on a completely different level than "Their shields are stronger/guns are bigger so they're beating us."
On the gameplay side, it's another useful knob for developers to turn and for players to adapt to. And on top of just "Enemy X has countermeasure Y so I need to bring equipment Z or find a way to manage despite my disadvantage," which is fine but a little rock-paper-scisorsy, it opens up new ship roles. But the biggest gameplay reason, in my opinion, is that it forces the player to deal with scarcity instead of abundance.
I could make a whole thread on scarcity vs. abundance in EV, which I may do at some point, but in brief, EVN, and to a lesser extent the EV and EVO, are games of abundance. (I took this abundance and ran with it in Anathema, and am dialing it back entirely in my post-Anathema project.) The majority of the things you want are pretty much handed to you – fuel/energy is cheap, afterburners are light, powerful weapons abound waiting to be exploited, etc. One of the biggest, and perhaps most overlooked, facets of this abundance is the ship's scanners. They're there, and unless you're in heavy interference, they work. You can use the credits you made from your first mission to get IFF and a density scanner and you're set. But if there are ships that can interfere with something as fundamental as jumping out of the system, or giving you accurate IFF readings, or effectively firing your weapons, suddenly there's a real tension – again, both in terms of flavor and gameplay.
For comparison, technological superiority being limited to the strength of guns, shields, and engines (and occasionally a few other things like cloaking) leads to scenarios where you have a David fighting a Goliath. Your enemy is pretty much like you, just bigger. Find a way around the bigness and you're good – and the way around it may just be bringing 20 Davids. On the other hand, if you bring in electronic warfare, you can end up feeling more like David vs. David, except your David suddenly forgets how to use a sling. What you're up against is preventing you from doing things that are fundamental, and it doesn't matter how good of a shot you are or how many others you bring because the things that are almost as natural to you as walking or breathing are stripped away. And that's really unsettling, which is good. On the flip side, if the player is on the winning side of the electronics arms race, they have a whole new element to consider in terms of ship design – also a good thing.
As long as you don't get quite to the extreme of "we can't even see them, so I guess we'll drop space mines all over Sol and hope for the best." Good for flavor. Not so good for gameplay. ^_^
@archon, on 20 March 2012 - 06:45 PM, said in Your game functionality wishlist:
One of the biggest, and perhaps most overlooked, facets of this abundance is the ship's scanners. They're there, and unless you're in heavy interference, they work. You can use the credits you made from your first mission to get IFF and a density scanner and you're set.
Although the paradigm is different from what you describe, Tom Spreen’s Rescue! made sensors something you needed to think about, in ways that are sort of interesting from an EV perspective. Your sensors had several levels of functionality, giving you different amounts of information about the world around you, but each level increased the energy drain. If you were extremely short of power, you might even need to turn off the long-range scanner itself (by closing the window). And all ship’s systems, including the long-range scanner and the targeting computer, could be damaged by enemy fire.
Note that this will be added as part of my big-ass EV4 wishlist :3
This post has been edited by Coraxus : 20 March 2012 - 09:00 PM
@coraxus, on 20 March 2012 - 08:21 PM, said in Your game functionality wishlist:
2. FTL intra-star system travel 5. When players possess a launch bay, they can have the option to retrieve a disabled fighter to be as part of their fighter compliment or as an escort 9. Players can transfer energy between shield, weapon, and engine power for different performance
2 - This leads to some annoying tactics, so no 5 - Agreed 9 - Nah, that would be overly complicated
2 - But such a feature was done on Ares, right? I figured it could work with with EV
I agree with Coraxus, but such a feature should definitely be balanced. For starters, 1) going FTL in system should drop your shields and 2) going FTL in system means you cannot fire any weapons while FTL or while dropping out from FTL speeds.
That eliminates a good portion of the abuse the jump key saw in Ares.
Well, if the jump key dropped your shields in Ares, you'd explode instantly. And shooting while in FTL was a pretty silly strategy that really never worked.
But it worked for Ares because Ares was a strategy game. Jumping allowed the rapid repositioning of your fleet or to quickly mobilize to intercept and engage attacks at various locations on the map or incoming Transports (which, importantly, couldn't use FTL). Plus the distances were often large enough that even FTL took some time to get places. In EV, the only real reason for it to exist would be to make overly spaced out systems less annoying (or getting to wormholes). You can generally reach most places in a EV system in a few seconds at normal top speed, whereas in Ares it would take several minutes or more.
In-system FTL is cool, but you'd basically have to design all the star systems in the game around having just a cool feature for it to have any point.
Read, you'd have to turn EV into a strategy game with some heavy RPG elements thrown in for fun. Still, I think the feature should be implemented for clever plug-in developers, and adding a way to turn it off by ship would make things more interesting. (Large cargo ships can't jump, makes them easy pickings for pirates and marauders, etc. etc.)
I said it should drop your shields because in Ares it turned the jump key into a good "panic" key. In an EV-esque game I imagine it would do the same, but since EV-esque ships tend to have good amounts of armor and shields dropping your shields would make standing and fighting a better option that being chased down and eventually pummeled to death. It would also make ambushes immediately after dropping from FTL much more risky.
And I said FTL jumping should disable your weapons because it only makes sense that your weapons wouldn't work at FTL. It would also eliminate mid-FTL battle shenanigans, like dropping EVC space bombs behind you and slamming them into a hapless target at FTL. (Which was fun to do in Lightnings in EVC BTW.)
This post has been edited by JacaByte : 20 March 2012 - 10:49 PM
Keep in mind however, that whenever we're talking about FTL, we are talking about all methods of FTL travel, this means not only just warping, but also using portal wormhole and space-folding technologies.
I think it would be usable on a small scale. An in-system FTL system should work on the current vector, and plug-in developers would specify how many pixels a person could jump in a straight line, the energy it would take to do so, whether or not the outfit would drain or not drain shields, ect. Similar flags to the cloaking device, in other words. It would be a good escape maneuver, I think. To keep it consistent with the EV style, a player would need to slow down and an FTL jump could have to take a few seconds, just like normal jumping (fast jump outfits granting exception.)
It could also be done simply with a secondary superfast afterburner, though. I agree with it disabling weapons while in FTL. I just think energy requirements, shields, and other flags should be available for developers to choose their effects.
Oh, and just because I always wanted to make a cool Farscape plug, I'd like the ability to have ships generate a graphic ahead/around a ship specifically for hyperspacing. Right now, it's a challenge to implement it. I'd prefer if it was simplified and broken into hyperspace effects, folding/unfolding, that kind of stuff. Basically, just a natural expansion of the shan resource. It would probably be more easily implemented if/when 3D model rendering for sprites is in place by referencing an additional model or texture layer.
@krugeruwsp, on 21 March 2012 - 10:09 AM, said in Your game functionality wishlist:
Well, I imagine it can technically be done already with the current Nova engine as basically it's just a set of pre-rendered animations. Of course it wouldn't hurt to expand the shan resources. I would like to see Nova being able to implement a ship that no only banks, but can also have rotating modules and have jumping animation all at the same time. Hell, might as well throw in post-jump animation. Or here's a real interesting idea, "snaking animation". I'm pretty sure you can imagine what I mean by that
Which reminds me, I gotta update my EV4 wishlist hehe.
Actually, it can't. Not for lack of trying, mind you. The effect I was trying to create was Moya creating the starburst window and doing the whole glow-line thing, then flying through the window to disappear. Given current engine limitations, the best I was able to do was get the starburst window to appear, but it moved with the ship when it hyperspaced. No good.
All in all, if EV4 was upgraded to include rendering full models as 2D sprites, I think many of these issues would be solved already. You could easily include things like rotating turrets, tentacle/snaky animations, that kind of stuff, with animated models.
I see what you mean. Sounds like you want to have a portal wormhole effect animation of sorts.
Pretty much.
Oh, I also think that a dynamic reference change system should be in order as well, to point missions or other information towards new spobs if something is replaced or changed. So, you have a mission to stellar 128, but stellar 128 has been replaced with stellar 129 (different Earth landing text, no shipyard because it was destroyed, whatever, I don't care. It's different.) When the spob is replaced, there should be a flag to alert the engine to redirect things from spob 128 to spob 129. This needs to be dynamic and persistent between saves. This should be part of a lot of different resource types, at least across spobs, systs, dudes/flets, misns, and maybe nebula resources as well.
Perhaps all references should be to some sort of 'meta-spöb' resource, which in turn lists the IDs of all the spöbs that are 'really' the same planet?
But... that would allow someone to pull a Neil without actually pulling a Neil.