!CFP! ENGINE CONTEST! (Check 1st Post!), 2 Engines to try out. Discuss!

WE HAVE TWO ENGINES FOR YOU TO TRY!
xn's engine
Guinea's engine
Please try them, look at the way they are written, and post your impressions!
What counts:
Do you think the engine is a good base?
Do you think YOU could use the engine yourself?
Point out possible limits you see in both engines, so you can be proven wrong or something can be done about it.

The most likely result is anyway, that both engines will be merged, combining the best parts of each. So here you go: Discuss!





After we've decided what we want to do, we will now start to work!

A quick summary of what the GAME will be about for those who forgot:
- Simple gameplay
- Four different characters (however, we've had suggestions to be able to unlock more after the game is over), namely the Mario Bros. and Wario Bros.
- Each character gets a special move: Mario=Wallkick, Luigi=Super Jump, Wario=Charge, Waluigi=yet undecided
- We'll have a worldmap
- We'll have characters selectable either on the worldmap or anywhere else outside of the levels
- We'll have a classic hitpoints system like in SM64.
- We will also have classic Mario enemies AND Wario-Land enemies


So welcome to the ENGINE CONTEST!
Be sure to read what comes now!

- We use Game Maker 6/7 unregistered

The engine you have to make requires the following:

Basics:
- collision + slopes + jumpthrough platforms
- moving platforms
- Different stats
They should be easily definable in the creation event of the actual characters:
maximum speed, maximum jump, acceleration, deceleration, gravity. Everything that comes to your mind should be customizable for each of the player characters. See below for more information on "parents".
- Use just the mask for now. Graphics will be added later.

Moves for the player object:
- walking and running
- variable jumping (as in: the longer you have the key pressed, the higher you jump)
- ducking + solution for when we can't stand up because there's a wall blocking the way.

Programming method: And this is the most important point of them all!!!
- INDEPENDANT PROGRAMMING
That means: Different things should have different code.
What I don't want to see (in s-tags, so no-one accidently thinks that the following is *good*):
> Collision programming in the drawing event or anything alike.
> "if keyboard_left: change sprite to Mario_left, skid if you're other direction, check for walls, move left, etc etc"
Bottom line is: Code everything as independant as you possibly can.
Seperate physics from graphics from keyboard input from enemy collisions etc.
You might still know what your code does, but this is a CFP, the C standing for "community" which means other people will have to interprete and change your code.
If you mix everything together, somebody could mess up the whole thing by wanting to change something as simple as a sprite.
- TAKE ADVANTAGE OF SCRIPTS
For everything that will show up more than once in the complete source: write a script!
It's a pain in the *** to go through 1000 objects and look for a small portion of code, compared to just changing a script to do the same thing.
Create scripts (if possible) in a way that you can use them for other objects than the one originally made for, e.g. a script that makes an object move horizontally, checking for walls and returning weither or not we have hit a wall should be able to be used by everything that moves, not just Mario.
- CUSTOMIZABLE KEYS
You don't need to implement a sytem to change them, but just assinging keys to variables so they can later be changed is enough. That way we can later change keys easily.
- PARENTS
Wherever possible and wherever common sense tells you that parents are useful.
Use them. e.g. one parent player object, the four Bros. would be child-objects.

Note: We don't need any enemies yet. Please only focus on the rules listed here.
And keep in mind the general gameplay concept, too. You're creating the engine for that.
Also, don't add too much over the mentioned limitations, because your engine has no guarantee to be picked! You might just as well have wasted time if you do too much.






As soon as we have a decent engine (+ a few extra days to give others a chance), this contest is over.
You will have the chance to discuss submitted engines.
Based on that discussion, the Organisation Team will decide which engine to use.
Note: Not the engine that looks the most impressive will win, but the one that works best as a base.


Good luck, gentlemen (and ladies, if some of you got the balls to program something as manly as a four-bros-game)!

This post has been edited by Guinea on Aug 18 2008, 08:40 AM

I'd just like to say that using the registered version of Game Maker would save a lot of time and decrease the file size.
especially if you don't remember which functions are only available to registered :x

This post has been edited by Elyk on Aug 11 2008, 12:51 PM

Alright, it's all up to the programmers now.

I'm hoping this turns out really nice. :]

I would also prefer to use a registred version of GM. I don't know which codes are or aren't in the unregistred version...

And I don't make games, but I think that if people are really serious about game-making, they'd use the registered version.
I know you want it open to more people, but I'm pretty sure most programmers here use registered anyway.

xn doesn't have reg as far as I know, just to name an example.

I'm all for reg myself, really, because of unreg's limitations.
If the ones who have unreg say that they don't want to contribute anything, enginewise, we can change to reg when everyone wants.

NOTE: If nobody who uses unregistered version complains within the next 24 hours, we will go to registered version as suggested by the posts just now!

can someone give me a link to the sprites from the first CFP?

They're in the archives somewhere. But aren't we supposed to...I dunno... Just use masks?

Mask size should be around two blocks high, just like your average Mario game meassurement. Also you should make your code so the mask size doesn't matter to the coding and can be changed at any time.

odds are you won't be using any registered functions for this contest, so don't worry about it

i like to think we all use c/c++, but that wouldn't be the first time i've been wrong about something

well then you leave me no choice but to complain till i'm blue in the face

i have to leave for a few hours; i'll write up a more formal opinion when i get back

no need for that. You complaint alone is enough and since you're one of the top programmers here, that counts as a definite "yes" towards using unreg.

Everyone got that? We use GM6/7 with UNREG Features only!

Maybe you should require some sort of control input handler that takes the player's input and turns it into variables. This would allow for easy CPU player control, for cutscenes and such...

Using unregistered functions is extremely limited when it comes to graphical affects that may be useful in the long run, but I'm not really the leader so I guess I can't tell you guys what you can and can't do. I'd help, but unfortunately I'm busy with two projects, and I need to have demos finished by ncfc.

Good luck guys.

This post has been edited by Razz on Aug 12 2008, 04:25 PM

see, now i feel bad for lashing out like that

Simply put, people really shouldn't be thinking about graphics at this point. About the only registered functions you'll need are those for resource management and data structures, and I was under the impression that very few people here know how to use them. Correct me if I'm wrong and you'll earn major respect points. =)

