I'm making a board for Android. I use .png images for the board (background) and checker pieces. Basically, it's a game where the graphics are updated upon touch events. It's a school-assignment so I have to use View implementations. For the graphics I've considered two options:
Making a whole "BoardView" class (that extends View) and draw all the graphic components directly on the canvas using onDraw(canvas).
Using ImageView objects to represent each checker piece and the board and putting them on a Layout.
My intuition tells me to use the first method. But my thoughts are that I want to use the pre-implemented TranslateAnimation when a checker is moved. From my understandings; this forces me to use the second method, since I can't animate a Drawable.
Now, to the question: what method is best for me? And if the second; which Layout is preferred to use? I want to be able to overlap the checkers over the board image and compare the ImageView objects' positions to each other to determine where to put the checkers on the board.
Regarding to your simple requirement, I think you can adopt method 2.
Trust me, I have done this kind of stuff years ago, on a legacy linux platform. For these kind of simple game applications, you really do not need to bother with all the frame drawing stuff. Just stick with the existing UI widgets.
This is because the visible elements are all very simple, like cards, static images, blocks etc. You don't need to perform pixel drawing. I have tried to make tetris, mine sweep, and card match games. I even create simple visual effects for it using existing animation facility. That is very easy to do so.
And, of cause, as a software programmer, to write a game using the typical frame by frame approach is much more professional. But it depends on the requirements. Why not using less code to create more value?
Related
I'm working on a university project in which I need to visualize on a smartphone datas from pressure sensors built in an insole.
I need to draw on a View, as a background, a footprint, something like the image below but just for one foot.
I don't want to use a static image because with different screens resolution it could lose too much quality, so I'm trying to do it by code.
The main problem is that I'm not very skilled in graphic programming so I have not a smart approach to this problem.
The first and only idea that I had was to take the insole's CAD representation, with its real dimensions, scale it in function of screen's ones and put it together using simple shapes (arc, circle, ecc...) available in Android.
In this way I'm creating a Path which will compose the whole footprint, once I will draw it with a Canvas.
This method will let me to do the work but is awful and needs an exceptional amount of work and time to set every part.
I have searched for some similar questions but I haven't found anything to solve my problem.
Is there (of course there is) a smarter way to do this stuff, saving time and energies?
Thank you
of course, you can always use open gl es
this method might not save your time and energy but will give you a better graphic and scope to improve it for later purpose
the concept is to create a float buffer with all the points of your footwear and then draw is with connected lines on a surfaceView
to get started with open gl es you can use this tutorial : https://developer.android.com/guide/topics/graphics/opengl.html
and here is an example : https://developer.android.com/training/graphics/opengl/index.html
I currently have an android application that utilises the native android views for the UI (e.g. imageviews/buttons etc)
Although this app is not a game, nor requires any heavy graphics or OpenGL, I would like to incorporate a little physics-related interaction. Nothing too significant but maybe display minor collisions/bounces, deceleration/acceleration or possibly friction.
Is this possible to simulate either within the android framework or using an external physics library like jbox2d without having to utilize an entire game engine (like andengine, libgx etc).
P.S. this is for API 15+
Thanks all.
As long as you can set/update the position of the UI elements every frame (e.g. with View.setTranslationX()), you can do it.
Animating the UI by hand would mean keeping a mapping between the UI elements and the physical (e.g. jbox2d) bodies that correspond to them. Then you update the respective positions of the UI elements to what the simulated bodies have each frame (such as body.getPosition()).
In event-driven apps, something like a Timer object is useful for scheduling the physics updates.
The easiest way (not that flexible) is using ViewPropertyAnimator.
With it you can animate properties even in parallel. Maybe you want to change a view margin from the parent left. You can change that margin there, setting up the time to move and else. Some examples on this blog
ValueAnimator is other alternative, which uses the AccelerateDecelerateInterpolator by default and you have to provide the code that changes the property you need. This official guide may suffice to get them working.
what you want is quite impossible - your options are:
you may fake stuff like bounces with animations
you can implement a whole new ui lib
you use openGL what i would do
I think this can be achieved, at least at some point.
You have access to a pretty complete Animations API. This last, together with some view bounds, distance, and probably device orientation calculations, can be used to simulate almost all the cases you mentioned.
You can create Accelerate/Decelerate, form change... and almost whatever animation you want.
How you can achieve what you are asking for:
Having different animations, one after another, creating and applying them dynamically depending on the view item state. And by state, I mean the "physical state": falling, collisioning, in touch with another view, and so on...
1) I am developing an android application for a puzzle that will involve n*n matrix displayed to the user. There will be objects(images) in each of these cells. Whenever the user clicks on the any cell the object of that cell should exchange position with one of the valid nearby cells.
2) When the object exchanges position, the movement should be shown to the user - the image slowly moving from its original place to another place.
If the animation above is very difficult to implement, please leave it. But I would like to know the answer for the question 1). Which layout would be the best for such a puzzle, which will involve constant re positioning of the child elements(cells).
If it's game - SurfaceView is your way. It's good idea, because you can draw from different threads and it's comfortable. If you want to create not simple game, use engine as example AndEngine. So you can use GLSurfaceView - openGL is very fast but it's not simple. And last way use simple view, but my opinion - it can be game like XO, barley-break and other not fast simple game.
upd:
If I create this game as in your case, I will use SurfaceView w/o any layouts. But I think you can do it with help standart view w/o surface. If your question about layout, I think its not matter. For example GridLayout. As minimum it sounds logical.
Good luck!
You would have a greater control if you create a custom view using the View or the SurfaceView.
I am working on a similar n*n matrix game and I am using the AndEngine game engine. It allows me to load images and then place them in an n*n grid.
I'm converting a project that I wrote in AIR a long time ago to native Android. In AIR, positioning views was fairly easy in x,y coordinate systems. With native Android though, I am trying to approach this in a correct way, but I'm unsure how to approach.
My view will consist of two circles in the background, with small objects within those circles that can roll around. There will be another view drawn on top of the circles to make it seem like there is glass over the circle, entrapping the small objects. The small objects are bound to the background circles.
I guess what I'm really asking is canvas drawing the best approach here, or is a view-based layout workable as well?
It sounds like your best option would be to use a SurfaceView. This is basically a hardware accelerated canvas. On of the benefits is that you can overlay standard widgets over top of it if you need to so you can mix and match custom and standard components. Here is a link to a website that walks you through getting a SurfaceView up and running
Say I'd like to make a memory/pairs game. I have currently made a draft that works on a Canvas, and cards are drawn into a grid.
This works for my current basic version, but I'd like show do an animation (when the card is turned, it will flip around and scale to higher size; or when the match is found, the cards would rotate around and then go back.
I can't imagine doing this on Canvas, I'd have to make a lot of timers and do the animation by hand, it seems overly complex for this simple task.
I think I could could subclass View for a control that would display a card, and then react to touch events for that control. It would also make drawing scaling of the images done by Android itself, and, most importantly, I could use Tween Animation for some effects.
My question is - would it be OK to use a View for each card in the game (I could have 5x6 or 4x5 cards), and arrange them in a GridView? Are there some pitfalls with this approach? Or should I continue with completely custom-drawn Canvas?
For such a simple game you should be fine using a collection of Views. As you mention using Views rather than trying to do it manually you get access to a lot of nice Animation functionality for free.
It also makes implement the user interface a lot simpler as you can just add onClickListeners to each view to capture user touches. If you're drawing it all manually to a Canvas then you'd have to interpret the touches yourself and decide which card was touched etc. While this isn't too hard, then I think subclassing View is a better model and will most likely result in cleaner code.
As you are only going to have 30 cards, then I can't imagine you having performance issues either - if you were thinking 100+, then maybe you'd have an issue, but I think you're fine. Also, if I understand your game correctly, the majority of your cards won't be animating most of the time so that's yet another reason not to worry - if you ever run into performance issues with the animations you can easily save off all the unanimated Views onto a Bitmap (Canvas) for the duration of the animation.