'Endless Runner' Game Background in AS3 - actionscript-3

I'm wanting to make an 'endless runner' game. So, I need a random scrolling background to act as the obstacles, platforms, ground, and background in general. It needs to be random though and not the same background repeated over and over.
The background I'm wanting to do is too complexed for tiles (or at least I don't think so). It will be a similar complexity to this game: http://www.mochigames.com/game/flood-runner-3/
How would I go about coding this?

There're lots of tutorials out there, you can try google firstly with "side-scrolling game" or "platformer game":
http://as3gametuts.com/2011/11/11/platformer-1/
http://www.youtube.com/watch?v=k38YrVxXkSM
etc...
And in my opinion, Circus Engine
is a great engine for platformer game in as3.

Related

Character animation with bones for AS3

I'm developing some platform-like game in Flash using AS3. Everything is quite clean. The whole code is class based etc.
I've already done the most of the mechanics, and now I need to do some main character animations. I've already designed it, and it's waiting to be animated as a vector graphics.
A the problem starts here... What is the proper way of doing that? I would like to use bone tools to make it smooth. But as far as I tried to find any materials about it on the Internet everybody just do some simple animations and play it separately one after another. How about playing legs animation simultaneously arms and other parts of the body? Maybe some tricky usage of state machine... I don't know.. Is there any ready solution for that?
More tips is better here, or even some tutorials - just anything.
This tutorial by Chris Georgenes seems to be exactly what your looking for: http://www.adobe.com/devnet/flash/articles/character_animation_ik.html. Chris teaches the reader while animating a simple character. Having a strong overall knowledge of the bone tool will allow you to get the nice crisp animations you seek. I sincerely wish you the best of luck with your project.

Flash actionscript 3 smoothly moving large sprites

I've got a problem in actionscript3 with moving large DisplayObject-s. When the size of the DisplayObject is quite large (more than screen size) the movement loses smoothness and it looks like the object starts jumping forward and backward, which overall looks very unpleasant.
Does anybody know the way to fix that? I am trying to make a sort of a race game, where I need to move the background sprite to make the illusion of movement.
Try turning on cacheAsBitmap. That may give you some performance improvements, especially if the object is static (doesn't have any animated bits in it). With AS3 and Flash Player 10 or newer you should be able to get smooth movement even with a large sprite. I've got several games that do it.
Have to agree with Laurent - it is probably better to split the background into small pieces and move them

Box2D and Sand in AS3

I want to create a game where you shoot a rocket into the ground (Sand) and it blows, and moves the sand to the sides...
Is it possible in Box2D? breakable little objects?
It's almost pixel perfect collusion detection.
Thanks!
Yes it's possible, but beware your performance is going to be pretty weak. See the following articles (sorry guys, I normally like to paste in code instead of just link but there is are too much of it).
http://www.emanueleferonato.com/2012/01/17/create-real-explosions-with-box2d-adding-textures/
http://www.emanueleferonato.com/2012/01/05/create-real-explosions-with-box2d-exploding-objects-and-setting-the-center-of-explosion-with-mouse-click/
http://www.emanueleferonato.com/2011/12/08/create-real-explosions-with-box2d/
As far as dirt flying out when the ground breaks, the dirt doesn't have to be physical, you can just fake that with some particle effects. (Lots of tutorials on those things here)
In box2d it's not possible to break an object other than to remove the old one and create many new objects. If you need almost pixel perfect collision detection you'd need lots of objects. A 100x100 square contains 10 000 pixels.
A year ago I created a physical simulation involving many small particle-like objects using box2d. You can find the video here. The number of objects you see there is close to maximum Alchemy version of box2d could handle. AS3 version failed with much less.
You should google how it was done in old-school games like Scorched Earth for example. Or it might be possible to "cut" sand particles in area of effect of your missile from box2d shape, create many small particles, simulate them and join back to main terrain shape. But it sound very complicated.

idea for morphing captcha

I've been thinking of a dynamic way of creating a CAPTCHA that uses morphing shapes or dynamic colors.
My first idea is to have a graphic, flash or something, that gradually changes from, say a square into a sphere. The user will be required to click the button when it becomes spherical enough.
Second idea is to have an area of color that slowly changes from, say, red to blue and the user will be required to press a button when it becomes blue enough.
Third idea is a combination of both methods.
I'd say the difficulty will be to match the clicks with the transitions. But it should be hard for automated code to detect shades or shapes.
Can people please offer some comments on my idea.
edit -
Thanks for the feedback. I'm now considering using a flash based video playback of a server fed video feed of a few colored shapes that morph into other colored shapes. The user will be required to pause the feed when the colors and shapes match some canned questions: such as : click on the video when you see two green squares turn into 3 blue triangles. The shapes will be amongst over overlapping and moving morphing shapes. Fun for the whole family!
Color is a bad idea as (a) its very easy for a computer to detect; (b) very hard for some humans — the color blind — to detect. Even if you're OK with denying access to the disabled, you'd have to worry about different monitors, systems, lighting conditions, etc. giving rise to different color perceptions.
How hard do you think it is for a computer to compare the red component and blue component in a pixel (or averaged over several pixels)? Trivial. So this isn't a problem for a computer.
Similarly, it isn't that hard to program the difference between a square and a circle. One has strait lines, one doesn't!
Good idea, you could also do it so that the shapes keep turning or moving.
I don't know if it would be safer than a regular letter capcha tho.
I'm not sure why you think color would be any harder to detect than text. Shapes possibly, but they would have to be more complex than n-sided polygons. The gradual animation is a good idea however. But if you can code it to show, someone can code something that watches it.
The real test is to prove humanness by identifying semantic meanings, rather than syntactic meanings.
For instance show pictures of animals and make the user click when a bird shows up. Or just say "click on the thing that can fly." And show some pictures of animals. This would be rather unbeatable by a machine until all images had been cataloged. The trouble with CAPTCHA of course is trying to make semantics with syntax. Therefore defeating itself from the onset.
You're on the right track, and I'm sure your proof of concepts are interesting. But remember: made by a computer: solved by a computer.
Although these ideas will almost certainly work, it's a security-through-obscurity effect. Classic CAPTCHA images are "one-way" in that the correct answer can't (theoretically) be deduced by a computer. The problem with saying "click here when the image turns blue" is that a computer could easily do this, if somebody considered the stakes to be worth developing a program for.
Additionally, unusual captchas will force your users to think. Depending on your audience this may mean losing some users.
I did a fair bit of research when developing a CAPTCHA system, and the classic method of printing text to an image seems to be the most effective. The trick is not in having lots of "background noise" behind the text, or different colours. It's about the following two things:
1) Random text kerning, with most or all letters slightly overlapping each other.
2) Random distortion, translation and rotation of the text.
If you have a look at Google's CAPTCHA, they pretty well only have those two features: https://www.google.com/accounts/NewAccount?service=mail

