I am creating game, in this a helicopter fires a missile it hit the target and the target and missile disappears.I want to show some kind of explosion when they collide.I heard there is some sort of built in function for this
?
Have you checked out the programmers guide? I would suggest looking into particle effects and even some of the open source games or code snippets provided by the community. I think explosions are not generic enough where there is something built in, but you can use the particle effect engine to easily create one.
Something else to consider is using the effects, which actually look pretty cool. You could probably do some kind of explosion by rippling a sprite of fire or something.
Related
Was looking into making a game with Qt and was wondering if QML has gotten to the point yet where it could be used as a serious tool on the desktop. Have seen some post from Qt stating that they will be transitioning most things to QML eventually, so this seems like it may be the way to go, at least according to Qt.
Edit: I realize that QML probably wouldn't be the best bet for a 3D game with heavy graphics. Was looking more for something that did mostly 2D stuff like a platformer type game.
Seen this http://labs.qt.nokia.com/2010/08/12/a-guide-to-writing-games-with-qml/. So its obviously possible to some extent. I have also seen some impressive games made solely with java script, which I believe is the base of QML. I was just curious as to what would be the best way to go with Qt at the moment since things have been changing lately...
It may depend on "how long" you want to wait before releasing your game.
The Trolls/Qt are re-doing its "graphics stack" right now: Rather than historic "every-widget-renders-itself" (which is the wrong paradigm for games and rich mobile apps), they are re-implementing to a single graphics stack that renders the WHOLE interface, where the "widgets" themselves are mere data-sets that feed into the rendering. In short, the goal is to make desktop/mobile applications with the exact same performance as the high-end games have done for decades (with their own graphics stack that looks nothing like the typical X/Xlib/Motif/Xvt/Win/MFC/Qt applications graphics stack). Further, the Qt5 plans (in planning/development now, they claim a release sometime next year) are reliant upon OpenGL for this graphics stack implementation.
After this work, the pipeline will be: Widgets==>QML==>(C++ Graphics Stack)==>Hardware. Currently (Qt 4 and previous) it is: QML==>Widgets==>(C++ Graphics Stack)==>Hardware.
You can google for various posts/discussions on this, or here's a long-ish presentation that talks about these efforts: http://qt.nokia.com/developer/learning/online/talks/developerdays2010/tech-talks/performance-do-graphics-the-right-way/
IMHO, QML makes more sense for games, since the interface components are "independent actors" (e.g., not tied to each other through layouts). That's also why QML makes so much more sense for mobile (where real estate is a premium), and for very flashy desktop apps (although it is still relatively young and unproven for that).
QML already has lots of rendering/animation options, but they are mostly a very rich 2D (but with which you could simulate 3D pretty well). The QML 3D is undergoing heavy revision right now, but the new stuff looks really good (and sits on OpenGL). So, if you want heavy 3D, it might be experimentation time for the moment, until you see the new Qt5 interfaces and can take advantage of the hardware acceleration (depending on how much 3D you need).
The performance specs I've seen from the new Qt5 stuff with the new graphics stack (in prototype development) are quite impressive, so much so that I've been thinking about writing some games in QML just to play with it. If this were twelve-months-from-now (or so, after the release of Qt5), I'd bet QML would be the best/easiest decision for games (because the components are independent actors, it's so simple to use, and I'd push all the game-specific heavy stuff into C++, which is really easy to do with QML on top).
QML is definitely a viable option for designing 2D games and can save you a lot of time and lines of code.
V-Play (v-play.net) is a cross platform 2D game engine based on Qt/QML with many useful V-Play QML game components for handling multiple display resolutions & aspect ratios, animations, particles, physics, multi-touch, gestures, path finding and more (API reference).
If you are curious about the games made with V-Play, here is a quick selection of them:
Squaby: a tower defense game
Chicken Outbreak: a platformer like Doodle Jump
Blockoban: puzzle game
Crazy Elephant: a game similar to Angry Birds
Snowball Mania: multiplayer action game
Blitzkopf: brain game
Remember that QML is only designed to lay out the UI. Fundamentally, it acts as a QGraphicsView with lots of utility functions (code in QML is at least three times shorter than the Qt/C++ equivalent, at least, that's how I felt it)
The core of the application is still handled by either javascript files (if things are not too complex) or C++/Qt files (if you want the full extent of Qt possibilities)
As Jeremy Salwen said, for a game that looks like a smartphone app game (big sprites that move with nice transitions, with simple logic behind it), then QML is more than sufficient.
But if you want something complex, then you will end up using in QML only QDeclarativeItem classes that you will have previously defined in C++. Not that useful.
Im in the middle of creating my first iPhone game - I have a background in OOP and in particular C++ so I had some questions with regards to how best to logically setup layers while maintaining functionality.
Currently I WANT for my game to have three main layers:
HUDLayer (All static objects on the screen are here - game controls, User score, pause button etc.)
PlayLayer (The Player, the main game loop and all of the game logic here)
Level Layer (The level images and the level physics objects that the player interacts with, and the background music specific to this level)
Notice I used the word WANT here - because for the life of me im constantly having to move logical objects around just to work within what appears to be Cocos2d's and spacemanagers structure.
Below are just some of the issues that I'm facing
I would like for my PlayLayer to be the scene thats loaded by the director - but if I do that then all of the HUDLayer objects get covered behind the PlayLayer, and dont stay in place like they should, hence the HUDLayer is my scene and I have had to do that just to make it work
I would like to play the background music (via simpleAudioEngine playBackgroundMusic) in the LEVEL layer because I want different levels to have different music. So far the ONLY way I have gotten background music to work is to have it in the TOP most layer i.e. in this case the HUDLayer
Because of the fact that I have to use an instance of the SpaceManagerCocos2d object to create physics bodies - it seems like my level layer has to be killed and just incorporated within my PlayLayer otherwise im having a nightmare of a time attempting to detect collisions between the player and the level.
Am I missing something very obvious here? is there a core understanding of layers that Im just not getting? More and more I feel like im being pushed by the framework to build the whole game inside of a single class and just to use layers as scenes.
Is anyone else having these problems? Am I approaching the architecture of the game wrong? Any help would really be appreciated.
Thanks in advance guys!
Well, each game is different. There are many good discussions on the cocos2d forums about architecture, some people prefer to use an MVC approach, some like using an Actor metaphor to contain physics objects, etc.
Here's my approach:
Use two CCLayer objects (GameLayer and HUDLayer) as child nodes of one CCScene (GameScene). These are the "view" objects.
Create a GameController singleton that can make changes to the game state (also stored in GameController, or in a separate file.) You could also subclass CCScene and call that your controller.
GameLayer is in charge of rendering the graphics of the game level and all actors in it; it also handles getting game input via touch events.
HUDLayer is placed at a higher z-index than the GameLayer and obviously has all of the CCSprite objects for the HUD and buttons.
Interaction between the HUDLayer and the GameLayer is managed via the GameController.
GameController does all of the state changing and game actions.
That's just my approach because it worked for my current game, and it by no means is the definitive answer.
I'd suggest that you look into using an Actor paradigm for your physics objects -- SpaceManager does a decent job, but you don't necessarily always want physics objects to extend CCSprite.
Hi guys
I am new to the cocos2D.In my game i have one scene and several layer to display Menu,pause,level finish,game over. now i want to find out the layer which is being used on top of the scene. i already tried and got the solution to solve it by using boolean variable for every layer. but this is not a good way to use i thought.
please provide some suggestions
Thanks
Riash
You can simply keep a pointer to the active layer. And it is better to have different scenes for every game state because in this case your management will become much simpler. That's because typically your game scene will have more then one layer. For example: background, level objects, controls and so on.
Has any of you guys ever tried writing a 2d game in C++ using Qt's QGraphicsScene/QGraphicsView classes for the purpose of rendering and collision detection?
Do they perform well if there are many moving/animated objects on the scene? Are there any caveats? In general, can you point me to any games written using Qt's graphics facilities?
Thanks in advance.
I tried to use them for rendering. They don't perform very well, besides Qt itself is not very adapt for a game: they're a pretty heavy library doing lots of stuff. Their event handling is not lightweight.
If it's a simple game you should be ok; that API is really easy to use and can be set to use OpenGL or software rendering with just a flag. But if you want to write a real game you should opt for something else, something thought for games.
I don't think using qt is an optimal solution any way it can be done even without the graphicsviewframework like this tutorial about creating a breakout game:
http://www.zetcode.com/gui/qt4/breakoutgame/
Anyway my suggestion is to use another library may be sfml or SDL or may be you can try the new polycode engine
http://www.polycode.org
It looks very promising.
I am exploring a possibility to write a kind of a notebook analogue that would reproduce the look and feel of using a traditional notebook, but with the added benefit of customizing the page in ways you can't do on paper - ask the program to lay ruled paper here, grid paper there, paste an image, insert a recording from the built-in camera, try to do handwriting recognition on the tablet input, insert some latex for neat formulas and so on. I'm pretty interested in developing it just to see if writing notes on computer can come anywhere close to the comfort plain paper + pencil offer (hard to do IMO) and can always turn it in as a university C++ project, so double gain there.
Coming from the type of project there are certain requirements for the user interface:
the user will be able to zoom, move and rotate the notebook as he wishes and I think it's pretty sensible delegate it to OpenGL, so the prospective GUI needs to work well with OGL (preferably being rendered in it)
the interface should be navigable with as little of keyboard input as user wishes (incorporating some sort of gestures maybe) up to limiting the keyboard keys as modifiers to the pen movements and taps; this includes tablet and possible multitouch support
the interface should keep out of the way where not needed and come up where needed and be easily layerable
the notebook sheet itself will be a container for objects representing the notebook blurbs, so it would be nice if the GUI would be able to overlay some frames over the exact parts of the OpenGL-drawn sheet to signify what can be done with given part (like moving, rotating, deleting, copying, editing etc.) and it's extents
In terms of interface it's probably going to end up similar to Alias' Sketch Book Pro:
picture.
As far as toolkits go I'm considering Qt and nui, but I'm not really aware how well would they match up the requirements and how well would they handle such an application.
As far as I know you can somehow coerce Qt into doing widget drawing with OpenGL, but on the other hand I heard voices it's slot-signal framework isn't exactly optimal and requires it's own preprocessor and I don't know how hard would be to do all the custom widgets I would need (say color-wheel, ruler, blurb frames, blurb selection, tablet-targeted pop-up menu etc.) in the constraints of Qt. Also quite a few Qt programs I've had on my machine seemed really sluggish, but it may be attributed to me having old PC or programmers using Qt suboptimally rather to the framework itself.
As for nui (http://www.libnui.net/) I know it's also cross-platform and all of the basic things you would require of a GUI toolkit and what is the biggest plus it is OpenGL-enabled from the start, but I don't know how it is with custom widgets and other facets and it certainly has smaller userbase and less elaborate documentation than Qt.
The question goes as this:
Does any of these toolkits fulfill (preferably all of) the requirements or there is a well fitting toolkit I haven't come across or maybe I should just roll up my sleeves, get SFML (or maybe Clutter would be more suited to this?) and something like FastDelegates or libsigc++ and program the GUI framework from the ground up myself?
I would be very glad if anyone had experience with a similar GUI project and can offer some comments on how well these toolkits hold up or is it worthwhile to pursue own GUI toolkit in this case.
Sorry for longwindedness, duh.
Have you tried FLTK? It is made with 3D graphics programming in mind and has interfaces to OpenGL. I wrote some FLTK->Scheme bindings and found the API to be real fun to work with.
OpenGL font support is terrible, in my experience. It sounds like you're going to have to develop all your own custom widgets anyway so don't even bother with a toolkit. You'll spend more time learning the toolkit, trying to figure out how to get that toolkit to work with OpenGL, and and trying to figure out how to make your special widgets in that toolkit than you will just rolling your own. I wouldn't give this advice in just any situation but it sounds like your application and your widget set is going to be very unique. Make a superclass for all widgets, define a draw method, even handler methods, etc., for override, and you've already done most of what those frameworks would do for you.
Also I'm sure you know this but this is an enormous project so you should initially narrow it down to a few simple objectives for a first iteration.