Nevertheless, I feel your pain about the image effects. (though why image_alpha is Lite is completely beyond me; it's just as difficult to program as the rotation and color effects.)

THEREFORE

I hereby command everybody to open up GameMaker, hit Ctrl-Alt-G, select the Constants tab, and create a new constant called pro set to the value false.

To set a pro object variable:

• Create an object variable with the prefix lite_. For example, if you wanted to set image_angle to pi/4, you would say lite_image_angle = pi/4;.
• In the end step event of your main controller object, check if(pro){with(parent){image_angle = lite_image_angle;}}

...you get the idea. Likewise to use a pro function:

• Create a new script with the prefix lite_ and call that as you would the pro function, for example lite_draw_sprite_ext.
• In your script, simply check if(pro){draw_sprite_ext(...);} else {draw_sprite(...);}

This should work for all image/sound pro functions (if your games in the WIP section are any indication, this accounts for 99% of all pro usage). As I mentioned above, there are some cases where lite just won't cut it, but the engine base won't require any fancy loading or object creation.

And FINALLY, if there is absolutely nobody else here with the unregistered version, I might be persuaded to upgrade to the Pro version. Terms and conditions apply. But for now, lemme just end with a comment I've already mentioned two or three times now:

You don't need GM registered to build the base engine.

This post has been edited by xn--e5x on Aug 12 2008, 07:35 PM

Well, I'm here now, and I also say, NO GM REGISTERED!! Sorry Reg people...

Good post, xn.
I hope somebody is already working on an engine ...

D:

Where are our programmers :[

Oh sorry, I didn't see that, I was too busy working on the contest.

This is easily a two-week assignment right here, what with the slopes and moving platforms and ducking. And then there's all the comments and documentation to worry about.

I'll probably finish within the next three days, but that's only because I'm recycling some of the code from DOKIME to hurry things along. Until then, keep an eye on my signature. (and note that I have a tendency to underestimate the completion percentage)

This post has been edited by xn--e5x on Aug 14 2008, 07:25 PM

Thank you xn

Thank you- because once we've got an engine down pat, we get ourselves a whole board for this project.

This post has been edited by Dex on Aug 13 2008, 08:01 PM