2d mobile game development: OpenGL ES 2.0 or cocos2d-x? - java

I plan to build a game for mobile. My target platforms are iOS and Android. I hope to be able to carry out testing on windows and/or linux. I'm a bit over my head in this as aside from general game development experience, all the technologies are fairly new to me. I've done a decent amount of research and have concluded that the game should be written in/ported to C++ to ensure that most of my engine can be easily ported to multiple devices.
Another thing I'd prefer is to write the game initially in java and port to C++ since that's where I'm most comfortable and will get it done the fastest.
Now I have the issue of choosing whether to use a game engine such as cocos2d-x, or to write the engine from scratch and use OpenGL ES 2.0 for rendering. Initially I thought it would be better to use cocos2d-x since I don't have a lot of experience with OpenGL. My problem with using cocos2d-x, however, is that since I want to write the game initially in java, that I'm going to have a hard time porting the engine to conform to cocos2d-x (or I'd have to learn all about the cocos2d-x engine to begin with and then write my engine to mimic the cocos2d-x engine.. seems redundant).
Upon further consideration, I thought that writing my own engine using OpenGL would actually be the better option. I'm able to use the PowerVR SDK along with JOGL to emulate a GLES environment. Also it seemed nice since I would be able to allow GL to do most of the work for me in terms of collision detection and transformations. My only issue with this is that since the game is going to have multiplayer support as well, the GL collision detection and such is basically moot since I'm going to have to do collision checking server side anyway to prevent the game from being easily hacked. Of course for the single player game play this method is viable.
Obviously this decision is subjective and depends on my personal preference, though I hope to have given enough background for some more experienced persons to lend their opinions.
That being said, my question is: given these parameters - would it be better for me to use cocos2d-x and suffer the head trauma of building the game from the ground up in C++, or would it be better to write my own engine initially in java and struggle through the OpenGL aspect of it?

Building your own engine from scratch would be too much of a work and would attract lot's of bugs to creep into. The tried and tested engines are better choice in my view. The porting would be far more easier to do, since you would be having a working game.
I am using Marmalade engine currently and I am quite happy with it's performance. It gives you direct access to the OpenGL libraries, although I've never tried it. You should give it a try too, although it's not free, but the 90 days evaluation license is free to check it out.

I've decided to write it from the ground up in c++ using cocos2d-x. It hasn't been as bad as I expected.

Related

How to use LibGDX?

I am just getting started with coding and app development using LibGDX and i´ve got some general and some more specific questions about it.
Before I start: I know that some of my questions might have already been asked somewhere on the internet but I found it really hard to get a straight answer to them.
So, the most basic question first:
Is it possible to create an average application (like angry birds or doodle jump) in LibGDX in a reasonable amount of time?
Browsing the internet I came across many people stating that engines like Unity are "just so much easier to use" and that you can create a game in a fraction of the time it would take you to code a game in LibGDX.
Is that really the case?
My second question connects to the first:
Is LibGDX really worth the time? Picking up any engine or Framework seems like a lot of work, so I wondered if LibGDX is a growing platform worth learning or just an irrelevant framework of many.
The third question is a bit more specific (and the most important one for me):
How can I make LibGDX game pretty?
I know, that sounds weird at first but looking at hundreds of apps in all kind of appstores I´ve noticed that most unity apps look really neat whereas most apps found in the Badlogic gallery look just awful to be honest.
So I wondered is there a simple way to add animations, particle effects, shadows, etc. to a LibGDX application. If I was coding a 2048 clone (just as an example) how can I make my tiles slide together and blend nicely?
Creating good looking animations is something I struggle with the most...
(If you want you can have a look at what I created)
I would really appreciate any answer to any of my questions!
Thank you for making it through this huge post.
MrMorph
Question 1:
If you're good at LibGDX and know quite a bit about the API, it would be easy to make a game like Angry Birds or Doodle Jump. Unity is easier to use, because GDX doesn't have a GUI editor - meaning you have to position things using coordinates.
Question 2:
I think LibGDX is worth doing. It's free and royalty-free, which is good unlike Unity, and it's on Java so it's relatively fast.
Question 3:
To make particles, there's a 2D and 3D particle editor which you can download of the LibGDX website or run from your IDE if you import the 'tools' module. For animations, you can make sprite-sheet animations easily with the Animation class and you can move things around smoothly (for your 2048 clone) using functions like MathUtils.lerp() to smoothly interpolate a value to another, over time, slowing down as it gets nearer.
A late answer, but hopefully someone will find this useful.
Checkout my answer to a similar question here: What I need to get android game with graphics like this?
I've used both libgdx and Unity and talk about my experience in the answer. At this point I'm in favor for Unity for most small/medium sized games. The editor really does make development much easier (especially for a one-man team). Libgdx + Overlap2D + Ashley (entity component system) is basically a very light-weight version of unity imo. Going the open-source route, you will definitely learn more since you'll be more involved in gluing these tools/concepts together. To answer your individual questions directly:
Question 1:
There are many good games made with libgdx. The reason you see a lot of crappy looking games in Gallery is because the submissions are sorted by time. The gallery does not prioritize good games to be shown first, this was a community decision a while back. Engines like Unity of course show off the best games first. To see some good looking libgdx games, checkout games by Robotality. Also, take a look at the "Showcase" section of libgdx forums; sorting by reply count will show some interesting games made in past few years.
As for the the claims that Unity is easier to use, I agree. I've made the switch myself just because how easy it is to come back to a project after months, and just starting playing around with it. Not as easy when your game is mostly code.
Question 2:
Libgdx is the better way to go if you want to learn. Because it's a framework, you'll be dealing more closely with the components that make up a game engine. You'll be putting your own game engine together with the APIs provided. Unlike Unity, you'll have to choose whether you want to use an Entity Component System like Ashly. You'll decide when physics engines get updated, when you render, how you load and manage assets, etc. Once again, unlike Unity, there is no enforced structure in place.
You'll be spending time reading libgdx's very well written source code as well as the excellent technical github documentation. I'd say the overall effort to make a game is greater when using libgdx, because of the learning. It's great if you have the time, but can be frustrating if you're developing only once in a while as a hobby.
Question 3:
The question is a little unclear. As I've stated above, there are plenty of crappy looking games made with unity, they just don't show them on their gallery/showcase game. Plenty of games with bad art are made with all popular game engines.
Libgdx has the things you want: checkout Interpolation functions for smoothly controlling object movements, particle editor to create & load particles, not sure about shadows (for 3D?).
Hope this will help someone decide what tool to use.
Yes it is very possible to create a simple game in libgdx. I used to use this framework all the time. If you are semi new to it YouTube has some awesome tutorials.
Now I use unity primarily, and here is why:
It is easier from a productivity standpoint yes.
Libgdx can be a lot of work when trying to work with graphics.
Plus it was an easy transition from Java to c#.
And yes in most cases unity can move a bit faster, again from a productivity standpoint, in libgdx there is more of a process to setting up graphics and viewports and etc.
libgdx is 100% worth it. A big part of what libgdx helped me with was grasping how the backed of these applications work. This has helped me a great deal in debugging problems in unity and just advancing my knowledge overall.
If you have good graphics and understanding of the framework then you can make a libgdx game that does look beautiful. The difference is that unity simplifies the process for you. And all the demos you see are from a huge pool of projects. With libgdx being such a good start to game development, there are going to be plenty of projects, with no proof of how much work and or time was put in.

Sharing a library between android and a PC application

I'm trying to design a side scroller for android and a level editor for windows. A lot of the code between the two programs will be the same. The bit I'm currently working on is drawing textures.
What I currently have is a library that includes code related to loading and drawing the texture information. The bit that I'm stuck on is how would I incorporate OpenGL (for windows) and OpenGL ES (for android) into the library?
I thought about having an interface that includes all the drawing functions and then implementing that interface separately within each program (since one will use OpenGL and one OpenGL ES) but that still produces a lot of duplicated code (and kinda defeats the purpose of trying to create this shared library).
Is there a better way to approach this problem? Am I just over complicating this by trying to make it too flexible? I have been thinking about this for a few sdays now, so any input would be greatly appreciated!
Please ask if anything doesn't make sense!
OpenGL and OpenGL-ES are similar enough, that you can share large amounts of the codebase. Since you're probably going to target OpenGL-ES-2, you will then probably use OpenGL-3 on the desktop. OpenGL-3 has a lot of what OpenGL-ES-2 has. So I suggest you develop your code primarily for OpenGL-ES-2 and then only for the small differences toward OpenGL-3 you add alternative codepaths.

Game development: "Play Now" via website vs. download & install

I've spent some time looking over the various threads here on stackoverflow and while I saw a lot of posts and threads regarding various engines that could be used in game development, I haven't seen very much discussion regarding the various platforms that they can be used on.
In particular, I'm talking about browser games vs. desktop games.
I want to develop a simple 3D networked multiplayer game - roughly on the graphics level of Paper Mario and gameplay with roughly the same level of interaction as a hack & slash action/adventure game - and I'm having a hard time deciding what platform I want to target with it. I have some experience with using C++/Ogre3D and Python/Panda3D, but I'm wondering if it's worth it to spend the extra time to learn another language and another engine/toolkit just so that the game can be played in a browser window (I'm looking at jMonkeyEngine right now).
For simple & short games the newgrounds approach (go to the site, click "play now", instant gratification) seems to work well. What about for more complex games? Is there a point where the complexity of a game is enough for people to say "ok, I'm going to download and play that"? Is it worth it to go with engines that are less-mature, have less documentation, have fewer features, and smaller communities* just so that a (possibly?) larger audience can be reached? Does anyone have any experiences with decisions like this?
Thanks!
(* With the exception of flash-based engines it seems like most of the other approaches have these downsides when compared to what is available for desktop-based environments. I'd go with flash, but I'm worried that flash's 3D capabilities aren't mature enough right now to do what I want easily).
Download and install is a harder sell. People are more reluctant to do it, and once they have done it, you own the problem of platform compatibility, and you have installed code to update or avoid as your game evolves.
Java applets eliminate all that mess. Presumably also flash or html5.

