Does anyone think Mojo could be great for Game Development?
It's faster than Python and C++ (on certain occasions).
Did anyone think of ways it could become used for Game Dev?
Did anyone think of ways it could become used for Game Dev?
AIntegrating Mojo into game development, especially with engines like Unreal Engine that use C++, could be groundbreaking. Drawing inspiration from 'unreal-rust', a Mojo plugin for Unreal could leverage Mojo's performance edge over Python and C++ in certain areas. This would not only enhance development efficiency but also open up new possibilities for game developers looking to create complicated games with the least effort possible (on the programming side). I'm genuinely excited about the prospects and eagerly look forward to it.
P.S. If Iām not wrong, Modular is cooperating with many big companies to leverage Mojo's popularity and capabilities. Just as an idea, as far as the roadmap focuses constantly on leveraging the performance with hardware accelerators, starting a new cooperation with EpicGames (the Company behind Unreal Engine) is somehow not changing the roadmap and can lead to moreover popularity.
P.S. If Iām not wrong, Modular is cooperating with many big companies to leverage Mojo's popularity and capabilities. Just as an idea, as far as the roadmap focuses constantly on leveraging the performance with hardware accelerators, starting a new cooperation with EpicGames (the Company behind Unreal Engine) is somehow not changing the roadmap and can lead to moreover popularity.
MThat would depend on the game industry. There is nothing preventing Mojo from being used for game dev, including for building the core infrastructures like game engines and graphics libraries.
RSomeone will almost definitely make a godot plugin for mojo at some point. If you check the roadmap you'll also see there's a plan to allow you to import c libraries and that would allow you to use stuff like sdl and raylib for making games
NIt is almost a certainty that it will make its way to Godot at some point as Godot is flexible with language integration. Official Unreal integration is questionable since they are working hard on their own language verse. I personally would like to see a new game engine built from ground up around modern standards with Mojo on its core. We consider engines like UE5 next gen but it still carries a lot of 2 decade old baggage with itself.
JReminder, the next generational step in games is interaction of AI models. Level generation, responsive, personalization, enhanced NPC's, more immersive. Mojo has speed advantages over other fast languages
RI'm Unreal game developer, but i wish some company can make a game engine, not just integrate into Unreal or Unity , Unreal and Unity are OOP base, but i think mojo is becoming to be a language, and now , the modern game engines are more likely to use to build the game, eg. Bevy (rust base game engine), so I prefer to have a company create an exclusive mojo base game engine.
K
BIn addition to pure-Mojo game engine, bringing a WASM compilation target into the Mojo universe could be another valid mechanism to get Mojo into some games' ecosystem. I have a buddy that works on a game that has created a WASM-plugin system (an in-house solution that is similar to this: https://extism.org/). If Mojo has a WASM compilation target, then a dev could create a level generator (or whatever) in Mojo, compiled to WASM target, and called by their C++ game whenever level generation is required.
RIs that mean mojo can also make cross platform GUI too?
BI don't know how to answer. Partly because I'm still new to Mojo and partly because I am unsure what you are asking.
At this very moment, I believe you could make a cross platform GUI in Mojo via importing Python packages, but I haven't tried it.
Regarding Mojo-native cross-platform GUI, I am not aware of an existing package. However, I believe the Mojo-UI repo (https://github.com/Moosems/Mojo-UI) belongs to @Three chickens in the green bag , who seeks contributors to help build a Mojo-native cross-platform GUI.
And if your question was specifically in the context of WASM:
WASM is a compile target, like Win-x86, Linux-x86, Linux-ARM, MacOS-Intel, MacOS-ARM, Raspberry-Pi, GPUs, etc. If you are unfamiliar with it, then Fermyon hsa an interesting write-up on WASM here: https://www.fermyon.com/blog/how-to-think-about-wasm
I hope I'm answering your question and providing useful info.
At this very moment, I believe you could make a cross platform GUI in Mojo via importing Python packages, but I haven't tried it.
Regarding Mojo-native cross-platform GUI, I am not aware of an existing package. However, I believe the Mojo-UI repo (https://github.com/Moosems/Mojo-UI) belongs to @Three chickens in the green bag , who seeks contributors to help build a Mojo-native cross-platform GUI.
And if your question was specifically in the context of WASM:
WASM is a compile target, like Win-x86, Linux-x86, Linux-ARM, MacOS-Intel, MacOS-ARM, Raspberry-Pi, GPUs, etc. If you are unfamiliar with it, then Fermyon hsa an interesting write-up on WASM here: https://www.fermyon.com/blog/how-to-think-about-wasm
I hope I'm answering your question and providing useful info.
MYes, thatās the hope. I have been planning things out for a bit but because of limitations canāt actually run any test code except through the playground which is quite the limiting factor.
BOuch! That's... just.... oof. What about getting a cloud linux box in AWS/GCP/whatever and SSH'ing into that?
MSSH doesnāt quite help much with visuals and Iām not sure about how the pricing would look for that. Every time I try and make a VM it fails to compile and I donāt have the RAM for anything but the most barebones OS
MI actually opened #2345 to get access to nightly on the playground
Bvisuals... yeah...... 
....I'm a terminal nerd, so my idea of visuals is:
Sry, gotta reset my brain a bit.
{ I shake my head like an Etch-a-Sketch }
Ok, ready now.
....I'm a terminal nerd, so my idea of visuals is: Sry, gotta reset my brain a bit.
{ I shake my head like an Etch-a-Sketch }
Ok, ready now.
MTerminals are greatā¦. For everything but the GUI 
BFacts.
MCongrats @bunny, you just advanced to level 2!
MWonder why 
BAnyway, sorry for side-tracking the thread. OP was about game engines and I think I inadvertently sent us on a side-quest.
B{ insert Fallout TV show meme: "thou shalt get side-tracked by ### every ### time" }
MGames are possible if you use FFI to call C/C++ game engines
MOr graphics libs
BSry, I'm being sarcastic.
IMO, we'll get there. The community of Python devs who seek something similar but faster is very large. As Mojo stabilizes, I think we'll see a flood of package devs join the ecosystem. I know a lot of peeps (including me) drifted toward Go (which is an awesome language), but having something that is sorta "Rust.py" is even better, I believe.
For that matter, I've been mapping out a little list of "what packages do I need to see in Mojo-land in order to create a MUD engine in Mojo"...? So, a game engine, but a very specfic type of game engine.
BAnd full disclosure: I haven't contributed to a MUD in sooooo long. And only really did it in C. But a few years ago, I started messing with Evennia (a Python MUD engine) and found it to be quite nice. But I never really took that anywhere; it was just some "goofing around with stuff" side project and not anything serious.
MI think itād more be a Mojo wrapper around it and then abstracted into more Mojo
Hyes
HIf anyone else is serious about this, i started a group chat for mojo game dev, just let me know and i'll send you the link
DI think your physics engine has some characteristics of a game engine. Btw, can u send me the link?
HYeah it's tied to my game framework for now
TWould be great if you sent me the link as well!
TAs a game dev myself though, I think it's kinda tricky. Would be absolutely cool if Mojo takes off in this industry someday, but as far as I understand it, for this to happen there absolutely has to be official support for Mojo from either Epic or Unity. In pretty much all the other cases it'll at most be a niche scripting lang used at a small bunch of studios and a couple of indies. Even Rust, that had been around for some time already hasn't seen any widespread adoption yet. So without an official integration of Mojo into UE or something like that I just don't see how it would ever happen.
Hwell the industry might not, but i'm certainly adopting it
Rjust because unreal and unity are the big two engines doesn't mean they need to adopt mojo for it to see success. It could be adopted by Godot (seems very likely even due to their plugin system) which is getting more popular, there could be a new engine written from scratch in Mojo that gets popular, or there could be a new engine written from scratch in Mojo that never gets popular but is still a good engine that is worth using (popular != good)
Tpopular == there's enough people knowing the tech for larger studios to hire
Godot is definitely awesome for being open source (I never had a chance to actually work with it), but even Godot, as probably the most popular engine after these big two still hasn't seen its first AAA release. I totally agree though that it would be awesome if Godot adopted it, or if there was some new engine written from scratch in Mojo, or if Mojo became popular in indie game dev scene, but from my point of view - "widespread adoption" I was talking about is when larger studios start making larger projects with it, which is just like I said, a bit trickier in my opinion
Godot is definitely awesome for being open source (I never had a chance to actually work with it), but even Godot, as probably the most popular engine after these big two still hasn't seen its first AAA release. I totally agree though that it would be awesome if Godot adopted it, or if there was some new engine written from scratch in Mojo, or if Mojo became popular in indie game dev scene, but from my point of view - "widespread adoption" I was talking about is when larger studios start making larger projects with it, which is just like I said, a bit trickier in my opinion
RIf large studios do start adopting it it probably wouldn't be through unity/unreal. Apparently there have already been 1 or 2 big studios that made in house engines in Rust so I imagine something similar would happen if Mojo became popular in AAA
TIt would be easier through Unreal though as quite a lot of larger studios already use it. As for the ones using Rust - there's one I'm aware of - Embark (they also do a whole lot of open source, this page might be very useful for people thinking about starting some gamedev-related projects in Mojo https://embark.dev/), but it's still nowhere near "widespread" imo
I'd absolutely love it if it became popular in AAA though!
I'd absolutely love it if it became popular in AAA though!
TI'm also absolutely planning to switch to Mojo for my out-of-engine scripting work for sure, as distribution of Python scripts to the team members has always been a PITA (just to understand how much of a PITA it is - two best solutions I came up with are using Pyinstaller or putting the embeddable Python distribution under project's source control, and these two are incredibly bad solutions)
Ryeah, Mojo also appealed to me as "python but I can just ship a binary like a real language"
Tit got me wondering, is there a way to run stuff from Mojo already? like Python's subprocess library
RI don't think there is natively but there must be a way to do it in C so you could use C bindings
JMojo is one of the newest languages on the block, isn't fully at a 1.0 status, and yet already has a decent following. Give it time and im sure it will pick up even more popularity. A high quality game engine could help boost its popularity which would then boost the engines popularity and so on. I dunno if you can dethrone Unreal as the go to for AAA games but id argue godot shows there's always room in the Indie industry.
NTBH even the mighty Minecraft was just made on top of Ogre3D. As long as you have good RHI to work with you can make Mojo work. Major pain point in current era of game engines is that API's are horribly designed (DX12, Vulkan) which makes it unnecessarily difficult to make something custom which leads to people moving to popular engines. I expect a lot to change with next-gen API's that will make path tracing a core feature and hopefully learned lessons from unnecessary complexity
JDX12 and Vulkan are powerful but they do be kinda crap to work with. I will say, if the GPGPU stuff for max turns out how I expect it to... we might see a python first API for working with graphics pop up written entirley in mojo
Jinfact speak of the devil XD
https://discordapp.com/channels/1087530497313357884/1282705421425049622/1282705421425049622
That bieng said these are SDL bindings as well for now as opposed to pure ground up mojo but it's a step in that direction
https://discordapp.com/channels/1087530497313357884/1282705421425049622/1282705421425049622
That bieng said these are SDL bindings as well for now as opposed to pure ground up mojo but it's a step in that direction
RThe problem is that GPUs still have a bunch of fixed function hardware for certain parts of the graphics pipeline that isn't usable with GPGPU tools. I would love to see Mojo support that somehow in the future but right now a shader based rendering approach will have significantly worse performance than a proper graphics API. I just started playing around with some vulkan bindings the other night. Will let everyone know if I come up with a nice to use interface because yeah, it's definitely "C programmer brained" in its design
Jthere is that python wrapper for vulkan library... could always abstract that (where it isn't going to horribly affect performance by doing so) Mojo bieng a superset of python which itself is super interoperable with C is such a nice feature honestly
NI very much dislike Vulkan.c though. There is Vulkan.hpp that has much better API combined with 1.3 features relaxes a lot of complexity but it is still overloaded for my tastes.
Jwell vulkan is an extremley low level and incredibly deep/powerful API so it's to be expected to some extent
NTBH I think it is just bad design Because even when you are giving devs low-level API's. It is good to make those optional and not the standard way to program. Complexity should always be tap-in, not on by default. Metal does this extremely well, it is just as powerful but doesn't have any of the overcomplexity of Vulkan. And Khronos group seems to be well aware of this given that they are actively working on getting rid of unnecessary complexity update by update