Would like assistance vetting MMF2d against idea

[Glenshadow]

Greetings all,

I am new to both this Development community and to MMF2d. I just downloaded the demo a few days ago and have been coming to grips with it. As such, I have a few questions.

To preface, to give you an idea of my background, I am an experienced developer in PHP, C#, ActionScrpt/Flash/Flex 2 (AS2, AS3), VB6, VB.NET. I am fully versed in TCP/UDP, winsock, HTTP, POST/GET/PARAM, SQL/MySQL, etc.

Most of my experience has been business apps, but I have done alot of amateur game programming utilizing virtually all the technologies listed above.

I have a gaming idea which is essentially this:

A 2D top-down scrolling engine with gameplay based on the Tribes series (Tribes PC, Tribes: Aerial Assault PS2, Tribes 2 PC, etc.). That is a brief summation of the game I am attempting to create and I'm wondering if some of you MMF2d vets can help answer of these points are viable within it's architecture?

1) 16 players via UDP (with TCP for import sends, like chat or who just picked up the flag, etc)
2) A game board of 2400x1800, with a viewport of 800x600
3) Dedicated server, no client/server hybrids
4) A control model of WASD (rotate left, right, move forward, move back) for character movement, and 360' for mousepointer/weapon targeting
5) AI turrets that fire on the opposing team

Those are just off the top of my head... Can MMF2d physically/technically meet those requirements if my programming ability is sufficient enough to implement them within it's architecture?

Are there any other pitfalls associated with this gameplay type I should be made aware of before I spend my cash?

I thank you in advance and hope I've provided enough information to get a good dialogue going.

[Glenshadow]

I should also mention the graphics will be 3D character models rendered down to 2D sprites. I will also be implementing/integrating a client/server matching system via PHP/MySQL, but from what I've read on the forums so far, integrating both of these won't be much of an issue.

[DavidN]

Well, you certainly sound pretty qualified!

With regard to the multiplayer issue, the most common way to get multiplayer support in the MMF2 family is through the Moo- set of objects. I'm not actually certain of the underlying details of them and whether it's TCP or UDP that's supported (or both), but I'd imagine that you'd be able to pick them up very quickly. Having a dedicated server available helps matters as well.

For the other issues you mentioned - 2 shouldn't be a problem at all, there are ways to get 360 degree mousepointer targeting systems although it may be slightly more complex to implement, and 5 sounds workable to me as well. It all depends on the details, of course.

(Actually, with your experience in more traditional coded languages, if you find that the existing MMF2 objects don't do what you need them to, you'd easily be able to code them up yourself using the C++ extension SDK.)

[Glenshadow]

I had originally wanted to use MooGame for the game's connection, but saw a few threads where people thought the dead reckoning (and even the basic functionality?!) and what not was 'broken'?

Is this really the case? Or is it an example of 'broken' meaning that people don't understand how to properly setup and test UDP connections within their home network when developing games (which is a common scenario).

If MooGame is *really* broken, I'll build my own logic on top of MooClick, which sounds like a viable alternative in that scenario.

I am also a little out of my element with the IDE, since not being able to actually write code/script directly is a little... Wierd.

However I'm taking to it, reminding myself that one of the reasons I'm here is so I don't have to write my own routines for bitmapdata and (core) collision detection and double-buffering routines and what have you.

[Popcorn]

Hi and welcome


2: Yes, just set the playarea to 2400*1800, while leave the gamewindow to 800*600
4: Yes, very easy. You can either use default movements or make your own.
5: Yes, wouldn't take you too long to figure out how to do.

The questions regarding online gaming I'll let someone else answer, but I pretty much think yes. I am unsure about UDP though.
Alot of online games have been made using the MOO (multiplayer online object) extensions, but I am not sure how fast it is for 16 players with lots of animations.

Edit: beaten by DavidN and yourself I see..)

[Glenshadow]

I would also really like to hear specifically about people's experiences with MooGame vs MooClick, which one you eventually ended up using, why, and which protocal you went with (UDP/TCP).

I would also really like to hear from the Developers of MMF2d, if that's at all possible (I apologize if I'm being presumptuous), about whether or not they feel their product is a good choice for my gaming project, or not.

[raytrace]

I don't use Moo Game because Moo Click has much less "user interface clouding" and I think it is more reliable. I haven't had much chance to use Moo for games so I'm not that aware of the advantages of Moo Game's Dead Reckoning feature.

Personally, I think MMF2 is the best game making equipment in this band of programming and compared to VB.net which needs 20mb just to get an application to run it is much more efficient.

Of course with your skills you really don't need to worry about the limitations of the capability of MMF2 compared to e.g. C++ because you can create your own extentsions to suit your needs.

[Blizna]

16 players is nothing, dont be affraid about MooClick..in my MMORPG (TCP/IP, completely server-based) there is about 40-90 players (in all locations) and my server handles it very well.

I strongly suggest MooClick..MooGame is good but MooClick gives you much more control about the architecture. Since the DR in MG is broken, its not hard to make your own.

I only dont understand why you want to use UDP? TCP/IP is fast enough and the more things are "guaranteed" the better for gameplay.

I think MMF2 is completely capable of making the game you want to make. The only little problem is scrolling speed but with good choice of ink effects/DX VRAM on-off experimenting you will find the best way for you engine.

[Glenshadow]

Thank you all for the comments so far, to append my previous brief I'm hoping to accomplish this game implementation without having to code custom extensions.

On paper, MMF2d should be able to do everything I would like it to do without having to code custome extensions... That's the main reason I'm looking at the IDE itself, more time to focus on the game and less time reinventing the wheel.

That said, there is often a space wide enough to drive a truck through on what most applications promise on paper and what they deliver in real life... Which is honestly the crux of my post here.

Thank you for your continued comments!

[Glenshadow]

I only dont understand why you want to use UDP? TCP/IP is fast enough and the more things are "guaranteed" the better for gameplay.

I think MMF2 is completely capable of making the game you want to make. The only little problem is scrolling speed but with good choice of ink effects/DX VRAM on-off experimenting you will find the best way for you engine.

I want to use UDP because this will be an action-focused game. In that scenario it isn't practical to use TCP, which is more suited to RPG style games.

UDP will be used for 'blunt broadcasting' non-time-critical stuff like x,y of a given player, etc. The stuff that is time-critical like who just grabbed the flag, or a text chat message will be sent with TCP, for guaranteed delivery.

As an example, if every client is UDP broadcast sending it's x/y 20 times per second, it doesn't matter if a few packets get dropped because the ones behind it will instantly pick up the slack.

TCP has too much overhead with it's guaranteed delivery mode for use in twich-style action games.