Oolite Bulletins

Commander McLane wrote:

jacksy wrote:

October update is very interesting

That's a veritable understatement.

The data visualizer/editor is so stunningly beautiful, I almost cried when I saw it.

Pretty amazing stuff the guy is a genius

How is Limit Theory progressing? I don't have time to follow it, but I read somewhere that it's third-person view only - is that correct?

Very nicely I'd say

In October I promised to reach deep into that A.I. bag and pull up a winner. Only time will tell whether that's what's happened here, but I'm fairly certain it's the case. With an artificial intelligence that can already think on it's feet, make long-term plans, and understand the nuances of performing multiple actions at once, we're well on our way to the vision of a living LT. Granted, there's a lot of gameplay left to implement before we'll see the A.I. really taking advantage of this radiant universe.

But the content is secondary - you all know by now, the magic is in the algorithms.

Cody wrote:

I read somewhere that it's third-person view only - is that correct?

Don't think so , he just seems to use it a lot in his update videos

Redspear wrote:

Cody wrote:

I read somewhere that it's third-person view only - is that correct?

Don't think so , he just seems to use it a lot in his update videos

Even in the videos there's a lot of switching between third-person and first-person view, similar to if you alternate pressing F1 and V in Oolite.

It is correct, though, that there is no cockpit view intended to be in the release, no ship interiors, and no walking around your ship. Just like in Oolite, you (more or less) are your (current) ship. Which to me personally feels absolutely right, because it's what I'm used to from Oolite. I won't miss neither a fancy cockpit covering half of my screen (looking at you, E:D) nor boring, empty, blocky, unrealistically large ship interiors (looking at practically all space games with first-person perspective and walking-around-in-the-ship functionality I've ever seen in Youtube videos). For me, in this type of game, I want space, no, I want SPACE! In my opinion there's nothing to gain from looking at your ship from the inside.

I couldn't afford to back LT, though I followed the forum for a few months.

As for the cockpit in E: D - I'll get used to that, but I've got absolutely no interest in walking around.

Cody wrote:

I couldn't afford to back LT, though I followed the forum for a few months - Josh is very impressive.

As for the cockpit in E: D - I'll get used to that, but I've got absolutely no interest in walking around.

If Josh doesn't get a doctorate out of this project then something is very wrong with the education system.

As for the cockpit in E: D… it is surprisingly easy to get used to. You hardly notice it. What I don't like is the inertia effect.

<brushes more cobwebs away> Anyone following this project? Seems to be stalled since Josh's breakdown and recovery.

Every few months I try to catch up, seems like he is still working on it but spending less time talking.

for anyone who want some updates: http://forums.ltheory.com/viewtopic.php?f=11&t=5031

Yeah, the Cult of Josh has been reinvigorated.

Cody wrote: ↑Sat Feb 04, 2017 10:12 am

Yeah, the Cult of Josh has been reinvigorated.

You have something there, Cody. In two weeks, the link I posted above now has 13 pages of replies, with lots of supportive flagellation by the community (admittedly, a community being supportive is a nice thing in these times so I won't criticise further).

I'll continue lurking quietly on the LT forums, and I'll purchase a copy if/when it becomes available. If nothing else, Josh has provided more than enough entertainment in this journey to justify the cost.

Bugbear wrote:

... supportive flagellation...

<sniggers> What a delightful description.

I lurk on the LT forum a little, make an occasional nonsense post - but thankfully, I didn't invest in the 'game'.

.....and two hours later at page 7 , i suddenly ask myself "why are you reading this?" .
i learned two things ...
1) programming isnt easy anymore! last thing i wrote was in turbo pascal4 for the IBM xt...lol
2) Gazz ( one of the moderators) needs to stop mucking around on the LT forums and get back to work on 7 days to die...lol
3) what the hell is LT anyway?

Geez, I believe I could have spared Josh so much work! And I can't believe I was so right when I saw he was making his own scripting language and thought that it could be a rabbit hole for him. Because I'm interested in this kind of stuff, and I myself wrote and rewrote my own language, while looking around for languages that would be exactly like what I want.

Python was an obvious wrong choice. It's slow, it's complicated. Lua is obviously much better: it's fast, it's small, it has been adopted by dozens of games including big AAA games that deal with real-time graphics and networking. Quite a solid record, often praised by professional game developers. LuaJIT is even faster, but only supports an older version of Lua. The original author left, and it seems that the project is frozen. That means that adaptations to new platforms or CPU changes are compromised in the long term. Which is a bit worrying for a game that's not even finished.

IIRC his language looked like a Lisp with some syntactic sugar. This is a good choice, Lisp is among the simplest languages to parse, which means he could devote his efforts to optimisations.

To make an interpreted language consists in two steps (when you don't use JIT): parsing the language (that is understanding what the programmer wrote), and then executing those "commands" (the source code) in something that is like a virtual machine or a virtual processor. We do it that way because the alternative would be to parse and execute each command all the time, and parsing takes time. In this two steps approach the computer parses only once the script. Also the advantage of this virtual machine is that you are its maker, so you can design its instruction set and more generally how it works. It's like ordering to Intel a custom processor. So for instance, to draw a triangle can be a single instruction in your virtual machine design. Of course, once you've decided this you have to make a piece of program that actual does it, which results in the execution of many instructions on the real processor, and/or the GPU.

The drawback of doing that is that decoding the virtual instructions takes time. Not as much as interpreting directly the source code, but still a simple addition is typically is done in one cycle by your real processor, but the virtual instruction decoding can take a couple dozens of cycles. That's a 10X slowdown right away. The solution to this, or at least one way to mitigate it, is to design your virtual instruction set very carefully for what you really do: the graphics instructions are obvious for a virtual machine for a game, but typically what's more commonly executed are the more basic and simple instructions like arithmetics and equality tests, and those are the worst because you have this 1:10 ratio between decoding and executing. So you have to look at patterns in the code - like recurring sequences of instructions - in order to create a virtual instruction for it. For instance if your script does a lot of rescaling, you can introduce a virtual instruction that does a multiplication and a division. That way, you fuse two instructions into one and you save one instruction-decode: big win, that's almost a 2X speed up. Another example: the authors of the Godot game engine liked Lua, but thought that they needed direct support for 3D vector operations to make scripts fast enough. So they made a language similar to Lua but with the needed extra virtual instructions in the Lua virtual machine.

So unless he was doing something really naive like interpreting directly the source code, his language was probably salvageable. His virtual machine would probably become big in order to achieve performance (because you need a lot of specialized virtual instructions), but that's not really a big deal.