Skip to content

Monthly Update: 2018.03.31

Jump to bottom
George Singer edited this page Apr 1, 2018 · 1 revision

If you’re new to this list, or need a refresher of what Simula is about, see the links at the bottom of this email for an explanation of the idea. Simula is currently looking for feedback, contributors, and alpha testers. Email me back if you’re interested.

YC

Earlier this month we recieved the following email:

Subject: Y Combinator: Invitation to apply

Hi George,

Thank you for applying to Y Combinator last batch. You were in the top 10% of startups we saw - if you’ve made progress on your company since, you should have a strong application.

Of all the companies we accept, 40% of them have applied more than once. We find that the best teams don’t give up easily. These are the teams we love to see apply again.

We’d like to let you know that the deadline to apply for the next batch is 3/24. Y Combinator only runs twice a year, so if you’re interested in doing YC for your startup, now is the time to apply.

Apply here

Looking forward to seeing your application,

-YC

so I spent some time updating last summer’s application and re-applying to YC. You can see the updated application here.

Godot Bindings

On the engineering front: This month nearly 800 objects(!) in godot_headers/gdnative_api_struct.gen.h have been given bindings in SimulaVR/godot-haskell, thanks to David Kraeutmann’s code generation schemas (some functions involving dynamic memory allocation still need some work). This gets us a lot closer to integrating Godot into Simula.

Zac Slade’s Architectural Objections

Last month @Zac Slade presented some harsh feedback last month on Simula’s development process:

We have no cohesive architecture ATM and this is leading to hack on hack on hack. This has two negative effects, 1) it always seems like we are one hack away from things working well (it’s an illusion) and 2) the fundamentals don’t get taken care of leading to poor performance and difficulty onboarding new coders.

The current need as I see it is to build our own engine and to have a better story about our own rendering pipeline and input handling.

And regarding our Godot plan:

[Godot] cuts us off at the knees in building idiomatic Haskell code. It forces us to write, what I like to call, HasC++. There is no reason why we cannot build it ourselves. The issue is the constant time pressure rather than honesty about how big a project this really is.

And finally:

What’s been needed for a while, and I’m as much to blame as anyone in not doing this, is to create an architectural vision for the code. David has done yeoman’s work getting things going and basing the work on Christoph’s thesis. The translation to Haskell was very good.

What has been missing is crossing the rubicon to an idiomatic Haskell approach. This transition has been hampered by the amount of C bindings necessary to get something functional at all and how low quality SteamVR was at the outset. That has gotten much better, but we are still limited by old ways.

Response

This feedback is good, and if anybody on this mailing list has any thoughts on Zac’s concerns, LMK. The primary rejoinder, as I see it, is that it will take a significantly longer amount of time to build our own rendering engine than it will to piggy back off Godot. For example, this article recounts a “story behind a year-long attempt at creating a game engine from scratch” by an indie game company:

High overheads / development time – It took us over a year to create our game engine, and even then, it had only a fraction of the features available in an existing engine such as Unity, Unreal or CryEngine. Each time we wanted to add a new feature for a game, we had to create that feature from scratch. This meant determining where best to factor this into our stack. Once this new feature was finished, it was likely the other prototypes would need to be updated depending on how much rearranging had to be done. We found it took an unreasonable amount of time to get anything done.

On the other hand Godot has the potential to provide Simula with high-quality rendering, a full 3D physics/collision engine, a library of 3D assets, audio/animation, inputs, OpenVR connectivity, a GUI scene editor, and 500 developers servicing the engine. Here are some other considerations:

  1. Simula without Godot is still built on top of many imperative/non-functional libraries (wayland/weston, SteamVR/OpenVR, [OSVR], OpenGL/Vulkan) and so, to some extent, non-idiomatic Haskell is unavoidable in the short-term. In these situations, “HasC++” is still preferable to C++.
  2. The above notwithstanding, imperative bindings can be made more idiomatic over time.
  3. Godot gets us closer to a day-to-day usable system which can attract users/funding.
  4. Going non-Godot might take too long to pull off (project funding would run out, or the window of opportunity for VR on Linux could close).

If people have thoughts on this debate let me know. We shall proceed another month with Godot, perhaps at our peril, and sensitive to the very real possibility that Zac is again right.

Goals for April

This month we are plowing forward with our Godot project, and now that we have bindings mostly finished, we can focus on integrating the actual Simula logic into our new system. This will get us closer to actually being able to focus on VR Desktop UX, as opposed to all of this backend infrastructure.

Resources & Explanation of the Idea

Clone this wiki locally