> sorry for the wall of text, i did my best to explain.

No need to appologize, I definitely asked for it.

I'll get back to your original questions in a little bit, first I want to talk about your list of inspirations:

> Gource
> Minecraft
> scribblenauts unlimited object attribute editor

And your description of what you want to do:

> simulations of objects in an environment
> Physics
> experiment with familiar concepts, like gravity, wind, light, ect
> create abstract system with odd rules

What you want sounds fun, but complicated. If you _really_ want to do this, it will obviously be possible. It may take a lot of work, but from here out, I'm going to assume you'll be willing to put in a lot of work. Even with that assumption, I think the best advice anyone can give you is unrelated to any technology: Limit your scope.

I've started a significant number of projects, super excited about all the possibilities, and started writing everything for the general, most abstracted case. When I do this, I invariably get bogged down quickly. When I'm more focused on one small feature, things turn out better. You want something that is immediately fun, even if the scope is tiny.

You can see this in your inspirations as well. Minecraft started development on May 10th, 2009[1]. It was playable by May 16th 2009 (First officially numbered version). That seems like a ridiculously short development time, but note that inventory management (the ability to pick up and place blocks) wasn't added until August 4th 2009. It's clear that Minecraft started with the smallest kernel of something that would be playable, and slowly grew from there, accumulating things that make it more fun.

So, the best advice I can give you, is to find the tiniest kernel of your idea. What is the smallest, simplest part that could still be fun? Your goal should be to narrow your scope as much as possible and then make that.

The next piece of advice is going to relate more to specifically what you want to do, and the tools you'll need to do it, also though, narrowing your scope further. There are going to be two sides to the software you're trying to write. The first is the physics simulation aspect, and the second is the graphical display. You should decide whether you are more interested in simulating novel physics, or displaying whatever simulations you do. That is, to begin with, would you rather see ugly graphics and deep physics or simple physics and beautiful graphics (obviously, I'm using physics as a generic term for whatever rules-engine you want to work with initially). Ultimately, what you're most interested in should inform what sorts of technologies you pick up.

If you really want to see beautiful animations of simple rules, you're not going to have fun building physics simulations in FORTRAN. If you want to precisely model the behaviour of subatomic particles, you're not going to have much fun with processing.

This brings me to your concern:

> what can be done in one language may take two lines of code, but done in another the same task can take a thousand lines of code

I'm pretty sure you understand that this quote means that some environments are well tailored to a given domain. One line of Mathematica could do more than thousands of lines of assembler (in the extreme case). I think it's important to recognize, though, that if you're doing anything that's even remotely novel, you're going to be writing thousands of lines of code. So I would simply pick something that you find fun, to start.

Processing might be fun. It's built on top of Java, so there's a lot of room to integrate it into a larger application. Play around with some of the examples [2] [3] [4].

Box 2D is a pretty interesting physics engine for games [5]. It's a primarily C++ project, but has bindings to other languages as well.

Start small, keep learning and experimenting, keep writing code, good luck.

[1] http://www.minecraftwiki.net/wiki/Version_history/Classic#Pr...

[2] http://processing.org/learning/topics/flocking.html

[3] http://processing.org/learning/topics/smokeparticlesystem.ht...

[4] http://processing.org/learning/topics/follow3.html

[5] http://box2d.org/about/