Rocket/Space Game (Was "Rigid body rotations")

[robly18]

Nice! Good luck.

By the way, still using VB or did you decide to go with another language?

[A Random Player]

Nice! Good luck.

By the way, still using VB or did you decide to go with another language?

Still VB, I'm not good enough in any other language yet! :p

[robly18]

Nice! Good luck.

By the way, still using VB or did you decide to go with another language?

Still VB, I'm not good enough in any other language yet! :p

Well, if you wanna try learning C++ someday! From what I've heard and experienced, it's pretty darn lightning fast.

[testtubegames]

NECRO TIME!!

I love necro topics! Glad to hear you're still working on this one -- and excited to hear as you make progress. When I get around to thinking about orbital mechanics in this way again, I'll hit you up for your calculations. Nice that you smashed through the road block.

[A Random Player]

Update:
Elements working. Orbit drawing is still a bit finicky, bit it seems to be working fine right now, with Peri and Apo display. SOIs rudimentary, but working. I have a Kerbal-scale system working, with Kerbol, Kerbin, Mun, and Duna. I have one ship that doesn't do anything (controlled by manually changing velocities), which I just took to a (very inefficient) trip to Duna. (see below. I had to rendezvous with the planet!) The camera system's pretty good for now.
Warp, the goal of this, works! 1048576 (4^10) warp! A (Kerbin) year in seconds!
I'm working on getting the SOIs better (so you don't need to stop warp to enter/exit and can see paths through SOIs), close approach indicators, and starting ships in a while.

Edit: SOI checking is harder than I thought

[testtubegames]

Cool - glad to hear you're making progress. I'd love to see any screenshots if you have 'em.

[A Random Player]

After thinking about the project for several months (and realizing that somehow I lost more than a day's worth of code), I decided one day only Unity would allow me to make the game without having to recode everything from scratch (physics, rendering, etc). You know, don't reinvent the wheel?

On my first try I followed a tutorial but found it rather complicated (it didn't explain seemingly important things). On my second try several (~5) months later I told myself I'd just jump right in and do random stuff, and I got a basic Newtonian gravity simulation (hey, first non-boring thing I thought of to try) working - blocks and stuff attract to the Earth.

My problem right now is that I can't get a bunch of physics objects on the screen and running some scripts without lagging a lot (about 60 objects is about 10 fps, compared to hundreds of objects I expect to have), so could someone (*cough* Andy *cough*) give me some pointers on this concept? (Ex. How do GSim and Shocktopus do it, and am I missing something obvious?)
To clarify, I'm just cloning the objects right now, and each object has a script that does simple keyboard control and 1-body Newtonian gravity.
Commenting out the script I can get 300 FPS with one object, dropping to ~100 with tons (couldn't count, at least 70-80?).

[Squirrelocrat]

Hopefully those FPS problems are just from something simple like FindObjectOfType() style functions inside one of the Update()s. Or some other bit of code that could be run once but instead is being run every frame. Maybe keyboard/UI code that could be consolidated to one script so that a key press is checked for once a frame instead of a few hundred times a frame. Maybe an object is being created or Instantiated every frame?

Or it could be the physics itself. Maybe there's something that could have been computed once but is instead being calculated every frame.


I'm pretty new to Unity as well, and I know what you mean its all a bit confusing at first. It seems like Unity provides a lot of different tools to accomplish the same goals which is great from a creative standpoint but that also increases the learning curve. Oh and I looooove the new UI engine, you could probably make an entire game just using UI elements.

[A Random Player]

Hopefully those FPS problems are just from something simple like FindObjectOfType() style functions inside one of the Update()s. Or some other bit of code that could be run once but instead is being run every frame. Maybe keyboard/UI code that could be consolidated to one script so that a key press is checked for once a frame instead of a few hundred times a frame. Maybe an object is being created or Instantiated every frame?

Or it could be the physics itself. Maybe there's something that could have been computed once but is instead being calculated every frame.


I'm pretty new to Unity as well, and I know what you mean its all a bit confusing at first. It seems like Unity provides a lot of different tools to accomplish the same goals which is great from a creative standpoint but that also increases the learning curve. Oh and I looooove the new UI engine, you could probably make an entire game just using UI elements.

Hahaha, thanks so much, this is awesome.
I had a GameObject.Find("foo") in each Update(), which apparently is what caused the problem. Additionally, I had multiple Debug.Log()s per Update() as well. While it seems simple, if you think about it these functions would be quite processor-intensive, having to search through every single object a frame.
I can now get to about 500 PhysicsObject2Ds and still maintain 60 FPS (which I hope to keep the game around).

WOTA:
This page discusses the GameObject.Find function. Do something like this:

Code: Select all

	private GameObject theThing;
	void Start() {
		theThing = GameObject.Find("theThingPicture");
	}

	void Update() {
		Vector2 thePosition = theThing.transform.position;
	}

[testtubegames]

Squirrelocrat -- well troubleshooted.

I'll just note that I generally try to minimize using 'Find', even in the Start (not that it's bad to do, mind you!). I just end up making a public GameObject variable, and dragging the object in question into it. (Let me know if that doesn't make sense... reading it back to myself, it's a bit confusing.) This isn't necessary, mind you, but it does keep me from ever accidentally doing a lot of 'Find's or '.transform.GetChild' or anything like that.

But doing it once at the beginning is fine practice, too.