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

In case anyone is interested in this anymore:
I'm also entering an engine.
I just need to think of a good way to do the moving platforms. I mean I know how to do them, but when I get the chance to do a new engine I always think how it can be better and easier to use.

I'm interested, I'm just trying to do the collisions right and I can't.

yeah, well, about that

so I'm cleaning up DOKIME, right, and I just need to make sure the enemies are working properly, since I'm using their collision code for moving platforms in SMCFP. I pick up a few gray shyguys and throw them onto a block. One of them isn't hopping up and down like he should be. Another one is jumping, but it's like he's in Jupiter gravity. Then I walk past them and everything seems normal... until one shyguy takes a HUGE leap and falls straight down through the platform.

three gruelling hours later I figure out that the glitched shyguys are deactivated. I narrow it down to a speed optimization wherein I deactivate every instance in the room, activate only a couple of instances close by, and THEN check for collisions, saving a lot of time; then I reactivate every instance in the view and things are supposed to return to normal. But they don't. That shyguy wot isn't jumping, is somehow staying deactivated.

I know this because if I take out the instance_deactivate_object line, the framerate drops but everything works.
...or that would seem to be the problem. Two MORE hours later I finally know what's going on...

Once I have a vague idea of what's happening, I throw together a bunch of debug checks and security layers around the optimization script -- make sure that you always call the return-to-normal script or there's an error; make sure the instance count hasn't dropped or there's an error; make sure you didn't deactivate your own instance or there's an error. Everything seems normal there. According to GameMaker, every instance that I deactivated earlier is activated after calling the return-to-normal script. I'm about to give up when a flash of insight hits and it turns out to be right on target. Here's what's really going on:

Instances can steal each other's step events.

Normally, step events are ordered by object. So all objects of type A throw step events, then all objects of type B throw step events, and so on. And if you were to call instance_deactivate/activate from a controller object like it says in the GameMaker help files, you wouldn't notice anything funny happening. But behind the scenes, GameMaker reorders the instances every time you reactivate them. And if you happen to reactivate your own object type in the middle of your own step event... that order becomes a lot more important.

The shyguy who was jumping with Jupiter gravity? He had two step events per frame. The one who wasn't jumping at all? No step event. Oh, and here's something truly weird: occasionally I encountered two shyguys who weren't moving. They were taking turns. That's right: half a step event per frame. Ridiculous.

tl;dr: Glitch. GameMaker's fault. Can't be fixed. Need a workaround. Need time to think about it.

Damnnnnnnn

I'm sorry this happened xn

We really need ya' man!

Ok, my engine now fulfills all requirements mentioned in the first post.
After changine one or two things to make the scripts more clear, I'll upload it for you to look at.

Without further fanfare, let me introduce what I call "Not DOKIME v0.3".

Edit: fixed a bug with slopes.

This post has been edited by xn--e5x on Aug 18 2008, 09:17 PM

Attached File ( Number of downloads: 21 )
 not_dokime.zip

Awesome. Now if Guinea posts his, we can decide which one to use and GET OURSELVES A CFP BOARD :]

YAYZ!!!

But no stupid posts there, okay?

Okay, my engine is up, too.
Might look confusing at first, but it's quite similar to the breakout engine we've used for the warm-up, style-wise.

Just follow the instructions in the ReadMe.
Whichever engine will be used gets a tutorial on IRC eventually, so don't worry if you don't understand everything right from the start.

I think we are now open to discuss, all candidates are here.

Attached File ( Number of downloads: 31 )
 cfp_enginebyguinea_0_0_0.zip

I've written a quick review of both engines. It's only slightly longer than a Radiant Silvergun boss fight as seen on super-play.co.uk. So on that note...
WARNING
data install
NO REFUGE

ENCOUNTERED AN ASSAILANT.
WALL OF TEXT

BE ATTITUDE FOR GAINS...

1:RELAX EYES
2:MOUSE SCROLL WHEEL
3:CAFFEINE

