Replies: 4 comments 1 reply
-
Somewhat relevant idea on how to address the design flaw |
Beta Was this translation helpful? Give feedback.
-
Hi Thanks for the input. In general, I agree with the "lack of agency" problem for the player and thanks for your proposals for how one might change that. On the crashing problem, this is most likely pygame. I have had success with pygame 1.9.6 and pygame-ce 2.3.0 (the new community edition/fork). Allegedly pygame 2.5.0 also fixes the problem, but I did not test it myself (pygame/pygame#3128). With this, we have the proposals:
Obviously, we also need a "counter balance" here. The game is already "easy but tedious" and both of the mechanics proposed so far would probably make it even easier as you can either actively lower your "death counter" or "stall it from raising" as fast (which in the steady state is basically the same thing). Are any of you interesting in coming up with a concrete design proposal for any of these mechanics? :) (Think concrete researches, choices and their consequences, CPU allocation to effect - that kind of thing) I could very much do with a co-developer/game designer on this game. If you can code as well, great - if coding is not your cop of tea, having concrete ideas for balancing with concrete numbering is fine too. :) |
Beta Was this translation helpful? Give feedback.
-
I wouldn't mind working on balancing a system, and could even do a little coding if necessary. I rather like this game conceptually, so I'd love to see its mechanics polished to make it a more engaging experience. Regarding how to solve the problem of the game actually being easy, that's a bit challenging because of how simple the game is in combination with the fact that all bad outcomes are a result of random events, while most good outcomes are a result of systematic long-term processes. For example, if you've got a 10 CPU base researching a 500 CPU upgrade and it gets destroyed or disabled after two days, your only setback is that you're not actively doing anything; you'll just continue the rest of the 480 CPU toward the research on another base. To be clear, that's the right design for research (having the player lose progress randomly would just be frustrating), but this game is in a unique position of choosing what to research and what bases to build being the only interaction. In your typical RTS, for example, you're making the same sorts of research and resource management decisions, but you're also organizing defenses against threats to them. In that situation, any random numbers involved in the destruction of your base are subtle enough that it wouldn't make sense to reload a save and then do the same thing hoping for a different outcome. With that in mind, as far as making the game more challenging goes, there would need to be a shift from just random number decisions to interactive events. Similar to how you might, say, be able to mount a defense against a rush of tanks coming your way in a typical RTS, Endgame: Singularity will need to have its design changed to create threats that the player can respond to in meaningful ways, and which save scumming is unlikely to affect the creation of. For example, taking a page out of typical RTS games, perhaps discovery chance could be changed to investigation chance. At the time that currently leads to discovery, the respective group would begin an investigation in the background. The player wouldn't be notified right away, but instead, a discovery event would be scheduled, where the "discovery" part is analogous to the actual battle in a typical RTS. Discovery, then, should be a very interactive process with little in the way of new random number usage. It's likely that any such shift will make the game seem on paper to be easier than it currently is initially, but if a good, interactive system is worked out, it can then be modified to add new sources of difficulty afterwards. I'll try to organize my thoughts into something more concrete later on; my thoughts are a little disorganized at the moment. 😆 |
Beta Was this translation helpful? Give feedback.
-
Sorry it took us so long to follow up on this. I think we won't be able to really help much after all; too much on our plate at the moment. That said, I think what I would do to solve the problem is simply to replace base destruction with a secondary, base-specific suspicion mechanic which can't cause loss of the game on its own, but exponentially increases the chance of the base being discovered each time a discovery happens. With discovery still raising global suspicion, of course. That would make discovery more like a threat that can be reacted to in various ways, rather than just something that happens to you and forces you to start rebuilding. A very simple change, but I think it would make a world of difference. |
Beta Was this translation helpful? Give feedback.
-
I first played this game many years ago (I wanna say around 2012), but I was trying it again recently at the higher difficulties, and I can't help but feel like the game's approach to difficulty is working against it (and that while this isn't a huge problem at lower difficulty levels, it makes the higher difficulty levels more tedious rather than more difficult).
Currently the approach is very simple: every base has a certain chance over whatever the period of time is of getting destroyed, and if a base gets destroyed, the player is penalized by further increasing the chance of bases being destroyed, creating a positive feedback loop. This forces you to take things slow and not, for example, constantly build bases over and over again to grow exponentially. At its core, I like that the game's design limits you in this way.
When it's implemented in this very simple way, thô, it's really not all that interactive. As a player, all you can do is choose where to build, and what to build, to attempt to balance the chance of base destruction with your CPU needs. In theory you can also put all your bases into sleep mode to wait for suspicion to decrease, but this only reduces the chance of base destruction, so in practice, there's always going to be some level of suspicion. This means that very consistently, the core gameplay loop ends up being a repetitive motion of: see that a base was destroyed, build an identical base wherever is best, rinse, repeat. And since basic maintenance costs continually increase thruout the game, you're limited in your options as regards what you can realistically choose to build, so while in theory you can tailor your options for risk, in practice, you have very little influence over the process.
I particularly was thinking of this because, due to the problem where the game randomly crashes (which unfortunately I wasn't able to solve by either upgrading or downgrading Pygame), I was saving a whole lot to compensate. Before long, I started to realize something: because base destruction is just a random chance occurrence, there is one thing that a player can do to influence outcomes: save scumming, i.e. repeatedly saving and then reloading whenever a bad outcome happens. And as it happens, I found that save scumming is less tedious than playing the game normally. That's really indicative of a serious design flaw in my opinion.
I've been thinking of ways this game could create the intended effect of creating tension by making you afraid of discovery, but in a manner that's interactive. A few ideas come to mind:
I came up with idea 2 as I was writing out idea 1, but I think I really like that one personally. I like how it gives agency to the player and allows them to choose what level of risk to take, while encouraging the player to still tend toward a sort of scorched earth policy as in the current implementation (albeit likely not quite as extreme as always destroying any base that gets detected no matter what).
In any case, I think something ought to be done to address this design issue.
Beta Was this translation helpful? Give feedback.
All reactions