According to the LibGDX web page:
Android applications can have multiple activities. Libgdx games should usually only consist of a single activity. Different screens of the game are implemented within libgdx, not as separate activities. The reason for this is that creating a new Activity also implies creating a new OpenGL context, which is time consuming and also means that all graphical resources have to be reloaded.
However, this isn't impossible to do - just undesirable.
I'm building an app that is designed to hold a few games built in LibGDX, as well as some information alongside it - video/audio, text with illustrations, and so on, describing the development of the games.
Is it a better idea to build this as a native android application that launches and tears down LibGDX whenever the user wants to play a game? Or should I write the entire app through LibGDX and do try and do the non-game stuff using UI libraries and so on?
I'm sorry I can't nail this down to a more specific question. I'm really interested to know before I embark down the wrong road.
The consensus in a linked Reddit thread here is that setting up and tearing down a LibGDX activity isn't such a huge overhead, particularly if the games are small (which they are in my case).
I'm going to opt for this solution, and simply shut down the activity whenever the user stops playing a game.
Related
I have made a light weight java web-server serving html files and static content (made with pure java library nanohttpd), i have successfully made a javaFX launcher window that has a single button, clicking button simply runs the server in the background and opens the localhost URL in Android/PC browser (I was unsuccessful in making an IOS version using javaFX)
I am thinking of using libGDX as "launcher window" because of IOS support and access to mobile specific hardware like SMS/GPS which javaFX don't have.
I am targeting IOS/Android/PC, I'd like to ask libGDX developers how possible is this given my target platforms?
Yes you can
There's a catch though, you may have to build the UI the game dev way
I've made a game or two using it and had rather steep learning curve in the beginning to get a hold on to how it worked. For example you'll have to provide the images for button, background and also, the pressed view of the button... like that. But your app is not a game. So you won't have to worry that much.
Once you learned how to place them in the screen successfully, there is not much to worry about because the API provides everything you need to carry on from there.
Also I found enough resources/tutorials online enough to make a game from ground up. So you'll definitely can.
And there's very little to worry about your multi-platform problem.
I have a simple kids app which teaches things such as colors, numbers, etc... which I am currently developing. It uses what I would consider "standard android java programming (Single Xml/java class)." I also have a simple game with a Dinosaur that jumps over letters using libgdx.
My question is, I would like to have the game as part of the "overall" app. I would like to know if it is even possible to add a libgdx game to an android native application. I tried adding the appropriate files to my app, but this caused a compile error, could someone point me to a place where I could find help on this issue, or perhaps let me know if what I am wanting to do is even possible? Thanks.
---To clairify, my main app has a menu which takes you to activities. I would like the libgdx game to be one of the activities.
---Edit to response---I compile using Gradle and have more errors than I can count. I've since removed the libgdx game from the app so I am not sure of specific errors, but iirc there were over 100, many of which were R issues, which I could have figured out, but I couldn't find anything on either S.O. or the web saying it was even possible to add libgdx to a non-libgdx app.
You can integrate your App with your libgdx game.
AndroidLauncher.java is your libgdx Activity and you can move from one activity to another using Intent.
intent = new Intent(this, AndroidLauncher.class);
startActivity(intent);
and movement from libgdx AndroidLauncher.java, you need to call it from inside the core project classes. You need to use an interface.
https://github.com/libgdx/libgdx/wiki/Interfacing-with-platform-specific-code
If your game is sub view of your App.The AndroidApplication class (which extends activity) has a method named initializeForView(ApplicationListener, AndroidApplicationConfiguration) that will return a View you can add to your layout.
Pros.-Code is already you have,only you need to integrate.
Cons.-you need to maintain OpenGL Context Loss. Libgdx do for you.
In Libgdx your entire game is just a single Activity. You can start it as any other activity from your code.
Please follow Can I run an Activity before running libgdx? for details.
The reason why most people would ever make their android project in javafx would be to have the same codebase across different platforms (such as ios, desktop, android, maybe even web using Bck2Brwsr/teavm/doppio)
But my question is, is there any advantage in javafx ui framework itself when compared to android ui framework?
I have never ever written even a hello world application for android, but I intend to do it now. So I am wondering if having the code in javafx is worth the effort when I can develop directly on android apart from the benifit of portability.
This type of question might result in a subjective/opinionated answer but I think it is a good question so I will provide my assessment.
Having the same codebase across all those platforms is huge. Do not dismiss this. I'm using Gluon Mobile to port aspects of the Deep Space Trajectory Explorer (DSTE) to Android and iOS. As you can see from the video its extremely complex application. There's no way I would rewrite that in native Android... it would be a no-go from a cost perspective.
Starting development from JavaFX makes it easier to make complex visuals. I don't just mean traditional 2D GUI forms. Again looking at the DSTE you will see we use Canvas to do dense renderings and JavaFX 3D along with the FXyz library to do 3D renders. These things are easy in JavaFX and again using Gluon simply "just work" on Android/iOS. In fact it only took about a day to get those aspects of the DSTE code base to work on a Pixel C tablet, most of which was getting the Gradle build setup properly. Now imagine having to port 3D code from JavaFX to a Native framework? I'm a 3D guy and I still wouldn't try it.
Testing is so much easier on the desktop than a mobile device. This doesn't mean the testing is 100% on desktop. Sometimes something that works on desktop "doesn't work" on the mobile platform and you have to tweak accordingly. However you can save a LOT of time standing up the application using JavaFX knowing that 90% of it will work the same on your mobile device.
Word of advice though... remember that a desktop application is NOT a mobile application. You will be tempted to just "port" your desktop app to your device. I was my first time. You can get into other issues where the interfaces and layouts you design for a desktop "work" on the mobile device but are not appropriate and so the usability goes down. Start slow when you port. Think of what aspects of your desktop workflow should be mobilized. Only port the things you absolutely belong in a mobile workflow. Save yourself some headaches.
I'm working on a game which would work both on the web, as an applet, and on the Android phone, as an app.
Is that possible to do, and if so, what do I need to be aware of to make that work (i.e if there are any settings that I shouldn't hard code and instead determine them based on the user's device when the game is run, or any java libraries that I shouldn't use?).
Also, the game needs to accept touchscreen as input for the Android app. Is that possible to build into the same game which will also be run as an applet? May be so at run time, the applet decides whether to use Mouse or Touchscreen for the input when it is run?
Although Android apps are written in Java, the framework around the app is extremely different of the framework wrapped around an applet. You won't be able to have one .jar file that you can include as an applet and throw at an Android device because that's just not how it works.
You will however probably be able to create all the game logic and objects and have them in be shared with the applet code and android app. You can probably even get away with having them in one repository and project (although it's probably going to have to be an Android project that you then wedge in your app build scripts).
In order to tackle the different controls for your game you are probably going to have to abstract away the input, and have your game/level object have a call back like userHasPoked(int x, int y) and then have the applet call that method on click of the mouse and the android app calls it on touch (which is oddly still called onClick).
I think it'll be a long road, but much easier than rewriting the whole thing. It'll probably seem like a lot more work up front, but once you are done wedging your code into an applet and an Android app, you'll probably "never" have to touch that code again and can just keep adding to the game.
I wouldn't underestimate the task, but that sounds like a very fun programming exercise. Good luck!
What kind of game do you develop? It may be the better approach to develop an Javascript game.
That can be installed with phonegap (cordova) onto an android device.
Let me break this for you....
Model - The Business Logic and Data
View - The Display of the Output of the Model
Controller - On which the action is done.
The advantage of using this MVC architecture is that, you can keep the same model and keep changing the Views.
So keeping this idea in mind, you can have the same model for both the Web App and the Android App, and then implement each others Views to it respectively.
I am going to be writing a tower defense game for Android phones. I have knowledge of Java and the Android SDK; however, I am new to animation and have a few questions about where to start.
I will be using only 2D graphics (maybe later down the road 3D graphics but for now I will keep it simple), have basic animations (enemies moving along pre-determined paths, stationary towers shooting at moving enemies, and maybe a few explosions here and there), and some sounds that result from different in game actions. Just to give you a rough idea of what I am thinking about, my game would be very similar to bloons tower defense 4.
My question is, based on what I have stated above would you suggest I incorporate Flash, HTML5, or Android's native animation libraries? What are the pros and cons of using each one? If none of these are good options than what is?
I'd suggest using Android's native libraries. Adobe has already said they're not longer going to support flash on Android so you'll slowly users over time. And beside, Android's native libraries are going to give you better performance anyway. In addition, there are some really nice frameworks out there that make developing games on android with OpenGL super easy (see andengine or this Gamers post for more details).
As far as HTML5 goes, I'd say stay away from it. Most users prefer a native app over a web-app and I can almost guarantee you that you're going to get better performance with a native app.
1) If you are going to make games, use definitely the Java. It is fast, there are plenty of game physic libraries, you can use OpenGL and you can even use C ports of some famous game libraries. You are simply not limited.
2) The HTML5 is pretty slow so far and no matter how good it is for mobile web pages, it is not sufficient for more complex games then Tetris or Sudoku. Just try some HTML games on couple of Android devices - nothing is better then own experience.
3) Do not start with Flash - Adobe company closes the Flash support in mobile phones. See there or there. This is releted to the Flash support in browsers.
4) As mentioned in one comment below - the Adobe AIR is other possibility and different story then Flash in web browser. This is Flex based technology (Action script + XML). It allows you creating standalone applications - we have 2 apps with AIR, but the AIR framework is slower then Java, it does not run on certain devices (low-end Androids), you must purchase the Adobe IDE and the developers base is smaller, so it is harder to find answers if you are in troubles. There is no clear advantage over Java, unless you plan to release also for desktop.
Regards,
STeN