60 days left until my (subjectively) big reveal

“Mommy, I can’t sleep”, whines the little boy.
“Why, dear?”, asks mother in a warm voice, placing her protective hand over his forehead.
“Haxe won’t let me!”

It’s the truth. In the past 10 months, more and more since the 1st of May 2018 when I first got The Idea, I’ve felt increasingly…

I was tempted to mercilessly ignore the tl;dr section, but I won’t. Here it is:

tl;dr

A big thank you to everybody that has helped me around here with my Haxe struggles. Thanks to you I’ve come a long way from where I was a couple of months ago. You are all truly dedicated and I believe a small but healthy (culturally) community can produce amazing results. I plan to give something back :slight_smile:

EOTLDR.

I’m working on what I feel to be the most important project and idea I’ve had in my life (aged 36, coding since 14, writing literature since ~11). I don’t know what impact is going to have and it doesn’t really matter. What matters is:

  • I am absolutely, totally and madly in love with this and it made for some amazing moments in the past 10 months.
  • I chose to write it in Haxe and I am VERY happy for doing so (more on that below)
  • I plan to give something back to this community (and society in general)

And despite “teasing” a big reveal, I can already share a few things I haven’t yet done online (or offline). And that’s simply from a desire to thank for and explain why I’ve been in need for the precious time & help I’ve been given here:

  • It’s going to be open source
  • It’s a game logic engine
  • It’s a game
  • It’s going to be imperfect
  • It’s going to live

Regarding the “live” aspect, pun intended, I’d like to mention that I’m going to launch it via a live video stream and I plan to start a series of recordings about coding in Haxe. And despite knowing my project will have its imperfections, I feel a powerful, long-term commitment to see it become something beautiful (yes, don’t we all want the same thing from our craft? But sometimes saying it makes it more real).

Regarding imperfection and video streaming (and recording): not only do I wish to advertise and bring new people to Haxe, but I plan to do so by embarking on a patient quest to perfect my craft and my project, alongside those who wish to embark on an epic journey into creating a game logic engine.

So what’s a game logic engine according to my definition? It’s the thing few game engines successfully tackle because it’s so damn hard to find a way to accommodate vastly different game designs. So then we ended up with a ton of graphical engines but very little diversity in the realm of what powers a game’s story. There are various tools for game design which tackle this from the top using very high level tools (usually visual editors) that produce a poor and rather inflexible output.

I’m going for something that resembles a toolset for story-writing and game-design, but rather than going to it from a “visual designer” point of view, I’m approaching this from the ground up by building a highly extensible and moddable framework that gives game developers & designers a great degree of flexibility.