What are the factors most important to developing a game?

I would like to know this to understand why some games like Mario is still playing today and because no other. This is to implement in future game projects.
What are the factors most important to developing a game?
Gameplay or Graphics? Both?
EDIT:
It's Possible combine these two?
Gameplay, combined with the often-missed concept of ease of play. If I can't pick up a game and make progress in a couple minutes I probably won't go back to it after I've been away. It's just disheartening to have to relearn how to play a game. Mario tended to have simple interfaces, one or two commands only, which makes it easy to come back to. Comes back to this: http://xkcd.com/484/
Gameplay. So many modern games just seem to spend their entire budget on developing an incredible graphics engine and forget to include plot / interesting gameplay. One example is Doom 3. It's kind of interesting, and spooky to play, but it's SO REPETITIVE. Tunnel after dark, deserted tunnel... compare it to Doom 2 which had a plethora of different types of missions. Doom 2 had crap graphics, but there's a reason people keep playing it.
That being said, a big reason people play old games is from nostalgic value. The gameplay might not be particularly excellent, but it does bring back memories, so that automatically adds value to the game.
Graphics are, of course, also important... you can't get away with 16-color 2D sprites anymore (or at least, not as easily). Rather than spend the entire budget on graphics, though, look into an OK graphics engine, and spend some time making the game:
Fun to play.
Have replay value.
Easy to pick up.
The most important is that you ENTERTAIN your target users.
Some users want gameplay. Some users are wow-ed by just graphics.
The think the real importance is addictiveness, which, of course, is rather hard to program in. However, I think the key to that is a task which is very easy to "almost" achieve. It's the "I'm almost there; just one more try" effect that keep most people coming back.
This might be a bit old-school for most peoples liking, but I'd have to say gameplay.
Put it this way, I still find myself running old SNES games I loved on an emulator these days, but I can't see myself playing a game that had great graphics but rubbish gameplay after it has had its time.
Both are preferable, but it's gameplay that generates the classics of each era.
Game play is what gets you hooked, especially if there's a very low learning curve such as pacman or breakout. Graphics is what sucks you into downloading / buying a game. Sometimes nice graphics is a demo don't necessarily translate to a nice game. I've seen so many games that have beautiful front screens, background, etc. but the actual game graphics such as characters, objects, etc. suck. Generally it's a good idea to think about your game design to make it easy to understand and play initially, then it gets harder with later levels by adding bosses, threats, bonuses, increasing speed, etc. Then fine tune how the game looks with snazzy graphics.
I would say it depends. For indie games, gameplay is the most important because that's what will keep your players entertained. obviously for big budget games, you need both to be successful. But as long as your graphics are clean and neat, players shouldn't complaint too much.
Distinguish between designing the game and programming the game. For a programmer, a game is simply an application, no different from any other kind of software. Game design is a whole 'nother beast of a different color :) If you can program well, you can program a game well.
Good game designers are the same kind of rare creative as good storytellers--who aren't necessarily always good writers.
Gameplay in terms of being easy to get the basics but difficult to master would be one factor, for sure. For example look at Diablo II for something with some nice basic elements but also some elements to keep playing for a long long time, like horadic cube recipes for example.
Replayability is another factor. How much does the game change if I pick a different starting character, assuming a game with this style like an action RPG or FPS or beat-em-up(Street Fighter II)? Is the game enjoyable from different views? How good is the AI if I have computer opponents in a real-time strategy game and how many settings are there?
Graphics can be a nice complement but just because a game looks nice doesn't mean I'll spend hundreds of hours on it. Titan Quest would be a nice example of taking the Diablo II style and adding some eye candy that makes for a nice game.
Nostalgia is a big factor in why some old games are still played like the old Super Mario games. The memories of playing those old games and seeing how cool it was to get to the next level can be why some will go back again and again. It is the reason why I still play my SNES at times.