Review: GUINEA
SPRITES
/ Actual mask sprites are neither monochrome nor floodfilled
- Origins not centered anywhere
- Some masks have questionable bounding boxes

SCRIPTS
+ Extensive whole-script documentation
/ Scripts ordered by action
/ Arguments listed in numerical format
- Very little specific-line documentation

OBJECTS
- Objects not arranged by hierarchy
- Questionable object visibility and depth for controllers

ROOMS
(No observations)

SYNTAX
/ I still read the abbreviation "prn_" as something other than "parent"
/ Mixes /*comments*/ with //comments
- Execute code used instead of execute script

WORLD
- No object activation system
- No enemy management system
- No views

CONTROLS
+ Key assignments defined as globals
+ Prohibits left+right and up+down
/ Key state constants save storage space but are hard to read
/ Left+right and up+down treated as neutral
- Key status and L+R/U+D in separate functions

CONTINUITY
/ Object variables/constants/countervars prefixed by v, c, and ct.
/ Moving platforms responsible for changing passengers' position
- Object variables/countervars prefixed by v and ct.
- Players treated as special objects
- Some objects move during begin step and others move during step step
- Moving platforms treated as special objects

METHOD
+ Uses function pointers
+ Uses pro/lite switch
+ Adjustable step events
/ Overrides GM default movement and gravity
/ Overrides GM default draw event
/ No distinction between onground and offground physics
/ Adjustable step events
- Single script handles all player actions
- Object capabilities can be enabled/disabled
- Incomplete documentation


FULL OVERVIEW

/ GM6 lite

Object Hierarchy:
Objects
* Main
* * Important
* * Nonsolids
* * * Players
* * * Enemies
* Blocks
* * Jumpthrus
* * Solidblocks
* * * Slopes
* * MovingPlatforms
* Enemies
* Items

Behaviour:
Update physical keyboard status in controller's end step
Update player's keyboard status in begin step
During player's step step:
* Set hspeed2 by input
* Set vspeed2/impetus by input
* Set jumping by input/assign ducking mask
* Set ducking by input
* Set/move walleject
* Move vertically/collision check
* Move horizontally/collision check
* Check ground status
Set draw info in end step

Block collision found by collision_line with bbox_ and handled by do not move

Do you think the engine is a good base?
Yeah sure okay
Do you think YOU could use the engine yourself?
It's not how I do things, but I'll cope
Point out possible limits you see ... so you can be proven wrong or something can be done about it.
Object hierarchy is ... questionable. Your player behaviour script claims it was specifically written for the player. It would work for enemies too, right? Right...?




Review: XN
SPRITES
+ Object origins centered
/ Actual mask sprites are monochrome and floodfilled

SCRIPTS
+ Extensive specific-line documentation
/ Scripts ordered by object
/ Arguments listed as C function prototype
- Very little whole-script documentation

OBJECTS
/ "D&D" object group for map editing
- D&D object group not arranged by hierarchy
- Object depth not supported

ROOMS
+ Object-specific creation code required for entry points
- Object-specific creation code required for entry points

SYNTAX
/ Mix of execute script and execute code
/ Objects prefixed with obj_, par_, and con_

WORLD
/ Object activation system is untested
/ Enemy management system is untested
- Views don't scroll

CONTROLS
+ Prohibits left+right and up+down
/ Key state constants are easy to read but require extra storage space
/ Left+right and up+down treated as last direction pressed
- Key assignments defined as constants
- Keystate read and status update in separate functions

CONTINUITY
/ Object constants prefixed by stat_
/ Passenger responsible for changing position during their own step event
/ Block sprite origins not centered (snaps to grid)
- Some scripts aren't named for the correct objects
- Object hierarchy is questionable for some families
- Constants' names are questionable

METHOD
+ Uses function pointers
+ Uses pro/lite switch
/ Overrides GM default gravity
/ Distinction between onground and offground physics
/ Object capabilities set by pointer
- Incomplete documentation


FULL OVERVIEW

/ GM7 lite

