I used to be a as3 game programmer. when I begin develop game, I would use a coding framework(suppose these called coding framework) like puremvc/mate/robotlegs plus other graphic framework like starling/away3d/featherUI. And now I am a C++ game programmer(novice), and I want to make a game using cocos2dx. But cocos2dx just a graphics framework, and I want to choose a coding framework like puremvc. I know puremvc has a c++ multicore version, but I found it very hard to learn because there no docs no example on the internet, I would not use puremvc-cpp until I found a good example or document.
I wonder to know that if other people that developing game with cocos2dx did not use any other framework? if yes, then what's mainstream framework for this situation. If no, then I am very sad.
Maybe this answer is late, but I'd like to suggest you a possible scenario: if you're learning to be a C++ programmer, then you'll surely find an easy path to move to the Unreal Engine to create your games.
About the chance to use the PureMVC implementation (standard or multicore), make sure to subdivide your game into 5 tiers:
ViewTech (Unreal, engine logic)
View (PureMVC Mediators, visual logic)
Controller (PureMVC Commands, game logic)
Model (PureMVC Proxies, entities logic)
DBTech (LightSpeed is my suggestion here, persistent logic)
PureMVC is feature frozen, so you can pick up any of the skeletal C++ examples from its main site and adapt them to suit your needs. So even if there are not much working examples out there, you'll still be able to build a prototype in less than 2 days.
This solution doesn't use Cocos2dx, but I think you'll have far more expressive power with these guidelines.
Hope this helps. Bye!
You won't need any extra frameworks when using cocos2d-x.
Cocos2d-x isn't just a graphics library - it's a whole graphics, input and audio framework. The framework itself promotes a certain type of architecture, so a coding framework like the ones you mentioned would probably not fit too well.
I suggest you have a look at the official samples (github) and use them as guidelines.
If you're using JavaScript to build your game, you might try the PureMVC JS port: http://js.puremvc.org
Essentially, PureMVC just want's to help you keep your model, view, and controller concerns separated, and it does so just the same in JS as it did in the AS3 world.
I'm working on a couple apps which require the use of OpenGLes 2.0. I made a prototype of one starting from a simple sample project. However, I wasn't very happy with the clutter that all of the OpenGL code caused. I think that all the clutter would cause issues if I kept extending the code.
So- Is there a good solution to working with OpenGL on a slightly higher level? I don't really need all the complexity and overhead of a game engine. I just am slightly frustrated I can't deal with OpenGL like this:
ShaderProgram shader(fragmentCode, vertexCode);
RenderBuffer renderBuffer(xResolution, yResolution);
You'll have to pardon the shameless self-promotion, but I've been working on just such a framework due to the exact frustrations you've been having. I grew so tired of the nonsense of having to properly initialize resources and then clean them up. Here is a sample from my XPG framework.
XPG::Texture2D tex("texture.jpg"); // automatically cleaned up
tex.bind(); // ready for use
I have built similar objects for things like vertex buffer objects (VBO). I am still working on it, but the OpenGL tools will certainly benefit you greatly. I have yet to see another framework make things this simple. If anyone knows of one, I would love to hear about it. The one I've been working on even works in Android. It should work in iOS, but I haven't tested it there yet. It does work on OSX though. :)
To see a high level demonstration, see the test module source code: interface and implementation.
I don't think the position somewhere between raw OpenGL and a complete engine would be effective. Suppose you have the ability to manage OpenGL objects like shaders, buffers, textures and others.
You will still need a loading logic to get the input data from somewhere. Engine has it.
You'll need tools to compose shaders in and test the scenes. Engine should have it.
You'll face hidden errors about incompatible vertex attributes - shaders - uniform parameters. Engine has to check the consistency and link those instances smoothly for you.
Hence my conclusion is: once you've decided to move forward from the raw GL, you'll eventually end up in an engine. Either in a long term if you do it yourself, or in a short term if you take an existent one.
More than that, I think the engine should provide you with an ability to create shader programs and render buffers in the way you want. And I wouldn't expect much overhead from these operations.
I've done a bit of iPhone development (3 apps in the appstore currently) but the interface has been pretty plain. I've used the stock components for the most part (UITableViewController, etc.) with a little bit of customization, but for the most part everything looks pretty generic. I'd like to get started developing apps with a richer user interface, but haven't found any good resources to get me started.
What resources have you all come across that outline how to create more advanced iOS interfaces (both iPhone and iPad)? Books? Blog entries? Just looking at the apps I have installed right now, some of the interfaces I've been very impressed with are the ESPN Score Center, XFINITY TV, Facebook, etc.
What about 3rd party interface component libraries? Are there any you recommend that provide more advanced interface components than those in the stock iOS library?
I'd love to take a look at any resources that you recommend for getting started.
I love Ray Wenderlich's tutorials. He's got one on Core Graphics which allows you to draw your own Table Views with headers, buttons, and bezier-curved footers!
Here's a little secret that often gets overlooked: a lot of the cool UI elements you see are stock Apple elements that have been customised to the brink of no return.
The main reason for this is Apple have put a lot of time and effort into making components that just plain work. A UIScrollView, for example, has had many more combined hours of testing than any app you write could hope to achieve.
The trick is to know exactly how to customise elements. A UITabBar is a good example: I've seen several apps that use their own custom tab bars. The problem is, often they don't handle edge cases particularly well. You might have issues if somebody tries to hit two items at the same time (I've actually seen an app that used their own implementation of a tab-bar crash if you pressed two items at the same time).
But if you use Apple's UITabBarController and either subclass, categorise, or otherwise overload it to get the customisation you want, you get a lot of the low-level event handling stuff for free.
You would be amazed with what you can do with a UITableViewController, and you get things like view recycling for free (some of the apps I've worked on have things like independent cell resizing, customised animation of cells, horizontal implementations of a tableview, etc).
Not a particularly useful answer, I grant you, but the point I want to get across here is once you've designed your kick-ass UI step back and consider what can be achieved with the existing toolset before rolling your own. You'll thank me when you come to bug fixing!
I also like Three20. Until now I didn't use it in my projects, but I played with it. And there's some really cool stuff in it. ;-) I think that's one way to extend your standard User Interfaces.
Another really cool part is designing your own elements. I like this really. Because you then have in your App something nobody else has. :-D
I've started looking into using Opacity for Mac, it's a pretty neat desktop application where you can generate your own graphical elements (buttons, switches, icons, etc) and then automatically generate the CocoaTouch / Quartz2D classes and headers to drop in your app ... Some elements work best when they're natively drawn on the device, rather than stored/loaded as pngs, or whatever. Moreover, you get #2x Retina display support for free. While not an interface dress-up framework, the fact that it generates Quartz2D code for you makes this a real contender for anyone who's remotely graphically creative but short on complex 2D programming skills.
Speaking of beautiful interfaces, if you're looking for inspiration or actual graphical elements to put in your interface, I frequently get some great ideas at 365psd ... they actually provide the Photoshop documents to reproduce some eye dropping UI goods, for FREE. Some places may just give you a PNG, but this does little good if you want to scale it (#2x or iPad) or customize it to fit your needs. It's like open source for graphical UI design.
I have a set of functionality (classes) that I would like to share with an application I'm building for the iPhone and for the Blackberry (Java). Does anyone have any best practices on doing this?
This is not going to be possible as far as I understand your question - the binary format for the iPhone and Java are not compatible - and even for a native library on a blackberry device.
This is not like building for OS X where you can use Java unfornately the iPhone doesn't support Java.
The best idea is probably to build you library in Objective-C and then port it to Java which is an easier transition than going the other way. If you programme for Objective-C and make sure you code has no memory leaks - then the changes are not so complex.
If you keep the structure of your classes the same then you should find maintenance much simpler - fix a bug in the Java and you should find it easy to check for the same bug in the ObjC methods etc.
Hope this helps - sorry that it is not all good news.
As Grouchal mentioned - you are not going to be able to share any physical components of your application between the two platforms. However you should be able to share the logical design of your application if you carefully separate it into highly decoupled layers. This is still a big win because the logical application design probably accounts for a large part of your development effort.
You could aim to wrap the sections of the platform specific APIs (iPhone SDK etc.) that you use with your own interfaces. In doing so you are effectively hiding the platform specific libraries and making your design and code easier to manage when dealing with differences in the platforms.
With this in place you can write your core application code so that it appears very similar on either platform - even though they are written in different languages. I find Java and Objective-C to be very similar conceptually (at least at the level at which I use it) and would expect to be able to achieve parity with at least the following:
An almost identical set of Java and Objective-C classes with the same names and responsibilities
Java/Objective-C classes with similarly named methods
Java/Objective-C methods with the same responsibilities and logical implementations
This alone will make the application easier to understand across platforms. Of course the code will always look very different at the edges - i.e when you start dealing with the view, threading, networking etc. However, these concerns will be handled by your API wrappers which once developed should have fairly static interfaces.
You might also stand to benefit if you later developer further applications that need to be delivered to both platforms as you might find that you can reuse or extend your API wrappers.
If you are writing a client-server type application you should also try and keep as much logic on your server as possible. Keep the amount of extra business logic on the device to a minimum. The more you can just treat the device as a view layer the less porting you'll have to do over all.
Aside from that, following the same naming conventions and package structure across all the projects helps greatly, especially for your framework code.
The UI API's and usability paradigms for BlackBerry and iPhone are so different that it won't be possible in most cases to directly port this kind of logic between apps. The biggest mistake one could make (in my opinion) is to try and transplant a user experience designed for one mobile platform on to another. The way people interact with BlackBerrys vs iPhones is very different so be prepared to revamp your user experience for each mobile platform you want to deploy on.
Hope this is helpful.
It is possible to write C++ code that works in both a BB10 Native app and an iOS app.
XCode would need to see the C++ files as ObjectiveCPP code.
I am currently working on such a task in my spare time. I have not yet completed it enough to either show or know if it is truly possible, but I haven't run in to any road-blocks yet.
You will need to be disciplined to write good cross-platform code designed w/ abstractions for platform-specific features.
My general pattern is that I have "class Foo" to do cross platform stuff, and a "class FooPlatform" to do platform specific stuff.
Class "Foo" can call class "FooPlatform" which abstracts out anything platform specific.
The raw cross-platform code is itself not compile-able on its own.
Separate BB10 and XCode projects are created in their respective IDEs.
Each project implements a thin (few [dozen] line) "class FooPlatform" and references the raw cross-platform code.
When I get something working that I can show I will post again here...
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 last month.
Improve this question
Summary:
Can I program a "thick
client" game in C without reinventing
wheels, or should I just bite the
bullet and use some library or SDK?
I'm a moderate C programmer and am not
afraid to work with pointers, data
structures, memory locations, etc. if
it will give me the control I need to
make a great "thick-client" game.
However, I'm thinking of eschewing
high-level languages & frameworks for
the sake of power and control, not
ease of use.
I'm interesting in tinkering with a 2D fighting/platforming game as a side project sometime. I'm primarily a Linux server-side programmer with experience in Python, Ruby and PHP. I know that there are excellent frameworks in some of these languages, like PyGame. I am also aware of the success people have had with stuff like Air and .NET... but I have some concerns:
Performance: Scripting languages are notoriously slow. If I'm making a real-time game, I want it to be as snappy as possible.
Huge binaries: Using frameworks like .NET or scripting languages like Ruby often result in big CLRs or libraries that you wouldn't otherwise need. The game I want to make will be small and simple--I don't want its CLR to be bigger than the game itself!
Extra stuff: Honestly, I just don't like the idea of inheriting some big game library's baggage if I can wrap my head around my own code better.
I'm asking this question because I know I'm very susceptible to Not Invented Here Syndrome. I always want to program it myself, and I'm sure it wastes a lot of time. However, this works out for me remarkably often--for example, instead of using Rails (a very big web project framework with an ORM and GUI toolkit baked in), I used an array of smaller Ruby tools like rack and sequel that fit together beautifully.
So, I turn to you, SO experts. Am I being naive? Here's how I see it:
Use C
Cons
Will probably make me hate programming
High risk of reinventing wheels
High risk of it taking so long that I lose interest
Pros
Tried & true - most A-list games are done in C (is this still true today?)
High level of control over memory management, speed, asset management, etc., which I trust myself to learn to handle
No cruft
Use framework or SDK
Cons
Risk of oversized deliverable
Dependent on original library authors for all facets of game development--what if there isn't a feature I want? I'll have to program it myself, which isn't bad, but partially defeats the purpose of using a high-level framework in the first place
High risk of performance issues
Pros
MUCH faster development time
Might be easier to maintain
No time wasted reinventing common paradigms
What else can I add to this list? Is it a pure judgment call, or can someone seal the deal for me? Book suggestions welcome.
I believe you are working under a fallacy.
There are several frameworks out there specifically for game programming --- written by people with much experience with the complication of game design, almost certainly more tha you do.
In other words, you have a "High risk of performance issues" if you DON'T use a framework.
My current thinking is:
If you want to learn to program, start making the game engine from the base elements upwards (even implementing basic data structures - lists, maps, etc). I've done this once, and while it was a learning experience, I made many mistakes, and I wouldn't do this a second time around. However for learning how to program as well as making something cool and seeing results I'd rate this highly.
If you want to make a proper game, use whatever libraries that you want and design all of the game infrastructure yourself. This is what I'm doing now, and I'm using all of the nice things like STL, ATL/WTL, Boost, SQLite, DirectX, etc. So far I've learnt a lot about the middle/game logic aspect of the code and design.
If you just want to make a game with artists and other people collaborating to create a finished product, use one of the existing engines (OGRE, Irrlicht, Nebula, Torque, etc) and just add in your game logic and art.
One final bit of wisdom I've learnt is that don't worry about the Not Invented Here syndrome. As I've come to realise that other libraries (such as STL, Boost, DirectX, etc) have an order of magnitude (or three) more man-hours of development time in them, far more than I could ever spend on that portion of the game/engine. Therefore the only reason to implement these things yourself is if you want to learn about them.
I would recomend you try pyglet.
It has good performance, as it utilizes opengl
Its a compact all-in-one library
It has no extra dependencies besides python
Do some tests, see if you can make it fast enough for you. Only if you prove to yourself that it's not move to a lower level. Although, I'm fairly confident that python + pyglet can handle it... at worst you'll have to write a few C extensions.
Today, I believe you are at a point where you can safely ignore the performance issue unless you're specifically trying to do something that pushes the limits. If your game is, say, no more complicated than Quake II, then you should choose tools and libraries that let you do the most for your time.
Why did I choose Quake II? Because running in a version compiled for .NET, it runs with a software renderer at a more than acceptable frame rate on a current machine. (If you like - compare MAME which emulates multiple processors and graphics hardware at acceptable rates)
You need to ask yourself if you are in this to build an engine or to build a game. If your purpose is to create a game, you should definitely look at an established gaming engine. For 2D game development, look at Torque Game Builder. It is a very powerful 2D gaming engine/SDK that will put you into production from day 1. They have plenty of tools that integrate with it, content packs, and you get the full source code if you want to make changes and/or learn how it works. It is also Mac OSX compatible and has Linux versions in the community.
If you are looking for something on the console side, they have that too.
I'm surprised nobody has mentioned XNA. Its a framework built around DirectX for doing managed DirectX programming while removing a lot of the fluff and verbosity of lower level DirectX programming.
Performance-wise, for most 2D and 3D game tasks, especially building something like a fighting game, this platform works very well. Its not as fast as if you were doing bare metal DirectX programming, but it gets you very close, and in a managed environment, no less.
Another cool benefit of XNA is that most of the code can be run on an Xbox 360 and can even be debugged over the network connection was the game runs on the Xbox. XNA games are now allowed to be approved by the Xbox Live team for distribution and sale on Xbox Live Arcade as well. So if you're looking to take the project to a commercial state, you might have am available means of distribution at your disposal.
Like all MS development tools, the documentation and support is first rate, and there is a large developer community with plenty of tutorials, existing projects, etc.
Do you want to be able to play your game on a console? Do you want to do it as a learning experience? Do you want the final product to be cross platform? Which libraries have you looked into so far?
For a 2d game I don't think performance will be a problem, I recommend going with something that will get you results on screen in the shortest amount of time. If you have a lot of experience doing Python then pyGame is a good choice.
If you plan on doing some 3d games in the future, I would recommend taking a look at Ogre (http://www.ogre3d.org). It's a cross platform 3d graphics engine that abstracts away the graphics APIs. However for a 2d project it's probably overkill.
The most common implementation language for A-list games today is C++, and a lot of games embed a scripting language (such as Python or Lua) for game event scripting.
The tools you'd use to write a game have a lot to do with your reasons for writing it, and with your requirements. This is no different from any other programming project, really. If it's a side project, and you're doing it on your own, then only you can assess how much time you have to spend on this and what your performance requirements are.
Generally speaking, today's PCs are fast enough to run 2D platformers written in scripting languages. Using a scripting language will allow you to prototype things faster and you'll have more time to tweak the gameplay. Again, this is no different than with any other project.
If you go with C++, and your reasons don't have to be more elaborate than "because I want to," I would suggest that you look at SDL for rendering and audio support. It will make things a little bit easier.
If you want to learn the underlying technologies (DirectX, or you want to write optimized blitters for some perverse reason) then by all means, use C++.
Having said all that, I would caution you against premature optimization. For a 2D game, you'll probably be better off going with Python and PyGame first. I'd be surprised if those tools will prove to be inadequate on modern PCs.
As to what people have said about C/C++/Python, I'm a game developer and my company encourages C. Not b/c C++ is bad, but because badly written C++ is poison for game development due to it's difficulty to read/debug compared to C. (C++ gives benefits when used properly, but let a junior guy make some mistakes with it and your time sink is huge)
As to the actual question:
If your purpose is to just get something working, use a library.
Otherwise, code it yourself for a very important reason: Practice
Practice in manipulating data structures. There WILL be times you need to manage your own data. Practice in debugging utility code.
Often libs do just what you want and are great, but sometimes YOUR specific use case is handled very badly by the lib and you will gain big benefits from writing you own. This is especially on consoles compared to PCs
(edit:) Regarding script and garbage collection: it will kill you on a console, on a recent game I had to rewrite major portions of the garbage collection on Unreal just to fill our needs in the editor portion. Even more had to be done in the actual game (not just by me) (to be fair though we were pushing beyond Unreal's original specs)
Scripting often good, but it is not an "I win" button. In general the gains disappear if you are pushing against the limits of your platform. I would use "percent of platforms CPU that I have to spare" as my evaluation function in deciding how appropriate script is
One consideration in favor of C/C++/obj-C is that you can mix and match various libraries for different areas of concern. In other words, you are not stuck with the implementation of a feature in a framework.
I use this approach in my games; using chipmunk for 2D physics, Lua as an embedded scripting language, and an openGL ES implementation from Apple. I write the glue to tie all of these together in a C language. The final product being the ability to define game objects, create instances of them, and handle events as they interact with each other in C functions exposed to Lua. This approach is used in many high performance games to much success.
If you don't already know C++, I would definitely recommend you go forward with a scripting language. Making a game from start to finish takes a lot of motivation, and forcing yourself to learn a new language at the same time is a good way to make things go slowly enough that you lose interest (although it IS a good way to learn a new language...).
Most scripting languages will be compiled to byte code anyway, so their biggest performance hit will be the garbage collection. I'm not experienced enough to give a definite description of how big a hit garbage collection would be, but I would be inclined to think that it shouldn't be too bad in a small game.
Also, if you use an existing scripting language library to make your game, most of the performance critical areas (like graphics) can be written in C++ anyway (hopefully by the game libraries). So 80% of the CPU might actually be spent in C++ code anyway, despite the fact that most of your project is written in, say Python.
I would say, ask yourself what you want more: To write a game from start to finish and learn about game development, or to learn a new language (C++). If you want to write a game, do it in a scripting language. If you want to learn a new language, do it in C++.
Yeah unless you just want to learn all of the details of the things that go into making a game, you definitely want to go with a game engine and just focus on building your game logic rather than the details of graphics, audio, resource management, etc.
Personally I like to recommend the Torque Game Builder (aka Torque 2D) from GarageGames. But you can probably find some free game engines out there that will suit your needs as well.
I'm pretty sure most modern games are done in C++, not C. (Every gaming company I ever interviewed with asked C++ questions.)
Why not use C++ and existing libraries for physics + collisions, sound, graphics engine etc. You still write the game, but the mundane stuff is taken care of.
There are alot of different solutions to the issue of abstracting and each deals with it in different ways.
My current project uses C#, DirectX 9, HLSL and SlimDX. Each of these offers a carefully calibrated level of abstraction. HLSL allows me to actually read the shader code I'm writing and SlimDX/C# allows me to ignore pointers, circular dependencies and handling unmanaged code.
That said, none of these technologies has any impact on the ease of developing my AI, lighting or physics! I still have to break out my textbooks in a way that I wouldn't with a higher-level framework.
Even using a framework like XNA, if most video games development concepts are foreign to you there's a hell of a lot still to take in and learn. XNA will allow you to neatly sidestep gimbal lock, but woe betide those who don't understand basic shading concepts. On the other hand, something like DarkBASIC won't solve your gimbal lock problem, but shading is mostly handled for you.
It's a sufficiently big field that your first engine will never be the one you actually use. If you write it yourself, you won't write it well enough. If you use third party libraries, there's certainly aspects that will annoy you and you'll want to replace.
As an idea, it might be worth taking various libraries/frameworks (definately make XNA one of your stops, even if you decide you don't want to use it, it's a great benchmark) and trying to build various prototypes. Perhaps a landscape (with a body of water) or a space physics demo.