Related
I need to write a desktop app and its been a while since I started used Swing so will have a learning curve with either technology.
Are there any advantages in doing my app using JavaFX 2?
4 Years back I was having the same question and came to the conclusion that I would be best of using Swing since a lot of third party libraries were still written for Swing in those days. Also 1.0 releases from Sun were usually a bit rough around the edges (I burned myself on JSF 1.0 and JPA 1.0 :-).
Today a lot of libraries have JavaFX counterparts or are available as JavaFX library. That said there are also a lot of libraries wich are still Swing exclusive. Also I've done some small things with JavaFX 2.0 and it seems really complete. I haven't bumped into any showstoppers.
You need to check how many external UI libraries you are going to use besides Swing / JavaFX (and which one). If the answer is not many or a lot have a Java FX alternative (or are simple to todo yourself) I would definitly go for JavaFX. Also you can still use Swing components in JavaFX.
As stated JavaFX is going to deprecate Swing in the future and Oracle seems committed on JavaFX (it also going to be opensourced). So I would highly recommend JavaFX.
Status update 13 april 2014:
JavaFX has been opensource for some time now: https://wiki.openjdk.java.net/display/OpenJFX/Main
The community is committed to JavaFX; JavaFX only libraries with no swing counterparts are starting to emerge.
Oracle has proven to be committed on JavaFX.
In case you weren't convinced 2 years back: JavaFX now definitely looks like the way to go. Though Swing will probably around for a long time it is currently in maintenance mode. It will take a lot of effort to port large applications (like IntellIJ or Netbeans) completely to JavaFX. And for those large applications such a large scale port is probably not worthwhile at the moment.
Status update 15 september 2021:
The JavaFX community is still going strong. OpenJFX is still there and has a flashier home.
Companies like Gluon (I'm not affiliated with them) offer commercial support LTS releases for OpenJFX.
There is GraalVM support for JavaFX allowing you to make JavaFX applications and distribute them as native binaries (ie. no JVM needed).
There are excellent opensource JavaFX component libraries available like TilesFX.
Both are good options:
If you want a rich, graphically enhanced application, the features of JavaFX 2.0 may be very appealing. It is designed to give you a lot of creative control over your user experience and visuals. Just be sure that it is supported on your target platforms....
If you want a standard desktop application that runs on as many platforms as possible, then Swing is probably a safer choice (since Swing is guaranteed to be available as part of all modern Java distributions). It also has the advantage of more mature 3rd party libraries.
Neither is likely to replace the other: they have slightly different target uses and will probably co-exist for many years to come.
I am interesting in game development. However, I am not sure what platform to choose. There are a few different platforms I have been considering so far:
Microsoft XNA
Games only work in Windows and Xbox?
JavaScript and WebGL
Bad performance. This is mainly due to JavaScript -- the language is essentially synchronous and even timers do not run asynchronously. The only good way to use JavaScript would be to utilize Web Workers, which complicate the development quite a lot.
Flash
A dying technology that I personally dislike and unsupport.
C++ and OpenGL
Cross-platform compliant all the way, but very hard to develop games.
Am I missing anything worth considering? What I am looking for is a simple yet enough powerful to make 2d and basic 3d games and being able to run it on as many platforms as possible.
Also, is it possible to run XNA games on Linux/Mac? What about mobile?
You should probably look at a framework that allows the use of Java/C++ but takes away some of the pain.
For C++ take a look at Ogre.
For Java take a look at jMonkeyEngine.
If you're going to be targeting mobile devices incl. iPhone/iPads too look at something like Unity/Unity Pro which supports JavaScript, C# and a dialect of Python and can publish out to multiple platforms.
You'll get better answers in https://gamedev.stackexchange.com/
If you don't mind spending some money, you might want to look at Torque.
For anything advanced you'll need to use C++, but for simple games, the TorqueScript is fine. They currently support Windows, Mac and iPhone/iPad, athough the Mac and iPhone/iPad support is usually less than the Windows support. But still pretty good for most things.
You can also publish the PC games to the web browser with their ActiveX and NP browser plugins.
They also support some consoles. For XBox they have a version of the engine that is built on top of XNA, and you can also get a version that is built on top of the native XBox SDK. I believe they've also gotten it going on PS3 as well. For the XBox and PS3 native stuff, you're going to be looking at some real money though.
WebGL and Javascript and canvas are getting a lot faster now, thanks to typed arrays and native animation support and hardware rendering, see for example:
https://hacks.mozilla.org/2010/08/more-efficient-javascript-animations-with-mozrequestanimationframe/
(download the nightly version of firefox minefield to try it out)
There are various webgl game frameworks available already (see the 'learning webgl' site for info).
It's not going to work on mobile/tablet platforms though probably for a good while.
You often see that a new game will be released on Xbox 360, PS3 and Windows PC.
How do gaming companies do this? Is it a common source code compiled using different compilers? Are different source codes actually required?
There's an example of this phenomenon described in this news article.
Generally speaking, the vast majority of multiplatform "triple-A" titles are implemented on top of an engine such as Unreal, Source, or other smaller engines. Each of these engines is custom-implemented and optimized for each platforms and may use a lower-level API such as DirectX/OpenGL which in turn uses the console. Each of these engines also has plug-ins for platform specific stuff (e.g., motion controls) that interact with the official drivers or APIs of the hardware.
Many of these engines support their own scripting languages or hooks for many things, so it is write once.
For example, take a look at the unreal engine:
http://www.unrealtechnology.com/technology.php
Most of the biggest engines, like Unreal are so flexible and robust that they allow developers to write all kinds of games. For instance, the Unreal engine was used not only for shooters, but also for shooter-RPGs like Mass Effect.
Remember that most of the manpower in making games is devoted to graphics, set designers, audio design, level design, etc., and there are custom editors for all of that. Many of the set pieces are usually programmed via scripting languages. Only a small portion of folks in gaming companies actually write code in low-level languages like C.
The engine takes care of this by providing a platform independence layer.
Things that varies between platforms for instance graphics library. threading, clock and filesystem etc; are implemented for each platform in the game engine.
I can make a call to the engine to render a 3D model consisting of triangles.
The engine in turn render this model by calling down into the platform independence layer which uses an implementation for the currently used platform.
There are two ways game companies do this:
1) Writing/using a multiplatform engine
2) Porting a game
A multiplatform engine will feature abstractions for platform-specific actions (making a Windows API call, rendering in DirectX vs OpenGL, etc etc) so that all of the work can be done once, then built for both machines. Usually it's a matter of writing simple wrapper methods for things like Direct3D calls and what not. Most newer game engines are being built from the ground up with multiplatform support. Others are adding multiplatform support.
If a game engine isn't multiplatform, it has to be converted to run on the target platform. This is usually a two-part operation. First, all of the API calls and interfaces with the hardware need to be redone for the target platform. The second part involves debugging and optimizing the game for performance. Typically a direct port will not perform very well, as the code will feature platform specific optimizations that do not apply to the new target platform.
For various reasons, ported games can suffer from performance issues, usually in spite of watered down visuals. Take a look at The Orange Box on PS3 or CoD: Modern Warfare for the Wii to see two examples of ports gone wrong. For the OB, Valve outsourced the task of porting the game(s) to EA. In the second instance, Activision decided that it made more sense to port a game on an engine designed for more powerful hardware over to a weaker platform instead of building the game on top of a new engine designed to get the most out of the Wii.
Many places will have separate teams responsible for different versions. That is why you always see some small differences. However, if a portable language is chosen, these teams may be able to trade code around.
If the company as produced a game engine, developers can just develop on top of that, leaving the engine to handle the cross platform specifics.
I'm guessing that the art/media department is that same for all platforms.
Actually, there are some frameworks that are meant to be able to run on multiple platforms.
For example:
The XNA Framework can run on Windows, Xbox, and Windows Phone with almost the same code base. (About 90% the same C# code can run on all of the platforms.)
Unity 3D supports PC, MAC, browsers, the iPhone, Wii, and it will soon support Android, too.
There are other such frameworks as well.
Also, most of the popular game engines (eg. Unreal, etc) are ported across multiple platforms.
This is often accomplished with a virtual machine that handles non-time-critical game mechanics and an abstraction layer for time-critical but platform-specific operations.
The particular methods are highly proprietary, secret, and are the among the most valuable assets of the game maker.
I remember reading an interview (or perhaps it was a .plan file/blog) John Carmack gave a few years ago. He was discussing developing for multiple platforms. (If memory serves this was around the time they were releasing titles for mobile platforms) The advice he gave was to always target the platform with the lowest system specs you plan on supporting first. His reasoning was that it is far easier to scale up than down. If you focus on the latest high end graphics you're likely to wind up depending on features only available on the high end. Making it very difficult to scale back for mainstream and lower end systems. Anyway, I thought it was pretty good advice.
This is all a guess because I don't work for a company that makes console games, but speaking from experience as a software developer what I imagine happens a lot of times is that external libraries are used against source code that's written in a common language, such as C++ or something. A lot of the core game code (game loop, physics stuff, etc.) can be used because the syntax is the same with the library across platforms.
However, there is a large degree of code that has to be written (and tested) that is unique to the platform. For example, most (if not ALL) graphics card-related code would have to be different for the Xbox 360 vs the PS3.
This allows for a large degree of portability on core functions and then the UI stuff and graphics-related stuff is platform-specific (not always for the UI).
Also, large game companies have 100s of developers working on a project, so they have a lot more resources than some indie developers might.
It's never perfect though. You always have to port SOME code. Unless you're using Adobe AIR, but your game is for consoles (and who uses Adobe AIR to develop REAL games?)
Game companies use commercial middleware, like RenderWare which do not come cheap. Most game platforms also support a C++ environment for code to get compiled on. Additionaly, most consoles come with a Development version (Playstations do) and there are simulators to test most code on. This middleware is now owned by EA (which is like the giant player on the field). Creating 3D games aren't just framework. Most of the game comes from a design document, which documents the flow of the game and game play. The artwork is done in other software (Maya and Lightwave for example) and the 'models' which are the game characters.
Even though it might look horrific a lot of work, when it comes to coding, it isn't that big of a deal. Writing the core functionality takes a week or eight, the rest is more in design and planning. Just remember that 3D is only 10% of the overall game. These are my two cents as a former game developer.
Not necessarily video game related, but the best walk through I've seen for doing multi-platform software was in GOF (http://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612). Read the case study on the windowing system.
I would say "largely they don't." All the money is in Windows or in consoles and a lot of the consoles want an exclusive license. I have seen a few ports but they're always a separate code base branched from a previous version.
Very often they use #define (for example in C++ code) so before the compilation for the specified platform the proper code is included or used. In bigger projects sometimes the parts of a game are totally different and written in different IDE's and compiled in different (platform specific) compilers.
Example from my experience:
When I was working on a game for Nintendo Wii, we were using Torque game engine. We were programming on PC's and compiling code for PC's. When some functionality was ready we used Metrowerks CodeWarrior (with special set of libraries etc.) to compile it for Nintendo Wii, send it to the devkit and then run from the Nintendo Wii console.
i've been making web app's and working with various server side language like php, ruby, perl for a while now. I've always been curious about game development, it's actually what I set out to do but I ended up in web development. I am trying to transition in to GD, but I cannot help see games from a web development POV.
GD = Game Development
WD = Web Development
Technical Questions.
How do you design UI in games? in WD you have CSS, and need minimal graphics to create a quick menu. are there similar tools or concepts in GD ?
How do you deal with storing data ? Do you use flat text files? Or is there something like MySQL or sqlite that you use to store information about objects, users, and etc ?
What game engines is commonly used ? Are there any that use scripting languages ? I only know VB and basic understanding of C.
With the proliferation of Iphone and Android, is J2ME being phased out for mobile phones ?
open 3D web is coming. What is your thoughts on having 3d applications running natively from your browser ?
What tools make it easy for creating 3D objects, levels, game environment, and animating characters and so on ?
Where can I find out more about how server/client, client/client, and MMORPG networking works ?
Where can I get or find generic or commonly used game flows ? for multiplayer ?
How do you deal with physics? Is there freely available algorithm or library that you can use ?
How are real time cutscenes made in games ?
Market Questions.
Which market should you enter? Mobile, iphone, wii, PSP, DS, android , ps3, PC etc.
Shouldn't you always enter mobile market, as it is easy to make small games on your own yet sell a lot ? Are there any resources where i can find more about each markets ?
What is your thought on Steam content distribution ? Is it the distribution model of the future ? Whats wrong with the traditional publisher/distributor model ? How does the traditional model work exactly ?
How big is the web games market? ex) Flash games.
How is game development different from any other software development or web development ?
I have a lot more....but those are the ones that I have been thinking about lately.
Thank you very much for reading !
UI Development
Depends on the game- is it animated, or a board-style game? Generally, UI assets are created as images, sprites, or storyboards.
Data
Again, depends on the game type. Realtime games need FAST access, so you want to store your data in a local database and cache it as much as possible. Local file-based databases tend to be the norm, either custom or off-the-shelf, such as SQLLite.
Engines
There are tons of engines out there for 3D, board, etc. Popcap has made their C++ game engine open source. Others include Unity, Ogre3D...
J2ME
I wouldn't target this platform for games.
Don't know much about "Open 3D Web" but it sounds very browser-dependent, so mileage may vary across browsers.
You can play with 3D with Google Sketchup and Caligari Truespace. Truespace was bought by Microsoft and made free.
Again, tons of engines out there for networking. Example: Microsoft's XNA framework has some networking bits you can leverage.
Not sure what you mean there.
There are physics engines built into some of the gaming engines I've mentioned, and external ones you can use.
Once upon a time, realtime custscenes were pre-rendered with 3D Studio Max or Maya. These days in-game rendering is often good enough for cutscenes: look at the latest Halo 3:ODST game. All cutscenes use the in-game engine.
Market
I looked into game development earlier this year. Casual games look to me like a growth industry- high volume, relatively low development cost. Big Fish Games for the PC is a good example there- they publish a few titles and resell most.
I think mobile game development is a huge potential market but the barriers to entry are high because it will be a crowded space. iPhone games are the 800lb gorilla but Android is coming up. PSP and others have a limited audience and are notoriously difficult.
The most important thing I learned in my research is that game development is a labor of love. It's hugely multi-disciplinary: you need programming, art, concept, production. It's more like making a movie than anything else. It's also rough to make a profit because of all that overhead. If you want to get into it, I recommend joining a game developer to learn the business. Once you have experience you can carry it forward to larger gigs at larger publishers. Eventually you can get to work on a major AAA title, after which you can really write your own ticket.
I'll stick to answering the technical questions:
1 - UIs are usually completely bespoke, with nothing resembling a standard in the same way that HTML/CSS is a web development standard. Some people use ScaleForm which is based on Flash but that is by no means common.
2 - Data is often stored in flat files - rarely text, more commonly binary. Again, these are almost always completely bespoke formats. Sometimes they are aggregated into archive files which use the zip format or something similar however. Occasionally, some programs might use sqlite, and online games often use SQL databases.
3 -There are many game engines used, although the definition of 'common' is vague. There are well-known ones like the Unreal or Source engines, down to lesser known ones like Panda3D or Torque. Some of these are heavily focused on 3D and leave much of the rest of the functionality to other packages (or the game developer themselves). Most are able to be used with scripting languages, or come with one built-in. (eg. UnrealScript).
4 - J2ME - couldn't say, that's not the sector I work in.
5 - 3D web will be interesting when it's ready, but cutting edge games currently require gigabytes of client-side data. Running the application in the browser doesn't get around that download, so it's not a great benefit. Nor is it likely to be as high performing as a dedicated 3D game renderer for quite some time. So while it opens many doors, it doesn't significantly change the state of play for gaming just yet.
6 - 3D art assets are usually made with 3D Studio Max or Maya, although there are several other related tools.
7 - MMORPG networking firstly requires understanding of basic networking (ie. strip away all the HTTP fluff and get right down to the socket level). Start with Beej, work up. From there, you're best off reading talks given at conferences and reading the Massively Multiplayer Game Development books, coupling that with anything you can find on traditional game networking. 2 good starting points are the Source Multiplayer Networking docs, and Gaffer's Networking for Games Programmers. Don't expect to understand everything the first time you read it, either. And bear in mind this is a field with ongoing research and the problems are far from solved yet. And that it's also a field where "if you have to ask, you can't do it yet". Emphasis on yet.
8 - I don't know what you mean by game flow - it's not a term I've heard used before.
9 - There are several physics libraries available, including Havok, ODE, Bullet, PhysX, Box2D, etc. Some are free, some are not. You can also write your own physics for simple games, as it's not all that hard, and indeed that is what everybody did until relatively recently.
10 - Real time cutscenes are typically either pre-animated in something like 3D Studio Max, or scripted to run within the game engine.
It depends very much on the platform you are developing for. some game engines, or platforms, have built in platform specific means of creating UI systems. An example is developing for the 360 where there is a proprietary UI system provided with the SDK tools.
However, systems like these tie you to a particular platform and this can be undesirable.
Another alternative is cross platform libraries like Scaleform, which provide game-side libraries for displaying UI elements, and a common way of editing and creating UI systems across different platforms.
The complexity of UIs in videogames varies wildly. Look at something like Peggle, compared to something like Codemaster's Dirt or EA's Dead Space. Each system is therefore implemented differently.
Some use 3D packages and the standard game engine to animate and render UIs. Others implement Flash. Others roll their own custom solutions. There's no easy choice or a standard like CSS I'm afraid!
Hope this helps,
-Tom
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
With iPhone and Android I feel Symbian is obsolete. But it is going to be open sourced. However the API looks like very different. With so many different types of discriptors, arrays and Active objects people feel creepy about it. Loo in wikipedia articles here:
http://en.wikipedia.org/wiki/Symbian_OS#Developing_on_Symbian_OS
http://en.wikipedia.org/wiki/Active_objects
I think when it goes open, the first thing community should do is cleaning it up. Though its very difficult but I feel its necessary.
The main reason, symbian is going opensource is to become competitive. The main advantage of Symbian is it is very stable with more than a decade of mobile experience. With the strong support of Nokia, and port of Qt it can definitely a major player.
Wikipedia isn't exactly representative.
Symbian OS development basics have recently been boiled down to under 50 pages in http://www.quickrecipesonsymbianos.com
There is an entire ecosystem that knows about the specifics of developing for Symbian OS. The C++ idioms might be a pain to learn but they have a purpose when it comes to using a mobile platform.
There is little technical justification to get rid of them.
Making things simpler for developers is another goal. A very important one, though. That's why many runtimes have been introduced for Symbian Os development. Qt, Ruby, Java, python, OpenC, Flash, NS Basic, .Net...
The customized, open C++ allows developers to add runtimes efficiently.
Each runtime has its own trade-offs to balance performance and ease of use.
Open sourcing will make runtime integration and native c++ development easier for sure but there also is a commercial point to it too. It gets more people interested and the platform compares more favourably to its competitors.
I think it's too early to say whether Symbian going open-source will be a good or bad thing for the OS. The debate over the branding selected for the Symbian Foundation website shows a certain lack of clarity of the role Symbian software will play in the future.
While it's true to say that there is an entire ecosystem that knows about the specifics of developing for Symbian OS, that's pretty meaningless in its own right. After all, there's still an active "ecosystem" that knows how to develop Cobol applications for IBM mainframes.
You need to consider the size of the ecosystem and appreciate that that ecosystem is small given that Symbian OS has been around for over a decade and the software powers in excess of 100 million devices today. Consider then the rate of growth of the ecosystems surrounding the offerings from Google and Apple - Symbian never generated that level of excitement and never saw that sort of growth in developer interest. Of course, we're a decade down the line and you could argue Symbian have done the hardwork and created the landscape in which Google and Apple are now competing. But just because Symbian was first, doesn't make it best and doesn't give it any right to survive.
It is true to state that the Symbian C++ idioms are a pain to learn. However, it is incorrect to suggest that there is no justification for getting rid of them. The justification is the persistent perception, 10 years on, that developing native code for Symbian OS is too hard. Most if not all these painful idioms were design decisions taken over a decade ago and whilst still beneficial on todays mobile devices are no longer essential. Mobile hardware has moved on substantially in the last decade. Symbian OS has not fundamentally changed, at least in terms of the developer offering. Consider now where PCs would be if the hardware had developed as it has, but the software stopped at Windows 3.1 or 95. We almost certainly wouldn't be able to have this discussion in quite this way for starters.
Looking at alternative mobile platforms, consider Android and Maemo. Both are linux based systems. Both use more developer focussed, standard development approaches which leave Symbian OS looking like it's come from another age.
That in itself is not necessarily a problem because as others have noted, Symbian OS supports several runtime environments that make development for mobile devices that happen to run Symbian OS much more approachable for the average developer.
Taking the runtime support to its natural conclusion, the underlying OS becomes irrelevant. A choice made by the device manufacturer based on cost, time to market, quality etc. But the end user doesn't care and in many cases doesn't know what the OS is. Developers then develop for their preferred runtime, rather than write native code.
Of course, we're not at that conclusion yet. We're still travelling the long road. Therefore native code still plays an important part in mobile devices. Hence the ease with which developers can write for a given platform is important - assuming the device manufacturers believe in supporting developer platforms.
So, will open sourcing be good for Symbian? It's difficult to see how open sourcing will be bad for Symbian. But whether it will be good or not depends on the ability of the community to make Symbian OS into the OS the community needs.
there's a move in symbian os towards using more common languages for development, including C, ruby python etc. try thinking of symbian c++ as like WIN32 programming (you're not telling me that's easy!), if you don't want to use it you don't have to but it's the native language and therefore most efficient.