And this nicely brings me to Haxe. I’ve seen my share of frameworks and languages (Basic, Delphi, C#, AS3, Java, C++ to name the ones I’m most familiar with). Haxe is the first place where I feel that my creativity as an engineer can be fully rewarded, especially due to its creators’ giving us access to the Abstract Syntax Tree and secondly because the language is open source. So thanks for that!

Of course, this is not a one-man project. Nor do I intend to keep it that way. There are some modules which are particularly tricky, such as the computational part of getting, for example, a damage per second value out of something like a bunch of items interacting with the Passive Skill Tree in Path of Exile.

Use full screen / drag & drop, zoom to navigate the beast below :slight_smile:

There are people that actually managed to reverse engineer all of that, which is, in my ideal world, a good start for the logic-computational part of the engine:

And what’s that about a game? Evidently, I’m going to ship my engine with a sample game. And that’s the part that is actually the “reveal”.

Until the 1st of May, when 12 months will have passed since my mind began to spin increasingly faster towards that single point of PURPOSE, I will gift you this one more image from my collection of treasures from the spinternet’s web:

4 Likes

Suggestions:

Go Parallel ( Threads or at least real Concurrent ), GPU would be impressive.
If for various reasons you can’t do Parallel code,
Put in Comments about WHY some Design/Implementation approaches were used.
The WHAT, WHEN, WHERE, WHO, HOW questions can be answered by Reading code / Static Analysis / Dynamic Analysis / Running or using the Debugger.
The WHY is critical to help in the future to migrate to Parallel.
Have the Comments embedded with the Code.
OK for separate Docs but try to make sure that Comments in Code and Docs are close to Reality of the Code.
That seems to be the best way Lazy (cough) I mean “less focused on Documents” Software Developers seem to work.

Try to Architect / Design / Implement for Embarrassingly Parallel
Think about your project as if it was an Enterprise / Web massively scale able framework that has been scaled down to fit on a smart phone. Light weight Independent services with No or very little Coordination between them.
References: Amdahl’s Law. Gunther USL.
Applying the Universal Scalability Law to organisations | the morning paper

Data Oriented Design
Anyone putting in significant effort for a program should understand the basics of DOD.
You know there is about an order of magnitude difference in Time when iterating through a 2D array, row major vs column major? Directly relates to less use of CPU cache operations. Locality of Reference is Your Friend.

Parallel is throwing Hardware at the Problem
But you can’t really get a speedup with a lot of serial code.

DOD is using awareness of Hardware characteristics (mostly the CPU Cache) to avoid looking silly from a Hardware point of view.

A Last Piece of Advice:
Point of View is critically important.
Use Cases flow from walking a mile in a particular Point of View shoes.
From Use Cases a lot of mistakes that Developers make when trying to enable Users can be reduced or avoided.
And If You Can Gracefully Do Multiple Points Of View
well, welcome to the Universe :slight_smile:

1 Like

@RMax that’s one awesome post & reply. Thank you for putting so much effort into sharing all these tips & resources. I think that the Haxe ecosystem could really benefit from a man with your dedication and knowledge. I read your post slowly and carefully and found a lot of useful insights.

I completely agree with:

  • simple design but leaving plenty of room for going BIG.
  • data oriented design: you have no idea how good it is that you highlighted this. My game engine & project relies HEAVILY on structuring data, because it focuses not on the graphical engine but on the logic engine and story. I already had in mind to read a very comprehensive book on data structures but your comment just bumped the priority on that one
  • design for parallel / perhaps even GPU processing

Thanks for the link. Will read.

I’ve also been a product owner/manger for a while, so I completely understand what you want to say with Point of View.

…Logic engine …

Design By Contract
Most people who learn about Eiffel and/or Design by Contract miss the big picture.

The ideas of Pre Conditions, Invariants and Post Conditions are quite useful to help with Design activities. It really helps to declare what are good Inputs, Behavior and Outputs for any Class or Module or Feature.
BUT
The Big Picture is that those ideas can be productively applied to many other activities around both Software and Hardware projects.
I call the overall approach
Thinking by Contract
If you think about various processes in Nature or by Humans you may see that nearly every step can help refine the thinking and goals by using a Thinking by Contract style. So the ideas are more powerful and widely applicable than casual reading may indicate.

ProLog and/or Constraint Programming
What is really cool about Constraint Programming is that you can specify the Constraints before the ProLog engine or the Constraint solver dances through the solution space following forward and backward chains as part of the dance.
What would be REALLY COOL for your project is to allow other Programmers/Users to specify Constraints that meet their Goals.

I think there is already a Haxe Constraint library but I have not tried it.

My intent is to be Dangerous with Constraints later this year.

I love the way you say that you plan to be “Dangerous” about something :smiley:

I am bookmarking this post, like some of your previous ones. I am currently, as I mentioned in an earlier post, possessed by some sort of power that drives me almost like a slave. I need to be finished with this prototype until the 1st of May.

I also loved (and love) how you talk about dancing through something software. In this case, you say “dances through the solution space following forward and backward chains as part of the dance.” Are you also a writer? Your posts have literary beauty. Some other people might get cancer from your posts (kindly and warmly referring to something somebody said some days ago about a post of yours, which I found amusing and honest - and I’m a lover of brutal honesty), but I just love the way you dance your concepts :wink: