1. Mobile App Development

In a world that’s increasingly social and open, mobile apps play a vital role, and have changed the focus from what’s on the Web, to the apps on our mobile device. Mobile apps are no longer an option, they’re an imperative.

Everyone needs a mobile app, but where and how to start? There are many factors that play a part in our mobile strategy, such as our team’s development skills, required device functionality, the importance of security, offline capability, interoperability, etc., that must be taken into account. It’s not just a question of what your app will do, but how to get there.

At the moment we support building two types of apps:

Native apps are specific to a given mobile platform (iOS or Android) using the development tools and language that the respective platform supports (e.g., Xcode and Objective-C with iOS, Eclipse and Java with Android). Native apps look and perform the best.

HTML5 apps use standard web technologies—typically HTML5, JavaScript and CSS. This creates cross-platform mobile applications that work on multiple devices. While developers can create sophisticated apps with HTML5 and JavaScript alone, some vital limitations remain at the time of this writing, specifically session management, secure offline storage, and access to native device functionality (camera, calendar, geolocation, etc.

2. Mobile Game Development

Making mobile games are not all about how easy, but also how to remain in the business. This includes how to balance the fun, creative side of the job and maintaining the quality and providing support for each game created.

Well this is how we do it :

2.1 Ideas

An idea is the first and the most important thing in this development project. This idea should include following :

  • Who is our player or target?
  • Why would a player want to play our game? What players’ needs does the game solve?
  • What kind of experience do we want the player to have? What is essential to that experience?
  • Is the game fun? What parts of it are fun?
  • What will surprise players when they play our game? What kind of surprises will we have through the game?
  • What is valuable in the game? How does the value correspond to inner motivations of the player?
  • What kind of problem solving does the game involve?

2.2 Develop the Concept

A game concept is a brief document containing a quick game overview and basic representation of four building blocks of every game.

2.3 Game Mechanics

Mechanics, the ruleset of the game, describe the steps a player takes to achieve the goals of the game.

2.4 Setting

The setting encapsulates two important parts: story and aesthetics. The story describes the game world, events that had happened before and events happening during the gameplay. The aesthetics is about how your game looks and sounds. Both parts of the settings are closely tied together. Both of them are extremely important to the user experience. The story could be omitted for some abstract games.

2.5 Technology

This may include but not limited to :

  • What are the target devices?
  • What kind of middleware are we going to use to create the game?
  • What programming language is the best choice for our target platform?
  • How much performance do we actually need, considering the chosen aesthetics?

2.6 Interaction

  • How do users interact with the game?
  • How are we going to use advantages of the device and chosen input methods?

This part is extremely important when mobile devices are taken into consideration.

2.7 Develop the Proof of Concept

Some parts of the concept document need to be verified as soon as possible. For example:Will the technology handle the task? To check this you need to create a quick and dirty implementation of critical features.

How does your setting appeal to the target audience?

Is the gameplay engaging enough? Most of the games could be reduced to paper / board game prototype and still work. In fact, if your game isn’t physics-based, but fails as a paper prototype it’s a good indication that it will fail after being coded.

2.8 Create a Game Design Document (GDD)

A game design document is a highly descriptive and detailed document of the design for a game. A GDD is a living document, which means it’s prone to feedback. Every time the requirements change, a GDD should change.  Usually, a GDD is created and edited collaboratively by developers and designers and used to organize the efforts within the team.

Unlike the high-level concept document, the GDD includes the underlying details of realization.

2.9 Create Prototypes

While most of the mechanics are already tested during the PoC phase, it is important to create a playable prototype for your target platform. A prototype should include most of the important mechanics and resemble substantial parts of the game.

2.10 Design Architecture

Most of the game functions and scenarios evolve during the development stage. Hardly any game in the world looks and behaves like it was initially described in the GDD. New ideas arise, the technology changes and so does the project. Ever-changing nature of game development requires very flexible architectural solutions based on the modular approach. Creating this kind of architecture design may be a hard task, but it is the most important phase in the game development process. The team of mediocre developers won’t have problems joining the dev team if a great architectural solution is already in place and presented to them, but even the best developers will struggle with a poor architecture framework.

2.11 Development

With the architecture already designed and prototypes created, the team should have no problems with the actual development. Due to above mentioned volatile requirements of the games, agile methodology should be used. Creating a Minimum Viable Product as soon as possible is also important for the team motivation and involvement of a QA into the process. Required tools should be created / bought at the highest priority. Having shared solutions for typical tasks is important for writing the supportable code. An early availability of the tools means that the game designers and artists will start working on the game configuration (like balance, lights, particles etc) as soon as possible.

2.12 Test the Game

As soon as the first playable versions are available, QAs and beta testers should join the team. When testing is in place, some teams prefer to work using tik-tok methodology, alternating between new feature development and bug fixing sprints. Delaying all the bug fixes is extremely ineffective and dangerous: it reduces the effectiveness of testing and may lead to accumulation of hard to solve problems.

When a release is approaching, the alpha and beta testing phases are required. During the alpha testing, the unfinished game is exposed to a narrow range of potential players to get the feedback about the gameplay and behavior of the game in the wild on a wide range of devices. During the beta-test there should be no critical errors, most of the content should be already in the game. This phase is mostly used to test the performance and make final fixes and balance small tweaks. Adding new features is highly unlikely during the beta testing stage.

2.13 Support the Game

For most mobile and web projects, a release is just the start of the long road. To achieve a continual growth of the user base and high retention rates, the game updates are critical! The analysis of the modern hit games suggests that the updates should be released every two-five weeks and every other update should add more content to the game.