I am creating a simple game for thesis. It doesn't have Activity classes but instead has Screen classes for each level. I would like to implement a SLICE functionality for this game. For example, the user would slice at the enemy to attack it.
I tried searching Google for this, but nothing comes up but the Slice game, slice() function in javascript, etc. I really don't know what to call it.
I think that what you really want is a "swipe" gesture, which recognizes someone quickly moving their finger across the screen.
This answer describes a great way of implementing such a gesture, and you could possibly modify it to parameters that "feel" right for your slice.
Related
This is the gist of my app idea:
When the user turns on the app, it calculates a position 100 ft in front of them, then overlays some kind of marker onto the camera, so that when the user looks at the position through the phone, they see the marker. Then they can walk towards the marker, which gets bigger (ie "closer") as they walk towards it.
The full idea for the app is more complicated than this, but I think that if I could create this, the rest would just be iterations.
What concepts of AR, mapping, images, Android API, hardware (and anything else I haven't thought of) does this bring to mind that I need to begin learning about? I have lots of programming experience, and some Android experience but next to no AR or vision experience.
Basically, I'm hoping you guys could give me a list of terms to Google so that I can begin forming concrete ideas of how to make this.
Isn't this a kind of 'Geo-Located" AR? To get search results matching what you are describing rather than methods that put the augmented content at a relative distance from the viewer, try searching "latitude", "longitude", "coordinates", "POI" etc., along with AR terms. I am currently looking into learning AWE.js because it offers true geo-located POIs (point(s) of interest) using coordinates.
I came across this (https://github.com/buildar/awe.js/issues/3) when trying to find for myself how to create geo-located POIs using AWE. For your purpose ("...calculates a position 100 ft in front of them, then overlays some kind of marker onto the camera...") you would need a way to leave the x and y axis as they are in the original 'geo_ar' demo (https://github.com/buildar/awe.js/tree/master/examples) - as relative to the user, not as lat/lon coordinates. However, for the user to be able to approach them, you would need to find a way to get them to initially appear as relative to the user (the default way), but then somehow be locked down. It normally wouldn't be necessary because in most apps geo-located POIs are placed near real physical places of some significance, so rather than the user having POIs appear near wherever he is, he goes to find them where they are. I don't know how locking down an initially-relative POI would be done - I am not a programmer, I just stalk programmers online. ;) Still, I hope that fills in some of your gaps to help you get started.
I believe there are games out there (though I haven't played them myself) that do this to spawn enemies like ghosts or zombies. They spawn a set distance away from you, but you have to run from them.
I'm fairly new to Android and I'm working on an application in which one particular section involves a more advanced UI interface than what you would normally create with the stock UI components. I've read through most of the SDK tutorials and I get the basics but I can't see how to implement something like this. I'm not looking for any code, just some advice on what technologies I should be reading about to achieve this.
Here is a mockup:
So basically at the top there is a thumbnail strip that the user can flip through. Clicking on a thumbnail will perform some action. I'm pretty sure there's a stock control for this.
Underneath that I need to be able to create a composite image that can be pinch zoomed and panned and has hotspots that can be clicked (tapped) on. For example, an image of the solar system, in which the background would be static, but the planets need to be placed at runtime and need to be clickable, and the whole thing needs to be pan/zoomable. Support for very minimal animation (eg slow planet rotation) would be a plus, but not necessary. I'm at a loss on what I would achieve this with.
Finally, there are three pull-out panes that contain other content, such as images, menu items, and other media. Basically these just need to be containers in which I can place any other UI content.
I've done some basic Activities so far with simple forms, so I understand the basic workflow of Android, but I'm just not sure what to look at to achieve something like this. Is this a good candidate for a SurfaceView? Is there something else I should look at? I have been a bit afraid to get involved with OpenGL, since I don't really have a 3D background, and I still want to be able to use native components (buttons, listboxes, etc) without having to re-implement them in OpenGL.
Have a look at this for the slides:
http://developer.android.com/training/animation/screen-slide.html
as for the thumbnails you can use a linear layout, with some imageviews and buttons.
I am programming an android game that has a screen, which has a ScrollView that contains almost everything on the screen. I need to have image elements that move around, can be clicked on (but also be transparent to clicks in certain situations) that have multiple layers and animations.
Should I use layered Imagebuttons? there can potentially be doezens of them on the screen at once, and i don't know if there are memory concerns about having 200 imagebuttons on a screen.
Do I need to use a canvas? I have seen canvases in many examples, but i don't know if they are the best option.
Is there some other class or way of doing this that is better?
any help you can provide would be much appreciated.
You'd be best served by an Android game library. Check also e3roid.
I'm thinking about writing a pretty basic game, which mostly involves sliding images around on the screen when tapped. So tap an image and it slides to one side. Doesn't seem like Android Animations will help me here since those don't actually move the images, just makes it appear moved.
So even though this seems like pretty basic functionality, it seems like I have to write a game loop,etc and implement my own code to handle the "animation" (including some acceleration/deceleration), etc. Not hugely hard or anything, but just seems like overkill. Also using a 3rd party game engine also seems like overkill, just in the time it would take to learn that, and so on.
Am I off base here?
If anyone has any suggestions that might get me pointed in the right direction (links, etc) that would be great. Is there a good way to use Android Animation functionality in this case that I am missing?
If you are developing for Honeycomb, it may be as easy with animations. With Honeycomb, there is a whole new strategy to animation. Check out the blog. The premises is that any property or value can be animated, and that includes the view's actual position (and not just look like it moved).
I have built a couple of games using AndEngine (http://andengine.org) I would recommend it for making games for android. And since it is all written in java, it is relativiely easy to integrate it with layouts and other activities.
I have a couple of images on available to my program. They are parts of jigsaw puzzle (with rectangular pieces though). I wanted the look and feel similar to that of google maps in android.
One way I could implement was to create a set of ImageViews and keep recycling them, as the user pans the image in any direction. However, to me that appears like a brute force method. Is there any alternative approach to implement such kind of application?
Or rather how is google maps implemented? A set of Imageviews ?
I think for your case the OpenGL route might be the best choice. You can get started with the GLSurfaceView.
Using set of images and recycling them is a valid method. But you can enhance it by adding some redundant ones to keep close to view area images preloaded.