i'm curious: how was your programming journey with MG?

my experience with programming before trying monogame was mostly unity and web development. i learned a little bit of gamemaker and godot also. i feel uncomfortable investing a lot of time into profit driven engines and i feel like godot isn’t quite mature enough, although i’m very excited about it.

i am making a 2D pixel art platformer and i’m just using vanilla monogame. it has felt great to write my own tools for my project with monogame successfully doing most of the boring stuff for me.

monogame works well to pull up a screen and give me the really basic tools to draw stuff and play sounds that works in a cross-platform way, which is all i really wanted.

monogame’s default wizard-thing for bringing in assets, like sprites and sound effects, seems totally bizarre to me. but since all it does is write to the “content.mgcb” file i ended up just writing a little node.js script that automatically scans my assets folder and writes to that file instead of dealing with that manually.

monogame’s built in song playing functionality was also disapointing. as it is now there’s no way to have partial loops in songs or to play songs from an arbitrary position. it was a huge pain, but i ended up writing my own song playing functionality that accomplishes this. i have a post here detailing that: i have a solution (i think) for songs with partial loops and other cool stuff - #3 by HopefulToad

i’m working on windows and exporting to linux is only slightly a pain and exporting to mac is extremely annoying. but i believe that has to do more with mac than it does monogame.

i guess i could also say the slow activity with monogame as a project has me feeling a little nervous, i’d be really happy to see like a patreon for the dev team to go up and to see more community stuff.

so in summary, as i someone who was disapointed with other established engines and really likes c# i’ve found great relief in working with the simple tools that monogame provides. i’m no genius, but i’m a pretty competent programmer and i was able to write my own tilemap editor and other nifty tools that make working on my game a joy.

i have been working on finishing my first game after working on it full-time for a few months, with before working on it every once and a while as well as having a full time job for about a year. monogame has served me well for the most part, but i’m curious about other solutions that are our there. but who knows maybe i’ll just come back to monogame for game 2 :slight_smile:

2 Likes

Basically started by making my own gamemaker-like engine and snowballed from there. https://github.com/Martenfur/Monofoxe

1 Like

:open_mouth: this might be worth sharing! make it completely non-gui :dancer:

that does sound like an overlooked common feature in the api… but maybe can just update it / send a pull request, like add an overloaded function?

yeah, i don’t expect Unity/Unreal level publishing from any other framework… but you’re using OpenGL right? Not actually 3 different renderers for 3 different platforms?

