At a Glance
DGA is a free/libre/open-source, cross-platform, massively multiplayer online role-playing video game (MMORPG) featuring weapons. The first type of weapons being realised is land combat vehicles.
Now DGA has reached the Minimum Viable Product’s stage and Version 0.1 is going to be published soon with its source code and documentation.
DGA proves multiple computational, technological, and gaming concepts at once, with the current estimates:
1. It is highly likely that a full-scaled F/LOSS Java game can be implemented.
2. It is highly likely that a full-scaled F/LOSS Java MMORPG can be implemented.
3. It is highly likely that a full-scaled F/LOSS Java MMORPG powered by jMonkeyEngine can be implemented.
4. It is most likely that a F/LOSS Java MMORPG backended by Jakarta EE can be implemented.
5. It is most likely that an XMPP-based F/LOSS Java MMORPG can be implemented.
6. If a successful F/LOSS Java MMORPG can be implemented is still in progress.
7. If a successful F/LOSS Java MMORPG can be developed with only F/LOSS tools is still in progress.
Proof of concept has become a useful tool for proving feasibility in different areas: engineering, project management, marketing, pharmaceuticals, etc. In software development, a proof of concept is closely related to a prototype and sometimes serves as its base. Proof of value is also used along proof of concept but mostly focused on business value a software system brings to users. A minimum viable product is often considered as an improved version of the prototype. All these notions have clear definitions, which though vary in details. In this article we are going to examine these definitions and determine their implementation for the DGA Game.
What they finally prove?
A software system is developed through a process that is a series of stages followed to design, implement, test, and maintain software applications and components, which constitute the target software system and then software product. At the end of every stage the system has to satisfy a set of requirements defined by the following notions, each of which indicates some finished result.
1. Proof of Concept (POC)
Wikipedia gives the most generalised definition of proof of concept:
Proof of concept (POC or PoC), also known as proof of principle, is a realization of a certain idea, method or principle in order to demonstrate its feasibility, or viability, or a demonstration in principle with the aim of verifying that some concept or theory has practical potential. A proof of concept is usually small and may or may not be complete.
TechTarget makes the definition more precise:
A proof of concept (POC) is a demonstration of a product in which work is focused on determining whether an idea can be turned into a reality. A POC’s goal is not to seek market demand for the concept or choose the best way to produce it. Rather than focusing on building or developing the idea, it tests whether the idea is feasible and viable. In addition, it enables those involved in the proof-of-concept exercise to explore its financial potential.
Thereby, we can define the following requirements a proof of concept has to meet in the field of software development:
- Realise some concept (idea, method, principle).
- Be an implementation (a turn into a reality) of the concept.
- Demonstrate feasibility (viability, practical potential) of the concept in reality.
- Be sufficiently small.
- Be sufficiently complete.
- Confirm the likelihood of the implementation’s success.
- Demonstrate the software system satisfies some aspect of the business purpose it was designed for.
The Unified Process (UP) that is a methodology of software development has an artifact called Architectural Proof-of-Concept (APOC) elaborated by a software architect during the Analysis & Design stage.
APOC is developed to help determine the feasibility of the project, assess the technical risks attaching to its development, and formulate and refine the architecturally-significant requirements.
APOC may take different forms, for example:
- A list of appropriate technologies (frameworks, patterns, executable architectures).
- A sketch of a conceptual model of a solution.
- A simulation of a solution.
- An executable prototype.
In summary, a proof of concept can be determined as a software system, which implements some concept within some technology stack in a solution and demonstrates feasibility of this solution for the target business purposes and users. The software system can be as small and complete as sufficient to confirm its viability and the likelihood of the implementation’s success.
In game development, tech and game demos serve as proof of concept demonstrating graphical and gameplay capabilities of the future game.
2. Proof of Value (POV)
As proof of concept, proof of value is the first realisation of a certain idea especially concentrated on demonstrating the business value and tangible benefits of a solution for business users and stakeholders. Proof of concept and proof of value can be demonstrated as a single solution.
Accordingly, a proof of value is a software system, which seeks to show how the solution can solve specific business problems and bring significant benefits to the company and end users. The software system often involves testing in real-life scenarios to quantify efficiency gains, cost savings, customer satisfaction, and other commercial benefits. The findings made during the proof of value’s elaboration are later implemented in prototypes and the minimum viable product.
3. Prototype
Prototyping is another engineering practice widely used nowadays. During prototyping a development team implements ideas and concepts into tangible forms from paper to digital. The team builds one or more prototypes of varying degrees of approximation to capture design concepts and test them on users. If previously a proof of concept had been implemented then the prototype can be a further development of it.
Thereby, a prototype is an early implementation of a software product or information system built for demonstration purposes and/or as a part of the development process.
Although the terms ‘proof of concept’ and ‘prototype’ are used interchangeably, but in fact they imply different results and serve different purposes. The purpose of a proof of concept is to help decide whether the idea is feasible or not, and to ensure it will work as intended. On the contrary, the purpose of a prototype is to test the usability, functionality and design of a working model.
4. Minimum Viable Product (MVP)
The further development leads the concept’s implementation from the prototypes to the minimum viable product, which comprises all the results of the previous development stages.
A minimum viable product is the simplest version of a new software product that you need to build to sell it to a market. This version allows the development team to collect the maximum amount of validated learning about customers with the least effort.
Then, the development team extends MVP into a Minimum Lovable Product (MLP), which is a customer-centered product that users love from the start, defined by its features and offering the minimum a product needs to be loved.
In its turn, MLP or MVP is developed into a Minimum Marketable Product (MMP) that is the version of the software product ready to be sold to end users. Usually, MMP is viewed as the simplest product that the market will accept before new features are added.
How they prove?
The table below compares the aforesaid notions by purpose, target, process, result, and limits.
| Proof of Concept (POC) | Proof of Value (POV) | Prototype | Minimum Viable Product (MVP) |
|---|---|---|---|
| Technical demonstration of a concept / product / process. | Business demonstration of a concept / product / process. | Early implementation of a concept / product / process. | The simplest version of a concept / product / process that you need to build to sell it to a market. |
| Determine whether an idea can be turned into a reality. | Show whether an idea can solve practical business problems and bring significant benefits to business users. | Turn POC/POV ideas into a slimmed-down version of the end product that can be tested and evaluated for usability, functionality, and design. | Allow the development team to collect the maximum amount of validated learning about customers with the least effort. |
| Test whether the idea is feasible and explore the idea’s potential to be developed or built. | Validate whether the idea has business potential and opportunities to be implemented. | Give users, stakeholders, project managers, executives, and potential investors a draft of what the final product might be. | Present the simplest version of software product built at a low risk to stakeholders and business that can be tested, refined, and grown step-by-step. |
| Verify that the idea will function as envisioned and identify potential risks that might interfere with success. | Measure the idea’s business value and potential Return On Investment (ROI) that the solution can generate. | Allow makers to determine how best to develop the product when it moves into full production for a final, market-ready item. | Uncover the market’s interest in the software product to study where to make improvements, scale back or add extra features to make the product marketable. |
| Not intended to explore market demand for the idea, nor is it intended to determine the best production process. | Not intended to measure all the business opportunities of the idea, nor may it offer a complete representation of the real-world environment and potential risks. | Not expected to have all the features and functions of a market-ready product, nor is it expected to contain all the usability or aesthetics of a final product. | Not expected to present all the features of a market-ready product, nor is it expected to contain features the market and customers will accept. |
DGA’s Architecture
Now the DGA Game has entered the Minimum Viable Product’s stage and its version 0.1 is going to be presented to the public in the near future.
DGA was conceived as a single proof for a set of computational, technological, and gaming concepts. This intention is implemented in DGA’s architecture, which principal representation is shown on the next figure.
DGA Game’s Principal Architecture
(Click on the image to enlarge; click on ‘X’ to return)
DGA is a free/libre and open-source, cross-platform, massively multiplayer online role-playing video game (MMORPG) featuring weapons. DGA is designed and implemented with a multitier client-server architecture based on the Java Platform and XMPP Network Protocol (Extensible Messaging and Presence Protocol). DGA’s game client is a Java application running on the jMonkeyEngine Game Engine.
DGA is intended to be played with an unlimited number of players accessing through their game clients an unlimited number of game servers connected into a game network. The Java Platform provides an integrated infrastructure that facilitates developing and running software applications written in the Java Programming Language. The Java Platform has been implemented for a wide variety of hardware architectures and operating systems with a view to enable Java programs to run identically on all of them. This intention made Java a truly high-performance, vendor-independent, device-agnostic software ecosystem.
DGA proves multiple concepts at once
DGA tries to prove multiple concepts that are discussed for a quite long time. There are two reasons to do that: first, it is interesting to try to prove them, and, second, it is interesting to find out answers to the same question ‘why not?’. The list of concepts looks as follows.
In game development
1. Is it feasible to implement a full-scaled F/LOSS Java game?
Mojang already proved that it is very feasible to make a game on the Java Platform and written in the Java Programming Language, unfortunately, not free/libre/open-source. There were a lot of other attempts to produce a computer game in Java, but Mojang’s Minecraft is the most full-scaled and successful. DGA aims to make a full-scaled free/libre/open-source Java game at once.
2. Is it feasible to implement a full-scaled F/LOSS Java MMORPG?
Whereas Minecraft wasn’t conceived to be an MMORPG and even an online game, i.e. played over the Internet, nowadays it is. Minecraft provides a very rich functionality for multiplayer gaming with the Minecraft Java Edition Server and various mods including MMO ones. Unfortunately, only some mods are free/libre/open-source. DGA aims to make a full-scaled free/libre/open-source Java MMORPG at once.
3. Is it feasible to use jMonkeyEngine for a full-scaled F/LOSS Java MMORPG?
jMonkeyEngine is an open-source, cross-platform, developer-friendly game engine, which is written in Java and uses Lightweight Java Game Library (LWJGL) as its default renderer, although supports other renderers based on Java OpenGL. There are multiple games powered by jMonkeyEngine and even some MMORPGs as Mythruna. Unfortunately, only a few of them are free/libre/open-source. DGA aims to make a full-scaled free/libre/open-source Java MMORPG powered by jMonkeyEngine at once.
In software architecture
4. Is it feasible to implement a F/LOSS Java MMORPG with Jakarta EE’s backend?
Developing MMO games with game servers that are based on Jakarta EE (formerly known as Java EE) is a long-lasting topic debated for decades. There are a lot of rumours about which MMORPGs, when, and to what degree were backended by Java EE. Obviously, since these games haven’t been free/libre/open-source. DGA aims to make a full-scaled free/libre/open-source Java MMORPG backended by Jakarta EE at once.
In networking
5. Is it feasible to implement an XMPP-based F/LOSS Java MMORPG?
Using XMPP in games is another long-lasting topic debated for many years. There are a lot of games adopting XMPP for different purposes and some of them are free/libre/open-source as 0 A.D., which uses XMPP for its multiplayer lobby. Alas, free/libre/open-source MMORPGs are still lacking. DGA aims to make a full-scaled free/libre/open-source Java MMORPG based on XMPP Network Protocol at once.
In business
6. Is it feasible to implement a successful F/LOSS Java MMORPG?
We are developing the DGA Game in accordance with the Free/Libre-To-Game Business and Development Model. Of course, we want a bright, successful future for our game, but what counts as a success for a game? Well, we aim to make our game as successful as GNU/Linux, Java, 0 A.D., and Mojang’s Minecraft at once.
7. Is it feasible to implement a successful F/LOSS Java MMORPG using F/LOSS tools only?
Although the Free/Libre-To-Game Model doesn’t prohibit usage of the proprietary software to develop free/libre/open-source games, actually the model presupposes that proprietary development tools wouldn’t be used, at least, on a daily basis. Otherwise, it may hamper gamers in rebuilding the game from source code and reproducing infrastructure to verify the game’s fairness. Additionally, this practice lessens the effort in evolving free/libre/open-source tools for software development. DGA aims to be developed with free/libre/open-source tools and services at the fullest extent possible.
What we have already proved?
As far along as DGA advances, our answers to the questions mentioned above become more and more accurate in terms of estimative probability. The table below represents our current estimates.
| # | Concept | Already Proved |
|---|---|---|
| 1 | A full-scaled F/LOSS Java game is feasible? | Highly likely |
| 2 | A full-scaled F/LOSS Java MMORPG is feasible? | Highly likely |
| 3 | A jMonkeyEngine-based full-scaled F/LOSS Java MMORPG is feasible? | Highly likely |
| 4 | A Jakarta EE-backended F/LOSS Java MMORPG is feasible? | Most likely |
| 5 | An XMPP-based F/LOSS Java MMORPG is feasible? | Most likely |
| 6 | A successful F/LOSS Java MMORPG is feasible? | In progress |
| 7 | A successful F/LOSS Java MMORPG developed with only F/LOSS tools is feasible? | In progress |
Summary
DGA aims to prove multiple computational, technological, and gaming concepts at once. Now DGA has reached the Minimum Viable Product’s stage and Version 0.1 is going to be published soon with the appropriate source code and documentation. Therefore, some conclusions to what degree the concepts are proved can be made now.