Most companies are using some kind of server based reward system which offers a REST based API in order to monitor activities. Once certain tasks are completed to satisfactory levels then an electronic reward is triggered such as badges, high scores and certificates.
It is far easier to store these rewards on the server for the purposes of sharing them socially across services like Facebook, Twitter and Instagram. It also enables us to change the rules on the server without having to try and push out a dynamic rules engine to all of the mobile clients.
There are plenty of vendors offering Cloud SaaS solutions with reward systems and as long as they offer a REST API with a CRUD philosophy then its easy enough to call them from desktop, mobile or IoT clients.
If you want to build your own such system then looking at the Tin Can API is a good start because it already offers the ability to monitor activities and store progress.
This is all largely server based with the client simply logging progress to the server and downloading any rewards. The other side of the equation is a client-side gaming engine. If Flappy Bird taught us anything its that the 'sticky factor' is fuelled by high score competitions and the subsequent financial gains through advertising are substantial.
Of course writing client-side games is a totally different skillset to calling a server side engine which stores rewards. Firstly you need to get a decent game designer who knows how to create a compelling gaming experience and this isn't the same as a user experience guru - no matter how hard you try to convince me.
Once you have a compelling game design then you need to choose a high performance gaming engine. Here is a hint: Flash is dead, long live HTML5 Canvas. You then need to find a decent developer to write your gaming masterpiece.
The skillsets for application user interfaces and game development are sadly world apart. A game developer has to be able to code to the metal with a watchful eye on performance. They will be drawing most of the graphics themselves using 'direct draw' as opposed to customising user interface components out of the box.
Of course there are plenty of HTML5 Game Engines out there and some are incredibly advanced. These offer valuable gaming commodities like sprint engines, tiling engines and font generators. HTML5 Web Storage can be used to store the high scores locally and AJAX can be used to upload the results.
If you really want to push the boat out then you can even look at multiplayer experiences. Firebase offers a real-time Mobile Backend as a Service which may be worth investigating. Other options include Meteor (which is a popular option) and using the MEAN stack with Socket.io.
Before you start on your journey you really need to de-construct your user journeys and work out how to implement a successful reward system and how to integrate any gaming widgets.
This process involves user experience gurus and preferably somebody who has implemented a gamification system commercially, as opposed to somebody having an overbearing passion on the subject.
A good starting point is working out which activities you want to monitor and what kind of behaviours you want to drive. If you are filling in a multiple choice exam then you could monitor the following: answers correct; answers correct in a row; time taken for each question; and even answers compared with others taking the exam at the same time.
Following the example then the server side reward system could trigger rewards based on real-time behaviour (such as 3 questions correct in a row) or non-real-time behaviour (such as a certificate of completion).
It may be that you don't want to implement real-time feedback for exams because most educational systems don't allow that. If its a casual quiz though then real-time feedbacks with "3 in a row" logos and score multipliers could be fun.
Finally don't forget that implementing multiplayer is difficult because you need a server to manage all of this. Sending the data over the air is much faster now with Web Sockets (TCP) and WebRTC (UDP) available in the web world. A service like Firebase or a developer with Meteor / Socket.io skills is definitely required though.
If you want to take your web experience and put it through PhoneGap to get it on an App Store then please don't forget to run an HTML 5 Canvas to OpenGL converter. You will find Intel XDK and CocoonJS offer nice solutions.
A really interesting option that I have my eye on is a portable native gaming solution called Platino. It is always worth checking out technology solutions actually written by gaming professionals.