Subscribe to GameFromScratch on YouTube Support GameFromScratch on Patreon
30. April 2012

image

 

 

 

Research in Motion, of Blackberry and Playbook fame, recently released Gameplay 1.2, a cross-platform 3D game programming library aimed at Indie developers.  As a game maker, it is easy to ignore RIM these days, especially with their CEO making comments like:

 

"We plan to refocus on the enterprise business and capitalise on our leading position in this segment,"

 

That doesn’t exactly give you the warm and fuzzy about the future of RIM consumer devices now does it?

 

That said, ignoring GamePlay would be a foolish thing to do.  Why?

 

Well first off, it’s free.  I like free.  As in, I really like free.

 

Second and perhaps most amazingly, it is cross platform.  You can target Mac OS, Windows, iOS 5.0 or higher devices, Android 2.3 or greater devices in addition to Blackberry Tablet OS 2.0 and Blackberry 10 devices ( when they arrive ).

 

Third, it’s IDE agnostic, except when required otherwise ( aka, compiling for iOS ).  I can work in my preferred Visual Studio environment.  You however have the choice between Visual Studio, XCode or Momentics IDE ( an Eclipse based IDE Rim inherited from QNX ).

 

Fourth, it’s open source and hosted on GitHub.

 

Here is a screen shot from a demo game in development:

 

 

I have to say, it looks impressive to me.

 

 

Oh, did I happen to mention it’s C++ based?  I think I just heard half of you cheer, while the other half swore! Winking smile

 

 

I do have to say, the folks at Marmalade probably aren’t pleased.  They both fill the same niche… but gameplay is free.  Now the question is, how good is it?

 

Feature-wise, here is what you can expect:

 

Current features in gameplay
  • Written completely in C++ and well documented using doxygen.
  • Solution and workspaces for Visual Studio 2010, XCode 3.2.1 and Momentics IDE’s.
  • Platform-Game abstraction layer separating all operating system code from game engine code.
  • Input system support for Mouse, Keyboard and Touch.
  • Full vector math library with classes for Vector2/3/4, Matrix, Quaternion, Ray, Plane. Also Frustum and BoundingBox/BoundingSphere classes for object culling.
  • Solid OpenGL 3.2+ (for Desktop) and OpenGL ES 2.0 (for Mobile) based rendering system with classes for RenderState, FrameBuffer, Mesh, Material, Effect, Pass and Techniques.
  • Easy-to-use and efficient Font and Sprite classes.
  • Scene-graph components such as Scene, Node, Light, Camera and Model.
  • Binary encoding tool for creating optimized bundles for loading TTF fonts and 3D game assets supporting both COLLADA and FBX formats.
  • Extensible animation system with classes for Animation, AnimationClip and Curve with built-in AnimationTarget’s on Transform and MaterialParameter’s classes.
  • Complete 3D audio system with additional support for compressed audio using OGG and supporting HDMI gaming.

 

New features in gameplay v1.2
  • Newplatforms now supporting:
    • BlackBerry Tablet OS 2.0 and BlackBerry 10 ready!
    • Apple iOS 5.1 for iPhone and iPad
    • Google Android 2.3+
    • Microsoft Windows 7
    • Apple MacOSX
  • New shader-based material system with built-in common shader library.
  • New declarative scene binding.
  • New declarative particle system.
  • Improved physics system with rigid body dynamics and constraints.
  • New character physics and ghost objects.
  • Improved animation system supporting animated skeletal character animation.
  • New declarative user interface system with support for declartive theming and ortho, and 3D form definition with built-in core control classes such as Button, Label, TextBox, Slider, CheckBox, RadioButton. Also includes Layout classes such as Absolute/Vertical and FlowLayout.
  • New cross-platform new game project wizard scripts.
  • New game developer guide.
  • New game samples and tutorials.

 

 

With the following coming soon:

 

The ‘next’ feature branch for v1.3, v1.4, v1.5
  • Optimizations and Performance improvements
  • Shadows
  • Terrain and Sky
  • Gamepad input for Wii, Xbox 360 and Bluetooth® HID controllers
  • Scoreloop Social integration
  • Editor

 

 

Editor hmm?  Wonder what that means?

 

 

I am going to download and play with the SDK, and if I get some time ( something I am chronically short of lately ) I may post a walk around and possibly a tutorial or two.  Has anyone out there been playing with this technology?  Any opinions?

 

 

If you are interested, check out the announcement blog post as well as the source on GitHub.  Oh and perhaps most impressive of all for an open source gaming product… there is actually documentation. The documentation is available here including this development guide[direct pdf link].

 

I have to say, congratulations to Sean Paul Taylor and Steve Grenier on this impressive release!

General


26. April 2012

 

I am noticing from search traffic that this is an extremely common question, people seem to want to know if you can use C++ with the PS Studio SDK.VitaCpp

 

 

Simple answer and you aren’t going to like it.

 

 

No, no you can’t.

 

 

 

I wouldn’t hold your breath either, it’s the mono runtime behind the scenes that is providing the portability across devices.  If you want native C++ support you need to have access to the full development suite.  Even becoming a PSN developer to develop PSN Mini games requires well over 1000$.

 

 

 

