Creating a UI via a class (for a game)

[kanaida]

Hey guys, I just recently started making a bunch of classes for an RPG game type of battle system so I could get a little more experience in game making. One thing that didn't really compute right in my head is how to handle game menu's.

Basically I came up with something like this:

Dim G as Game
G.initialize
G.MainMenu

What I wanted to do what not use multiple activities, seems kinda unprofessional looking. I was thinking just make a few panels, populate them via a few classes and simply make the one's i'm not using invisible while overlapped on top of each other. The other thing I was trying to avoid doing was any kind of real coding in the main activity. I wanted to go, here you go game class, do what you want with this activity, place your controls, draw your graphics etc... etc..

But I can't seem to find a way to just pass an activity to a sub.

eg.

G.CreateMainMenu(Me)

The the class would take over from there. Maybe i'm taking the wrong approach here, what do you guys think?

 

[Informatix]

What I wanted to do what not use multiple activities, seems kinda unprofessional looking. I was thinking just make a few panels, populate them via a few classes and simply make the one's i'm not using invisible while overlapped on top of each other.

If you want my opinion, it's exactly the contrary. Creating multiple panels and consuming memory in invisible panels is highly unprofessional. Look at the forum questions; it's what all beginners do.

In most games made by professionals (or skilled amateurs), all is done in the same activity because everything is drawn. When you need another screen, you erase the current one and draw the new one. Another reason is the loss of context when you change the activity.

About your menu, I don't know what to answer because your questions are extremely vague.

 

[Erel]

I don't see any reason why not use several activities for the menus. It will not affect the actual game performance.

 

[kanaida]

Hey guys, thanks. I will consider using different activities for the menu part. I'm just kind of used to seeing animated backgrounds, and animations during button presses with buttons that fade into the next screen etc... A little more console like is what I meant. In reality it's not that much more important, it just looks a bit more 'integrated'. Maybe I can just force the fade transition effect.

As for the other part, the actual drawing and game loop. I'm having trouble passing the activity as a parameter to my game class so I can draw stuff to it easily. It complains (because my game object is process global).

It was supposed to go something like this

[Process Globals] - to store my game object, and it's children inside it to keep the state the same.

[Main Activity] - used to display the objects, either as a bunch of views to hold the little game components such as clouds, tiles, characters, etc... but I wasn't sure how slow that would be v.s. some light code to draw all the stuff using a canvas to a bitmap, then draw that bitmap when completed, to the screen (double buffering).

A timer would keep track of how often to call .NextFrame() to advance the loop (an interval of 16 is roughly 60fps). I would stop the timer to pause the game.

Activity pause and resume would be used to pause the game and drawing or start it up again.

If possible without requiring the hardware acceleration manifest entry that needs jelly bean. People have been making games for much longer than when jelly bean came out, probably even without any acceleration and still managed to make things smooth. I'm trying to explore how to achieve that as well. Part of it is realizing, my old sega genesis easily achieved 60fps had a processor that ran at around 7.6Mhz, by contrast my android is 1180Mhz x2 so its interesting for me to learn all the tricks needed to get stuff to that level of performance.

 

[Informatix]

Hey guys, thanks. I will consider using different activities for the menu part.

If your menu uses standard views (panels, labels, buttons, etc.), it is maybe more convenient to use different activities for each submenu. But if you draw completely your menu (with graphic functions), there's no need to switch to other activities. You just erase the display and you draw another menu. As you want to do an animated menu with an animated background, it's probably the way to go.

I'm having trouble passing the activity as a parameter to my game class so I can draw stuff to it easily

That will be easier to understand with a bit of code.

but I wasn't sure how slow that would be v.s. some light code to draw all the stuff using a canvas to a bitmap, then draw that bitmap when completed, to the screen (double buffering).

To use this technique, you have to prepare your scene in a separate thread (because you won't have the time in the main thread). It's possible with a class named SurfaceView. Unfortunately, I know no library for B4A that wraps this class, and the technique is considered deprecated by Google. SurfaceView doesn't (and won't) benefit from the hardware acceleration, so forget the idea.

If possible without requiring the hardware acceleration manifest entry that needs jelly bean.

The rendering pipeline of Android benefits from the hardware acceleration since Honeycomb (3.0). Not using the HA is a very big mistake because that adds not only speed to your drawings, but also smoothness to their animation (JB, for example, uses a triple buffering).

People have been making games for much longer than when jelly bean came out, probably even without any acceleration and still managed to make things smooth.

That's right. These people use the OpenGL ES API. OpenGL uses the GPU for its rendering, so it is always hardware accelerated. On devices under Gingerbread or Froyo, nothing can beat its performance. That's less true since Honeycomb.
B4A has two libraries giving you access to the API, so you can try it.
OpenGL is complex and needs more than a couple of weeks to be learnt. Probably many months to be mastered at a decent level. Java users have an easy solution: they use a game engine. That eases a lot the use of OpenGL. Unfortunately, B4A has no game engine (I mean nothing that can really deserve this name) and the only class made with OpenGL to make it more easy to use has poor performance. It's a common problem with OpenGL: if you don't master it and cannot use at its best, you won't get the performance that you expect. That's why it's probably better to consider alternatives. There are two for B4A: GameView and Accelerated Surface. Try them and make your own opinion.