Related
i am working on an application ( game sorta ) which uses the kinect as an input device.
i need a "moderator" to be able to reset the application once new users are interested.
i was thinking that covering the sensor with a hand for some seconds could do the trick.
however the only way to achieve that would be to analyze the rgb camera output all the time for "all black".
any thoughts on this?
thanks a lot.
p.s.: i am using the openni sdk on mac and the game is developed in as3 using the airkinect framework.
What you mentioned sounds like a fair solution. On similar lines you could even use the depth sensor and detect the depth as (approx) 0 to trigger the reset.
However, I can come up with cases where using either one solution may be a false positive. Keeping it simple for the user, you might even want to use a combination of zero depth and all black for this.
Making it complex and accurate you could use a QR code or a RED Paper to indicate (STOP). A GREEN (for GO), etc.
(Kindly mark this solution as accepted if you find it sufficient. Awaiting your comments, if any.)
My first thought would be using voice recognition instead. It seems like a more natural interaction than covering the sensor. If you keep the voice commands limited it works very well.
I've used voice recognition in the past to determine the leftmost and rightmost edge of a "playfield" by holding my hand on one of the edges and saying "calibrate", "left", "right", and "Okay" to confirm. It worked very well. If you have a lot of people talking, you could listen for a keyphrase first. So "Kinect: calibrate" and "Kinect: left" to filter out the false positives.
You should first answer the question of how the user and moderator will be interacting with the application and the active interaction space. If a moderator has to approach the Kinect sensor and cover up the camera in order to reset the instance, why not just give them a wireless keyboard or mouse to hold? A mouse click or a keystroke can reset the scene in this case -- and a keyboard would offer many other keys to jump between multiple scenes, or configuration settings.
If you are truly needing a "hands free" solution for the moderator, I would look into gestures or speech recognition. I'm not as familiar with OpenNI, so links below will reference Microsoft SDKs but can be used for reference and ideas...
In the case of speech recognition, an "activation" keyword can be used (e.g., "Kinect" or "Computer") followed by an action request (e.g., "Destruct sequence 3, code 1 B-2B-3", or just "reset" if you want to be boring). You can read more about speech recognition using Microsoft libraries here: http://msdn.microsoft.com/en-us/library/system.speech.recognition.aspx
For gestures, you can use a static gesture to reset the scene -- for example, on the XBox holding one arm at your side and the other a 45-degree angle will send you back to the main menu. You can always assume the moderator will be on a certain side, or will always be the second player to enter the scene. You could just not care and let users reset the scene if need be. You could also mix it up and have the moderator give a "control" gesture or voice command first, so the system knows they are the moderator, and then give the reset (or other) gesture.
Two gesture libraries that could help in this are here:
http://kinecttoolbox.codeplex.com/
https://github.com/EvilClosetMonkey/Fizbin.Kinect.Gestures
I am porting as3iso to use with my abstract display list but I fail to see the reason why the author decided to use a secondary display list (the node hierarchy). I cannot think of the necessity of this apart from being able to get the children array of a display object. Is it really that big a performance hit to do for(i in 0...numChildren) getChildAt vs getting the children array? This can also be mitigated by maintaining a children array while overriding.
The only other reason is that some properties of flash.display.DisplayObject are final and wanting to have x and y correlate to isoX/isoY, but worldX/worldY is a reasonable API for this.
I have no problem with the secondary display list but I fail to see the point and am leaning toward having my iso display objects extend from my DisplayObject.
Also, I had presumed that marking objects visible=false that are not on the screen or outside of a scrollRect is not necessary with Flash and in rendering in general as this is/should be handled at the renderer level? Is this the case with the flash software renderer?
For the last question, it's useful to set visible=false because that way the renderer can quickly skip this object without having to calculate whether it is within the screen rectangle or not.
This way the library doesn't rely on the rendering system. You can use the traditional flash display list, Stage3D or a custom solution.
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.
Currently I'm writing an app. If I want to avoid Singletons, do I have to simply pass references of everything around?
For example,
I have a "main" class.
Class: Main
+---- Screen
+---- Camera
+---- Terrain
+---- Vehicle
+---- PhysicsWorld
It contains my Camera, Terrain, and Vehicle,etc classes. Now, I have issues when I'm creating say, the Terrain object. Terrain wants to access Main classes Screen object so it can add its Terrain Graphics to the screen. It also wants to know about the Camera object for when it is drawing so it knows what scale to draw it. It also wants to know about my PhysicsWorld object so it can add itself to the physics engine.
Do I have to always lug these objects back and forth between constructors? I mean, when I create a Terrain object, do I simply have to pass around my screen object, my physicsWorld, camera, etc?
Another random scenario I have, is now.. inside my Vehicle class I need to call a Restart() method on my Main class. Does this mean I have to pass an instance of main to Vehicle? Really??
It feels cumbersome to constantly have to pass 4-5 things to my classes, especially in my scenario now where almost every in-game object I have needs a screen, physics, camera info, etc.
Any suggestions?
It feels cumbersome to constantly have
to pass 4-5 things to my classes,
especially in my scenario now where
almost every in-game object I have
needs a screen, physics, camera info,
etc.
Then the correct question to ask is "why do I need all 5 objects in all my classes?"
Why on Earth does every in-gmae object need any of the mentioned things? An in-game object needs a position and whatever it needs to process its behavior. Then a separate renderer can, you know, render, the object. Which means that only the renderer needs the camera info and screen.
The physics could go either way. You could have a separate physics entity which updates the game object, or you could pass that physics object to every game object. But even if you do pass that around, we're down to one out of the three objects listed. :)
That's why globals and singletons are often best avoided. They disguise your dependencies so you end up with far more dependencies between your objects than you actually need. And then it becomes almost impossible to remove the globals.
However, if you do stick with globals, do yourself a favor, and at least avoid singletons. You don't need the additional constraints enforced by a singleton.
Terrain wants to access Main classes
Screen object so it can add its
Terrain Graphics to the screen. It
also wants to know about the Camera
object for when it is drawing so it
knows what scale to draw it. It also
wants to know about my PhysicsWorld
object so it can add itself to the
physics engine.
The terrain object needs to know one thing: What is the terrain like. Someone else can take responsibility for rendering it. That someone will need to know about the camera, screen and terrain graphics, sure, which suggests that the same object might plausibly be able to do other tasks involving these objects (such as other rendering tasks).
Why should the terrain care about what scale it's drawn in? It needs to know the scale ingame, but not the scale in camera-space. And why can't someone else add the terrain to the physics engine? The main function might be able to do that, even. Create terrain, create physics engine, register terrain with physics engine, start game.
I don't know ActionScript, but assuming variables are passed by reference, the least you could do is construct a 'Environment' class holding Camera, Screen, Terrain, PhysicsWorld which you pass to the instances.
I have the exact same problem (also in actionscript 3, coincidentally).
I have been working on an RTS for flash and had found myself needing to pass around large numbers of references to each new class (e.g., gameGrid, currentSelection, visibleUnits, etc.).
I eventually realised that what I really should be doing is to have every class maintain it's own properties, and instead pass around references to these classes, (well objects).
But anyway, now what I'm doing is having static variables containing references to commonly used objects such as the main stage, interface, engine and display area inside a class called RTSGlobals. I'm also putting constants such as the screen size in there.
I know this doesn't really answer your question, but I figure sometimes it is worth ignoring a bit of OOP good practice in favour of an efficient solution.
If someone has a does have a good practice solution though, please tell :)
I suggest you take a look at XNA's samples projects (google it). They're well designed and might give you some hints.
Also, since you're using AS3, you could use the event system to dispatch message to other entities. For example, instead of passing your Main to your Vehicle class, make your Main (or whatever else interested) a listener of your Vehicle class. Then, let's say the car crash and you want to restart the game, dispatch an event, for example CAR_CRASHED. The listeners of your car should do something based on this message. If you want to understand the event system, type EventDispatcher, highlight it and hit F1 in your Flash IDE.