I'm working on implementing an android version of the board game Cloud 9. I have never designed games, android apps (except 1-2 hello world apps) or even programs with GUI before (did a lot of CLI), and I have some questions regarding the design.
The game is turn-based, so there's no real-time considerations here, and I was wondering what was best to do. The game consists of pretty simple 2-3-options selections for each decision the player has to make, and for starters I want to make it "text-based", i.e., have a TextView with the game "log" on it and whenever the human player has to make a decision, he is given 2-3 buttons with the options he can play. The game consists of several rounds and levels.
I started out implementing the game "core" without a GUI altogether and with AI players. I then tried to figure out how to allow for human players, GUI, etc. My current design idea is a GameEventListener class which will be informed of different events in the game (round begins, round ends, a certain player did a certain action, etc.), and have the activity implement it and thus it can draw/write to the screen what happens, etc.
However, I'm not sure if this is the best approach, and how the Android part should be implemented (for example, I would like that after some events, the player will have a "continue" button, so he can see what was done before the game continues - how do I wait for the button to be pressed? If I return from the listener function, the game will continue). Any suggestion on how to proceed?
You can take a look at my Tetrads Drop game here for GUI and some of my approach
http://code.google.com/p/tetrads-drop-lite/
It is a tetris clone and can play with another player over the internet. If you need help with some GUI code, Ed Burnette's "Hello, Android" is a good book to start.
Updated
It is quite similar to what you are designing.
There are these package hierarchies
-com.aunndroid.Engine (handling game logic)
-com.aunndroid.View (managing 2D Views)
-com.aunndroid.Tolk (communication between deivces)
Since your game is turn-based, then I think design such as GameEventListener is OK.
Basically,this kind of GUI can be implemented by replying to the events. You can assign each UI component your listener.
For example, button.setOnClickListener(Your listener class);
For different buttons, you can create different listener classes for them respectively, and you can collect them in one GameEventListener as well. If the operation reacted to the events is not complicated, we can even use anonymous class:
button.setOnClickListener(new View.OnClickListener() {
public void onClick(View v){
//do your operations here(e.g. get input, update UI)
}});
Related
I have been learning OOP for about 2 to 3 years, but I am still really confused about interfaces.
In Java for example there is an interface called View.OnClickListener.
Now I know the class which implements this interface will have to provide body for its abstract methods, but what I do not get is that in the API documentation its written that the onClick method is called when a view is clicked.
So who calls this method? Is there any other class which implements the interface and then somehow call the method when view is clicked?
Link (https://developer.android.com/reference/android/view/View.OnClickListener)
You are probably a lot less confused about interfaces than you think.
Basically, GUI frameworks like Android's view framework, classic Java Swing, JavaFX, Eclipse SWT and so on are all big and complicated1. But they all work by turning the application "upside down". Instead of your application code controlling everything, the framework is in control. Your application registers a bunch of listeners or "call backs". Then it hans over control to the framework, and waits to be called back to do something.
The GUI framework will have a master "event thread" that reads the stream of low level events coming from the device (clicks and movement from the mouse, or touch screen events, key presses and release on the keyboard, etcetera). For each one, it maps the low level event to the appropriate part of your application, and then calls your application to say something has happened.
Suppose that an Android user taps her finger on the screen. The framework will translate the touch screen event's physical screen position to virtual screen location of some "component" of your app. If that the component was a button, and you had (previously) registered an OnClickListener for that button, the framework would find the button, and call the listener's onclick() method to tell your application "this button has just been clicked".
It is all rather simple and elegant ... and good sound OOP. But the relationship between your code and the framework is upside down to what you would expect.
1 - and too complicated for most people to fully understand. Though in fact, you don't need to fully understand them to use them.
Those methods are called by the Android framework itself. This is one of the useful things the framework does on your behalf, so that you don't need to interpret raw user finger input and figure out what constitutes a "click"!
From https://developer.android.com/guide/topics/ui/ui-events (my emphasis):
Within the various View classes that you'll use to compose your layout, you may notice several public callback methods that look useful for UI events. These methods are called by the Android framework when the respective action occurs on that object.
For onClick specifically, that same page says:
This is called when the user either touches the item (when in touch mode), or focuses upon the item with the navigation-keys or trackball and presses the suitable "enter" key or presses down on the trackball.
I'm currently working on a UI Engine called PlaneUI
To give you a basic idea, it's a touch UI system where the entire screen is made up of "Planes", which can show content, as well as be used as buttons. (Additional Info Below)
When the user is not interacting with the screen, he/she sees a continuous surface of content (which is actually made up of Planes), but when the user touches a Plane, he/she can differentiate the individual Plane, and see it being pressed down like a button. The point of the system is to eliminate the need for clunky on-screen buttons and allow a very elegant design whilst maintaining rich touch feedback. Screen transitions are shown using these Planes as well.
To make development implementing this system feasible and make it open to other developers, I made a class called PlaneView which extends SurfaceView which internally handles all of the Plane management. The only thing that needs to be added by the developer using this engine is the content to be drawn on each Plane, and what happens when these Planes are pressed, released etc.
Currently, methods within PlaneView, such as draw, press, release, etc. are called when a Plane is drawing its content, gets pressed, released etc. However, in this case, developers need to go into the PlaneView class and add code into the declaration of these methods, such as the content to draw, and actions to be taken when pressed, released etc.
Is there any Java programming mechanism(?) I can use so that developers can define these things within their own classes?
I apologize about the excessive use of abstract language. I'll take any advise about terminology or my possible misconceptions about the Java language (I've been programming with GML on Game Maker Studio, and started Java only recently)
You can make PlaneView an abstract class that has abstract methods onDraw, onPress etc. Developers using PlaneView would have to extend PlaneView and implement the relevant methods. Make sure to be careful with what is private, what is protected and what is public within PlaneView.
public abstract class PlaneView {
protected abstract void onDraw();
// Similarly for the other methods ...
My question is more about general design and code flow, rather than a specific issue like syntax. How can I take an existing game (a fighting game, kind of like Pokemon) and add a GUI to it? I've done very simple GUIs before, so I understand the concepts of adding a frame, selecting a layout, and adding panels, buttons, images, etc. I'm not stuck on the details. Rather, I don't know where to implement the GUI.
Is it best to create a class or classes for the GUI, and then create instances of those classes within my existing code? Or do I go the other way around, and have the code within the GUI drive the game forward?
I also haven't used event driven programming before. How does this fit into the structure?
You might want to read up on the Model-View-Controller pattern.
Take your existing game and turn it into a library of objects that maintain the game state through the various actions the players can make. This will be your "Model".
Then create some graphical elements that will display the game state to the user. This will be your "View".
Finally, you will need some user interface elements that allow the user to update the game state (buttons and such). These will have callback or events in which you will put the code that calls the methods in your "Model" object to update the game state, and to update the "View" objects as necessary. That's the Controller.
I'm building a game using Java for a university project. The game had to use a textual interface at first, and only later we had to add a GUI.
I have a thread running the game logic and updating the game model, and a separate thread, the one with the main function, having the JFrame instantiated on, where I then switch panels according to the game state (the controller tells the gui which frame to display with a setPage method).
Getting the user input, however, is what is driving me crazy now.
With the textual interface, all I had to do to get the user input was to call a method, something like getPlayerNum, and after the user put in the number and pressed enter I would have the input back to the controller.
All the game logic is implemented in a game loop, asking for input when it needs it and notifying the output to the view.
How can I emulate a similar behavior now that I'm forced to use a event-based gui?
How can I block the method call until the user clicks a button, and then have the method return the correct value?
Kudos for developing an independent game model. As a prelude to designing your GUI, start with this very simple game. Add a TextView that listens to the model and reports on game progress. This will help you see how the GUI works, and it may help you decide what additional features you may need in your model.
So I'm new to Android, and have been having some difficulties with understanding threading/Android UI updating and such. I have some code for a simple game engine I made for an AP computer science final project and I have been trying to make it into an Android app. Coming from the java world I'm not used to threading or worrying about how much time or where a calculation is taking place so I've been having some difficulties getting my game playable. After a splash screen and a main menu, I have it set up so an activity named "Play" starts. In this activity I have found that I can initialize my game engine object(which gets passed from class to class), create an object I created to make an AsyncTask("GuiThreader" in the code linked below) but as soon as I throw in some code in "Play" to do anything more than that (like initialize a button, or start the threader helper class) I get an "Activity has Stopped Unexpectedly" error meaning I'm doing something wrong. I've been looking at a lot of the Android example code but its making little sense to me. So I guess with all that background my bigger question is how can I get this code working? More specifically where should I have my loop that checks when the game is over, and how can I update my button colors outside of the "main" threader to keep it from crashing.
Here is my code:
"Play" Activity (with lines of code commented that I was testing with):
http://pastebin.com/K5kFsMvG
"GuiThreader" used to make the game calculations an AsyncTask: http://pastebin.com/306eUYfq
"GUIdriver" used to call a class that updates the button colors: http://pastebin.com/RANZBH38
"ButtonColorUpdate" saves a value for buttons and updates their colors: http://pastebin.com/qN2fw1RC
If you need anything else just comment and I'll put it up. Thanks in advance for any help!
Start by reading this. Then I'd recommend looking at the code from Replica Island. There's a ton you can learn from studying the code of this project. If you want to interact with GUI "stuff" from a separate thread, a Handler (see the API) can be useful for sending messages between the two.