Doc

Members
  • Content Count

    26
  • Joined

  • Last visited

Community Reputation

8 Neutral

About Doc

  • Rank
    Bottle Rocketeer

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. I think the whole concept of the tech tree, contracts, and science should get a rework. They definitely give me the feeling of 'But why?' attached to them. Why would KerbalGov pay me money to add a cupola to my own station? Why would landing on minimus let me build better jet engines? These gamification steps feel just like that, and indeed, it kind of makes a fun sort of sense with creating a bunch of mini-rewards along the path of play. Human-apes like getting their reward centers stimulated. But it does create alot of perverse incentives, and especially some pretty weird issues with flying say, a silly two command seat with a radio biome hopper to minimus and unlocking 'all the parts'. It would be much more interesting (in my mind) if our 'space program' learned about new things in a family by working with old things in a family. For example, if we use a Flea in a launch, that contributes practical experience in working with solid rocket boosters. Rather than unlocking things via 'science points' we unlock them via engineering points (EP). Each part has a 'type' ie (storage, power generation, structural members, aerodynamics, propulsion, science, habitation, survivability for ex). Every time you get a part to a biome (or new milestone place) that part accrues experience, which would contribute towards the unlocking of items farther down the technical development tree that share the same class. Each part should have some sort of 'practical knowledge' cap that can be learned about it, so that you don't just fly a 1,000 radial flea booster to insta-unlock all boosters. This could be done in a very clever way, for example, by awarding different specific parts different amounts of EP based on where they are used. Using a Flea on Kerbin for launch does not get you alot of progress towards future boosters. Reaching space with a Flea, on the other hand, is something pretty cool. This gets alot more interesting when you start to use parts in places other than Kerbin / LKO. You'd earn tons of aerodynamics points for flight surfaces on Eve, for ex. Not as much for a ballistic nosecone on Duna. All the points for a Orion Drive in the Mo-hole (nuclear cannonball). This then ties back into exploration; once you visit / know about a biome, your scientists have an idea of what would be interesting to test there (it can be high level; engines get extra points, solar panels are boring). That helps you plan unique and interesting missions, that would actually involve *learning* about how your equipment works in places you visit, and tying that back towards what you are doing back at KSC. This system is quite intuitive to understand, and works in the model of loads of other games, which allow you to 'get better' at certain skills / attributes by using them. As opposed to the 'from the head of god' way we learn about stuff now. This then lets us break the idea of 'science' away form 'engineering' which is a really important step in making the game more interesting to explore and play with. Science is something accumulated by going and doing there, and accumulating knowledge. What good is knowledge? It could be used to unlock the *concept* of new things, or it could be used to all for better planning (of course, this is defeated by Wiki). Knowledge is also how we often judge a space program, doing amazing things and learning amazing stuff impresses the public, which makes them more likely to fund our space program. So, TLDR Replace Science points by engineering points, and link engineering points accumulation to taking parts to places where those parts could be useful. Use Science to better understand the places we are going to visit, to better plan those trips, to unlock new concepts or to impress the public.
  2. Just a tiny bit of comparison. Your cost - per - hour for each game is thus. Kerbal: 0.375 pence per hour of play Rimworld: 1.580 pence per hour of play Warband: 1.500 pence per hour of play Rome: 2.470 pence per hour of play You have spent (vis your posted numbers) roughly 7,000 hours playing these 4 games in the last ~8 years. I'll assume that you work full time @ a minimum wage job 6.70 / hour (not that you do, but mere for context). That's roughly 13,000 hours worked. Ok, so every two hours you work, you are getting 1 hour of gaming enjoyment. For the two hours you spend working (and earning 13.40 while you are at it) here is the number of seconds you spent paying for each game. Kerbal: 1 second Rimworld: 4 seconds Warband: 4 seconds Rome: 7 seconds Bro, you need to seriously readjust your valuation of your own time. You are quite literally spending less than 1/1000th of your labor on what appears to be your primary form of entertainment.
  3. Gravity assists is a good point that is solidly in the 'plus' column, along with lagrange points. I can imagine 'casual+' players making use of those things. Wouldn't automated stationkeeping effectively be placing non-piloted craft 'on rails' anyways? I am not going to make an official comment either way - since doing things 'the easy way' can often prevent you from doing other things 'the easy way' and then you need to make a complex system over there instead. N-body is neat, but the implementation needs to be handled in such a way that a 9 year old can effectively build a ship and reach orbit, without failing for complex reasons.
  4. That would probably be 'easiest' - just treat everyone elses ships like they are 'on rails' - that'd even solve the time-warp issue. But I wouldn't really call it multiplayer...
  5. That's my bad - I think I was aiming at a different open thread and dumped it here. Because I herp the derp. Sorry
  6. What does n-body physics add to gameplay for the large majority of players? Lagrange points, weird orbits, lots of complexity? Lagrange points are good, weird orbits are bad. I've done games before, and folks on the forum forget that they represent the most dedicated, tiny sliver of the total player base. If you are on the forum, and actively discussing any of the mechanics in a reasonable degree of accuracy, you know more than 99% of the playerbase. This is something that you really need to consider as a developer - does the feature you are adding make the game more valuable or less valuable - players just want 'the best game evar' ; however they define it. So games have to choose the level & type of gamer they want to be delivering to - KSP hit a great sweet spot in terms of realistic-ish challenge (rocket building and orbital mechanics is hard) without being punishing (tiny planets = easy to get to orbit!). Adding N-body (or any other system) needs to keep that sweet spot, in order to maintain a player base. I don't see Kerbal picking up a ton of players from adding n-body, but I can easily see it turning people off, if it makes it harder to accomplish stuff. So it needs to be handled really, really well. That extends out to opportunity cost as well - how much performance is n-body going to eat, that could be doing something else 'cool' (bigger ships? Better physics?) - and also dev opportunity cost. Conics on rails work 'pretty good' to build a really, really fun game. We have a pretty good idea how they need to work to be balanced, and I suspect that they could implement something similar without a massive dev lift. But N-body is going to have tons of edge cases, that we aren't even aware of being an issue. So - what are the benefits vs what are the costs.
  7. Saw this in an article. Latest March 2020 release, for what it is worth https://www.pcgamer.com/uk/kerbal-space-program-2-release-date-multiplayer-everything-we-know/
  8. My bucket of nickles... MP 'seems' like a fantastic option for Kerbal, but we all have lots of questions on how it would actually play out, especially given the tensions inherent in making the game. The obvious attraction is that multiple players can 'collaborate' on projects which scratch their own particular itch, but also have parts they don't really like. For instance, I love designing and building ships & bases, but once I figure out that they are actually possible to assemble, I get bored. Some folks love the sim aspect of cruising their rover around or their crane and actually putting stuff together. So we can co-op. I deliver cool base modules, they stack them up. We're both happy. Yay. Or you can run in a more 'competitive' mode, where multiple space agencies are vying to be 'the most awesome' - competing on a space race, for colonization, for science etc. The problem comes with the tension in how the game works; to be coop, we need to be able to interact with our fellow players constructions. To have the power to interact in kerbal is to have the power to destroy. If the power to destroy exists, there are going to be griefers. It is known. In all cases, we have some real problems with synchronization due to the 'time warp' nature of the game. We *need* time warp to accomplish any of the goals in the game - even a mun mission is nuts if you try to do it in real time. So time warp is a given. That right there is, I think, the essential problem with MP. How do we allow for people to conduct missions according to 'their own' schedule, without ruining other peoples planning. I honestly don't have any idea how to make this work well in anything outside of a very friendly group of players. But lets just assume that they come up with an elegant and effective way to keep everyone in sync. That still leaves the issue of ship interaction <-> ship destruction being a huge risk for bad player behavior / griefing. Even in a small group of friendlies, the massive frustration that everyone would experience if Bob got drunk, and accidentially mistimed his retro burn when approaching our 2 year old station, would be *brutal* One thought I have been having alot recently is the idea that solving bad player interaction could be countered by putting a ship/station/base 'on rails' - so that its configuration, orbit, etc was converted into a semi-static object, which you can't affect via physics. Things like docking ports etc could still be 'active' to allow for interaction, but it would be more like as if the VAB had a docking port bolted to it. This would allow players, via some sort of process to put some things 'into statis' and beyond the ability of other players to interfere with. It could be done in alot of ways, but simply having 'ownership' of a ship and then a toggle to put it 'on rails' or not would be easy. Likewise, a 'merge ship' option could be easily implemented, so that once you dock to a ship on rails, you can vote to have your ship 'merge' with the railship, and then the railship owner accepts the request, and poof, your module is now 'bolted' to the on-rails unit. I think that there would need to be a two-step process for putting anything on rails - for instance, anyone in the local physics bubble has to agree, or the server has to majority vote agree, or the server owner needs to agree. The 'ship on rails' thing is also a possibility for handling different ships owned by other people. It would be possible to treat *every* ship, not owned by you, as 'on rails' and indestructible. That would be a big lever to prevent griefing, especially in competitive games it might be sufficient to just run it that way 100% This would introduce some weirdness, especially w.r.t. docking; if you just 'bounce' off I think something like the above system I describe is how the devs would need to handle a thing like the colonies they are describing, or the orbital VAB structures. Being able to de-orbit the super VAB, or break it, or whatever would be neat for a few people, but super annoying for the great masses. .
  9. Just noticed that mechjeb isn't patched yet, and realized how freaking dependent on it I've gotten for making those repeat missions less grindy. Just wanted to say 'thanks' for all the hours of work you put in, so that my gaming is easier.

     

    Doc

  10. I am just going to throw this out there - not saying it is or is not what happened. But alot of smallish companies (like squad) need to set milestones, which they need to achieve, by a certain time, or else they can lose control / money / flexibility - the banks, VC guys, and run-of-the-mill partners want to see a certain progression. It is completely possible that '1.0 before May 1' was a milestone that made 'unpleasant' things for the company happen. Is 1.0 perfect - not really. Is it a big step forward? Oh yes, yes it is....
  11. So I've started on this challenge a half dozen times, but get distracted (constantly). Here is my mission that actually should -actually- finish. Mods: DRE FAR KW Rocketry Mechjeb TAC Life Infernal Robotics I use standard reusable lifter that puts ~38 tons to LKO with each flight, and an 8 kerbal crew lifter. All missions comply with the ... <to be continuted>
  12. I stick my 'thrust around heatshield' engines out on Infernal Robotics telescoping pistons. I extend them to thrust, then retract for re-entry. Works pretty good.
  13. Hey Claw, I haven't tried this fix yet, but it sounds like it's a bang up for what went wrong with my station. Thank you for all your hard work in trying to run this down. -Doc
  14. Getting ready to launch a full TAC-life Duna exploration mission. 6 crew, round trip, with manned landings. I'm using a variant of my munar lander with a shielded descent stage, but the rest of the lander is *not* that aerodynamic, but its still duna, so I hope FAR doesn't kill me. Also building a LKO OKS station, that eats up all my extra income
  15. 1.100.000 for testing an Aerospike around minimus. Icing on the cake is a LV-1R test for 300.000 *also* around minimus. 1.400.000 for a <50k launch... Which is a good thing, since my giant OKS LKO gateway station & Duna explorer mission have really been sucking up funds.