joeyjojo

I would also consider trackers as being very intuitive in a lot of ways compared to DAWs, coming from the perspective of someone who isn't great at playing midi controllers live.

I do find tracker software to not be as immediate compared to a DAW for quickly producing a loop or initial idea, but beyond that initial hump the workflows for fully fleshing out and completing a track seem simpler and intuitive compared to a DAW, IMO. Once you have established the beginning of an idea the UX feels like editing a spreadsheet. The difference between using a DAW or tracker, for me feels like the difference between coding in a text editor versus using a node based UI. They are both intuitive in very different ways.

> The point of Haxe seems to be as a meta-compiler to generate code for a bunch of different languages/compilers?

That's basically correct, although there is also a cross platform runtime called Hashlink but is unsupported by Kha.

https://hashlink.haxe.org/

I am glad people are working on it!!

Have you seen Kha by any chance? It has similar goals. I find it quite awesome, but it won't gain mass adoption for a bunch of reasons. https://github.com/Kode/Kha

Someone built an immediate mode renderer on top https://github.com/armory3d/zui, which is utilised by ArmorPaint https://armorpaint.org. I also use Zui for my own bespoke 2D game engine.

I find this tech and tooling really quite amazing (just look at how little source code Zui has) given just how small the ecosystem around it is. I think Kha really illustrates what can be achievable if the lower levels have robust but simple APIs, just exposing the bare minimum as a standard for others to build upon. It really suggest taking a look at the graphics2 (2d canvas like) api.

For the kind of project I work on (mostly 2d games), I think it would really awesome if your framework also supported low level audio, and a variety of inputs such as keyboard, mice, and gamepads. If it also had decent text rendering support it would basically be my dream library/framework.

There absolutely is a need for a robust cross-platform rendering/multimedia solution, more in a similar vein to SDL than Unity or Unreal. The offering of Unity, Unreal, and perhaps Godot is just abysmal when considering that for all of the man hours put into the game development space, that is basically all we got. There should be hundreds of viable cross platform game engines catering to a wide variety niches that continually stretch the bounds of what a game actually is and how it can be represented. Game libraries such as Monogame, Heaps, Raylib, Love2D, etc just wouldn't be that popular if Unity and Unreal are the be all and end all. Adobe Air was once a popular choice (a very large number of top 50 app store games were built with Adobe Air) and I'd wager still would be if it didn't collapse under its technical weight.

Currently it is the low level, cross platform layer that is the most complex and the biggest hurdle towards making a game engine viable. If it wasn't so insanely complex, and the technical barrier towards making your own engine is reduced, the tired cliche of "don't build an engine" wouldn't hold as much weight, and it opens the doors to building a bespoke, fit for purpose engine for every game you create. Don't underestimate what an individual or small teams can produce if they are operating on a solid platform that facilitates a rich ecosystem of tools.

I suppose it should be considered where the abstraction actually exists. If the abstraction exists in logic or mathematics (ie. a triangle is a 3 sided polygon) it probably doesn't make much sense to consider the ramifications that thought occurs in a physical brain that can fail. On the other hand if the abstraction is physical (ie, hardware), then the fact that it is bound by physical law is obviously implicit. Software encompasses both physical and logical abstractions, so you need to pick a lens or perspective in order to actually view its abstractions.

Also, for even things like physics there are many simple ways to do things. Take Towerfall's arcade physics for example[1]. In under 100 lines you can create the basis for your platformer game. Sure, it's not just pluggable into other pre-existing solutions, ie tile maps, but at least you aren't endlessly hacking all over the place to tweak Unity's physics into submission to get the controls feeling right for your simple 2d game. There is a massive wealth of gamedev knowledge that doesn't seem utilised to its potential because existing engines want sell their pre-canned solutions. I think what the gamedev scene needs are more tools like LDTK[2], with more thought given to how such tools could interop, and a better selection of low level rendering libraries (like Monogame and Raylib) with very robust cross platform support and dead simple build systems (or none at all).

I use a very obscure library called Kha[3] and it has by far and away the best performance for 2d rendering that I have encountered. It is amazing what you can do with just a very basic immediate mode ui library called Zui[4]. I think it is shitty advice to say that you are either building an engine or game. This advice would be applicable if you are building a general purpose game engine, not the highly specific and bespoke engine used for you own game. Your game and your engine are basically the same thing and you take many shortcuts, make many compromises, and build out a rough and minimalistic "editor" used just by your small teams (or yourself) to get the job done.

[1] https://maddymakesgames.com/articles/celeste_and_towerfall_p... [2] https://ldtk.io/ [3] https://github.com/Kode/Kha [4] https://github.com/armory3d/zui

I have wondered if the UFOs specifically exist in a plane that will always be at the edge of our awareness. They aren't so much moving through physical space, but though our collective consciousness. Similar to how a physical person may temporarily exist in your mind, a UFO may temporarily exist in the physical space, and attempting to "capture" them is like trying to control a dream.

It just seems to be the same guy going on the podcast circuit talking about the Tic Tacs, and all I see is a video with a black blob in the centre. Have you got any links to back up your claims about all these people telling their stories?

It just opens your json in a publicly accessible page at https://jsonhero.io/

I could see a tool like this being really useful on my web game projects, where I would like artists/animators making contributions.

I don't see anyone mention affiliate links when talking about the indie/old web. Affiliate links were such a crucial element to the early web 'surfing' experience. It's a pretty shitty web without those affiliate links, IMO, and the only means of discovery is generally through some giant platform.

Outside of Vue, and maybe Angular, are there any other stable alternatives with a decent ecosystem? I'd love to hop off the React train, but I haven't found anything that compares to the experience of just using create-react-app with Typescript support.