If for some reason you prefer C++’s syntax over C# ( this may in fact be a sign of insanity by the way… ), you *might* and I emphasize *might* be able to take advantage of this project CPlusPlus, at some point, but even then you would have to write pure CIL code.  Without native access, there would be very little point using C++ in this situation.

 

 

 

Therefore for all intents and purposes, no you cannot use C++ with PlayStation Suite. C# is the only game in town and I wouldn’t expect to see that change any time soon. 

Programming


31. December 2011

 

 

As the title says, the 9th part of our C++ game programming using SFML tutorial is now live. In this chapter we implement a caching solution for dealing with SFML game audio files. Along the way we learn a bit about C++ exception handling as well as touch on the subject of C++ templates. We also implement our second paddle and give it the most basic of artificial intelligence.

 

 

 

As the majority of this chapter is audio related, this image really isn’t all that impressive, but here is our current game in action.  We are very near to a complete game at this point and have covered most of the basics of C++!

 

 

pang9b

 

 

 

 

You can access part 9 by clicking here.  If you haven’t read any of the tutorial yet, you can access the table of contents here.  Again, any and all feedback appreciated.

Programming


22. November 2011

 

 

Continuing the long standing ( and very cool ) tradition of releasing id source code a number of years after being released to market, the Doom3 engine/game source code has been made available on GitHub.

 

 

I have only had the chance to peruse it briefly, but I have to say what I saw was very clean, and shockingly enough C++!  After seeing prior id code, I simply figured it would be straight C for some reason.

 

 

Anyways, I highly recommend you check it out.  Clean, complete, professional quality source code isn’t made available every day, and Carmack really is one of our day’s brilliant minds.  I know I will be doing so in more detail shortly!

 

 

Now I cant wait for someone to port Doom 3 to my toaster…

Programming


20. November 2011

 

 

Handling game time is problem that almost all games have to deal with.  A very good question recently came up in my C++ game from scratch tutorial about why I didn’t normalize the players movements which reminded me of a post on the subject.

 

 

Years ago Shawn Hargreaves of XNA ( and Allegro ) fame blogged about how XNA handles the Update and Render loops.  I simply post it here again because it is one of the most succinct posts I have encountered on the subject.  So, if you are looking into creating a game and need to figure out how to implement the game loop, I recommend you give it a read.

 

By default XNA runs in fixed timestep mode, with a TargetElapsedTime of 60 frames per second. This provides a simple guarantee:

  • We will call your Update method exactly 60 times per second
  • We will call your Draw method whenever we feel like it

 

Digging into exactly what that means, you will realize there are several possible scenarios depending on how long your Update and Draw methods take to execute.

 

The simplest situation is that the total time you spend in Update + Draw is exactly 1/60 of a second. In this case we will call Update, then call Draw, then look at the clock and notice it is time for another Update, then Draw, and so on. Simple!

 

What if your Update + Draw takes less than 1/60 of a second? Also simple. Here we call Update, then call Draw, then look at the clock, notice we have some time left over, so wait around twiddling our thumbs until it is time to call Update again.

 

What if Update + Draw takes longer than 1/60 of a second? This is where things get complicated. There are many reasons why this could happen:

 

  1. The computer might be slightly too slow to run the game at the desired speed.
  2. Or the computer might be way too slow to run the game at the desired speed!
  3. The computer might be basically fast enough, but this particular frame might have taken an unusually long time for some reason. Perhaps there were too many explosions on screen, or the game had to load a new texture, or there was a garbage collection.
  4. You could have paused the program in the debugger.

 

We do the same thing in response to all four causes of slowness:

  • Set GameTime.IsRunningSlowly to true.
  • Call Update extra times (without calling Draw) until we catch up.
  • If things are getting ridiculous and we are too far behind, we just give up.

If you think about how this algorithm deals with the four possible causes of slowdown I listed above, you'll see it handles them all rather well:

  1. Even if the computer is too slow to run Update + Draw inside a single frame, chances are that Update + Update + Draw will fit into two frames. The game may look a little jerky, but it will still play correctly. If the programmer is particularly smart they might even notice that we set IsRunningSlowly, and automatically reduce detail or turn off special effects to speed things up.
  2. If the computer is way too slow (ie. if the Update method alone is too slow to fit into a single frame) there isn't really much we can do, other than set IsRunningSlowly, cross our fingers, and hope the game might do something clever in response to that. Most of the time, though, if you find yourself in this situation you just need a faster computer!
  3. If a particular frame happens to take unusually long, we automatically call Update some extra times to catch up, after which everything carries on as normal. The player may notice a slight glitch, but we automatically correct for this to minimize the impact.
  4. Pausing in the debugger will leave the game a long way behind where the clock says it should be, so our algorithm will give up, accept that it has lost some time, and continue running smoothly from the time execution was resumed.

 

 

Shawn’s blog in general is a very good read, but this this post in particular is one that I seem to keep coming back to.

 

For the record, Pang from the C++ tutorial does not gracefully handle hitting a breakpoint ( it adds a layer of unwanted complexity for learning purposes ), so will do downright stupid things when it hits a breakpoint causing it to pause for a while.  I believe on the next frame it will cause your movement to be really really really far.  It would be as simple as adding if(elapsedTime > someReallyBigValue) startTimeOver() if you really wanted to fix this.

 

 

Sorry for digging up the past, now back to your regular broadcast!

Programming


GFS On YouTube

See More Tutorials on DevGa.me!

Month List