I am trying to develop several Android games that work on a grid system. I will need to update the game surface frequently, so using a GridLayout does not seem to be a good option. The frequent updates to the game surface would be similar to what you see in Plants vs Zombies: the user can interact with parts of the grid, but the sprites representing the computer opponent will always be moving until the level ends.

I want to sublcass SurfaceView but give it many of the built-in properties of a GridLayout (ex. I want to allow the user to drop a game object in a grid cell and have that object start animating within the bounds of the grid cell, so I would want row and column indexes built in to my custom SurfaceView) but that's a lot of work.

Do you now if something like this already exists?

Is it better to just use a "normal" SurfaceView and somehow keep track of where on the SurfaceView the grid lines should fall, maybe using a HashMap or something to track the vertices of all the grid cells? That seems like a lot of work and I don't want to reinvent the wheel if I don't have to.

I'm looking for design device or recommendations on free libraries (*.jar) that I could use to accomplish this goal efficiently. I'm coding in plain old Android Studio so no Unity access :(


1 Answer 1

  1. Don't subclass SurfaceView. Use composition, not inheritance. There's no value in subclassing it, and many basic mistakes (like overriding onDraw() when your goal is to draw on the Surface) are impossible if you don't.
  2. The View-based UI is rendered on a separate layer from the SurfaceView's surface. (The SurfaceView has a View as well, but generally that's just a transparent hole that the layout code uses to position things.) Mixing View elements with stuff drawn directly on a surface is viable but trouble-prone given the wide variety of device characteristics, so mixing GridLayout and SurfaceView isn't a good idea.
  3. What you have described so far doesn't sound that complicated to do, unless you try to reinvent GridLayout and all of the invalidate/measure/layout fun -- a simple regularly-spaced grid subdividing the surface should be easy. You can even set the surface size to a fixed value with setFixedSize(), though you still need to worry about the display aspect ratio. (demo)

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .