The path from FlashPunk to HaxePunk to Heaps...Punk?

#1

the year is 2022 and HaxeFlixel is still alive?? lol.

coming from those lovely little first game engines (HaxePunk, Love2d, etc.) and going into this, i feel there’s a layer missing… you know, the very high-level newbie layer with an entity system, scene, world, classes for input ‘n output, and updates for them all, and disposal of them all too!

now, checking the haxelib, it seems at some point in space and time people have naturally began to create this layer, only to abandoned it shortly after ;(

as a person with fond memories of the minimal HaxePunk, i might have to start simple, with terryheaps

…but i wonder, is there some popular one i’m missing? i know deepnight’s, but that one seems a bit more like his own personal thing…

given that this is made by the man himself: the man who made the language(!!), surely this game engine is the way forward… (and away from OpenFL)

Or, am i just viewing all this wrong? Maybe it’s all very simple use of hxd and h2d classes? I’ll spend try to spend this week on it…

just from my quick glance at it tho, especially the samples, i feel that it’s more like an input/output library (hence the .io?), more akin to openFrameworks, Processing, or even XNA/MonoGame etc., in which you get the init, update, basic game loop, but the rest is up to you. …is that right?

orrrr maybe i’ve been duped into thinking in a very bad inheritance / object-oriented box, and i should instead learn to step out of that box, and throw all of the game code into one giant main file. :stuck_out_tongue:

1 Like
#2

oookay, my bad y’all, i’m starting to see it all now…

i guess when i saw the samples, i didn’t really… learn much?… i just saw how individual bits work (which is still really nice tho!)… It wasn’t until i sat down and read through the main classes (app, scene, object) that i grasped the bigger picture. Maybe i just needed a simpler game jam game to look at, to very quickly learn by example.

but yeah, this. is. effing. amazing. I’m doing this from an ancient iPad, and everything about it is nuts. The compiler builds super fast on my shit $5 server, poops it out the .js build onto the http web-server, and even tells me not just the line of my error, but the exact characters in the line? holy moly… and the Flash-like drawing API? and built-in collision? Whaaaatt?? This is unreal.

so, forget the HeapsPunk idea, but maybe there’s a place i can contribute some simple game examples? For the uninitiated…

1 Like
#3

Hi @Rahil627
I come from the old Game Maker (6, 8.1, then later tried GMS2 and finally some Godot). So don’t know much about how HaxePunk was working out. Since 2020 I’m diving into Heaps/Haxe and then by that actually programming/SE itself. So I know for a newbie Heaps is just “shattered”. It’s really scattered across the Heaps site/ this forum, the discord app/channel and many git sites and there’s no official overview (e.g. there’s one for Haxe by dvergar) and really scattered tutorials (e.g. official samples, github samples and “documentation” and Yanris FAQ and Deepnight’s tutorials). It’s just really “wild open source” style and everyone glues it together their own way (e.g. by an on-top “engine” or software architecture like EC, ECS etc. or by Terryheaps, Heeps, GameBase, AveNyrh, Jefvel etc. etc. there I was really lost when I started).

about new ideas

So it’s up to us to let it grow and form it’s future (or it’s in the end also Mr. Cannasse’s “green light”, idk actually?) :slight_smile: .

Compared to other engines (and like you mentioned) there “is a layer missing… the very high-level newbie layer” and the samples available usually show how to deal with something in the API and don’t show (small) games… I like the idea of a place to “contribute some simple game examples” (atm most games are probably on jam sites like ldjam.com or on itch.io …)

I would really like to improve the tutorials section (“documentation”), but haven’t found the time yet… But it took me really a while to get the concepts and to just find everything.

entity systems & update/game loop

Heaps itself leaves it up to you to build the way your game is updated and as Haxe is multi-paradigm there are many routes to choose from. Here inheritance and object-oriented is just an option for the way you organize your “game entities/game pieces/game objects” (that’s why there’s no prebuilt entity system etc.). And for instance stuffing all code in just one giant file is what I recently did for ECS experimentation and it worked really well.

And yes IO is just by calling e.g.:
if( hxd.Key.isPressed( hxd.Key.SPACE ) ){ /*then shoot at enemy*/ }
somewhere in your update function (see here). Not sure what you mean by “disposal” but IIRC there’s a garbage collector running just dumping dead references (in Haxe itselft, or maybe only in HashLink… hm…I’ll look that up…).

1 Like
#4

Hey @Rahil627! I see you already figured out quite a bit on what HeapsIO is, let me chip in a few bits more, for the newcomers that may come across here in search for those initial answers about Heaps.

I’m not a HeapsIO expert by any means, just started recently working with it more and basically moving from Lime to Heaps.

Heaps was made for games that Shiro Games is making and is released as an open source, but without the complete game engine(s) they used for their games.

It is not, what most of us would probably consider, an “actual” game engine, it sits somewhere between low-level graphics programming stuff (i.e. OpenGL/DirectX API) and a fully featured game engine (i.e. one that is focused on and provides you all the tools to easily build platformer games), but it’s closer to the game engine than it is to that low-level API calls.

So, it provides you with solutions and tools to build 2D/3D games/apps, but it doesn’t provide the actual game engine. I.e. if you are building isometric game, Heaps provides you with tools to load and work with tiled textures, it is up to you to implement the actual game engine logic for tiled maps (specific to your game) on top of that. It also provides you, for example, with tools to implement UI layouts (the Flow, among others) and to seamlessly handle mouse/keyboard interactions, but it is up to you to implement an actual button. This gives me a freedom to implement whatever kind of wonky UI I can think of, but it comes at a price that I have to implement the final bits and pieces (and logic) for the UI.

And this level of freedom was one of the main reasons I went with Heaps. It does come with the cost of having to make your own level of engine before you actually start working on the game/app you’re making, but, for me, that’s the whole point.

I made a fair number of things with UE4 and few with Unity, and they are awesome and great tools, and while providing a ton of features so we can focus on working on the actual game, each of them also comes with their own philosophy on how one should program and build their code. And it proved to be a lot of work, at least for my use case(s), when I wanted to create some stuff that these tools were not designed to do in the first place. So, for my crazy apps, Heaps. Yay!

In the end, all of this doesn’t mean we have to do things from scratch, because community: there is already a fair bit of examples and finished bits (that may or may not fit to what you want to make) out there, as @AlienBuchner noted.

Hope this helps to clarify things a bit more,
Cheers!

1 Like
#5

@AlienBuchner,
wowwww, before i even read and properly reply, thank you both for such great replies… this is amazing! :o

and YESSSS YES YES to everything Alien felt, of being a bit lost at first, due to info being rather all over the place. I was just looking at a 4 year old Youtube video by Nicholas presenting the engine to a live audience lol… :woman_facepalming: It’s actually the best intro to heaps that i know of.

i’m actually uncertain if if it’s my own problem though: my own inability to make something truly from scratch with just libraries. You know, like a real programmer? :confused: I think i personally just rely moreso on examples to get me started, you know… it’s some kind of gestalts inner brain magic that works for me. I bet good programmers can just make a game without any sort of tutorial, like just straight-up DIY with SDL in C, lol. Yet, on the other side, i think many kinds of people, for us noobs especially, do truly quickly learn by way of examples.

i glanced through a few libs that people made (i’ll spend tonight studying through those links you provided tonight; thanks), mostly those game jam people (terry ‘n deepnight), but i didn’t feel that was the right way to go about it either, because it felt like i was reading yet another layer, often times an unnecessary layer given how simple Heaps actually is (i just had to read the code…). For example, terry has a very very good example of a tower defense game on his github which makes incredible use of the Graphics drawing stuff, drawing lasers just like i want, but, it also has like his own layer, perhaps an entire engine (!!! haxegon?), on top of that (just as you said, ECS: objects for Entity, World, etc.)… sooo mehhhh? It was honestly quite strange to me that he (and perhaps those other people you mentioned) made another layer on top like that… I mean, why not use the core system Heaps provides (Scene, Object.addChild / parent, etc.)… Or maybe Heaps just didn’t have it at that time! Or maybe he just ported his games, and therefore his engine from Flash. Who knows… But the way to go surely are examples that use the core libs.

Yeah, I LOVE that it’s just a lean, minimal, game engine—FlashPunk was the minimalist younger sibling of Flixel—, and that leanness enables them to be much more flexible, more powerful, making one feel like one can make anything, similar to how “creative frameworks” do… yet, it seemed to me that Heaps kind of does provide this Flash-like parent-child “screen tree” design framework. No? I mean, i guess it’s always optional to not use it… LOL. Terry’s tower defense game, again just as an example, was interesting, because he straight-up made his own Object class: named Entity, and it didn’t inherit nor composite Heaps’s own Object class nor Drawable nor Graphics or anything really. He only used the Graphics class to draw stuff with; that’s it. It seemed totally separate from the core lib’s design, just by my quick glance tho…

I mean people in the Flash days ditched the entire design ‘n drawing stuff and created an entire bitmap-based ECS because it was truly inefficient and Adobe wasn’t open-source… But i don’t think that’s the case here…??

Anyway, I’m personally going to stick to what Heaps offers: App.s2d/s3d (Scene), App.ChangeScene (or whatever), Object, Drawable extends Object, Object.getBounds for basic collision ‘n col folder for more kind, the default scene tree stuff: addChild, Object.new(parent), and i think i even saw layers somewhere??.. I just trust in Nicholas ‘n the Haxe crew. He’s got that Jon Blow “i’m gonna make EVERYTHING, from scratch(!!), and do it the right way” vibe, lol. I don’t doubt the people who wrote the compiler AND the language the engine itself uses. This engine has to be great, it’s just that it’s lacking that accessibility, as you say. And those kinds of people definitely don’t have time and shouldn’t even spend time on things like this. They should be working with Elon and getting paid 200k, but thank god they love games instead lol. :slight_smile: :slight_smile: That’s truly a blessing…

i’ll read ‘n reply to zagortenej later. :stuck_out_tongue: sorry for such a long-winded reply.

1 Like
#6

@zagortenej

ahhhh okay, interesting interesting…

yeah, i feel you on the freedom part. I personally never used Unity precisely because it just seemed an overkill for the things i wanted to do: namely, 2D… i mean, before it natively had 2d, people hacked it, and it was ugly. Godot was far compelling, but… I dunno… Even the idea of being tied to a “scene editor” feels like a stab at freedom ‘n power. I dunno how to express it, but there was just something special about making Flash games with just a decent IDE (FlashDevelop). It was a heavenly feeling. :kissing_heart: And I truly feel Heaps might just have that indescribable feeling too. :open_mouth: :open_mouth:

at first, as in my first few days, i thought it was just an IO framework too, not a game engine, but now, maybe just 2-3 more days later, i started to see an entire game engine in there, complete, not just raw input/output, but collisions, “scene tree”, “scenes” itself (App, Scene), and even then, the input/output are super super duper high-level, often one-line of code, no need to touch renderer stuff (for 2d). Anything more would be too specific, too constraining. I think it’s close to that perfect balance, for me.

I think perhaps because of this, being on the leaner side of big game engines, and honestly being more tied to linux ways of doing, it’s fate has been less famed… yet, i think it’s the right way.,. It’s just so puzzling that this framework isn’t like the most popular among more programmer-oriented game-makers… But then again, yeah, it has all that nme, openfl, lime, kha, flow, hella confusing past tied to it. :confused: yeah… hahah, sucks. Maybe it’s tooo much freedom that’s the problem, lol, and so people end up making their own engines, instead of working together on just one.

i now see that there’s no need for HeapsPunk. Heaps, i feel, kinda already is just that: all that i ever wanted in a game engine. :slight_smile: It’s just hiding in the library… somewhere. lol.

*update: i went through the links that Alien mentioned and lol: that “documentation” is indeed spartan!.. Yanrish’s FAQ was pretty mean in a funny way about this whole lack of tutorials situation… In it, one of the questions brought up something that i found interesting too: that the Object doesn’t have an update function. I really dig it… just maybe… my old ways of thinking was surprised when i was searching for it in the Object’s structure. It makes sense tho!

1 Like
#7

update: not on the actual samples page of the heaps website (strange…), but on the documentation page, tacked on the very end of the docs side navigation bar, there is indeed a “full game samples” page that i had missed which includes 3 game jam games by Nicholas…, and links to previously mentioned deepnight’s stuff, and yanrishatum’s game jam games.

they’re… uhhh… they’re definitely made by someone who knows the engine really really well… lol. I mean, they are good because they don’t tack on that extra abstraction layer (as mentioned previously), but…, mannnn, those took some serious skill… they might just damage one’s confidence,… loll.

#8

from a very old post, i found Beeblerox’s Simplest Heaps Examples, and i had to emphasize the simplest. Now, they start out stupid simple, as in two lines of code, but, the later examples, particularly Console, Layers, and Flow are all really nice. It’s really a nice quick read, and the simple to more complex ordering makes it rather educational. Nice! Heck, I didn’t even know there was a console(!), and i direly needed it! :open_mouth:

It’s still just examples of features, not games… but still quite nice.

#9

I know right? These games are really programmed. Maybe their later games (ld40+ld47) are easier to understand, however it still just takes a programmer to really get and learn from the code or just at least some experience in “having made a game that way” without IDE (setting the game all up by yourself). So with an gamedev background only (like only some “high-end” game engine with IDE like Unity, Godot etc.) it’s normal to have a hard time grasping these sample games.
(I would like to contribute to a simpler games section on Heaps… once I would take the time for it :sweat_smile:)

1 Like
#10

Yes, totally. The good thing about Beeblerox’s samples is they rely on a very simple level, like really only the code required just to demonstrate the topic. But actually most github Heaps samples are too (maybe some rely on some resource in one res folder or derive from SampleApp.hx)…

#11

Actually, everyone learns that way. I mean like +50% of programmers, maybe like +90%. You/They/We just have to see how it’s done.

Layers are actually the “ancestor” of (extended by) Scene. (And the Camera, part of Scene, can then decide which ones to draw how.) The tutorial (“documentation”) could really need an update (took me a while to find/get all this stuff together)…

And maybe one thing that actually explains a lot here and seems only to be mentioned once
(edit: twice, but rather hidden) in all the materials: “Heaps is a cross platform graphics engine.”
That’s what it’s for. All engine stuff’s still up to you. Heaps mainly provides API for not setting a game engine’s visual aspect yourself (or so I think…and cross-platform of course)

1 Like
#12

nick’s ld40 is a really, really good example—nice find!. And i now already feel i made the mistake of using and tackling Heaps own Object/Drawable/Graphics classes, instead of just making my own super-simple “entity” class/struct for general game objects, and maintaining them in an array… I mean, the only time i remember seeing Object used, it was used as a layer: a layer of entities, not for a single entity.

now, yanrishatum’s ld47 is RIDICULOUS. w. t. f. i mean, howwwww??? Was that really done over a weekend?? If so, i have no chance. :face_with_head_bandage:

ahh yeah!, that’s where i saw layers. I remembered it was somewhere surprising !.. Maybe it’s just a different conception from the layers i was thinkin’: a layer of graphical entities. I’ll look into it tonight.

Huh… You think so? You think it’s just a graphics engine? I thought and still think of it as a complete game engine, just leaner (yet still extremely mean :muscle:), and oriented around how GPUs work, instead of the past CPU-heavy Flash days. That’s a… very very interesting take tho… hmmm :thinking: :thinking: …maybe there isn’t much difference between the two anyway…

yeah, maybe i’ll try Godot one weekend and see how that feels in comparison… but in the end, i think it’s better to stick to Heaps, and just get better at making games at this level—not exactly from scratch-scratch—C language stands for crying :sob:—, but close enough to where it will never constrain or hinder design. It hits that goldilocks zone for me… As seen in those LD game jam games, it’s clearly just practice, lots and lots of practice. :sob: tough. :musical_note: Life for a game-maker shouldn’t be so hard. :musical_note: … :frowning:

#13

I just didn’t enjoy working with Godot, GMStudio and Unity. I decided it should feel good to work with your game engine or toolkit. I felt like it should be possible somehow to really program/software-engineer a game from scratch but with a smart baseline to start from. Still there are many routes to choose from (C++, Java, C# etc.), and engines “en masse” (!) and really strong ECS-frameworks (e.g. ENTT) you just have to find them (which takes time)

But still today I tell myself, “okay maybe Heaps is just too difficult for me” and I check Godot for recent updates, because they’re both MIT licensed (also e.g. GDevelop, which seems interesting too). However, I kind of enjoy the challenging (often times really killing me) software-engineering/software-architecturing part of it. This is what lets you decide really how you set up your game entities and everything.

And that’s why to the public game engine seems misleading, though technically correct. Ppl here therefore rather call it graphics engine, framework or low-level flexible engine to clearify it really differs some way from Unity and others

1 Like
#14

my god, i looked at the ENTT stuff and :nauseated_face: :face_vomiting: :face_vomiting:. That whole stb-header-file-only-modern-C++ stuff looks like a deep deep rabit-hole for programmers—legit programmers.

However, I kind of enjoy the challenging (often times really killing me) software-engineering/software-architecturing part of it.

I’m on the game-design side, so i could never find happiness in making an entity system. I’d rather stare at a wall !, lol. I absolutely rely on the game engine!

But still today I tell myself, “okay maybe Heaps is just too difficult for me” and I check Godot for recent updates,

well, that’s a relief. :relaxed:

Hmm, i guess only time will tell how different Heaps really is from Flash/HaxePunk. I can’t even explain why Punk ‘n Flixel were (are?) so much more accessible. Heaps truly has everything… it’s just… a bit harder to comprehend, and jump into… I just hope I don’t have to re-create an entity system (as you say) or anything like that… which is… what everyone here has already seem to done (deepnight, terry, etc.)… :confused:

at the moment, i just extended Graphics class to be used as my normal Sprite/Entity class, feel wrong about it, and even kinda dirty about it, but… eff it. I just want to maaaakeeee :sob:

#15

For some part you have to do that, but it can be really simple. For instance iterating through a list/an Array of a class that represents your game objects/entities and calling their update functions. And your entities probably need a public var sprite : h2d.Object (when using 2D at least). This class as far as I recall was named “h2d.Sprite” before it finally became the “root” or “placeholder” for all visual 2D things Heaps can render.

However, some programming step will be there, at least for now. Maybe one day one could create a very basic entity system for beginners, experimenting and just game jams.

#16

huh, that’s precisely the root of one of my main confusions…

I thought Object/Drawable/Graphics is an entity. So, instead of putting it inside another “entity” class (composite?) that i make, i chose to extend/inherit it… I thought I could just use Scene’s functions that already does the work of iterating ‘n finding objects, and Objects functions that already does the work of creating a bonding box for basic collisions.

…but now thinking about it some more…, maybe Object is just a component, particularly the transform component, and Drawable the transform + render components, Graphics the transform + render + vector drawing toolkit(?lol) component, even Interactive the transform + input (mouse/touch?) component. :thinking:

hmmmm. Maybe i did go at this completely wrong already… It just seemed to me that the entity system already exists within Scene/Object. They already have so many entity system like functions…

yeahhhh, i know i’ll def have to remake what i already have :sob: lol

edit: …i think i’ll do just that, re-write it using composition design, using ld40 as a model example. It’ll save my autocomplete from working so hard. :stuck_out_tongue: … Scene might extend Layers, but in ld40, Layers is added to Scene :thinking: :thinking:

#17

okay, just about done with my session here… this is what i’ve got thus far. Beware of a ton of comments as i haven’t programmed in a decade and am learning all of these things at once: cli, linux, vim, haxe, and ‘cause i tend to get stuck in programming design choice dilemmas :frowning:. This is why i much prefer to leave this stuff to the experts… Choices are so hard for me. :sob:

For anyone that stumbles upon this in the future, my notes on the structure of the main classes in Heaps are in to-heaps.txt. With so many public functions, and no way to tell which ones are meant to be used internally (maybe @dox hide…) and which ones are meant to be edited, it’s quite the beast to tackle.

As one could tell by this thread, it took about a week to get a general understanding of things… Much much thanks to @AlienBuchner :pray: :pray: for his/her/etc. (? lol, etc. might be offensive… sry) communication, and even @zagortenej, who’s post now as i re-read, i now much better understand, particularly, where Heaps lies in the spectrum of game engines and io frameworks.

I ended up with just two classes: a global class HP (ancestor of FP/HXP in Flash/HaxePunk), and PunkApp, simply needed to initialize that global class. Nothing—no actual data—was added, save a Console when in debug; It’s just a bunch of pointers/references (i think?). The rest is kinda a “base”/“bare-bones” /“skeleton” code, all optional, so that again, nothing is actually added to Heaps.

I personally found nicholas’s ld40 as the best example of ~”how-to-use Heaps to make a game”. Just from a quick glance, I think jefvel’s gamebase looks like something that i would make, closest to my own style. TerryCavanagh’s terryheaps has a primitive beauty to it :japanese_ogre:. And I think if I had just started with deepnight’s gamebase, i wouldn’t have had to gone through all ‘uh this mess. :stuck_out_tongue: Thanks again to @AlienBuchner for mentioning these. (ld40 and deepnight’s gamebase are actually in the docs, only jefvel’s isn’t…)

I think those “gamebases” were the thing that i felt was missing: the missing foundation. With them, you can jump in and make stuff, day 1. Without them, welllll, it’s been an interesting week of reading and re-reading code??.. That’s what i believe constrains the accessibility of Heaps, compared to say… Punk ‘n Flixel. That was the missing link, in my eyes at least… From Punk, i think only two classes are missing: entity and world(?). Punk’s world is now Layers, which is optional to implement yourself (simple games might not need it), and entity, which is… well, completely optional(!!). (ld40 and both gamebases all use layers and create their own entity class)

From the maker of Heaps point of view, i can see it being optional; The main class is App, not Game. You can make any sort of i/o new media art, “creative” app, digital toy, whatever cool thing with it (dreams of making apps with an awesome game engine :slight_smile: )… but is there really no way to come to a consensus and provide a modular, optional entity framework?

I think I get it…: simple games don’t need one at all, and more complex ones need more complex frameworks… But surely there’s some common middle-ground here we can all agree on? We don’t all need to re-invent this wheel… We don’t all need our own game-base… do we?

Anyway, that’s how i felt after about a week… Now that the hard part’s over, I feel pretty rad :raccoon:. I’ll soon have my own super bare-minimalistic… tool-box: whether it’s just “barebones” code, “helper classes”, static extensions, or an outright “framework”, whatever. And, with each thing I make, hopefully i’ll just get better at making that particular layer, precisely tailored to it’s own needs, without the excesses that come from general one-for-all frameworks (evil eye to Unity…), and without the shackles ‘n constraints of them too.

…I think the true source of the problem is me: I’m a lazy person; I don’t want to do the work. When Fez ‘n MonoGame were out, I thought, yeahhhhh!!! C# and code-based game-making!! yeahhhh!—And then I quickly realized noooooo!!, it doesn’t come with anything!?!? Whaaaat!? You had to like actually draw triangles / vertices in OpenGL just to do something like lineTo (maybe slightly exaggerated, lol)… Compared to that this little game layer, is A okay. :slight_smile: …maybe even liberating! :dancer: …the Haxe world seems full of liberations like this. <3 The punk is strong in this one… <3<3

#18

I think I really get the point here now when reading through your to-heaps file, what you made it for and then having a peek back at the flixel docs. There’s just a gap to the “casual” gamedev user, that maybe has no software/computer science background.

  • (at least) one nice tutorial that really tackles the minimum set of features/classes/API you need to handle in order to make a game
  • a very simple entity system. Maybe not as part of heaps itself, but really optional, comprehensive/easy and as a quickstart. (edit: However like @zagortenej explains correctly, engineering your own game engine logic is actually really the “whole point” with Heaps — or at least one of its actual qualities)

so, I’ll try/would like help tackling that… eh… let’s go, I guess :sweat_smile:

1 Like
#19

welp, i’m about as done as i can be. Spending anymore time on it just feels unnatural, in the wrong direction. I wrote a lot of it in github pages, LOL. There is a 0% that this’ll compile!

Hmmm, yeah, the hand-holding through the commonly-used api to make a game tutorial would be major! Otherwise, it’s just studying ld40, ‘n other similarly straight-forward game jam games… (I still haven’t even played that game! :frowning: ). Libraries ‘n game bases often just add more layers of confusion ‘n misdirection, I’m not even sure if my own would be helpful, beyond the global class.

Providing a global helper class would def save people from searching through the api’s for everything they need to get started…

The entity thing… well, i’m not sure anymore really. Now that i made this entity thing, i feel like i was better without it! More free. Just doing everything in the main class, just the way that many game jam games are made… In the opposite direction of making is a sorta never-ending object-oriented rabbit hole that contradictorily leads to more and more constricting systems! I don’t know… but maybe i’ll know soon enough tho… :confused:

Even with such few structures, and i mean the most basic of basic stuff, i already feel is all an overkill. A tutorial that just used the core engine is enough, properly using Object / Scene / Layers, inputs, resources, audio, containers, etc., just as ld40 does. I don’t think there’s much more to it than that… well, except 3D. :japanese_ogre:

Heck, i feel a little freer already, knowing that i don’t need to work on this damned entity framework any further. lol!