If you are interested to see what games do we have in our catalogue already then please take a look at our published mobile games: Android Games, Android Applications, BlackBerry Games, BlackBerry Applications, Java Games, Java Applications, WindowsPhone Games, WindowsPhone Applications, Symbian Games, Symbian Applications.
Jan 22, 2015 - In spite of the challenge of creating multiplayer games, they are. All of your coding is going to be in C# — no Objective-C, Swift, or Java here! You may have already heard at least of Java games (more precisely. If you want to run 3D and/or Bluetooth (multiplayer)-based games.
For the content developer a single agreement with ZGroup Mobile gives immediate access to wireless operators and customers all over the world; in Europe, Asia, and the Americas.
Do you have a mobile content that you want to distribute? If yes then you are in the right place.
What mobile content are you interested in?
Everything! Android games, BlackBerry games, Java games, WindowsPhone games, Symbian Games, MMS, logos, ringtones, truetones, polyphonic, greetings, videos. . . etc.Can you tell me more about your Publishing program?
ZGroup Mobile publishing program will allow you to partner with us and allow us to distribute your application for you worldwide. We don't ask for exclusivity. Our distribution points include wireless carriers, mobile operators, mobile professionals, large and important portals and mobile game aggregator. ZGroup Mobile has good contacts with almost all wireless carriers in Asia, Europe, Russia, Arab World, South and North Americas.ZGroup Mobile will help its partners by exposing their products to more customer. Thus help them get to wider market faster. We can also help you to localize your application to many different languages for FREE. So no need to worry about localizing your application to many different language, because we will do that for you!Our Publishing Program will enable you to focus your valuable resources on developing new and innovative applications and unique mobile content. We will handle selling, marketing, and distribution of your application to operators, portals around the world. Your application will get the same level of attention as our own applications.Am I the first on to join the program?
Actually no! For example: As for Mobile games we have signed deals with more thousands developers, and our catalogue include now more than 1.8 million games/apps in all categories. So what are you waiting for? Join us!Where will you be publishing our products?
That depends actually on your application(s)/Content, and whether the applications are already published by other aggregators. We will include your application in our catalogue which is updated monthly to partners worldwide.Can you tell me more about the Process?
You send us an email to [email protected] giving us details about your company and your products and asking to join our publisher program. If you had exclusive deals in specific areas then please include this also in your email. We will then review your products of wireless applications or multimedia content and rate it. Once we approve at least one of your products, we will send you our our Publisher Agreement. You can fill and sign both and email it back to us, and voila! Your application will be soon on worldwide markets!
We require content organized in a certain folder structure that we will give to you. If you have your own standard then we can convert your content to our standard.
The business model is revenue sharing. The shares are negotiable depending on the quality of content.
We provide also localization of your content to multiple languages. The localization will be done by us. You just need to provide us with the original text. We can also use our mLocalization solution where we can localize the game but we need to have your approval in the contract we sign.In Brief what can your Publishing Program provide me/us with?
- 1- We will distribute your applications to all the channels that we have access to. Of course this will depend on the territory that you grant us for distribution. We prefer worldwide non-exclusive.
- 2- Promote your product to partners around the world. This will draw much attention to your specific product, and help you establish your brand.
- 3- Disclose some valuable information about market needs and hot products. This will assist you in developing new products or in improving your previous products.
- 4- Bring new opportunities to you. Maybe your application isn't limited to what you are thinking of! Distribution outside of the Appstore is still generating good income!
- 5- Provides you with technical support for new handsets, and emulators if necessary.
- 6- Localization of your product to different languages. This will be done here in ZGroup Mobile as no charge for you.
- 7- Reduce all of your costs
- 8- Collect all the payment for you, and send them to you in one Cheque.
- 9- Open opportunities of embedding your application or content with OEM (Original equipement manufactorer). Your games/apps or other content will be embedded with the device. This is always a great opportunity to generate income and establish a strong brand.
How do I Join?
If you are interested to join our publishing program please email us: contact(at)zgroup-mobile(dot)com.
By Michael Powers, April 2007 |
The focus of the mobile gaming industry, and the past two articles in this series, centers on the wide-area wireless capabilities of mobile devices. The ability to connect to anywhere in the world is what defines the wireless computing revolution.
But gaming is fundamentally a social phenomenon, and it makes sense that you'd want to challenge players within earshot. The casual, handheld, and immediately accessible nature of the mobile Java gaming platform makes it a natural fit for ad hoc network gaming with the people around you.
Today, many mobile devices now include local-area connectivity capabilities in the form of Bluetooth wireless technology. As you will see, adding Bluetooth support to a Java application is a clear and straightforward process.
To demonstrate the ease of use of Java's Bluetooth APIs, I will modify the mobile multiplayer game from the previous article to play against local devices using Bluetooth. I will also point out important development considerations along the way.
Contents- | What is Bluetooth? |
- | Multiplayer Gaming with Bluetooth |
- | Java APIs for Bluetooth Wireless Technology (JSR-87/JABWT) |
- | Bluetooth Connection Protocols |
- | Refactoring with Bluetooth |
- | Joining an Existing Game |
- | Hosting a Game |
- | Client Communications |
- | Host Communications |
- | Other Connectivity Considerations |
- | Summary |
- | About the Author |
- | Acknowledgements |
- | Resources |
Bluetooth is a technology developed by a consortium of wireless computing and communications companies. As a wireless networking technology, it's much like the popular WiFi network standard, but optimized for ad hoc 'personal-area networks' of small devices.
Because previous generations of handheld devices utilized infrared for wireless connectivity, they struggled with notoriously precarious line-of-sight connections. Bluetooth removes this limitation entirely. Devices merely need to be within general proximity of one another to establish Bluetooth communications. For most devices, the range is limited to 10 meters, but can be boosted up to 100 meters with more power.
The Bluetooth protocol stack includes transparent data encryption and error correction with very rapid frequency hopping to mitigate the effects of local interference. Bluetooth achieves data transfer rates of up to 1 Mbps, with 720 kbps reserved for data and the rest allocated for up to three voice channels. Updates to the standard promise to double these transmission speeds. Because Bluetooth connections concurrently carry voice as well as data, the most popular Bluetooth peripherals sold today are hands-free headsets for use with mobile phones.
Bluetooth's intrinsic characteristics hold many benefits for mobile device manufacturers, and as a result, shipments of Bluetooth-enabled devices increase from year to year. Power management figures greatly into the architecture of all mobile devices, and Bluetooth's design effectively minimizes power consumption. Bluetooth uses only unregulated frequencies so devices can and do interoperate around the world without costly customization for country-specific standards or infrastructure. Not least, as production volumes of Bluetooth modules increase, the cost drops, and more devices now include Bluetooth as a standard feature rather than an optional accessory.
Multiplayer Gaming with Bluetooth
Bluetooth's performance characteristics better suit multiplayer gaming than slower, intermittent wide-area connections over TCP/IP. Most important, message latency is much smaller with Bluetooth, ranging from 40 to 400 milliseconds on average, and degrades in proportion to the size and number of messages transmitted on the network. This exceeds on average the best performance of TCP/IP on the newly deployed 3G wireless networks. Bluetooth connections are also more robust in the face of interference, and dropped connections due to loss of signal are rare.
Bluetooth connectivity is sometimes called 'personal area networking,' and the personal nature of the interaction patterns force a simplified network topography. A Bluetooth network is called a 'piconet' and consists of one or more client devices connected to a single master device. The master device is therefore responsible for all message routing on the piconet.
Each device on a piconet gets a unique identifier based on a three-bit address space, which effectively enforces a maximum number of eight devices on a single piconet. Up to seven client devices can connect to a master device to form a piconet. Some devices may further limit the number of devices on a piconet. Consult the 'bluetooth.connected.devices.max' property of the LocalDevice class to determine the maximum number of devices allowed by a device.
To engender wider collaboration using Bluetooth messaging, a master device in a piconet may join another piconet as a client, thus creating a chain of piconets. This configuration is known as a 'scatternet,' where messages between piconets are routed though these bridging devices. Few Bluetooth hardware stacks support scatternets at the time of this writing, and their effective implementation is beyond the scope of this article. We will therefore limit our exploration to network games with up to eight players.
Applied to games, Bluetooth network topography turns the conventional client-server gaming model on its head. With PC-based local-area network games, one player hosts a game, acting as a server, and broadcasts its availability to other players who then connect to the server as clients. With Bluetooth, only the piconet's master device may initiate connections. Therefore, the clients broadcast their intention to join a game, and the host then searches for those clients.
Each client creates an instance of the game service and waits for a request. The host then scans for devices that have created the desired service and initiates the request to connect. Clients may only ask to be invited into a game; the host must explicitly invite them to join. Once invited, the client accepts or declines the invitation. Once the invitation is accepted, the two devices are connected.
Java APIs for Bluetooth Wireless Technology (JSR-87/JABWT)
JSR-87 defines the Java APIs for Bluetooth Wireless Technology (JABWT). This specification defines the javax.bluetooth package and its classes and capabilities. JABWT is not specifically a mobile API, although many classes depend upon CLDC's Generic Connection Framework (GCF).
Several articles cover JABWT in detail (see Resources below) and the reader is well served to read them. This article focuses on the application of this API toward the implementation of a multiplayer game.
For continuity's sake, I'll summarize here the key concepts that comprise the APIs. The functional areas include discovery, device management, and communications.
- The discovery APIs include facilities for finding local devices and browsing the services on them. Applications also register services for discovery by other devices.
- The device management APIs expose information about local and remote devices, including the classification of each device according to Bluetooth's official taxonomic hierarchy.
- The connection APIs extend the GCF connection classes to expose Bluetooth-specific behavior. The usage pattern is familiar to anyone who has previously written applications that use the GCF for network communications.
The following sections demonstrate all three functional areas of JABWT.
An understanding of the communications protocols supported by JSR-87 helps to determine what kinds of connections best suit an application. JSR-87 requires the L2CAP and RFCOMM protocols, and the OBEX protocol is optional.
L2CAP is the lowest-level protocol of the three, and serves as the foundation for the other protocols. An instance of
L2CCAPConnection
is obtained by passing to the Connector.open()
method URLs that use the 'btl2cap://' protocol.With L2CAP, small, limited-size byte arrays are transferred over the Bluetooth connection with only 4 bytes of overhead and low latency. Developers must factor their applications to partition and reassemble their network messaging to fix into the maximum transmission sizes allowed by the L2CAP connection.
The RFCOMM protocol provides a higher-level streaming interface to a Bluetooth connection, abstracting developers from the complexities of L2CAP. Passing a URL using the '
btspp://
' protocol to Connector.open()
provides an instance of the familiar StreamConnection interface. The latency is only slightly worse than L2CAP, and the overhead is on average 8 bytes for every 128 bytes transmitted.The OBEX protocol facilitates the transfer of large files or other binary data, but is generally unsuited for the purpose of network gaming.
With each of these protocols, latency, bandwidth, and reliability exceed that of the wide-area network in almost every circumstance. RFCOMM is easiest to use, and it's what I'll use for Battlecruiser. It's generally a good choice. If performance is a concern, you may consider refactoring your communications to use L2CAP.
Refactoring with Bluetooth
Retrofitting Bluetooth networking into the Battlecruiser game from the earlier articles in this series illustrates real-world challenges facing Bluetooth games developers. To demonstrate the ease with which Java enables us to move logic from the server to the client, and from wide-area networking to personal-area networks, I'm keeping the code changes to a minimum.
From the outset, Battlecruiser was designed to be an easy-to-pick-up game where the user could automatically connect to other players upon application launch. With Bluetooth, players must first physically gather together and agree on who will host the game before it can begin. After that, each player must launch the game and wait for the invite from the host to join in.
Where the original game connected immediately, the Bluetooth version must first prompt the user to either host a game or wait for invitations from another host. This represents the only major user-visible change in the game.
From a programming standpoint, joining an existing game is a simple matter of advertising the client's availability for the game. Hosts will scan the vicinity for all clients that advertise this specific service.
A service is identified by a universally unique identifier (UUID) that is known in advance to the applications that wish to communicate. The UUID class represents a UUID and can convert a UUID to and from its string representation.
A UUID is basically an arbitrary number, and because they can be very large, just picking one at random gives a very good chance of getting a number no other Bluetooth developer in the galaxy is using.
Applying some simple algorithms to the generation of the UUID, incorporating the current time and the network address of your computer, for instance, practically guarantees that the UUID is truly unique.
The UUIDGEN program on my MacBook does exactly that, and I've determined that Battlecruiser's service UUID shall be 'C25D5973-8B78-48EA-9863-54FCD69FC6A4'.
To advertise its availability, a client must create a service record with this specific service UUID. While this sounds complicated, JABWT's connection APIs hide the details. Just construct a btspp URL to localhost and the UUID, as the following code demonstrates:
The
BluetoothClient
class implements this logic and provides methods to start and stop the listening process.Note that the client device itself must be 'discoverable' to other Bluetooth devices. Otherwise, the published service will be undetectable to those other devices.
When a host connects, the user is presented with an option to accept or deny the invitation. If accepted, the game begins.
Hosting a Game
To start a new game, the host establishes connections to clients advertising the appropriate service record. This process takes three steps.
First, the host must scan for all local devices.
For each device, the host must examine all the services offered to find a matching service.
Then, for each device advertising the desired service, the host establishes a connection.
The
BluetoothHosting
class implements the DiscoveryListener interface and brings all of this logic together. With all the callbacks, it's an intricate but uncomplicated process.Because all of the communication logic was contained in the Synchronizer class, converting the client communications to use Bluetooth requires a rewrite of only that class.
Originally, Synchronizer polled a remote host over http. On a regular time interval, it transmitted all locally generated events and received all events generated by other players since the last transmission.
The polling architecture simplifies a lot of the state management complexities, so I'm keeping that in place for now. The poll interval can shrink due to the lower latencies and greater bandwidth of the Bluetooth network.
The major work to be done, then, is in converting the HTTP request and responses into byte arrays written to and read from the Bluetooth communication streams. The communication protocol for sending and receiving events is largely unchanged.
Because a URL is no longer used to send each request, and because there is no need to differentiate between GET and POST requests, the data format for requests needs a small header that contains the last timestamp and the number of local events to be transmitted.
A more sophisticated approach is to process events as they are read from and written to the connection streams. Moving from a 'pull' to a 'push' architecture eliminates unnecessary network traffic and improves responsiveness. But, it adds significant state logic and management overhead to the server, and I'm trying to keep architectural overhauls to a minimum.
Host Communications
In the previous incarnation of Battlecruiser, the mobile client application connected to an application running on a remote server over HTTP. For the Bluetooth iteration, the mobile application will contain both client and server logic.
The server runs only the on the hosting application. After connecting to all available clients, the host creates an instance of the server, connects each client-including itself-to the server, and the game begins.
Keep in mind that the architecture is still client-server. Thanks to Java portability, from server to client as well as desktop to mobile, we can just relocate the server to co-exist on one of the clients.
SpaceServlet was basically a message queue and the revised version is no more complicated. Analogous to the rewrite of Synchronizer, the new SpaceServer class reads the connection streams for each client, awaiting polls and returning the latest event data.
Bluetooth hardware serializes communications so that the host of a piconet communicates only with one client at a time in a round-robin fashion. For this reason, multithreading communications hold no significant benefits, but neither is there harm. Applications that use RFCOMM StreamConnections will block on reading from the input stream until the connection is next serviced by the host.
Also note that Bluetooth achieves exceptionally low power consumption by quickly placing the hardware into a standby mode as soon as there is a pause in communication. If your game is not constantly using the communications channel, the first message after a pause will have increased latency as the Bluetooth hardware is reactivated.
The threshold for switching to low-power mode, as well as the time needed to switch back, vary from device to device. Therefore, the best strategy for maintaining consistent low latency is to ensure that communications from client to host are frequent but short. The polling architecture used in Battlecruiser serves this purpose well.
Summary
This article exposed the raw potential that Java technology and Bluetooth bring to mobile gaming. You should now have a basic understanding of Bluetooth's capabilities and constraints, its ease of use, and how to put it work in your application.
Michael Powers is Chief Technology Officer of Mpowerplayer Inc., a leading provider of technology solutions to the mobile gaming industry. You can play mobile games from leading publishers right on your desktop with the free Mpowerplayer emulator, available at http://mpowerplayer.com. Michael Powers is Chief Technology Officer of Mpowerplayer Inc., a leading provider of technology solutions to the mobile gaming industry. Mobile games from leading publishers right on your desktop, come with the free Mpowerplayer emulator, available at http://mpowerplayer.com.
Acknowledgements
The author wishes to thank Kevin Lym and Jon Byous for their helpful suggestions and improvements to this article.
false ,