Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

I've been learning Android in my spare time, and one of the first things every tutorial/guide will introduce to you is the concept of an "Activity." Everyone loosely defines an Activity as a screen for doing a certain activity.

My question is, how relevant/important is it to have multiple Activities for a game? Are there any guidelines for breaking a game down into multiple Activities? To explain what I mean, let's take a game like Final Fantasy.

In Final Fantasy, you have several different screens that get used over and over and over again:

  • The world/dungeon map
  • The battle screen
  • The equip/skills/items menus

Would each of those be an Activity that you swap back and forth between, or would you redraw the screen within one Activity?

Let's say it is all just one "game" Activity --- this raises other questions, such as, what about a splash screen before the game starts that shows your company logo/name and plays a sound? Should that be considered part of the game Activity, or should it be it's own Activity?

share|improve this question
1  
Just out of curiosity, why aren't you using LibGDX or AndEngine that completely does all these things for you. –  Sidar Aug 8 '12 at 2:17
    
Because I just started --- to give you an idea, the last tutorial I did was making Tic Tac Toe, and so far nothing has mentioned either of those two things. –  CptSupermrkt Aug 8 '12 at 2:20
1  
Well I never really looked at the activity object. The LibGDX and AndEngine API don't really concern themselves much with the Android API on the surface( even though you can access it). I was able to run my simple test run in no time, without the knowledge of an Activity object. However if your focus is really to learn more about Android itself, keep at it! =D –  Sidar Aug 8 '12 at 2:24
2  
Also LibGDX and AndEngine are NOT official Google-Android libraries. They are made by other people. That is why your tutorial doesn't mention them as those two libraries are build on top of the Android API. Your tic-tac-toe was a complete different focus and was working with the Android API directly. –  Sidar Aug 8 '12 at 2:28
2  
No problem, you will save yourself a lot of headaches! But then again, if your intent is to learn more about android continue what you are already doing! ( I prefer LibGDX over the other, be sure to check it out it's awesome) –  Sidar Aug 8 '12 at 2:30
show 1 more comment

3 Answers

up vote 5 down vote accepted

I recently moved into Android development myself. I've got many years of development experience, but decided to wade into the shallow end of Android development.

Which means I was pretty much doing similar things to what you have been doing, but my perspective differs because of experience.

Having said that, I originally started out with the "one screen == one activity" approach, and quickly learned its limitations.

Which works after a fashion. Invariably, I will use some sort of finite state machine, and so activities became the states... simple enough, I thought.

Then I came to the realization that whenever I press the back button, I go to whatever the previous activity is.

This may or may not be a big deal to your game, but consider the following:

You are in the OverworldActivity(using familiar Final Fantasy-esque terminology), wandering around the world, when suddenly you have an encounter and go to the CombatActivity.

If, at this point, you hit the back button, your game goes back to the overworld.

And that is unacceptable to me, and I'm almost certain unacceptable to you.

Yes, you could put handlers into the Activities so that if you are at an invalid activity it sends you to the correct one, but really the better thing to do is to design activities with the "can I safely hit the back button and still have the game play make sense".

So, here's a scheme that is more likely to work for an FF style game:

  • MainMenuActivity(has the "start/resume", "instructions", "about")
  • HelpActivity (self explanatory)
  • AboutActivity (also self explanatory)
  • GamePlayActivity(does the world wandering, combat, and most other game aspects that cannot fit into the "go back" scheme, hitting the back button goes back to the MainMenuActivity, which makes sense)
  • InventoryActivity(you get here from the GamePlayActivity, and so it makes sense that you "go back" to the GamePlayActivity
  • ShopActivity (when you enter a shop/inn/whatever)
  • DialogActivity (presuming you can end a conversation at any time by hitting the back button)

And hopefully this helps.

share|improve this answer
    
Thank you very much for the detailed answer :) –  CptSupermrkt Aug 10 '12 at 12:05
add comment

Quoting the Android documentation, "An activity is a single, focused thing that the user can do."

So, for each type of gameplay/menu function, you would want to have a different activity. Your example with Final Fantasy is perfect. As for a splash screen, that seems to be a matter of preference, for example, you could have it integrated with the main menu activity, or have it as a separate one that chains into the main menu.

share|improve this answer
1  
Yea but that advice doesn't translate over well when you have to spin up a gl context every time you want to jump to another Activity. It's best to run a single graphics context and use a screen interface as is supported in libgdx and andengine. –  Rubber Mallet Aug 8 '12 at 4:34
    
Huh. I hadn't thought about gl contexts, since I've only done some rudimentary 2D programming on the android –  AohmZ Aug 8 '12 at 4:38
add comment

I may repeat myself, but this was my answer at a similiar question:

Have a look at Replica Island. It's written by one of the Google engineers. They use different activities for everything. But I think using one activity is way easier! Other games and some of the available game engines do it that way. The downside is that you have to implement behaviour like button presses etc. yourself.

And not only button presses but also the different states a game can be in, like splash screen, menu, playing etc. But since all the mentioned game engines are open source, download them and have a look at their code ;)

Sometimes I think that Google's idea of Activities confuses more than it helps.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.