I'm going to be working on a decent-sized game in clojure and for now it will have 2d graphics. Is Processing (or rather, Quil, which is just a clojure wrapper for Processing) an appropriate tool to use for this.
Processing presents itself as a way to quickly experiment with different ways of generating and manipulating graphics rather than a scalable 2d graphics library, but I don't see any obvious reasons why it couldn't be used as such, so long as you take care to properly separate logic code from rendering code.
If there are better options, let me know.
Processing is certainly cool, but is somewhat specialised towards visualisation / interactive animations. It also has it's own mini-language designed for visualization applications. While it is possible you could make a decent game using it, you might start running into performance issues as this is going outside its usual usage.
For a decent-sized game I expect you will ultimately want to use OpenGL directly, in which case LWJGL might be a better option.
Ultimately, you probably need to prototype using both and figure out what works best. As a rough benchmark, you will want to render a full screen of tiles plus 1,000 sprites at 100+ FPS with less than 20% CPU. If you can demonstrate that processing can handle that then you may be fine.
Other options that you can consider:
Swing - good for simple 2D games. Has the advantage that it is built-in to the standard Java distribution and has lots of good tutorials. Wasn't really designed for games but works fine providing you aren't too demanding.
JavaFX 2.0 - roughly intended to plat in the same space as Flash (rich internet applications). Looks pretty cool, but is still fairly new. Again, probably fine for simple Flash-style games.
I would be careful of using processing for this. I'm not sure about PC, but on the Mac Processing can have pretty hi CPU usage, depending what you are doing. So if your game is cross platform there might be a better option. If it's an online game why not use Flash? The scripting languages are not too far apart and in the book 'Processing: A programming handbook for visual Designers and Artists' (Casey Reas & Ben Fry) there's a handy little section at the back (pages 686 - 691) showing the comparative syntax of Processing, Java, Actionscript & Lingo that would be a useful way of getting you started.
Related
If I am going to make a game like Tower Defence on iOS or Android, do I need to use OpenGL ES extensively? Or am I merely using textures without using other features like geometry transformation, lightning, drawing primitive shape and such?
Secondly, if I am only using the sprite-sheet to animate the game, could I stick to the native platform provided library without the use of OpenGL ES? For example on iOS, using the UIImageView class animation method to perform an animation.
This is such a complex question that you will hardly receive a conclusive answer.
In short: There is no need to touch OpenGL at all to do a game.
Every method that you describe would work, but with various advantages and disadvantages. A short excurse for inbuilt frameworks on Android:
Use standard views (like FrameLayouts): The Framework can do most of your work (animation, z-sorting, ...) but you will run frequently into weird layout errors and surprising performance hits. This is because you are essentially perusing a UI framework for a game. However, for a very simple game it might be just the right thing to do.
Use Canvas painting: Android contains a good and rather fast 2D graphics library in that. You can use it for games, it will deliver enough performance for many games. However, you have to do more yourself already (e.g., z-sorting, animation) and some high-end effects are still not possible
OpenGL ES: Best performance, most choices. Good luck, when starting from scratch, there is A LOT to do before you get even the simplest stuff on the screen. On the other hand, you can do things that are almost impossible with the other approaches. Also, it's possible to reuse parts of the code for multiple platforms.
Renderscript: In my experience even worse than working directly with OpenGL in that the learning curve is even steeper.
In short, design the game first, then decide on which framework provides enough functionality for that without being too complex.
And finally: Think about not doing all the plumbing yourself but take a look at the existing game engines (Unity for example). Almost anything you ever need will be in there; furthermore, some of these engines work even cross-plattform: Write your game once, publish it on iOS AND Android!
I'm looking for a good (hopefully free) 2d graphical library in C++, or in worst case, Java, which helps create the look and feel of Flash animations, the typical ones you can find in most flash games.
The best would be if it provided most of the features and easiness of Flash animation programming, like layers, or even collision detection, etc., without all the micromanagement of pixels typical for opengl. Of course, it can be built upon opengl...
Edit: interactivity is important, it might not been clear in the first description. So I'm not aiming just for an animation, or presentation. A good collision, gravity, etc. system is very much welcome, as are good GUI widgets.
Checkout the new ForPlay from Google.
It compiles to java, javascript, android and more.
Edit: Moved and name changed to PlayN
There is also a stackoverflow tag
Potential ideas:
Processing has been used to make some very good visualizations.... depending on what you want to do this may be a good option.
JavaFX was designed as a framework for building Rich Internet Applications (a bit like Flash). I think it has a lot of the Flash-like features you are referring to.
I don't know if this is exactly what you're looking for, but you can take a look at SFML.
I'm thinking of writing a new web-based game, and wondered if anyone had any suggestions on which platform I should opt for.
The game will be 2D sprite based, but will need to maintain a decent fps rate (there'll probably be up to 20 things moving at once). It'll all be controlled via the mouse.
I use .NET daily, so Silverlight seems a natural choice for me, but I want to make sure as many people can play it as possible...
Can Silverlight games be developed straight out of Visual Studio (I have VS 2008), or do I need additional software (and does it cost...)
What limitations does Silverlight have in terms of .NET version (can I use .NET 3.5 for example?)
What physics engines can I use?
Would Flash be a better choice? Are there free development environments for it (that are any good)? (I don't care about learning curve)
Is Java still an option?
So I just wanted some feedback on what's the best thing for me to use for a simple 2D web-based game.
EDIT:
can you provide more information? is
this single-player/multi-player? what
kind of genre? will there be a lot of
classical UI involved (lots of forms
with lots of button/checkboxes,
datagrids etc.)? will there be a lot
of animation and effects?
Single player game, with "attack waves" of enemies
enemies are only thing that move, player just points and clicks
no classic UI, just clicking on buttons (no lists / dropdowns etc)
minimal animation and effects, only graphical requirements are movement of enemies (which will require little animation)
I'm also interested in web-based 2-d games. I personally favor silverlight because:
I'm already familiar with c#/.net.
It has a lot of capabilities, even if it's not as many as full-blown WPF. I hear that LINQ alone is awesome for games. Local storage may also be a plus. There is a rich selection of controls you can use for the gui portions of your games. Honestly, WPF loses to silverlight in terms of interesting controls.
It's totally free. You need to download the silverlight toolkit for VS, but that's no issue.
One cool thing is that you can do full-screen displays. I also found it is fast enough (on my core2 duo laptop) to handle a decent amount of objects. The fact that silverlight is going to be a big part of winmobile 7 is also a good point (though we'll have to see how that turns out).
There are a number of silverlight games out there so you can see the possibilities.
http://www.silverlightclub.com/
http://silverlightgames.org/
http://www.silverarcade.com/
I suppose the main negative is portability and making people install "yet another plugin". Flash obviously has the broadest user base, but if your game is decent enough, people probably won't mind installing the plug-in. It's a painless install.
In terms of physics engines, FarseerPhysics that TomTom mentioned is most popular.
There is one other thing that I thought was really cool and compelling: http://www.codeplex.com/silversprite. From the website:
Run XNA games without code changes in Silverlight 3. SpriteBatch based graphics only, no 3D. Since the game compiles into straight Silverlight code, it will run anywhere that Silverlight can. [emphasis added]
The XNA-in-Silverlight approach is potentially really good (especially for more complex games that you might want to try profiting from) because that also opens you up to Xbox with minimal porting effort. However, I don't have any experience in that, so I can't comment further.
Edit in response to the OP's edit:
Since your game sounds even more simple than I had imagined, if you don't mind the learning curve or potential difficulties with doing a pure HTML+CSS+Javascript approach (which may in fact not be so great), I'm going to say maybe that's the best route after all. That's because of portability.
That said, I'm lazy and don't care if a few people miss out on my game, so I'd just stick to silverlight. =P
If you want maximum playability do it with all HTML and javascript and don't even use canvas and then the game will work basically everywhere, including mobile. You can balance what extra work that might cause you against developing for Flash or Silverlight and having a very limited mobile audience. You can check out processing.js as well.
If you want to go the HTML + javascript way, you can take a look at processing.js. It's a Javascript port (by John Resig) of the Processing language.
Pros:
Totally free.
Easy syntax.
Portability. No plugins.
Cons:
Still under development, some Processing functions (like the 3D functions) aren't ported yet
Also, check out John Resig's tower defense game in Processing.js.
IMHO Java is still an option, in particular JavaFX (http://www.javafxgame.com might be a good starting point).
However, your experience with a language/technology is probably more important than the choice of platform, so you should choose .NET (given that none of the suggested alternatives stands out so far).
As stated by Benny, Silverlight is a great platform if you're already familiar with .NET, and most of the tooling you need is built into Visual Studio (VS2010 has a built-in designer but the current RC version doesn't support the upcoming Silverlight 4).
One cool feature of Silverlight is its ability to utilize the GPU. This should provide a nice performance boost. I don't know if Flash offers this.
The Silverlight runtime is very small (under 5MB). And you can easily enable out-of-browser support, so that your game may be launched from a desktop shortcut, for instance, without the need for launching the browser (and being online). Silverlight 4 adds the ability to use elevated privileges (this gives you access to the native network stack instead of the sandboxed browser stack). With SL4 you also gain webcam support, if that's important to your games.
Silverlight MAY need additional tooling for Visual Studio, but this is a free download. Basically 2008 was made before silverlight, so you need to download the tooling for it.
Silverlight runs on a limited version - read the documentation.
I would in geneeral advice to go .NEt 4.0, Silverlight 4.0, Visual Studio 2010 - those are aruond the corner and you wil ldevelop longer han a month anyway.
Java - no sorry, why. I mean, theoretically yes, but if you are a .NET person, you have more knowledge there, siverlight is XAML (WPF similar experience, always nice). Why should you giv all that up for using Java?
Flash - DAMN, NO ;) Seriously ;) You dont want to deal with that unless you have to.
Physics engine - no idea. Need to check. Not sure there is a lot for it. Did you google? http://www.codeplex.com/FarseerPhysics comes up first.
I think it is a good approach. Silverlight is a small download to start - so, I dont think you loose too many people by it. I would do it.
I want to write a very simple game in Java to demonstrate a wireless controller I've built. I thought of something like Breakout or Pong. Currently, I have a prototype Pong implementation that does all animation directly using the AWT functionality. However, this is somewhat awkward to program and also a major CPU hog.
My question:
Can someone recommend a library for Java to display simple 2D animations? What have you used for similar projects?
The library should be easy and straight-forward to use -- I'm not looking for something like Java3D.
Integrated collision detection would be a pro.
This question relates to comparisons of Java 2D frameworks and may be of use.
I'm interested as to why your original implementation is a CPU hog. Is that just whilst it's drawing, or is it consuming CPU resource all the time ? If the latter, it may point to a problem wrt. how you're querying/polling your controllers.
I'm looking into technologies for a new embedded product that has a 1 ghz via processor, and a via s3 graphics chip. So far the target platform is Linux, but would like the option to move it over to a windows based platform.
The application would consist of widgets like buttons, graphs, and numeric/text displays. More importantly, the app would contain animating objects, such as fans constantly rotating.
Qt seemed like a good choice because it is cross-platform and has a nice API for a bunch of widgets and an animation framework.
However, this animation framework uses the CPU quite heavily. The target CPU usage for rendering the UI is 40%. Rotating 25 objects with an image uses about 90% CPU.
The thought is to use opengl to animate the objects and take that heavy load off the CPU.
My question is, if Qt the best choice for something like this? Should I be looking more heavily into something like Java 2D?
OpenGL could give you a performance boost:
Qt for Embedded Linux and OpenGL
Or maybe you need a better graphics driver (I don't know if your graphics chip is supported out of the box by Qt Embedded):
Adding an Accelerated Graphics Driver to Qt for Embedded Linux
As far as I recall, Qt's animation framework can be used for continuous animation, but probably isn't the best choice for such. I think it was more designed for transient animations, like sliding a widget around, or growing/shrinking things. I would look into either using OpenGL or possibly QGraphicsView, which allows you to do a more direct sort of drawing.
Additionally, if you look around, you should be able to find instructions for telling Qt to use OpenGL or OpenGL ES as the back-end for the rendering system, which shoud reduce some of the hit to your processor (assuming you haven't already done so).
You need to profile your application to really find out what is wrong there. For example, a fixed shape but continuously rotating graphics item can benefit a lot from item coordinate cache (see QGraphicsItem::setCacheMode). Likewise, fixed images should be cached and kept as long as possible as pixmaps. Color depth may also play an important role. Complex path-based graphics items should be simplified as much as possible.
In short, there are tons of reasons why graphics performance is bad. Without elaborating them and attack them one by one, moving into OpenGL will not really solve the problem. It might accelerate the frame-per-second (due to the obvious advantage of shifting some responsibilities to the graphics hardware), but this is a near-term advantage and quickly diminish in the long-term if the real problem is not uncovered.
Qt's primary selling point is that it's a cross-platform GUI toolkit, which is a nice feature but one that Java has already. You may prefer Qt's version, and many people do, but don't use it just because it's cross-platform. This article shows that the Qt animation framework is not yet integrated into Qt.
If you can program in GL then JOGL is an obvious start point, but if you can't be aware that GL programming is not easy. You might also consider Java3D. Possibly what you want can be done in JavaFX.