Envision, Create, Share

Welcome to HBGames, a leading amateur game development forum and Discord server. All are welcome, and amongst our ranks you will find experts in their field from all aspects of video game design and development.

[46/90] Perihelion - MonoGame Engine + Demo

Sailerius and I are working on a MonoGame engine, and my goal this month is to finish the GUI system and polish up the demo game we're making.

To-Do List

Engine:
  • [*]Finish refactoring core GUI components for more modular design
    [*]Redo button API
    [*]Decouple everything from MonoGame namespace and create a DrawManager to handle drawing; allows for easier porting in case we want to expand to Unity
  • Implement user-defined macros in the scripting system
  • Integrate tweens into GUI system
  • Implement text effects like shadow and stroke
  • Implement text transitions, e.g. fading in next letter
  • Implement animations or find a library that uses them
  • Implement text cursor that appears at the end of lines
    [*]Create extensions library to enable easy creations of things like menu and dialogue boxes, maybe inventory
  • Support XML windowskin configuration files
  • Implement scroll windows

Demo Game:
  • Finish backgrounds. Current progress: 2/5 or 6
  • Create inventory system
  • Polish GUI

If I manage to finish all of this by the end of the month, I'll probably start on map loading.
 
Thanks! I will. :)

Spent around five hours today refactoring my GUI system to use decorator pattern, among other changes. I think I fixed most of the things I broke when I decided to gut my code again, but I need to repair the interface with the scripting system before I can really test it. The big question I'm dealing with right now is how much functionality I should build into the engine versus how much I should leave for the client to handle. The core GUI framework includes support for text boxes, layouts, windows, buttons, etc., and I'm also making an extensions library to support things like menus and meters, but I'm not sure what to put in it besides menus and meters. Any suggestions? Also, man, I wish I could get around making the MenuFactory an abstract class that the user has to extend and finish, but buttons can support arbitrary behavior, and I can't think of any way for the MenuFactory to create ButtonBehaviors with arbitrary parameters.
 
Spent about eight hours programming today. Probably gonna do some brainstorming with the rest of my evening, but I'm not counting that towards my hours. The GUI refactoring is almost done, although I wasted a lot of time hunting down dumb bugs. I think the only things I have left now are refactoring windowskins and updating the API on both the C# side and the scripting side. Designing a good API is actually really tough. I'm trying to leave as much freedom for the user as possible while requiring them to do as little coding as possible, and it's really hard to strike a good balance.
 

Zeriab

Sponsor

Perihelion":8rdqyktq said:
(...) Designing a good API is actually really tough. (...)
It sure is, and the first time you are not gonna get it right.

If you want a second eye on any of your code just drop me a pm with it ^^

*hugs*
 
Worked for about four and a half hours today. Refactored my windowskins to be easier to use and fixed bugs (urg race conditions). I really need to figure out how I'm going to handle buttons in my API, because right now the API is pretty awful. Next time I feel like messing with it, I'll try writing out what I want my API calls to look like and then figure out how to make the back end work. I think I've been doing this backwards.

Engine screenshots aren't very impressive, but since you asked, here's one:
Oo4ZhHY.png

This doesn't look very exciting (all the graphics are placeholders), but there are a lot of complicated things going on here, including showing text one letter at a time, automatic text progression, lots of things automatically resizing and aligning, etc. You can't really tell from this screenshot, but it supports RM-style windowskins. I started with the ability to draw pictures and text to the screen, plus a couple things Sailerius had started on.

Not sure what I want to work on next. I still need to decouple everything from XNA so Sailerius can start on shaders, but I'm bored of refactoring for now and wanna implement new features.

Also, I think I'm going to be upping my goal. I hope I have enough time to keep working on this once term picks up.
 
i totally understand, im just a few steps behind you, ive been looking into using monogame to convert my game from XNA to mac and Android. haven't decided if its worth the work. i just finished some major code changes in my game, the results look so simple, but the code was alot of work. i get about 100 fps better though so im happy (i always work on the game with no frame limit so i can easily see how changes effect my games performance.) keep on the good work :D
 
There are a few major caveats with MonoGame, most notably the lack of custom content pipeline extensions. Plus a few other things, like render targets inexplicably not working on some Android devices. If you do switch to MonoGame, I recommend making it a priority to test your game on all platforms you intend to run it on as early into development as possible. In theory it should run on a bunch of things without much trouble, but you know how theory goes.

Yeah, the thing about making an engine is that you often do a ton of work and wind up with no visible results for it. I just spent several days making major changes to my GUI codebase and only just got it working to how it was before I started mucking with it. It was definitely worth the effort because it's a lot better now, but it gets frustrating sometimes to not make any visible progress.
 
