Second person game? that sounds scary!

The game character would stare at the screen and would make you do things O_O

In games, like in literature, we talk about how will we perceive the protagonist.

1st person: Me. I am the protaginist. I see through his eyes.

2nd person: You. O_O maybe.... you're watching someone else play?

3rd person: Him. He is the protagonist, and I control him.

and then, there's "behind view where the camera is top down".... which would mean our character is laying face down on the ground?

Sneaky edit: I get it now, both behind and top... usually called 3/4 perspective or isometric (btw isometric means a right angle pointed at the viewer will have projected 30? edges on both sides... it's a very specific projection).

O_o I don't get it.

If you meant 3rd person, from behind..... then I'd have to agree with LMK: either sprites standing up on an inclined plane or my very own 2.5d system which is not done yet ( D: ). You'd just go upwards instead of to the side.

Like so!

http://octavoarte.cl/25d_conceptv.exe

Keep in mind this is the same engine as before, I just enlarged the layout, placed more objects and tweaked camera and blur. So it still crashes under 20fps.

Edit: making this demo showed me I do need to consider height in the ordering. Notice how platforms below the "bridge" show over it. Try walking below the bridge. I'll have to think of something there.

you could try On Animation Finished instead of comparing to the last frame

:s

still weird, last frame should work

I did read that nameless thread and I must say he asked for it

I do wish him luck in his endeavor though... but when someone disregards every advice and even feels offended by the advice given... yeah I get pissed too.

I recommend abandoning such threads. Lost causes. Some people don't really want to hear the truth.

I think it's because the object doesn't have a fixed number of parameters. So the only way to have variable number of parameters is to take them one by one.

Yeah it's cluttery, but I can't think of a better way.

looks good.

Dunno if you already have planned to change this, but I'd suggest the power ups don't do the explodey animation, as I didn't realize at first that they were powerups... I thought I was getting hit.

I like the spinning helpers

I'm sorry.

Every time I read the title of this thread, I can't stop thinking of this --> http://failblog.org/2009/12/21/wish-granted-cody/

About the board, my first idea would have been using the array object, with 0 meaning empty and using a number for each piece. Then you can represent their movements by displacements, with the rook requiring that dx=dy, knight dx=1,dy=2 or dy=1,dx=2..... you get the idea.

beautiful art makes my programmer eyes weep

:')

I'm not sure but.... maybe animation frames start from 0?

there's been some mixups with stuff starting from 0 in some places and from 1 in others.

that'd be cool, thats what I'm trying to do.

The bones behavior could also use some work.... it's not very comfortable to use, and animations are very core to a game!

I'm thinking I'll have to open up motion reference separately and place it side-to-side with construct, copying manually. Yeah, that'll do.

At college I've been around this group that works on "Model Driven" programming. I did cite Construct as an example to them.

"Model Driven" is when you use design software to.... well, design your software. I've always been the coding type, and never liked this approach, but I took a serious look at it in this workgroup.

What I found out is that Model Driven development only works when the model IS the software. That is, there's no in-between model (such as exported code, in this case).

WHY?

Well, if you export the code and then change something there, the modified code no longer conforms to the original model. Things are lost in translation. Semantics are lost when generating the code, code doesn't contain semantics so you can't have them when creating a model from code.

This happens always, everywhere! just try translating text from english to russian and back to english. Things are jumbled, meanings are lost. (Just in case: think of english and russian as two models for expressing human thought).

So I said, and this is my current official stance, Model Driven is only a good idea if there is no way to do these in-between changes. The model becomes the code.

This is my opinion, based on my own experience with tools like Bison, Flex, Antlrv3, Doxygen, PHPDoc, MySql Workbench, Power Designer, etc.

PS: Okay, not-fail post follows. Perhaps too late but whatever.

I realize I'm a little late to the Wall Of Text Competition, but here's my entry:

When you post stuff in a thread that clearly reads DISCUSSION, you might be getting some discussion. So keep that in mind when you say things like this:

I posted some ideas, and I think anyone would agree that they have been met with some very fierce (and somewhat puzzling in its ferocity) opposition

In a discussion, when someone thinks you're wrong, they'll tell you. I also think you're wrong and I will outline why:

1. A Web-style creation system with simple-to-program randomization ---

The mistake here lies in the simple randomization. What's simpler than rand()? Of course, that's without getting into the "Insert American Football Game" Button issue (yet!)

For it to be built into a template with a webbing style.

Huh? webbing?

Sports-friendly creation algorithms

The mistake here lies in assuming Construct is not friendly to sport games. Construct is 2D friendly. If your game is 2D, then Construct can help. Now if by "friendly" you mean "built-in" then no, it's not built in. You can always make your own behaviors and even share them with the community. If you head to the finished plugins section of the forum, you'll find out several people have already done this, and we're very thankful for their work.

A Template system ---

As already mentioned, there is already a template system. There is no American Football template, so instead of posting a page detailing what such a template should include, you could make one.

What's left?

Oh, a detail.

[quote:2kwfhaw6]

American Football games are perhaps the most difficult to program because of the incredible attention to detail that has to be taken into account to recreate something that closely resembles its real-life counterpart.That's why doing it in C is not ideal unless you have a talented dev team working on it as a full-time job. Programs like Construct have the ability to cut through 90% of that, the only thing it needs is a purposeful template that will take the guesswork and jimmy-rigging of general features out of the equation.

Emphasis mine. You will NEVER pump out a good game without WORKING ON IT. No matter the tool. Work always shows. So, if you want, say...

Difficulty depends on how realistic you want it to be. To make 10-yard Fight, probably not so much. To make Tecmo Super Bowl, much more difficult, though not impossible. To make anything above that, virtually impossible unless you're a genius with this program and have incredible attention to detail that can stand the community scrutiny which even Madden in all it's complex programming glory has not been able to do.

yeah if you want Tecmo Super Bowl or even Madden quality, then you'll have to put in about the same amount of work that went into Madden. If they have a system that helps them do that game, well they've built that system over several years, refining and improving it. It's very specific, and It's a lot of work. WORK. And you must know your tools in and out, with ANY game system. This includes Construct.

As for the "ferocity" you've been argued against is... well... because you're so very very very wrong on most accounts.

Yes, this includes joysticks. See, some console devs are STILL struggling with analog input. Some still use a button for running, and simply use a fixed, unchangeable dead zone (Bad!!) if they even use dead zone at all, and if out of the dead zone they check the angle and that'd be all. Remember how long it took to get rid of tank-like movement? some still use that.

Why? well, because consoles have drifted from the green pastures that are fixed hardware specs. You'll see devs struggling also with multiple resolutions now. So yeah, they're multimillion-budget dev teams, and they can't figure out developing for multiple resolutions (Dead Rising, Soul Calibur).

SO! if you have doubts about the NUMBERS... well, nothing stops you from reading the input from the controller and putting it out on the screen. In construct, that'd be two events per stick (one for each axis) and the xbox controller object, plus two text objects per stick. Really fast to do. You should really do it. Seriously.

As for PC Controller support yeah. (hi devs!)

And FINALLY:

Wheee!! FOOTBALL http://octavoarte.cl/futbol.cap

5 minutes, discounting half an hour of head-scratching with some Object Pairer weirdness..... I may have found a bug there, will do some tests to make sure.

Now. If you breathe deeply, you'll find that the community is pretty helpful when you let it help you. If you don't want feedback or are not ready to accept it, please don't ask for it.

... post fail, editing