Would you like to see a KSP for the CE? |
Yes |
|
69% |
[ 47 ] |
No |
|
4% |
[ 3 ] |
Only if it was really good |
|
26% |
[ 18 ] |
|
Total Votes : 68 |
|
Calculator Space Program
I was thinking, we have a bunch of space games for the Ti-84 Plus CE but none of them really make me to keep them on my calculator. So while I was playing KSP I thought, "Hey, why not make a 2D version of this game for my calculator?" Unfortunately, the only way to get the FPS that I want for this game requires it to be a program written in C, and I know 0 C programing.
However, that didn't stop me from making a PowerPoint to layout most of my ideas.
Instructions for this PowerPoint:
Don't use your arrow keys on your keyboard to go to the next slide, I made this like a wire frame. If you click on an option like [Start] it will take you to the correct slide. Only use your arrow keys to get more info for that slide. Also, the five buttons on the bottom of most slides work. (NOTE: not every slide has more info (marked with an 'no more info popup'), nor does every button do something.) Sorry for any bugs that may occur, I had to hand draw all the pictures and make this PowerPoint in only two days.
Anyways, feel free to leave any constructive feedback, or let me know if you know any rocket science!
Finally, here is the
link to this PowerPoint (it may run better if you download it)
Thank you for your time,
Go make a paradox,
Have a good day.
This is an ambitious but interesting project idea. Nailing the physics will be the most important aspect naturally, which would require some research to achieve at a good speed.
Perhaps C would be the most appropriate language for this platform which would enable you to prototype the math. Some vector style graphics might also be of advantage to this as well?
I'm sure this will generate some good interest among the Cemetech community, many of which will be more than happy to help flesh out the calcs etc.
I like the idea, it would just have to be REALLY good! (No pressure!) ;P
tr1p1ea wrote:
This is an ambitious but interesting project idea. Nailing the physics will be the most important aspect naturally, which would require some research to achieve at a good speed.
Perhaps C would be the most appropriate language for this platform which would enable you to prototype the math. Some vector style graphics might also be of advantage to this as well?
I'm sure this will generate some good interest among the Cemetech community, many of which will be more than happy to help flesh out the calcs etc.
Yeah, I am hoping that I can figure out how to do some great physics, I'll probably poke around NASA's website for the equations. Unfortunately I am still trying to learn Python and C seem like a big step up from it.
I also updated the PowerPoint so now if there is no more info on that slide, a text box will pop up that says 'no more info'. Much easier for you guys! I also forgot about Thrust control! silly me, so I fixed that and added some more info to that slide.
Not to be a downer but...
This is an incredibly ambitious project, there are sooo many things that work together to make KSP an enjoyable experience, It would take a ton of code just to get it to a playable stage. That's without counting the amount of pixel art required, for just about everything... Did you consider landing on planets? How would that work? I am tempted to say "Only if it was really good".
mr womp womp wrote:
Not to be a downer but...
This is an incredibly ambitious project, there are sooo many things that work together to make KSP an enjoyable experience, It would take a ton of code just to get it to a playable stage. That's without counting the amount of pixel art required, for just about everything... Did you consider landing on planets? How would that work? I am tempted to say "Only if it was really good".
I was wondering how I would I would do the planets, maybe since there are only three planets, a moon, and a sun, there could be a couple of app vars (or however maps are stored) for each of the celestial bodys? Then when you fly near that body the correct app var would load. The texturing doesn't need to be complex. Sorry if I am going at this completely wrong, I don't understand how everything works in assembly.
You surely would have to keep things simplified. One way is by not loading the universe entirely and refinid it when getting closer (Simplify planets as circles, for example), another way would be loading the map by areas. With realistic orbital mechanics, that poses a challenge, as these said areas need to be dynamic.
Well, you don't need an AppVar for each of the planets, since they're all hardcoded into the game along with the sprites and orbital parameters. The only things that are worth saving are ships, their orbital parameters, and the game time which can be used to determine the mean anomaly and current position of celestial bodies.
The first version of KSP really only had 6 parts. You had the cockpit, the 1 m fuel tank, the 2 rocket engines (one with thrust vectoring and the other one without), the wing, and SAS. That was it, and that's all you really need. Then maybe later you can add RCS and overheating.
First, you want to define a root part, which is the cockpit (or wherever crew is held); then you can build off of it. To make things simpler, you don't even have to make snapping; just make sure all parts of the rocket are connected to the root part.
Then you have to deal with rotation. Rotation isn't a particularly difficult concept to grasp; the problem is rotating the sprite itself. There are many algorithms you can use for rotation, but I recommend you use the simplest, fastest one.
Then you have to deal with physics, but specifically part-to-part collisions. If you can do this right, then it'll only be a slight performance hit.
You're probably going to end up having to mix assembly with C. It's probably going to have to be ASM for the physics and algorithms and C for the graphics.
Thanks oldmud0! When I finally learn how to do assembly and C I'll definitely use your advice. I'll probably just have the VAB available for use on v.1, Like KSP v.1 there will probably only be the parts you see on the PowerPoint.
This could probably be made to run at nice FPS if written in C/ASM. Maybe instead of using a building system like KSP uses, you have a tiled building system? EG like 2D minecraft where each part will be 1*1 or 2*1 etc.
Edit:
I actually had an idea for a space based CE game, not necessarily a KSP port though, maybe i'll try working on it sometime
c4ooo wrote:
This could probably be made to run at nice FPS if written in C/ASM. Maybe instead of using a building system like KSP uses, you have a tiled building system? EG like 2D minecraft where each part will be 1*1 or 2*1 etc.
Edit:
I actually had an idea for a space based CE game, not necessarily a KSP port though, maybe i'll try working on it sometime
That's a good idea, the tiled building system, but where did you learn [ez-80] assembly? I looked around Cemetech but I only found the incomplete tutorial. I'd like to see your space game when you release it.
You may want to see the game "Simple Rockets" for Android.
Though it costs a bit ($3 or so, I think) and as much as I have seen from it, it is totally not worth the money, it is still a good starting point and pool of ideas.
Again, you'd either have to buy it or see it on YouTube, then.
Here's an idea: The rocket isn't rendered during flight, but instead represented with an icon. Every so often, the game recalculates center of mass, center of thrust, and other stuff and uses that to calculate physics stuff.
Physics Question though: When an object is in free fall (orbit) around a planet, gravity is always acting on it. So what force keeps it from speeding up towards or around the planet?
c4ooo wrote:
Here's an idea: The rocket isn't rendered during flight, but instead represented with an icon. Every so often, the game recalculates center of mass, center of thrust, and other stuff and uses that to calculate physics stuff.
Physics Question though: When an object is in free fall (orbit) around a planet, gravity is always acting on it. So what force keeps it from speeding up towards or around the planet?
As you might know, Potential energy and Kinetic Energy are at play here. Let's have a look at the formulas for these and it will become incredibly obvious.
EPot=mGh
EMec=1/2mV^2
EMec+EPot=C
Where m is mass, G is Gravity, h is height from ground, and V is velocity, and C is a constant.
When you're in regular freefall (like the hammer and feather thing on the moon for example), then you are directly converting potential energy to kinetic energy. This is because h is decreasing, which means that potential energy is decreasing as well. Since EPot+EMec=*a constant*, then EMec must increase. Indeed it does, since velocity increases. However, when in a circular orbit, the h does not change, so no energy is converted to kinetic energy and therefore, V does not change either. This is also why when you are in an elliptic orbit, your velocity is biggest at perigee and smallest at apogee (because those are the two extremes as far as h relative to the center of mass is concerned)
c4ooo wrote:
Here's an idea: The rocket isn't rendered during flight, but instead represented with an icon. Every so often, the game recalculates center of mass, center of thrust, and other stuff and uses that to calculate physics stuff.
I would suggest precalculating the changing CoM as a function of fuel used versus CoM and using this. With minor adjustments needed depending on various factors.
c4ooo wrote:
Physics Question though: When an object is in free fall (orbit) around a planet, gravity is always acting on it. So what force keeps it from speeding up towards or around the planet?
mr womp womp explained it quite well, but it is hard to grasp. Some visualizations:
Imagine this: It is moving literally so fast that it misses the ground.
Another visualization:
Imagine you throw a ball. Usually we approximate this with a parabola, meaning a flat ground. But now imagine you do this on the planet of the little prince. Of course the ball would not simply fall to the ground in a parabola, as there would be no ground below it!
But what happens to the ball? The curvature of its fall makes it fully circle the planet! And if there is no atmosphere and thus nothing to slow the ball down, it will not loose momentum and stay in orbit.
Now the same thing with a normal planet... Imagine you throw a ball (no atmosphere for simplicity). The ball flies approximately in a parabolic trajectory and hits the ground. Now you throw it farther every time, a hundred miles, a quarter way around the earth. You can see where this goes.
When you finally throw it hard enough so that it goes around the earth (This would be about 8 km/s, I don't think you could do that ), the ball is in orbit!
But like. If i have a vector representing the X/Y direction of the rocket (in 2D space). And if i add to it a vector representing gravity (pointing towards the planet, then it will all just work?
Indeed. At a certain speed, the planet's gravity is not enough to make the rocket crash, but rather curve the trajectory into a circle or ellipse that misses the surface and atmosphere. This is an orbit.
c4ooo wrote:
But like. If i have a vector representing the X/Y direction of the rocket (in 2D space). And if i add to it a vector representing gravity (pointing towards the planet, then it will all just work?
Yep, a good way to think of it is by imagining that you have a rock attached to a string. When you spin the rock around faster and faster, you will feel the string pull harder and harder. This is because it requires an increasing "gravity" vector to have the same effect on the increasing velocity vector. If you want to see this in action in KSP, simply get in a circular 100 km orbit around Gilly, then get in a circular 100km orbit around Eve. You will see that you must be travelling MUCH faster around Eve than around Gilly to get the same orbit, because Eve's gravity vector is much bigger. In the rock and string analogy, this would be the equivalent of saying "if you are pulling hard on the string, you must be spinning it fast, and if you are not pulling very hard, then you must be spinning it slowly." In an orbit, you have the gravity vector pointing straight down, and the inertia vector pointing 90° from the gravity vector. When you add them together, you get a resulting vector which is pointing in between the two. if you recalculate it continuously, the resulting vector becomes the orbital trajectory. Here is an image of the vectors.
This is how all motion works by the way, you just add up all the forces acting on an object, and then you can find out where it will go and how fast it will move, its the first thing taught in college level physics.
mr womp womp wrote:
[...] its the first thing taught in college level physics.
Hehe.
I am in tenth grade and we just got taught that. Don't ask me how the hell that works, but in Germany the stuff is totally mixed up in order.