How do you manage the lifecycle of objects with the observer pattern? I saw an example of the pattern below that is crucially missing a 'remove' function to unsubscribe from the subject. Like when using events at the app/controller level, I have found a layer/glue starts to form associated with the adding and removing of subscription handlers, and it is this subscription management layer where the majority of complexity and bugs lie. Being inspired by immediate mode renderers, this is what makes React so great - it basically eliminates this entire layer. I might have PTSD working with observers and events from my AS3 days, but if I were building a single page app I wouldn't use the observer pattern over React unless there was a robust way to manage the subscriptions. Perhaps I am overcomplicating something that is actually pretty simple, but I imagine using the observer pattern by itself doesn't really scale beyond the component level?

This is just iteration on the awesome groundwork that React laid, and shows that things can still be much better. React has some very peculiar patterns that don't really jive well with javascript as a language, or its ecosystem. If the setInterval example is fundamentally against what React is, then IMO that really hammers the point the author is making. I have a few React projects under my belt, and often times still find myself confused by hooks or the mess that I create when I use them.

I'm not sure it is particularly desirable to clone Flash's vector drawing tools. They were certainly nice to use but also pretty glitchy as you say. Functionality like vector shape tweening, while nice to have, is also not that important IMO. If the tools optimised more for artists and animators, they would mostly be using graphics tablets for more illustrative graphics. Vector tools for UI could perhaps be more along the lines of what Sketch offers.

I reckon taking something like Godot's vector draw tools, and combining that with a Flash timeline/library, with a Javascript runtime, and you would win over all those animators that keep saying "why can't they just re-make Flash".

At its core the beauty of Flash was the extremely tight interplay between vector graphics in nested timelines, and the the programming environment. Many people compare Flash to Unity, but I really don't find the two all that comparable. You don't create your assets in Unity, and by the time those assets get into Unity you have lost most potential for dynamic behaviour. Flash's tight integration allowed for extremely fast iterations, and its hierarchal model was very flexible and allowed you to work very fast and creatively.

I'm surprised no one has had a good crack at re-creating the core functionality of Flash circa 2004, based on web tech, or something like Kha[1]. I've thought many times about starting such a project. I think the biggest challenges are developing a solid vector rendering runtime alongside the vector drawing tools, but just about everything else that ex-Flashers want can be reduced down to some pretty simple functionality. You could even forego all the cruft of the display list, the event model, etc, and just go with a simpler immediate mode renderer and I think you'd still be retaining those core components that made Flash special.

There are so many use cases (eLearning experience, Digital Signage, Touch Screen Kiosks) that Unity isn't particularly suitable for, and for which HTML/Javascript is just clunky, that such a tool could far better accomodate.

1. https://github.com/Kode/Kha.

I wish Nintendo would just give us a decent battle mode, with the N64 levels.

Synthstrom Deluge. https://synthstrom.com/product/deluge/

I had an OP-1 for a number of years but I could never progress beyond 2-4 bar loops. When I bought my Deluge I made a full track in my first two hours with it, and I was pretty proud of it. I own a number of groove boxes now, but have only ever managed to completed tracks on my Deluge.

For the majority of my React projects I just import a single index.scss file in index.ts, and it has all the imports for my /style folder. It's not much different to the old school approach and is pretty pragmatic IMO.

For my last project I went with CSS in JS. It has some shortcomings and I don't think it would work very well if I use a lot of components from NPM, but it was really nice at encapsulating the component to a single file.

I don't think either approach is more or less proper. Inline styles had obvious large shortcomings in 2010, but not so much in the current context of front-end development.

I'm looking forward to picking up Svelte and just going back OOP for state management. Immutable state with React was a massive eye opener, but right now I think OOP is just better for state management, especially with all the insights gained from using React.

This looks look great, thanks for sharing.

Yes! I coded many games with Flash/AS3, which is regarded as low level these days, but it actually had a lot of abstraction over the rendering. For years I would battle with the opinions of the framework, usually attempting to smooth over it with my own even higher level framework.

It wasn't until I start coding directly with HTML canvas that I was finally able to produce code and workflows without the battle. I don't understand why pushing and popping to transformation stacks isn't the norm, when it is just sooo much cleaner. As soon as an underlying framework introduces an object hierarchy for rendering state, in the form of a display list or scene graph, it takes away so much of your ability to structure game state how it best makes sense. I would even say that ECS (entity, component, system) is often times an attempt to smooth over the opinionated framework problem, but it isn't all that great compared to plain and simple data structures for your game state.

I wish more people were using rendering libraries such as Kha (http://kha.tech/), building tooling on that sort of tech, and making those lower levels more robust and portable.

Awesome, that's great to know!

Is Safari actually getting WebGL2 support? I looked into this around 6 months ago, and what I gathered was the WebGL2 support was based on rumours from a Twitter post, and the supposed checkbox to enable WebGL2 on iOS actually does not enable it. I still can't find any solid info about WebGL2 coming?

Looked at a billboard designed to grab your attention - dead.

You have fixated on a single point that the parent comment mentioned, hyperbolised it, and gone off on a complete tangent. I think you should take a step back and attempt to understand the overarching point the parent comment was making, because I don't think you get it.

As a front-end dev, I've been interested in learning about such a process but don't know where to look. What kind of tooling would you use to manage your migrations in a CI environment?

Now I know why my girlfriend's cat was such a little prick, swiping me in the face and drawing blood. She had an automatic feeder.

I have sat many hours in an Aeron (and am sitting in one right now), but am not sure why I don't hear more about the Herman Miller Sayl Chair. I find it vastly more comfortable.

I really like this. I could see myself using this in the future for some personal projects or for prototyping.

What I would really love though is something a little more similar to Dropbox, with tight integration to the user's filesystem, and keeping the spreadsheet as the source of the data.