I'm creating a space game in actionscript/flex 3 (flash). The world is infinitely big, because there are no maps. For this to work I need to dynamically (programatically) render the background, which has to look like open space.
To make the world feel real and to make certain places look different than others, I must be able to add filters such as colour differences and maybe even a misty kind of transformation - these would then be randomly added and changed.
The player is able to "scroll" the "map" by flying to the sides of the screen, so that a certain part of the world is only visible at once but the player is able to go anywhere. The scrolling works by moving all objects except for the player in the opposite direction, making it look like it was the player that moved into that direction. The background also needs to be moved, but has to be different on the new discovered terrain (dynamically created).
Now my question is how I would do something like this, what kind of things do I need to use and how do I implement them? Performance also needs to be taken into account, as many more objects will be in the game.
You should only have views for objects that are within the visible area. You might want to use a quad tree for that.
The background should maybe be composed of a set of tiles, that you can repeat more or less randomly (do you really need a background, actually? wouldn't having some particles be enough?). Use the same technique here you use for the objects.
So in the end, you wind up having a model for objects and tiles or particles (that you would generate in the beginning). This way, you will only add a few floats (you can achieve additional performance, if you do not calculate positions of objects, that are FAR away. The quad tree should help you with that, but I think this shouldn't be necessary) If an object having a view leaves the stage, free the view, and use the quad tree to check, if new objects appear.
If you use a lot of objects/particles, consider using an object pool. If objects only move, and are not rotated/scaled, consider using DisplayObject::cacheAsBitmap.
Related
I am trying to create an animation for lemon juice and baking soda experiment, and I was wondering how can I create a foaming effect such as the one shown in this image:
The idea I have in mind is to simply draw a foam in photoshop and then use motion tween to change the size. I was hoping I could find a better solution to this.
I have something somewhat similar that you can probably use as a springboard for doing your own thing.
http://www.shaunhusain.com/SteamEffect/
http://www.shaunhusain.com/SteamEffect/srcview/index.html
Currently I'm just drawing some circles with this and then setting a blur on them (not very efficient I know but it served the purposed as I didn't need it to create a bajillion particles to still be effective as "steam" which was the intended goal). You could swap out the shapes/filter I'm using for your own drawing and use the same basic structure.
EDIT
Perhaps this requires at least a little explanation:
Basically you'd want to look at the two files SteamCanvas.mxml and BitOfSteam.as. To be honest I have no idea why I decided to write SteamCanvas as an mxml file. I chose to use Canvas as the base class so I could just wrap it around any other component as a container and be able to detect mouse clicks anywhere within a region. If this is being used in a pure Flash environment, that is one not using the Flex libraries (or mxmlc compiler) it could be changed to extend from Sprite and be written purely in AS3, essentially just the creationComplete code should be moved to the constructor. How this works is the SteamCanvas is a wrapper for whatever controls or components you want to put in it (just like a normal canvas uses absolute positioning, but could have containers that define layout nested within it if need be). The SteamCanvas sets up a timer and if the mouse is down when the timer ticks, it creates instances of BitOfSteam and sets the properties for the steam based on the SteamCanvases own currently set properties. In the project you'll also see a SteamEffectTest.mxml which is just the file you see running that has the sliders on it to change the properties of the SteamCanvas, I used these to come up with what I thought were good values to make somewhat realistic steam. If I remember I'll revisit this component tomorrow and try to take Marty's suggestions to get it updated.
Wasn't sure if this question belongs here, but I'll try. So I'm about to move my project from Director | Shockwave Player (if you ever heard of these) to Flash Player for numerous reasons and while I'm thinking how to better start off I got a question which really made me wonder. To the point.
Currently in Director each game window in the user interface (like small alerts or large windows with lot of elements in them) is drawn upon need - meaning that the actual window's graphical image is being put together from configuration (all sorts of properties like width, height and all elements and their properties) from numerous pieces of graphics (e.g. window background is made from 9 small pieces like the 4 corners, 4 middle pieces between corners for dynamic width and height and 1 central piece to fill the window) and then added to stage. This approach makes it easy to edit each graphical element without having to redraw the actual windows and everything in them if we would like to change the color scheme or improve something in a element. It also saves the resources as windows are being drawn only when requested.
Now I got to figure out if it's worth writing such code in Flash too as opposite to just creating all the windows and placing them in the library and adding to stage when they are requested. What do you think? Is it worth writing such implementation?
IMO, it depends on 1) How comfortable you are with Flash's drawing API / graphics class, and 2) How flexible each window/dialog needs to be.
If it's easier to just throw them together as static objects -- and if they don't necessarily need the flexibility to change dimensions/style much (can you count on one hand how many times they've needed to change since it was originally done in Director many years ago?), it's obviously easier to do this than going through the time/energy to recreate them dynamically, especially if you're not very comfortable with Flash's drawing API.
That said, a lot can be accomplished dynamically with Flash's drawing API, so if you have the time/interest I'd certainly suggest digging in and doing it the "right" way if you want to familiarize yourself with the drawing API.
My method for doing this sort of thing usually goes like this:
Create a separate class that extends Sprite/MovieClip; something like 'Dialog.as'.
Create public init(), show(), and hide() methods, and a private build() method.
init() is called just once upon initialization of your app, and takes some global parameters to hold on to internally (padding, colors, etc).
show() takes an argument of either text (a String), or even a Sprite/MovieClip -- whatever it is you want to show in this dialog. When called (when you want to spawn a window), it uses this -- plus whatever init parameters were originally passed in during init() -- to draw itself, and then unhides itself (tween the .alpha property, or simply set the .visible property).
When you want to close the dialog, make sure to invoke the hide() method, which first hides itself, and then cleans up whatever was created (removing listeners, etc) so that the next time it is called upon it can draw itself fresh.
It might also make sense to pass into this object a reference to the Stage (in the original init() call), so that it can center and size itself accordingly on the stage, and also addChild itself to the top of the display list so that it's always above everything else.
I hope this helps.
If is 2D you can check this:
http://pushbuttonengine.com/
if is 3D you can start here:
http://alternativaplatform.com/en/alternativa3d/
I can suggest you also Unity3D but this is outside of flash
Hope it helps
I'm brand new to Flash (and game programming, really), but want to learn a bit of it. My overall learning project is to create a Monopoly clone in Flash. Unfortunately, I'm struggling to get over even my first hurdle - how to create the board graphically, and how then to deal with it in the code. So far, my thoughts are to break the board down into the different sizes of tiles (the normal property ones, the corner 4 and a large one for the middle section), then somehow place these all in the correct position relative to each other and keep that positioning correct as the pieces (and thus the camera view) move about the board. (And, hopefully some day have a zooming ability too...)
Is this a good approach, or is there a better one? Does anyone know where I can find a tutorial specifically on creating board games in Flash (any sort really, wouldn't have to be Monopoly but just a game that has a board which tokens move across - and preferably which has to pan as well).
Also, as an aside, is there any way to have a dynamically coloured rectangle in a flash MovieClip (like you can have dynamic textboxs)? I ask because it would be useful if there was, as I could generate every property tile with just one MovieClip which took a name, a value and a colour...
everything you describe here you can do pretty easily once you get the hang of component sprites. personally i would make a single sprite that will then hold all of the "tiles" in the game, this would allow you to "zoom" the board while keeping all the pieces relative:
if you create this parent to have an addTile() and getTile(index:int):Sprite method then you can easily push the tiles and retrieve them from an array, so that Go is at index 0, old kent road is at 1 etc. that way you can use a single integer value to determine the position of the player piece as you can then use getTile(int).x etc.
the position of the tiles themselves can be worked out relative to the others. if you have a tile that is 20px wide and 40px high then you can position the tile as x = index * 20 for the first row, after the initial 11, you need to rotate them all and then use the y index instead (rotation = 90; x = 11*20; y = (index-11)*20) this will depend exactly on your origin point of your Sprite.
to draw coloured boxes you use the graphics of the Sprite, there are plenty of tuts on API drawing out there, but here is a basic box of 10x10px:
var drawing:Sprite = new Sprite();
drawing.graphics.beginFill(0x0000FF);
drawing.graphics.drawRect(0, 0, 10, 10);
drawing.graphics.endFill();
Another approach to your question could be to learn about Object Oriented Programming. That may not solve your representing the board graphically straight away, but it would definitely help you structure your game.
With OOP, you could define a "Property" Class with a set of properties such as streetName , color , price etc... I haven't played Monopoly in a while but you can get the general idea, i.e. to create a base object and make it specific by setting the object's properties. Your question about the colored rectangle can actually apply to other properties, a great way to avoid unnecessary repetition.
Broadly speaking OOP tends to emulate real life situations, so you could actually look at your Monopoly game, break it into its various parts, find common properties etc... I won't start a lesson here :) I'd be pretty bad at it, but there's plenty of resources out there . Look for OOP, Design Patterns & Actionscript3.
After a little research, you may find that your question about how to handle graphics may not be such a problem after all.
Your questions are way too general. I'm sure you don't want us to walk you through your whole project right?
Now to gain some experience, I suggest to you simply work through a few flash gaming tutorials. There are a LOT of those, I googled for 2-3 seconds and found this:
http://pelfusion.com/tutorials/35-flash-game-development-tutorials-fla-files/
I'm sure you feel disappointed by this answer, but this is the first step in solving your own problems. The internet has more than enough general game tutorials already. If you have specific problems, we might be of better help to you.
I assume with dynamically colored rectangles, you mean simply changing the color during runtime. Well you simply give the rectangle a name, and change the color property of it in code. Like this: rectangle.Color = Something.
You might want to start out with a simpler project just to learn some of the basics, maybe a little game where the player has to move a rectangle from one side of the screen to the other using the arrow keys or mouse, upon which a score is incremented or something. This will help teach you how the coordinate system works, among other things.
To draw stuff using code, you can create a new Sprite or MovieClip object and use its graphics property to draw primitive shapes (rectangles, etc.) to it at runtime.
I'm currently working on a pure html 5 canvas implementation of the "flying tag cloud sphere", which many of you have undoubtedly seen as a flash object in some pages.
The tags are drawn fine, and the performance is satisfactory, but there's one thing in the canvas element that's kind of breaking this idea: you can't identify the objects that you've drawn on a canvas, as it's just a simple flat "image"..
What I have to do in this case is catch the click event, and try to "guess" which element was clicked. So I have to have some kind of matrix, which stores a link to a tag object for each pixel on the canvas, AND I have to update this matrix on every redraw. Now this sounds incredibly inefficient, and before I even start trying to implement this, I want to ask the community - is there some "well known" algorithm that would help me in this case? Or maybe I'm just missing something, and the answer is right behind the corner? :)
This is called the point location problem, and it's one of the basic topics in computational geometry. There are a lot of methods you could use that would be much faster than the approach you're thinking of, but the details depend on what exactly you want to accomplish.
For example, each text string is contained in a bounding box. Do you just want to test whether the user clicked somewhere in that box? Then simply store the minimum and maximum coordinates of each rendered string, and test the point against each bounding box to see if it's contained in that range. If you have a large number of points to test, you can build any number of data structures to speed this up (e.g. R-trees), but for a single point the overhead of constructing such a structure probably isn't worthwhile.
If you care about whether the point actually falls within the opaque area of the stroked characters, the problem is slightly trickier. One solution would be to use the bounding box approach to first eliminate most of the possibilities, and then render the remaining strings one at a time to an offscreen buffer, checking each time to see if the target point has been touched.
I have an image of a basic game map. Think of it as just horizontal and vertical walls which can't be crossed. How can I go from a png image of the walls to something in code easily?
The hard way is pretty straight forward... it's just if I change the image map I would like an easy way to translate that to code.
Thanks!
edit: The map is not tile-based. It's top down 2D.
I dabble in video games, and I personally would not want the hassle of checking the boundaries of pictures on the map. Wouldn't it be cleaner if these walls were objects that just happened to have an image property (or something like it)? The image would display, but the object would have well defined coordinates and a function could decide whether an object was hit every time the player moved.
I need more details.
Is your game tile based? Is it 3d?
If its tile based, you could downsample your image to the tile resolution and then do a 1:1 conversion with each pixel representing a tile.
I suggest writing a script that takes each individual pixel and determines if it represents part of a wall or not (ie black or white). Then, code your game so that walls are built from individual little block, represented by the pixels. Shouldn't be TOO hard...
If you don't need to precompute anything using the map info. You can just check in runtime logic using getPixel(x,y) like function.
Well, i can see two cases with two different "best solution" depending on where your graphic comes from:
Your graphics is tiled, and thus you can easily "recognize" a block because it's using the same graphics as other blocks and all you would have to do is a program that, when given a list of "blocking tiles" and a map can produce a "collision map" by comparing each tile with tiles in the "blocking list".
Your graphics is just some graphics (e.g. it could be a picture, or some CG graphics) and you don't expect pixels for a block to be the same as pixels from another block. You could still try to apply an "edge detection" algorithm on your picture, but my guess is then that you should rather split your picture in a BG layer and a FG layer so that the FG layer has a pre-defined color (or alpha=0) and test pixels against that color to define whether things are blocking or not.
You don't have much blocking shapes, but they are usually complex (polygons, ellipses) and would be unefficient to render using a bitmap of the world or to pack as "tile attributes". This is typically the case for point-and-click adventure games, for instance. In that case, you're probably to create path that match your boundaries with a vector drawing program and dig for a library that does polygon intersection or bezier collisions.
Good luck and have fun.