Yeah, the render target thing is a huge pain in the ass. We're trying to find a workaround but no luck so far. :\ Apparently it's an OpenGL bug or something, and since it relates to a certain GPU that's now becoming outdated, it's unlikely to be fixed. Unity also runs on Mono, and I believe its render targets work on Android, but I have no idea how. They must have reimplemented them or something, I guess, but I wouldn't have the faintest clue how to do that. We've also been having problems loading XML through the content loader on some platforms, but I don't know if that's a MonoGame thing or if there's a solution for it we just haven't found yet.

I gotta say, I'm really glad I'm working with Sailerius on this. I think I have a good grasp of OOP now, but I've been programming seriously for less than a year, and fixing all of these obscure problems is probably beyond me. Especially the stuff he's been doing with the scripting system, which I'm pretty sure is black magic.
 
lots of good information, if i get to that stage anytime soon im open to sharing my experiences with you, i personally hate xml and dont use it much. but i love render targets i use them alot
 
I don't think anyone likes XML, but sometimes it's necessary. For example, I'm going to be implementing map loading at some point, and XML is the only way to do that through the content loader since you can't write custom content pipeline extensions in MonoGame. There's not even a way to just read in text files unless you do it through the operating system.
 
Yeah, it's too bad. They're useful. The nice thing about the content pipeline is that it compiles everything to an xnb for you, which is binary, so it makes it harder to steal your assets and so on.

Although if you're using XNA, I should warn you that Microsoft just officially said they're abandoning it. MonoGame isn't going anywhere, though, so I recommend you switch. And you should do it as soon as possible to avoid changing more things later.
 
I have some time between classes, so I'm thinking about my button API.

Current Situation:
There's a Button class that is applied to drawables as a decorator. This means you can turn just about any image, text, whatever into a button. Buttons take ButtonBehaviors, which define what happens on different events, such as click, cursor entering or exiting the button, cursor actively hovering or not hovering, etc. The problem with this setup is that there's no way for the menu system I'm including in the extension library to automatically create Buttons and ButtonBehaviors since they need initialization with arbitrary parameters. This means the user has to write a ButtonFactory or something in addition to the ButtonBehavior class if they want to use the button in a menu, which I don't like.

Moreover, buttons would be much more flexible and easier to use if there's predefined behavior to select from. They should ideally be able to be created from scripts as well.

Proposed Solution:
You'll still be able to define your own ButtonBehaviors in your project if you want, but I'm going to switch the main focus to constructing them out of predefined behavior components, which could be assigned to whatever event listener you want.

Supported Behavior Components:
  • Function callback
  • Scene transition if scenes end up being built into the engine
  • Change text
  • Change background
  • Change text color/alpha
  • Change background color/alpha
  • Show selection cursor
  • Hide selection cursor
  • Apply shader
  • Stop applying shader
  • Apply tween set (moving or whatever other arbitrary behavior you feel like tweening)

Am I missing anything? Also, I should make some of these recyclable for other purposes.

How to do this?
I'm thinking I'll make a generic ButtonFactory or something. After instantiating it, you would be able to set it to create buttons with certain properties (e.g. text or background) and add behaviors to the various function calls. So if you want the text to change color and a selection cursor to appear whenever the cursor enters the button, you would create a behavior for color change and a behavior for showing the selection cursor, then call the factory's method to add them to the OnEnter method or something. I guess the builder should add them to a list of actions or something and pass them to the button, which calls all of them whenever the event is triggered. When you're done, you can either tell the factory to create the button and handle it yourself, or you can feed it to a MenuFactory and have it construct a menu.

I'll probably be making other factories as well, and I'll add methods to automatically apply transition sets to all objects created by the factory on creation and destruction.
 
im not sure if im misunderstanding the issue, but couldnt you just have your menu class take the premade buttons as arguments? you prob dont want to specify how many, so id just use a List<Button>
 
If you wanted to do that, you could just add all the buttons to a layout or something. There's no such thing as a menu built into the core GUI framework, just buttons and layouts and windows and things like that. So the idea behind the MenuFactory is to provide a convenient wrapper for the common task of making a menu, since there's some annoying stuff like setting up callbacks and waiting for user input that you'd need to do otherwise. So the MenuFactory creates the buttons both for convenience and because it has to create callbacks in the ButtonBehaviors for when the buttons are pressed. Basically, the way it works is you feed the MenuFactory (actually I should probably rename it since it displays the menu in addition to creating it) some strings for choices, and it returns to you the number of the choice the user selects.
 

Thank you for viewing

HBGames is a leading amateur video game development forum and Discord server open to all ability levels. Feel free to have a nosey around!

Discord

Join our growing and active Discord server to discuss all aspects of game making in a relaxed environment. Join Us

Content

  • Our Games
  • Games in Development
  • Emoji by Twemoji.
    Top