next »

[bateleur]

We can also have best of all word, ie function get turn into token object you can drag, but can be type when edited

This isn't really visual coding so much as an IDE, though. (I remember back when people got similarly excited about "folding editors" that collapsed code sections. They never actually achieved much.)

Unity is basically like this in most respects. So when - for example - you set the action for a UI button it's selected from a list of methods of the components on a GameObject. You can do pretty much everything this way... except actually writing new methods.

[Sik]

The thing is what would be the paradigm of manipulation, My main issue with text is that it's open to syntax error and require many step (typing) to select one command. Visual scripting remove syntax error but have a slower procedure to select command (drag and drop), the question is how to improve the selection procedure to keep it fast yet precise?

http://4.bp.blogspot.com/-lUibvtAqm2E/UYVrSpG_4MI/AAAAAAAAAxE/oov7bXRCLw4/s1600/keyboard.jpg

Not to mention that BASIC editors by general rule won't even let you move onto another line until you fix all syntax errors. That still won't help you with logical errors though (which are the truly dangerous ones). And really, normal compilers also stop when they find syntax errors.

[AaronB]

The real problem with visual coding over text is that it's so much less expressive. That's by no means an insurmountable problem, but a truly powerful visual coding language might conceivably end up no simpler to use than text.

This is my primary argument.  Software is infinitely expressive and any system that tries to compartmentalize the complexity will ultimately reduce that expression.

[gimymblert]

No that's not a fatality at all, visual != abstraction. You can expose the complexity by making it more readable, that's all.

I mean visual interface

This isn't really visual coding so much as an IDE, though.

What's the difference? Visual coding is just about the interface, it's not a new language per see. Though people try to do both most of the time, it's not necessary, which is my first complain. Of course a simple visual wrap around a language is not enough if we can leverage new paradgim, but it mean we understand the problem to begin with.

For example when you jump from assembly to python, to c++ to ruby, it's all text right now, but they have different abstraction and paradigm, so it's the text that allow the abstraction, it's the structure of the language, "text" != language. I'm very insistent on visual interface as manipulation of the logic.

Now visual don't help necessarily with logic, it just have the potential to remove one step of indirection (syntax error). Exposing logic is something visual language can help too but generally aren't design with that in mind. Also because most visual scripting have a one size solution for all aspects mostly. For example visual node, which is only one type of visual interface, treat basic expression with the same interface as overall code flow, which lead to messy result when you complex expression and it lead to local spaghetti entanglement, so you need different interface depending on different problem, also I don't think they are good for loops. That's the idea behind "function" and "object" to hide some complexity by avoiding repetition of text that made it more difficult to read and understand the logic, it allow "chunking", which is only necessary because there is a human that need to understand. SO we need more visual paradigm to interface code.

The idea I proposed was just a starting idea.

[surt]

Spent the last two hours trying to figure out why my uniform location was invalid.
Turns out the glsl compiler was optimizing it away because it wasn't being used yet.
 

[AaronB]

Needed to collect data in one frame and use the result in the next, however I was getting a weird result in my mapped storage buffer and started having doubts about memory barriers and GPU / CPU buffer synchronization (which was freaking me out).  After much debugging, angst-ing, and general confusion it suddenly dawned on me I was using 'game_time' (real time) instead of the game loop counter 'game_tick'. 

[JWki]

I'm grumpy about graphics APIs.
OpenGL used to be my no-brainer go to and it still is for cases where I just want to quickly get something on the screen because it's pretty easy to do that, but I've done enough advanced stuff with it now to really really not like the API anymore. 4.5 is somewhat alright but still iffy in places. On top of that, actually shipping OpenGL stuff is SUCH a pain because it lacks any real validation layers and there's no conformance amongst driver implementations so getting it to work on my dev machine is only the first step, followed by finding bugs and edge cases on other machines and having to fix those.

On the other hand, I really like working with D3D for some reason but that's ofc Windows only and while that's fine for personal stuff that isn't really intended to be exposed to a public audience, I DO want to ship stuff on other platforms - I feel like nowadays it's somewhat mandatory to support Linux, and while I don't really care about Mac too much I think it could be beneficial to support that as well.
With the recent shift in graphics APIs though, support for Windows, Linux AND Mac either means going with the common denominator, which would be OpenGL 4.1 - and that's just a big no for me, no thanks.
Now, for Linux and Windows, I'd probably just go with Vulkan, but Mac doesn't support Vulkan. Instead, there's Metal, and from what I've heard Metal is actually a pretty decent API, possibly even the nicest out of all the available ones right now... But that means supporting multiple render backends. And it'd probably mean having a backend for D3D12, Vulkan AND Metal, because if I'm going to abstract stuff in a way that allows for two backends (Vulkan and Metal) I might as well have three. And there we go down the rabbit hole.