Best Java 'framework' for LOW-END 3D Graphics?

I've made my share of 2D games on various platforms but I have never developed a 3D game.
I want to make a small "mmorpg". I already made my server in python and it works just fine with my flash 2D game but I decided I want to step it up and try out 3D. I want to make a 3D game for the web browser and I think Java might be a good choice for this.
So basically I'm just looking for a straight forward and well documents 'framework' to make LOW-END 3D games. Keep in mind that I will be targeting peoples with very low-end PC's (plus my 3d modeling skills aren't great so I wouldn't mind hiding it somewhat, haha)
If you care to develop your own software 3D engine, which is pretty cool, Developing Games in Java is a complete walkthrough, step-by-step, of developing a 3D engine in pure Java, capable of rendering textured and lit polygons. You learn a lot about the math involved and you realize that it's really not a terribly hard thing to do; in addition, the engine is all yours, so you know it inside and out and you don't have to learn an API. On the flipside, it might be outdated. It's been sitting on my shelf for a number of years now, but it is made with Java 1.4 so it's not all too old.
Otherwise, I would definitely recommend JOGL or its competitor LWJGL; however, both require OpenGL knowledge, so if you want to just deal with loading 3D models and moving them around, jMonkeyEngine could be a better option for you. There is also the lesser-known Xith3D engine, somewhat a competitor to jME, though it hasn't been updated in over a year.
P.S. Ever seen RuneScape? It used JOGL, though now I think they switched to their own port of only the OpenGL functions that their code uses, kind of like a stripped-down version of JOGL.
JOGL would be a good possibility. You could look at the older "Java3D" framework as well.
You might want to check out the jMonkeyEngine.
I would advise against Java3D. We're using it for a project and frequently run into gotchas. If we had the resources, I'd migrate to something else in a second.

