A true Christmas story! Somewhat unrelated, could someone provide insight into the following -
"MonoGame is a "bring your own tools" kind of framework, which means that it provides the building blocks to build your own engine and tools, but it isn't quite an engine itself.
If you are expecting a scene editor (like Unity or Unreal), MonoGame is not that.
If you love coding and understanding how things work under the hood, MonoGame might be what you are looking for. And fear not, getting a game running with MonoGame only takes a few minutes."
Yes, this is basically correct. When you start writing a game with MonoGame, all you get is basically a class with two methods, Update() and Draw() that MonoGame will be calling in a loop, plus a bunch of libraries for input, graphics, audio, content loading etc. you can use in your code. It's a step beyond something like bare raylib or SDL2, but it's a far cry from Unreal, which lets you think in terms of game entities from the very start: "here's the map, here's where the player will spawn, here, add some buildings and you can run around them".
With MonoGame/XNA/FNA, LOVE2D, libGDX, HaxeFlixel you are getting a bunch of tools instead, which is probably not bad if you like coding and your game doesn't fit into one of existing popular genres.
I think a lot comes down to whether a game is art-first or code-first, and almost all modern games are art-first, so it makes sense to have your platform be one that artists and designers are immediately productive in, and the software people are basically writing behaviour modules and plugins for that established system.
But it's good that code-first engines still exist. There are always going to be projects that are more experimental, or don't have a clear pattern of entities, or are dynamic enough that that kind of thing doesn't make sense.
This is a somewhat naive view of engines in modern game development. Full-featured engines allow every department to dive in head first in parallel. The first gameplay elements often get programmed before the first pieces of content arrive. Scenes can be blocked out and drafted immwdiately at the start of the project. Complex animations with states and blend trees can be created amd tested independently of the gameplay code. Audio scenes, complex cues and (dynamic) music can be mixed and mastered independently of any code to integrate audio into the game. The whole process is highly parallelized these days and the engine tools serve to insulate the departments from one another to some extent so that everybody can move faster.
Right, yes. I think all I meant is that in earlier generations you could do modeling/sprites and concepting from the beginning, but there was a hard line in terms of how much code had to exist before the whole thing started to look or feel like much.
Thinking here especially of the Doom / Quake / HL1 era where they were basically building the level design tools in parallel with the game.
Whereas nowadays you can have movement, mobs, dialog flow, etc all with very little code, and it's placeholders like "oh we need a custom shader for this effect" or "that boss needs some custom logic".
You don't have to reinvent all these systems, but in my experience, you still have to code a lot to wire these very generic building blocks up in a good way that fits your specific use cases.
So... I remember math including doing quite a bit of geometry by hand and with real tools, at least initially. "Math" is not just the symbol stuff written with a pencil, or with a keyboard.
Yep! Honestly it was just a random rabbit hole - I recently read Lee Smolin's Time Reborn (highly recommend btw, super fascinating read) and was curious as to what his more recent work was about, which lead me to come across The Autodidactic Universe paper. With the AI hype train full steam ahead, the paper felt newly relevant, especially as it seems that we're starting to hit plateaus for model intelligence and looking to other areas (e.g. world models) for further advancement in the field
The bigger issue here (imvho) is that financial institutions / systems / companies accept (maybe even invite) / tolerate a small degree of fraud as it's "good" for the system.
In more detail: Chomsky is/was not concerned with the models themselves, but rather with the distinction between statistical modelling in general, and "clean slate" models in particular on the one hand, and structural models discovered through human insight on the other.
With "clean slate" I mean models that start with as little linguistically informed structure as possible. E.g., Norvig mentions hybrid models: these can start out as classical rule based models, whose probabilities are then learnt. A random neural network would be as clean as possible.
"MonoGame is a "bring your own tools" kind of framework, which means that it provides the building blocks to build your own engine and tools, but it isn't quite an engine itself.
If you are expecting a scene editor (like Unity or Unreal), MonoGame is not that.
If you love coding and understanding how things work under the hood, MonoGame might be what you are looking for. And fear not, getting a game running with MonoGame only takes a few minutes."
reply