hi everyone!
my name is su, but feel free to call me mouse =]
I’m a game developer with about ~ seven years of programming experience - mostly with gamemaker’s GML, but also a little bit of python [though that was a very long time ago], and c# has rapidly become my favourite language of all time =]
I’ve been evaluating monogame for my future projects, and it looks great - but there’s one thing I can’t seem to work out how I would go about coding.
the way I’ve always done moving platforms in gamemaker is to basically:
have the platform calculate their next position,
have everything check if they are on the platform,
have the platform move, and then
have the things on the platform move accordingly, taking into account the platform’s new position.
obviously, this isn’t possible with just one update function - you’d need at least two for this scenario, and due to one reason or another I’m currently using all three [called “begin step”, “step”, and “end step” - I’d like to clarify that these are built-in names, not my own] in my current gamemaker project.
as far as I can tell, using monogame the way it’s supposed to be used only allows for a single kind of update - the GameComponentCollection class is sealed. is there any way to get around this limitation? or maybe, there’s some way of thinking that would make them unnecessary?
The way I get about things like this is having an Update, and a PostUpdate in my state classes. So when it comes to the Update in your main Game1.cs, you’d have something like the below:
public void Update(GameTime gameTime)
{
currentState.Update(gameTime);
currentState.PostUpdate(gameTime);
}
That means you’re updating twice before drawing your assets.
Getting to the crunch, there are many ways to do things, a good idea would be to search for the XNA resources and also consider if you are up to it, building your own physics system and also, if you are one of those, look at the numerous physics libraries on here and around the web.
I agree with the above somewhat, in that you break up your checks into multiple stages, this is real coding, so you are not limited as such in what you can do, you make your code, and only your capabilities limit what you really can do here.
thank you! after looking around it seems that most people do not actually use components as much as the code seemed to imply, so seeing alternative architectures has been very interesting.