C vs. Java for game programming [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I understand that C++ is generally considered better than Java for games (at least larger-scale games). Why is this?
What is keeping Java from being competitive in this field? Which reasons against using Java for game programming have the most basis, and which ones are myths?
EDIT: Am a bit unfamiliar with C/C++, and did not think to differentiate between the two at line 1 >.<
The reason Java (and C#/.NET) is not a viable option for AAA titles at this point is the established game engines and their toolchains are written in C++. Game development is all about getting a title on the market in the shortest amount of time, and budgets don't allow for piddling in things like a new language/engine when several are already available, work well, and have an extensive set of editors and tools backing them.
Moving to Java (or C#) would also require a new performance-driven JVM (or CLI) across the big-3 (PC, X360, PS3) or big-5 (add Wii, iPhone). It's technically doable, but not financially viable.
Edit: Anyone with low-level knowledge of both virtual machines and the current state of game engines can tell you that a JVM or CLI could unquestionably be implemented with a new game engine to beat the performance of current C++ engines. The preventing factor is time and money, nothing more and nothing less.
High performance and the inertia of C and C++ traditionally being used for games.
Choosing based on performance isn't that big a priority unless you are making a 3D extravaganza.
Because:
Java is not compiled to native code, meaning that there is a performance hit the first time the code is run.
Java does not give you a predictable memory model (console games need this)
Java does not give you deterministic object finalization.
Java is not as close to the hardware as C is, an essential for a lot of professional 3D game programming.
Console programmers likely don't have a JVM that runs on the PS3, X-Box, etc.
Runtime performance penalties.
You will never be able to squeeze as much performance out of a Java app as you can with a C++ app.
There are probably more reasons, like the fact that they are using pre-existing code that was written in C or C++.
EDIT: As an aside, I don't think that many modern games are written in C. OOP lends itself to game development, and C++ is the de facto language of choice.
Also, I won't add it to my list, but as others have mentioned there is a lot of pre-existing code that works very well that is used in the game industry. It would not be practical to rewrite all/most of your tools just to switch to a new language especially when that switch could cause you a lot of headaches.
I would say, despite the other answers pointing to a lack in speed caused mainly by the JVM, that the real reason people don't code games in Java is the lack of support for environments such as DirectX and OpenGL (which actually remove the need for your code to be close to he hardware as it was suggested by some answers). They are the base frameworks that people generally use to code games, especially nowadays with 3D games being everywhere - and lack of support for them is the reason why Java is not considered as a language for game development.
To emphasize my point, I would suggest you take a look at Microsoft's XNA which is currently optimized for coding in C# via the .NET framework (which like Java is Just-In-Time-Compiled and doesn't run natively per se). The XNA framework interfaces with DirectX which talks to the hardware and so it is very fast.
EDIT
#Ed Swangren's comment made me realize yet another distinction between .NET vs Java when considered for game development. I think another strong point to .NET is that if you do need to be able to squeeze out that last bit of performance and do some pointer math or implement a sophisticated high-performance algorithm it's a lot easier thanks to the unsafe mode. Of course you can even go beyond that and write native libraries to be used by your C# code which is made pretty simple thanks to P/Invoke.
Leaving C(++) aside for the moment... I am inclined to say much of the reason is that Java lacks anything like XNA. What advantages does Java actually have over a language such as C++ when it comes to game development? You have to consider that several of it's typical advantages disappear for the specific area of game development, while C++ gains several.
XNA is what made C# a highly popular language for amateur game development, and contrary to common belief, a quite viable option for commercial development too. C#/.NET being a parallel to Java in so many ways (and arguably a better framework nowadays), when people now have the option for game development with a higher-level language, C# would seem like the much more appealing one, unless cross-platform support is essential (then again, we have Mono and OpenGL for .NET).
C (or rather, C++) has long been the language of game development due to their low-level nature (thus performance benefits) and the host of graphics frameworks (DirectX, OpenGL) and engines that primarily target them. It's usage is embedded in game development and been used virtually since the inception of the industry - and won't disappear any time soon, I suspect.
Java doesn't have as controllable performance
Its highly reversable so harder to protect
Many Games employ scripting languages like lua or python to get "higher" level programming
the API of most systems is C oriented.
Java can be used for back end server systems that games connect to
Flash games seems to of taken the niche Java games could have had.
Java can be optimized to be very fast, as is evident by an interview I had recently with a high-frequency trading company, where they do use Java, as well as C++.
Java has OpenGL bindings, as others have pointed out, so getting to the hardware isn't such a problem, esp since not all games need that, some commercial games have been written for Java3D.
You can use Scala or F# if you want some more performance for multi-threaded or numerically intensive operations, and just tie those in with the GUI.
But, as others have mentioned, the tools that are used tend to be written for C++, and some companies feel more comfortable doing some optimizations in assembly, but, given the fact that the new cpus are very complicated, with multicores, it is unlikely you will get any performance increase over the optimizations from the compilers, but, as long as companies feel these optimizations are still needed, they will stay with C++.
If some developers wanted to write commercial-grade tools for Java or .NET, there could be a market opportunity there, but it will be a great deal of work to make it as good as what is already out there.
I think C or C++ is a better language for building many types of games because it is closer to the hardware and likely to be the first language implemented on any new hardware. Not only that the libraries for accessing many of the advanced features of today's hardware are likely to be implemented in C.
Your typically general purpose higher level language has no easy way to access features of the hardware unless it uses some type of binding layer to call the libraries which are written in C.
For instance how do you write code to access a GPU, or write a custom Shader, or write code that run well on a Cell chip, or run on an Iphone, or on a Blackberry in a high level language. Even when these things are supported, they come out well after other people are able to write games in C that use these features in games.
One compromise you can make is to use a higher level language like Java for most things and C where its needed. You will limit the types of platforms you support though.
Java might also be good for client/server games where the server is written in Java.
It's very hard to write a program that runs in constant memory without garbage collection in Java.
If you want to read statements from game studios who are happy to use java for serious game development then search on twitter for #javaforgames
https://twitter.com/search?q=javaforgames
By studying the Java developers tweets conclude that Java is good for game development if you use it in combination with a high level game engine API such as libgdx and jmonkeyengine that both ease development effort and makes the game tuned to take advantage of the OpenGL/ES hardware acceleration provided by modern GPU hardware.
Java do allow cross-platform goals using said engines on mobile, console and desktop.
Some game developers prefer java for the design phase of the game to engineer in-house tooling.
Java game studios and developers who seek the best performance can archive it by tightly controlling OpenGL by using JOGL or LWJGL directly. Also performance and flexibility archive this by writing their own engine, if time and money allows it.
I wouldn't say that it is always true that C is better than Java for game programming.
For example, if you want to write a game client which can be hosted in a web page, Java could be better.
When writing games which produce amazing 3-D graphics (e.g., Halo on the X-box), usually there is barely enough computing speed to generate all the pixels for each frame. In this kind of game, C would be preferable to Java because it allows the programmer to write faster programs -- at a large expense in terms of difficulty in extracting that speed.
I think it's mostly because c lets developers squeeze every last little bit of performance out of hardware, whereas Java doesn't, it's not low level enough for things like high end 3d video renderers. Basically c lets you squeeze out a couple more frames per second in your next gen shooter.
Inertia mainly... Although it's a bit old now, you can look at Jake2 (which is a pure Java port of Quake 2 with jogl as the openGL lib).
It can perform up to 85% as fast as the C++ original, which means it's fine for most games; especially modern ones which are more social and game play based rather than the limited "hard core" games.
I'd also suggest that most of the answers you get here are coming from a gaming geek/"I want the coolest hardware and games". For [these] hard core 3D games and gamers, that final 15% is hugely important, as that's what separates the $150 graphics card from the $500 one they just bought.
As John Carmack is reported to have said (something along the lines of): "If I were to enter games programming now, I'd program for the iPhone". e.g. it's not nearly as much fun to make the fastest game with the best 3d engine as it is to make the best game.
The console game market is about 10X larger (financially) than the PC game market. For current generation consoles, all the major programming is in C or C++ with some little bits of intrinsics or assembler. If you want to be a professional Game Programmer and work at any major game company, then learn C and C++.
More to the point, all the commercial cross platform engines that are that starting points for many commercial games are in C or C++ right now as well.
You may be able to work on small games in java and flash or even casual Windows games in C#. You can even code C# for XNA games but if you want to make REAL (pressed on DVD) XBOX 360 games you need to learn C++.
Speaking as a game developer at WBGames Chicago. We would not hire a programmer who didn't have strong C++ skills. The same is true at every other game studio that I know of.
The short answer is because almost no gaming platforms support Java, or if they do there is a much better alternative.
On the game consoles, seasoned game developers are using C because that's what they've been doing for 20 years. There's no compelling reason for Java games to exist there.
On the desktop, there are a few Java games, but they can't compete with the market leaders such as World of Warcraft.
On the web, Applets are long dead, and if you're going to make a casual game it's going to be in Flash.
In the mobile space, JME has had it's time in the sun but it's on its way to obsolescence in the face of far superior platforms such as the iPhone.
The perfect world scenario for Java to be a heavy hitter in the gaming world would be for Sun/Oracle to deliver a gaming platform like the Wii or the iPhone - a must-have device that everybody owns. Then, there is a good reason for developers to invest time into experimenting with new technology. But given Sun and Oracle's apparent lack of interest in the consumer market, the chances of them making a gaming rig are slim to none.
It's not a technical issue but purely a "client optics" issue for this.
Good Java code can run just as fast as good C++ code. It can access OpenGL just as fast as native C++ via projects like LWJGL and JMonkeyEngine.
The real reason is that Sun never put any effort into highlighting Java for games and they've never made any deployment particularly easy for Java games. It's a LOT of work and effort of the developer / team to create a seamless / smooth installation (and launch?) experience for the player.
Customers just don't "trust" Java games and bail during the install process when they see the logo.
Although old, no one here seems to point out
All the games and apps on Android are programmed in Java
Because not only is Android written in Java, so are most all of its apps/games/etc...
I will answer in a very different way.
If Java can nevre write a device driver like C, how can you Imagine that it would be faster than the language that the driver is already written in ?

Categories