I noticed that this write up is old (2014), so most of the designs shown won't work in the base game anymore. That's good, because why should you be able to launch what looks like a wedding cake?
I've been playing this game regularly for 3 years now. It has a vibrant modding community, and recently some of the more popular gameplay mods have made their way into the core game (mainly more realistic aerodynamics, resource mining, my favorite, "deadly reentry"). It's basically a SimCity game, but with rockets.
The one downside is that while it's a lot of fun at the beginning, it gets kind of monotonous at the end (if you can call it an end). Flying crew to and from Duna is hard. I've never done it. Even just sending a probe is hard to hit it.
I was amazed at how over-engineered their first rockets were. Having always played career mode I was 'forced' to do the minimum, getting to the Mun with only 2 or 3 engines total.
Flying to other planets is really difficult, something I still can't reliably do with hundreds of hours played. I've only sent probes to 3 of the other planets (Duna, Eve, Jool).
It can get monotonous, but when I play I am strongly motivated by trying to achieve something I never have before. (Or if I'm playing mods such as 'Real Solar System', but that's another step up again in difficulty).
It's mostly a question of dv. Getting the perfect transfer window is hard, but eyeballing a good enough one and doing some mid course correction is significantly easier.
If you put the sun at the center and kerbal at 3 o'clock, you get a good enough transfer window by waiting to having duna at 1 o'clock. You can then eject tangentially from kerbal sphere of influence and correct half way trough.
The only real plugin that I strongly suggest there is the aereobrake plugin, that'll show you the predictoion for aerobraking directly on the ksp map.
Back when KSP released their first version with other planets (2012 or so), I was a forum mod and tester for them, and I build a small website to simplify interplanetary transfers: http://ksp.olex.biz. It's still running and up-to-date, and apparently still used, despite there being a ton of other sites and ingame plugins that provide the same data in much better ways.
Thanks for your contribution! I've flown many interplanetary missions with your tool.
For more accurate and realistic missions, there's this tool [0] to calculate pork chop plots [1] to find minimum energy transfers. (you surely know about this)
I think calculators and mission planners like this should be a part of the game proper. Switching to a web browser mid-game to do mission planning is a big turn off for me.
It might be a part of their game design, there are very few numbers and data presented in game. But I don't think it works very well apart from some very basic moon missions. A lot of the information is there but it's just difficult to find (e.g. want to know your inclination? select moon, and then look at ascending/descending nodes in map view).
I enjoyed the eyeball method initially but you grow out of it soon. I liked the "fire prograde when moon rises over horizon" moon missions and I even achieved a rendez-vous in 0.17 [2] before there were maneuver nodes or other helpful gadgets in the map view.
But once we got maneuver nodes, intersection markers, etc that playing style was out of the window. Now I'd really want to have some proper mission planning utilities (similar to some MFD modes in Orbiter).
I think the game should (at minimum) have a transfer window planner, a patched conics solver (with optimization), a pork chop plotter and a rocket burn planner for ascent and powered descent. Perhaps a Clohessy-Wiltshire-Hill equation solver for pinpoint accuracy rendez-vous too.
yeah that tool is great if you know how to translate it in game, but you know the original protractor method[1] ain't bad and one can kinda eyeball it like in the old days when we timed the mun burn based on the moment it dawned on kerbin... good times XD
Knowing the transfer window is the key. Check out Launch Window Planner for KSP. It tells you when to start your transfer down to the second. If you're within a few minutes of that window, or even within a couple of days in that same section of the orbit, you'll get there fine with slight mid course correction.
Now that KSP lets you plan your intercepts several sphere of influences away also makes planning easier. Just adjust your maneuver nodes until you see an intercept, then follow them.
Known both in KSP and space industry as "asparagus staging", it's a pretty old idea. It's tough to implement in real life, though, because pumping fuel around adds a non-trivial amount of complexity to the rocket. FH might be the first ever production rocket to use it, actually.
EDIT nevermind, I didn't realize SpaceX scrapped the idea too.
They're really handy in the latest version which requires you to set up a sattelite network for communication with unmanned probes, you'd need at least three (ish) to be able to communicate with a probe on a planet, and you'll need several in various positions around the sun to make it work across the solar system (in career mode you only unlock the strongest transmitter late in the science tree, and even then you'll need several).
I always felt like there wasn't a need to "build" much past the first Mun mission, and grinding for science performing slight variations on the same task to get new parts was really boring.
My first thought was how I wished I had to set up satellites (or some sort of infrastructure like remote fuel depots) to reach farther planets. That would also take time but be much more interesting.
Having played early in the beta, and then picked it up again this year, I discovered the new need for antennas when my unmanned craft couldn't receive the commands to complete its orbital insertion around Duna.
Classic KSP. An hour into a mission and you realize you never added batteries and you can't move your probe because the sun isn't hitting the solar panels.
Or even worse, you realize as your crew is barreling towards Kerbin that you forgot to add parachutes to your lander...
Whatever you do, avoid the console version at all costs.
A friend told me about this game, and I thought it would be perfect for my (then) 10 year old. We got it for the PS4, and it was nothing but frustration. The biggest controls were complex and confusing when mapped to the PS4 controller, you couldn't install mods, and the game was buggy, frequently crashing and corrupting saves.
We finally got the PC version (which I run under Wine on FreeBSD), and it works much, much, much better.
I used to buy them because they worked without an internet connection, and the devkits usually provided their own (well written) primitives and game engines so bug-free (or seemingly bug-free) games tended to be the norm.
Now everyone just writes things in unity and the DRM forces you to have a reliable broadband connection, I don't see the point anymore.
Console dev kits for major platforms never included game engines, and the primitives included with older console dev kits, if any, were often ignored because more custom versions were required to get the desired performance.
What's happened to the console ecosystem is a whole bunch of different things. More accessible tools (e.g. Unity) and platform holder development programs have gotten more developers who are less experienced and not as well funded onto the console platforms. Availability of easy online patching has lead to physical releases, which have to be finalized months before the actual release date, being intentionally left incomplete, with gaps to be filled in by a release day patch. Changing technology cycles have made console generations blurrier. And yes, online DRM has become a thing, although I'm not sure that's quite as onerous in practice as you suggest; it's not like current consoles just refuse to run any games while offline.
That's not an exhaustive list. The appeal of consoles is what it has always been, they're still the easiest and cheapest way into modern video games. But it's true that some of the advantages over the PC platform have begun to erode.
My only computer is a Macbook Pro running Arch Linux (which is my ideal setup for getting work done). In general it struggles to achieve unplayably low framerates in the small selection of games that even run on Linux.
Given that I want to play games, my options are to spend a bunch of time and energy researching, price-shopping for parts, and building out what would likely be a $1000+ dedicated gaming Windows PC, continuing to funnel time and money into upgrades as games demand more and more horsepower; or pick up a $250 current-gen console at Walmart, knowing that it'll be able to handle anything I throw at it, and only worry about upgrading several years from now when some game I really want comes out on a future generation console.
As someone with a limited entertainment budget, the latter option is by far the more attractive option.
I bought the PS4 recently to play Crash Bandicoot, great game. Other than that, I just don't understand how people play anything else other than racing games with a controller, that thing is absolute trash for actually "controlling" anything.
I build a new PC approximately every 7-10 years and so far my computers handled everything fine. My current one which I'm about to replace has a first gen i7 and a GTX480 and they worked perfectly with pretty much any game. I'm about to replace it, probably with a 7700k and 1080Ti which should again last for quite a while. The only reason why I'm replacing it at all is because some random component on the motherboard started overheating so I finally have a good reason to upgrade.
> spend a bunch of time and energy researching
This is a terrible argument, I know jack about hardware yet am able to build a relatively decent computer. It's not rocket science, a couple minutes of looking through your local computer shop should give you a good idea what sort of components are good or bad. You can also throw your build into PCPartPicker which will generally let you know if something is wrong.
> I just don't understand how people play anything else other than racing games with a controller
Oh, not up to the challenge of playing games with a controller? /s
But seriously, adjusting controller sensitivity/etc to your liking and practicing helps a lot. You can also turn on aim assist in most shooters (it's usually on by default, actually). There are plenty of great PS4 exclusives that it'd be a shame to ignore simply because you think they're unsuitable for controllers (depending on your taste - Horizon Zero Dawn, Bloodborne, Uncharted 4, The Last of Us, Nier Automata, Nioh, Ratchet and Clank, The Last Guardian, Persona 5, Gravity Rush).
That said, there definitely are plenty of games that have terrible console controls (especially bad ports, like Kerbal) and I've never seen an RTS done well on a console.
> I just don't understand how people play anything else other than racing games with a controller
Don't forget top-down and fighting games. RPG's too.
But if you're talking about games that have a first/third person aiming component, yeah, mouse and keyboard are better, but if you're stuck with a controller, you just aim a bit differently. You have to rely more on strafe-aiming, sweeping, and movement prediction.
It's usually not so bad the controller is a reason to give up on otherwise good console-only games.
I think the only point is that console hardware tends to be cheaper than a PC with similar performance due to the mass manufacturing. Also the games only target one platform so you don't have to mess with the settings to get decent performance (if the devs do their job correctly, that is).
I agree that console gaming is not really attractive nowadays if you're not on a budget and don't mind missing a few exclusives.
>the devkits usually provided their own (well written) primitives and game engines so bug-free (or seemingly bug-free) games
I don't think that's quite right, I think the main reason games seem buggier nowadays are because:
- Nostalgia goggles, some games were utterly broken even back in the day, we just don't remember those.
- Games are a lot more complicated these days, it's easier to test Pacman than GTAV.
- You can now patch games so "going gold" is not that much of a deal anymore. Back then if your Nintendo 64 cartridge shipped with a game-breaking bug you were screwed.
- Even though the games themselves are overall more complex, gamedev is also more accessible thanks to Unity and other frameworks. That lowered the bar for game devs and as a result the average skill level is probably lower than it used to be.
In my experience the "well written primitives" is a myth. Older console (anything up to the 16bit era) hardly had any primitives to speak of, you just wrote assembly and talked to the hardware directly.
Later consoles had a kernel or "BIOS" but it's really not as good as you could imagine. To take the PlayStation for instance, the BIOS is a piece of crap with poorly optimized code and buggy functions. Just read a bit trough http://problemkaputt.de/psx-spx.htm#kernelbios to get a taste.
FileSeek: Movement from the eof is incorrect. Also, movement beyond the end of the file is not checked.
FileGetc: For some strange reason, the returned character is sign-expanded; so, a return value of FFFFFFFFh could mean either character FFh, or error.
strstr: After rejecting incomplete matches, the function doesn't fallback to the old str address plus 1, but does rather continue at the current str address
Since the PlayStation doesn't have a MMU many games actually hotpatched the BIOS to fix some of these issues or add functionality.
The fact that Linux is not FreeBSD is still a major stumbling block for the idea that drewg123 should not use a compatibility shim and just run the Linux version, of whatever bitness, though. (-:
I recommend Scott Manley's tutorials on youtube. Even though many of them are for older versions of KSP, they are still great to get you started. If you are willing to spend a bit, there is a great book that covers a lot of ground in KSP:
I'll second that. Scott Manley is THE source KSP tutorials and just plain absurd fun-with-KSP-plugins. You'll get a lot more out of KSP if you watch/follow his videos.
The game is fun, and I definitely recommend putting in the time to figure it out. There will come points where things just click, and suddenly getting to orbit becomes easy, then orbital rendezvous, then Mun and Minmus landings, etc., etc.
For me the struggle of figuring it out from the very basics was the best part. It's ok to have 10 or 20 or 50 failed launch attempts in the beginning. You're learning how to go to space!
Not a tutorial per-se, but rather a series of KSP youtube shows, https://www.youtube.com/user/BeazaYT has done some amazing story telling, and a lot can be learned by watching his build teardowns.
I really love Kerbal Space Program but I stopped playing a couple of years back. Unity is really terrible. I remember landing 3 pieces of a moon base, and I was getting like 3fps... After another 3 weeks of making a space station, again was getting 5fps.
The funny thing was, I went out and splashed 1.5k on a new PC just for Kerbal, I loaded my save file of my moon base, and now I had 7fps....
Absolutely useless. KSP is like a Mr Universe Body Builder wearing a 3 year old girl's dress.
Unity gets bad rep the same way FL studio (in 00s) or any other accessible creative tools do. Because they're the most accessible tools for beginners, they attract beginners and they use it to develop a lot of beginner-level products with all the downsides; however, these tools are quite capable of achieving AAA results in professional help.
Unity has nothing to do with KSP being laggy. KSP is a very ambitious game written by a beginner team; without Unity it couldn't have been made at all.
I have not yet played a Unity game which doesn't have the "unity look and feel". I don't think anyone is going to be able to convince me otherwise. I am happy to purchase a modern (in the last 3 months) popular unity game tonight. If you can think of one that doesn't run like a Flash SWF, I will buy it.
There're these, for a start. (Though I don’t know why "modern" is qualified as being within three months.) Perhaps the problem is that no one can recognize a game made with Unity at a glance? The cheaper, lousier games can’t or don’t pay to remove the "Made with Unity" splash, so Unity has acquired something of an [image problem].
And how would you know what engine was the game built with anyway? If you're relying on the Unity log splash screen, then indeed you only see games developed by beginner teams who can't even afford a paid license.
Can't you tell? I can't tell the difference between Lumberyard, Crytek, Unreal (I could Unreal until 2012ish), but I always know a unity game because it looks and runs like shit.
It's not really an argument against Unity per se, but low KSP performance had everything to do with that engine - because it ended up being CPU-bound through single-threaded physics. This problem is now solved, from what I remember.
That's everything to do with correct usage of the engine. Unity's PhysX is a general one-size-fits-all solution, which is not suitable for advanced physics-based game like KSP. Using it is only acceptable for prototype; they should've written their own physics, which suits their needs, and make it multi-threaded, and they should've done it in any game engine. In fact, many developers I know that worked with physics-based game mechanics have done just that - and none of them had requirements as significant as KSP.
I have a ~5-year old PC that was around $1,250 new. KSP still runs without issues. I don't know the frame rate but it's not low enough to affect performance in any meaningful way.
More importantly, as others have stated, the performance has really improved over the last 12-18 months. Give it a shot again and you might be surprised.
It has absolutely everything to do with Unity - or at least it had, when Unity 4 single-threaded physics engine was used. AFAIK KSP now has a properly multi-threaded physics engine, and works much faster.
I don't think there's any reason why C# can't be comparable to C++, or any reason to think a programmer using C++ would be able to write significantly more efficient code than if they were using C#.
We're not talking about Python here, C# is a JIT compiled language not an interpreted one. The performance could be roughly comparable given the same code.
A lot of AAA games use scripting languages for implementing game logic (notably Lua), even if the heavy lifting (graphics, physics, AI, etc...) is done with C++.
I understand what you are saying, but the latest version is a "big leap for kerbalkind".
You should give it a try again.
When I have time, I play it on a mid-range laptop.
I played KSP all the way up until 1.0 on a $900 Thinkpad x220, and I was usually getting 15-20 FPS. My old $1.5k-ish gaming PC was getting a nice solid 60fps until I started making launchpad monstrosities. So I find it hard to believe that your new $1.5k PC is actually struggling with KSP under "typical usage," as opposed to some weird corner case in your save or just a really huge moon base.
That was when the game used Unity 4? KSP used to have a single-threaded physics engine. AFAIR they replaced it now, so it should handle much more complex objects without destroying the framerate.
i can't help but love KSP. But I wish it was easier to just design the craft and missions, and not have to do the manual control. I like flight sims, but KSP controls are a bit too wonky for my tastes.
Once you have a good design (with just enough control surfaces, good aerodynamics and appropriate thrust-to-weight ratio), you get to low orbit with almost zero input [1][2]. If it requires a lot of input after picking up some speed off the launchpad, it might be a bad design.
The controls feel "wonky" for the most part because, since it's a game more than a simulator, you tend to have way more control authority than is realistically possible, specially with reaction wheels. There are some mods to rebalance that.
A lot of the fun in KSP can be finding the line between bad design and good design, and then trying to pilot your way through it (IMHO). I will never forget my first Apollo-style mission and just how many dozens of struts it took to hold together (this was before they added the current largest-diameter tanks/engines), and how hair-raising the piloting of it all was. To me, no game has ever matched the intensity of that experience, before or since.
Agreed. In my current game, I built a station that's in about 100 km orbit of Kerbin, and I've been using Apollo style CSMs and LEMs for munar and minmur missions, but I honestly hate the ships. They have often don't have quite enough fuel for the return trip, so I ended up having to put a tanker out in minmur orbit. It sucks. I've tried to redesign them, but I'm kinda of in a local maximum in designs right now, which kinda sucks.
Assuming you're in career mode, where are you in the tech tree? Some of the later fuel tanks and engine make it a lot easier to haul huge amounts of mass around the solar system.
Also if you don't do it already pay a great attention to you engine's specific impulse. It's often a lot more important than thrust, at least outside of first stages and landers.
My go-to combination in the mid game is Mainsail engine for first stage from kerbin launchpad (high thrust and good Isp in the atmosphere) and then switch to the Poodle while in space (not-so-great thrust but high Isp in vacuum). Oh and a healthy amount of "asparagus" staging, it's always a bit annoying to set up but well worth it in KSP.
Later on you unlock even more efficient engines, such as the "Nerv" nuclear engine with an Isp of 800 in vacuum.
Finally you can also mine fuel on planets and asteroid to refuel your tanks, I generally like setting up a "filling station" on minmus to avoid having to haul massive amounts of fuel out of the kerbin gravity well.
I've played a lot of my games in my life so far but very few, if any, have matched the thrill of landing on Mun for the first time (and making it back).
There are mods for that. MechJeb and kOS come to mind: MechJeb includes an autopilot, kOS lets you program your own. There's also kRPC which lets you control KSP craft via RPC, so you can use a language that you like such as Python or Node.
MechJeb is about the only mod that I use on a vanilla install of KSP. I honestly feel that it's something that should be part of the game (although I can understand the hesitation to include it).
I never use MechJeb because I feel like it's cheating, however I agree that some base functionality is missing from the vanilla game. In particular dV and thrust-to-weight ratio indicators for your rockets while you build them, as well as flight info while in flight without having to switch to map mode every two seconds (for instance your current apoapsis and periapsis and the time needed to reach them while climbing to orbit, and also the amount of dV left in your rockets when you plan your maneuvers).
However MechJeb is a bit overkill for that, I prefer to use Kerbal Engineer[0]. It's simple and offers a few quality of life improvements without actually playing the game for you.
The other mod I consider vital is the docking alignment indicator[1] which makes docking massively less painful.
MechJeb is awesome, but I only tend to use it once I got the launching manually thing down properly - MechJeb can compensate for some bad design decisions. Some, that is.
Different people, different tastes. After a hard day of programming I love to relax by doing programming, but this time on something I care about and not $dayjob related nonsense.
You need to get used to kOS scripting language but it is extremely powerful. You can script your whole mission from launch to landing to return. So it can be used for autonomous probes simulations or to automate parts of the mission (Apollo style).
It sounds like you want MechJeb, which removes a lot of the manual guesswork - it'll do automated ascent, descent, docking, hohmann transfers, etc. - I played vanilla for years but would always get tired of the tedious guesswork and was dubious about MJ, thinking it'd be game-breaking - but rather it's made the game 30x more playable and enjoyable, and doesn't sap the challenge one bit.
Only yesterday I ended up doing a return from mun orbit with bingo fuel by spinning a craft up to crazy longitudinal rpm and decoupling the descent stage at just the right moment.
My first interest in programing, outside of the simple office automation scripting I was doing, started when I built an orbital rendevous calculator in KSP (back before they had orbit planning built in).
I eventually merged my mod into mechjeb, adding a whole slew of orbital calculation functions, and many fun space times were had by all.
Thank you for contributing! I love KSP, and Mechjeb helped me get past the frustrating stage of learning the basics. I usually only use it for TWR and ΔV now but I think I'd have given up without it at first.
Because to a certain extent, it's "the Kerbal way".
That said, using more efficient staging designs is usually superior to the naive "moar boosters!" philosophy that new KSP players typically start with.
I've been playing this game regularly for 3 years now. It has a vibrant modding community, and recently some of the more popular gameplay mods have made their way into the core game (mainly more realistic aerodynamics, resource mining, my favorite, "deadly reentry"). It's basically a SimCity game, but with rockets.
The one downside is that while it's a lot of fun at the beginning, it gets kind of monotonous at the end (if you can call it an end). Flying crew to and from Duna is hard. I've never done it. Even just sending a probe is hard to hit it.