;( They should be sponsored by Microsoft honestly… but i’m personally not worried about it being abandoned or anything. It’s already lasted a decade now (…? the original xbox)! Simple frameworks are way more stable than complex ones, and can last a long long time! Hopefully the shift from mono to .net.core or whatever was smooth…?

:relaxed:

wow congrats on almost finishing that game!!! it’s always the last 5% :cry:

i’d be happy to share it once i get the chance!

yeah! it’s just one project that exports to whatever platform you want based on an argument to a build command.

ahhhh nice! Then yeah, that sounds like the problem of other platforms… probably Xcode! That thing is hot garbage!

i took a peek at your sound code, and wow, that looks really complex. :sob: All that work… just for some sound functions? Hopefully most of it was copy-pasta of the original class?? I feel like the sounds component is always threaded (i mean, it has to be… right? to have audio and graphics work concurrently?), but luckily i’ve never had to use threads either… :woman_shrugging: sorry, can’t help you there.

@Martenfur :o wow, thanks for sharing! looks like ive got some home-work to do(!), reading this, haha

update:
@Martenfur i skimmed through your engine, MonoFoxe, and yessss!!, that’s pretty much what i had in mind!! This isn’t as terrible of a task than i thought! wow… :open_mouth: For some reason i felt it was a gargantuan thing, but after reading through your code, i feel like, this is much much much simpler than understanding a big engine. And better yet, everything can be customized to our own liking! Yes yes yes. I now believe assembling my own engine is the way to go. Yay! :slight_smile:

i was a little surprised that you had to write your own 2D shapes drawing functions though, and even further, your own 2D primitive drawing below that…?? :ghost: not hard, but, didn’t expect MG to be so… bare.

reading through your ECS was a breeze too. :slight_smile: I sorta understand that now… although, should every Entity have a map (dictionary) and list, or should there just be one static dictionary? :thinking:

only thing missing really, is collisions then? Or maybe i missed it in the math class somewhere…

overall, i feel pretty relieved now. thanks! As long as i don’t have to write scene/layer/camera, i think i’ll be ok. :slight_smile: I imagine those would be near impossible to write dependency-free, and probably just need a separate 2D and 3D version… (although i’m def avoiding 3d, lol)

i added a reply to this post about the same problem for those curious about how i never manually add content files to my game

1 Like

So basically, a worse version of what I wrote. GitHub - Martenfur/Nopipeline: A Monogame Content Pipeline enhancer.

It’s done as a bit of an optimization. Sometimes you need to iterate through all components and sometimes search them using a key. And note that it’s not a ECS, it’s a EC which is miles simpler than an actual, cache-optimized ECS.

I still spent 1.5 years to release v1.0, so beware. And I intentionally kept everything dead simple to use and understand, unlike some other moongame-based thingamabobs. You can simply take what’s there, in fact, I do recommend taking an existing engine and either just using it, or expanding it.

Monogame is literally Draw and Update loop and crappy content manager, that’s it.

LOL, that’s harsh… :sob: But this is exactly why i prodded Zach about it. It’s just one of those things that makes sense, at the least adding it to the tutorial as a non-gui option, and at the most, choosing one open-source implementation to replace it. I mean, if one can use MG, one doesn’t need a GUI there, do they? Unless it’s actually really useful. I’ll def give that tool a try tho… I’m in no position to say anything… But i already sense that many people have created their own wheel, and to me personally, that wheel is not fun to make! Game-play, yes, please. Automatic asset/resource importer… :scream:

and lol, Martenfur, you got me. I just throw out that word (ecs) without ever really knowing what it means… Well then, maybe that’s why it was so easy to understand!! :slight_smile: I love it! I was gonna go with composition until i learn the hard way :stuck_out_tongue:

oh yeah, makes sense about optimization, i think… so you have the option to choose hash(map) or list implementation (and it doesn’t cost much to have both, so why not!), whenever you want… nice!

:scream:
i’m afraid again, halp!

LOL. That should be it’s tag-line. Actually… that would really help ward off people coming here thinking that it is more than that. I’ve always thought of MonoGame as just SpriteBatch. :joy: Maybe NoGame? But that’s the beauty of it, no? This way, there’s nothing anyone can complain about, because you wrote the game engine part… (except the content manager thing…).

No, the default pipeline tool is crap and has zero reasons to exist. On top of being a pain to use, it’s buggy as all hell. That thing crashed on me so many times I lost count.

Yeeeeeah, spritebatch is also not that great tbh. It’s not straight up bad, but has a ton of room for improvement (that will never happen). You can take a look at Monofoxe’s VertexBatch that is based on spritebatch, but has more features and a nicer api.

it’s one small javascript file that does exactly what i need it to.

i think it’s important to share simple “i did this in an hour” solutions alongside the more comprehensive ones :slight_smile:

1 Like

LOL Martenfur… well okay then, i’m convinced! I’ll just start with Zack’s script; Then, if that for some reason isn’t enough, I’ll go with yours. :slight_smile: I’m a simple man: I like simple–perhaps the same reason i came to MG!: simplicity.

i also realized, just quickly looking at MickGuyvr’s “Content Crawler” and Zach’s script, how… how to say… robotic(?) C# is. I look at Content Crawler and i think: Microsoft naming conventions, classes, namespaces, lines with just a bracket (??), interfaces, exceptions, project files, visual studio, etc. Then i look at Zach’s javascript, and i think: :relaxed:. Scripting languages certainly have their place. (just not javascript tho :smiling_imp:)

yeah, i just checked https://github.com/aloisdeniel/awesome-monogame#pipeline and found Martenfur’s tool… Maybe can add yours there too? Or does everyone in the C# world actually use NuGet? :woman_shrugging:

Of course. Nugets are the way to go.

As it should be. Opening braces on left on the same line are heresy.

His seems to be very restricted in what and how it can process, gonna have troubles with custom resource types.

Well, gonna disappoint, this is not what monogame is about. It’s about freedom and control over what your game does.

2 Likes

it’s true, the way i did it is restrictive and will likely need some tweaking. i shared it mostly as inspiration as one way to do it. it wasn’t really meant to be a catch-all solution

what martenfur has done seems cool, and will prolly work out of the box.

1 Like

I’m a largely self-taught programmer, and I started because of my interest in making my own games, not because I wanted a job at a company. I’ve started quite a few projects over the past years, but never got close to finishing one until my most recent game that I’m working on. I suffer from Not-Invented-Here Syndrome, so I haven’t used any of the popular extensions to MonoGame. Instead, I’ve created my own class library with useful objects and functions that I can reuse with multiple projects. My class library isn’t really an engine, and I won’t be open-sourcing it as that would require me to document every public part of the API and also hold the source to a standard that I otherwise wouldn’t need to. Also, it’s tuned to my specific needs and not to generalized, wide use cases.

I don’t use Entity-Component. My style of programming is more barbaric, I suppose: simply create a new class type for each type of object I might need. Sometimes with several levels of inheritance!

FYI, you linked to my response in your topic and not to your original post.

Well, it also handles input and sound. I’m personally glad it doesn’t railroad me into a specific game design style, instead giving me more freedom than something like Unity would.

1 Like

Nice joke.

MonoGame’s built-in sound handling may not be up to your standards, but it does exist, and is sufficient for some use cases.

1 Like

It’s not just up to the standards, it barely works.

Users are free to use a separate sound engine if they desire, or even to modify the source code to make it a better fit for their needs if they want.

I’m not a MonoGame maintainer, but I’m pretty sure their top priority was close parity with XNA, so if there’s a deficiency in sound management in the framework, XNA was probably like that too. If you have ideas on how it could be improved, perhaps try bringing them to the attention of MonoGame’s maintainers.

1 Like