Object Hierarchy:
Objects
* Game objects
* * Instances
* * * Simples
* * * * Jumpthrus
* * * * * Solidblocks
* * * * * Slopes
* * * Mobiles
* * * * Player-controlled
* * * * * Bros
* * * * AI
* * * * * Enemies
* * * * * Moving platforms
* * Controllers
* * * Entry points
* * * Cue cards
* Extra objects

Behavior:
Update physical keyboard status in keyboard's begin step
Update mobile's keyboard status in begin step
During mobile's step step:
* Set key states
* Set walleject
* Set ducking by input
* Set hspeed by input
* Attempt button actions
* Assign ducking mask
* Set gravity
* Set onground status
* Move object on slope
* Move object on platform
* Vertical collision check
* Horizontal collision check
* Determine animation status
* Throw custom step/timer events
Update mobile's draw info in end step
Update walleject in collision event

Block collision handled found by place_meeting with stat_platformcollisiongroup and handled by move_contact_solid

Do you think the engine is a good base?
Yeah sure okay
Do you think YOU could use the engine yourself?
Yes, but I'd still rather use VB6 or C.
Point out possible limits you see ... so you can be proven wrong or something can be done about it.
Collision detection is a bit sketchy, and multiple objects will kill the framerate rather quickly. Also the engine wasn't initially meant to handle slopes, so you may encounter some bugs there too.

...

Clearly, the superior engine of the two is...
Eh? I wrote one of them? I'd best not vote then.

Guinea's is a little better, mainly because of the slopes.

I think both of them should make you jump less far when you just tap the button, though. I think I'm jumping too high when I just tap the key.

Also, for the record, I have have Game Maker but don't make games, which is how I tested these. :]


Edit: woah xn big post

Also, I can't really vote for them since I don't know which is easier to work with, I'm just talking about how it feels playing them.

This post has been edited by Glukom on Aug 18 2008, 09:02 PM

? what's wrong with my slo----- oh right that. oopsie.

OK, I've uploaded a new file which fixes the bug that caused Mario not to correctly transition from a flat block to a sloped block.

If you're on dialup and don't want to redownload it, open up the engine in GameMaker and search all scripts for the text ins_snaptoinstance_vertical(ins);

this line appears only once, in mob_check_gravity. Replace it with

This post has been edited by xn--e5x on Aug 18 2008, 09:22 PM

I like guinea's for the following reasons:

1. It runs slightly smoother than xn's.
2. xn's seems to have complicated solutions to simple meathods
3. Guinea's is more colorful! :P
4. Since I understood the breakout engine, this is simple to me.
5. Guinea's provides somewhat walkthroughs for scripts and such.
6. the colisions in guinea's are slightly smoother
7. the acceleration and deceleration are easier to handle gamplay-wise.

6 1/2 good reasons right there.

I'll agree with Glukom about the slopes, but otherwise I feel like I'm playing the exact same thing.

Nice job you two.

xn, that was a nice and objective review, even though you have written one of the engines yourself.
As said in the first post, I think we'll go and merge the two engines then. When you get around using MSN/AIM, it'd be nice if you came online so we could talk about this.

Whoever has something to say, please do so, otherwise you have no right to complain later.

Well, if you merge the two, then I don't understand half of it. Literally.

They will of course be merged in a way they're more understandable than both are for themselves.

Newsupdate!
I've had a chat with xn.
Xn himself suggests to use my engine as the base for the following reasons:
- his engine (Dokime) will go open-source. If we used his engine we had the same engine like dozens of other games on MFGG. (this was also the main reason why he suggested to not use his)

Other than that we have agreed that I will implement as much as possible that his engine has better than mine.

As soon as that is done, the CFP#2 is ROLLING.
We will get our own board and from then on, everything is OFFICIAL.
Stay tuned!

Sweet!

Not to seem impatient, but does that mean we can start spriting now?

NO YOU CAN'T START SPRITING NOW!
big size so everyone sees it.
There will be a sprites list and based on that you're allowed to sprite whatever fits.