I always wanted to build an abstraction that works with an arbitary API as backend, but it IS somewhat more involved than going with a single API. Chances are a portion of the performance advantage that the new gen APIs have goes lost in translation, so to speak.

All this wouldn't be a problem if I could just be bothered to use OpenGL everywhere and be done with it but that's just not something I'm willing to do again.

Also as graphics are the field I specialize in I should be familiar with all the APIs out there so it's probably even a good idea in that regard.

[Schrompf]

No Vulkan for OSX? Oh sh...

[JWki]

No Vulkan for OSX? Oh sh...

No they are content with having Metal I guess.

[Zireael]

This grumpy programmer is trying to figure out alternatives to obsolete Lua module keyword. Alas, none of them do multiple inheritance, so this grumpy programmer is trying to wrap her head around ecs... Any tips?

[oahda]

This grumpy programmer is trying to figure out alternatives to obsolete Lua module keyword. Alas, none of them do multiple inheritance, so this grumpy programmer is trying to wrap her head around ecs... Any tips?

Assuming ECS = entity/component system: well, the underlying principle is more or less always the same, but different people have different ideas on the specifics of implementation, and probably certain things will be more or less suited to the engine/game in question—what have you read so far, and where do you feel stuck? c:

[Zireael]

Assuming ECS = entity/component system: well, the underlying principle is more or less always the same, but different people have different ideas on the specifics of implementation, and probably certain things will be more or less suited to the engine/game in question—what have you read so far, and where do you feel stuck? c:

Yes, I mean an entity-component systems. I have found some high-level explanations, but none of the more hands-on. Say I have a roguelike/RPG. I'd like to avoid ripping everything up, and I've read ECS can work alongside OOP. I'd like to avoid having an entity-component part for drawing, for instance. I'd like to use ECS instead of multiple inheritance while still doing inheritance for simple things that only inherit from one class.

I was thinking of using ECS for the complex stuff - actors, mostly, of which players are a subtype (actor + some components specific to the player I guess). But I can't find a guide on an RPG/roguelike using ECS at all. Even an action RPG would do, so that I know how to split up my existing classes to be components, because currently I'm using OOP with multiple inheritance...

[JWki]

Essentially, the principle is: Everything that you'd derive from usually, you make a component instead and have some way of registering that with the entity that should have the corresponding attributes.
The simplest way is to have the entity have a member for each component it has. This works well when you don't want to dynamically assemble entities at runtime.

[qMopey]

Personally I wouldn't bother with ECS stuff. It's all not very helpful.

Games want to have some polymorphism so we can write generic functions. Functions to loop over all entities and update them, or draw them, send them across the net, etc. This does not have to be implemented with some kind of components, or with inheritance, it can be any kind of polymorphism. In my own game I use some tables of function pointers and an enum.

The other thing games want is categories. So the game can ask "is this entity something that can fly?", "can this entity be hurt by fire?", "does this entity collide?". Again, doesn't matter how this is implemented, ECS, OOP, or any other silly acronym/buzzword.

[Zireael]

Personally I wouldn't bother with ECS stuff. It's all not very helpful.

Games want to have some polymorphism so we can write generic functions. Functions to loop over all entities and update them, or draw them, send them across the net, etc. This does not have to be implemented with some kind of components, or with inheritance, it can be any kind of polymorphism. In my own game I use some tables of function pointers and an enum.

The other thing games want is categories. So the game can ask "is this entity something that can fly?", "can this entity be hurt by fire?", "does this entity collide?". Again, doesn't matter how this is implemented, ECS, OOP, or any other silly acronym/buzzword.

So how would you do the categories without ECS? Because with inheritance, I'm running into diamond problem, or loops. Actors in my game are fairly complex. Stats, skills, spells, special abilities, combat... that's without mentioning player-specific stuff such as resting...

[qMopey]

Some category implementation ideas:

• Sort the entities when they are made. If an entity is created and has its Init function called, inside of Init it gives some systems of the engine its handle/pointer. For example in my game colliders work by each entity assigning itself to tiles.
• Some categories (32 for an int, or 64 for __int64) can be implemented with a bitmask. Upon entity init OR together all the category flags together. Then certain functions that loop over entities can skip ones without certain bits set.
• Categories can just be hash tables. Does this entity belong to category X is about looking into hash table X to see if the entity is in there.

This is just a data structure problem. Try to setup your entities so that when they are made they are already sorted into appropriate data structures. Try to solve problems "outside of code", by sorting data, or simplifying the design. Or in other words try to figure out fundamentally what it means to have stats, skills, abilities, and how decide how to express that with data structures. Instead of a list of observers and callbacks, does sorting the entities into a few arrays make a simpler solution? Try to stick to arrays and POD-structs when possible.

One last tip is to not make things very granular. Make bigger fatter "categories", or "components", whatever you want to call them. Trying to reduce ideas down to granular pieces for no good reason is a waste of effort. Can this thing collide? Then it has a collider. Can this thing draw? Then it has a sprite. Can it animate? Animation goes in the sprite, not a separate data structure. Does this thing do combat? Then it has a combat struct containing all the stats, skills, and somewhere a data structure knows where all the combat structs are in memory (or can at least find them when needed).

Separate pieces into smaller bits and reduce *only* when you need to (or know you will need to very soon). Start out writing code to solve specific problems. As more related problems start joining the party, refactor the code slightly to accommodate. Solve the immediate problems, and then simplify code as needed.

[qMopey]

Well, since this is the *grumpy* room I'll completely rant off-topic and not directed at anyone in particular: ECS is a bunch of garbage. And for that matter so is OOP. Actually, all the acronyms are garbage. These acronyms are methodologies. Methodologies turn into cookie cutter solutions, or the annoying "bag of tools", or even worse "bag of patterns". Each problem to be solved is unique (otherwise it would already be solved!). Trying to fit new unique problems into patterns is bullshit. All these acronyms are just... bullshit. 

[InfiniteStateMachine]

Well, since this is the *grumpy* room I'll completely rant off-topic and not directed at anyone in particular: ECS is a bunch of garbage. And for that matter so is OOP. Actually, all the acronyms are garbage. These acronyms are methodologies. Methodologies turn into cookie cutter solutions, or the annoying "bag of tools", or even worse "bag of patterns". Each problem to be solved is unique (otherwise it would already be solved!). Trying to fit new unique problems into patterns is bullshit. All these acronyms are just... bullshit. 

I like to use the term shoehorning to describe trying very hard to fit a pattern to a problem :D

I think it's good to know about these patterns just so you can have some exposure to how problems are solved by other people.

There are times where those patterns can be useful. OOP really shines when it comes to rich GUI's for desktop applications or games. FP really shines for long running concurrency problems. ECS is a little weird but it's really good for showing how composition can be really flexible relative to deep inheritance chains.

I do totally agree though. I tend to end up writing a lot of my games without an engine because despite the nice tools, it can be harder to make my game due to the opinionated patterns of the game engine.

[JWki]

Well, since this is the *grumpy* room I'll completely rant off-topic and not directed at anyone in particular: ECS is a bunch of garbage. And for that matter so is OOP. Actually, all the acronyms are garbage. These acronyms are methodologies. Methodologies turn into cookie cutter solutions, or the annoying "bag of tools", or even worse "bag of patterns". Each problem to be solved is unique (otherwise it would already be solved!). Trying to fit new unique problems into patterns is bullshit. All these acronyms are just... bullshit. 

Quite the strong sentiment. Can't say I disagree tho.

[oahda]

In case the above discussion hasn't scared you away from the concept and you still want to try it, here's something I found, which at least to some extent seems to adopt a philosophy more along the lines of what was suggested above:

https://github.com/bakpakin/tiny-ecs

I don't know Lua and haven't used the library, so you'll have to ponder its usefulness for yourself. p:

Trying to fit new unique problems into patterns is bullshit.

I agree with this fundamentally, but I also don't think that makes ideas with names unjustified—the core philosophy of any given methodology can always be the spark of a variation on its fundamental idea that does work well for any particular application, and surely if there's terminology to give others an inkling of one's direction that can be helpful, since after all most ideas are variations on others and not completely unique. At least to me, terms like OOP and ECS are a bit fluffy and don't describe anything exact (C structs with associated functions to me are as much OOP as the C# model)? Just my thoughts on it! c: