ZingMobile

1. 2011
Developing OWE Application
1/20/2011

2. Table of Contents
Server Configuration .................................................................................................................... 4
Widgets and commands ................................................................................................................ 5
Core Language .............................................................................................................................. 7
Comments ..................................................................................................................... 7
Variables ....................................................................................................................... 7
Operators ...................................................................................................................... 8
Conditionals .................................................................................................................. 8
Looping ......................................................................................................................... 9
Functions ...................................................................................................................... 9
Arrays............................................................................................................................ 10
Objects .......................................................................................................................... 10
Standard Library............................................................................................................................ 12
Cross script invocation................................................................................................... 12
Built in Globals and Variables ........................................................................................ 13
IO (Input/Output) .......................................................................................................... 15
Standard Objects ........................................................................................................... 17
Session Control.............................................................................................................. 18
Collections..................................................................................................................... 18
Persistence .................................................................................................................... 18
General ......................................................................................................................... 19
Tutorial Developing OWE application ............................................................................................ 20
OWE Script .................................................................................................................... 20
2

3. OWE IDE ........................................................................................................................ 20
OWE Development Outline............................................................................................ 20
OWE CLIENT_MAIN ....................................................................................................... 20
OWE SERVER_CONTROLER ............................................................................................ 20
OWE GAME_SCRIPT....................................................................................................... 20
Tutorial: Kitty Guess ...................................................................................................................... 23
Game flow ..................................................................................................................... 23
The Controller script ...................................................................................................... 26
The Game script ............................................................................................................ 26
Utility functions ............................................................................................................. 27
startGame ..................................................................................................................... 27
Tutorial: Structure of your Client ................................................................................................... 30
Login ............................................................................................................................. 31
Signing Up ..................................................................................................................... 31
Home Screen ................................................................................................................. 32
Marketplace .................................................................................................................. 32
Profile Screen ................................................................................................................ 32
Contact List ................................................................................................................... 33
Instant Messaging ......................................................................................................... 33
Tutorial: Starting with DevStudio................................................................................................... 34
Create Build................................................................................................................... 35
Create Widget ............................................................................................................... 37
Create Script.................................................................................................................. 40
Support Information ...................................................................................................... 40
3

4. Server Scripting
Open Worlds scripting is built upon on OWScript1, an extremely simple scripting
language. OWScript provides the developer with the basic programming constructs like
variables, operators, conditionals, loops and functions to script the necessary application
flow.
The Open Worlds platform comes with a set of standard library functions which
objectively supplements OWScript with common functional features used by
applications running on the platform such as I/O, session control, persistence, etc.
An Open Worlds server side script is known as a Widget, and a widget is logically
partitioned into:
 Controller Script
Handles command processing and routes incoming request to a specific game
session. This is "stateless".
 Game Script
Handles logic for a game session; instance per game session is created by Open
worlds platform for every running game. This is “stateful”.
The following diagram shows the logical server side scripting stack; the Open Worlds
platform runs and manages independent widgets for different content providers.
Figure 1 Server scripting stack
1
http://OWScript.sourceforge.net/
4

5. Widgets and commands
The Platform handles all transport level IO between the client and server and mandates
a primitive stateless request-response RPC code model to allow the developer to work at
the highest level of abstraction possible for the nature of applications that the Platform
is designed to support.
The client will send commands and parameters into the server widget; the server
widget's controller will receive the command and route it to the game script instance.
Game Script
Invoke script function
Client Script Controller Script
COMMAND #nn,payload
COMMAND #nn, payload
OWE Client Server Scripting
Engine Engine
HTTP
Figure 2 Command request pipeline
5

6. The client scripts uses the high level client API to send a command number followed by a
sequence of parameters to its server widget. The OWE client engine handles the
transport and delivery to the server as a HTTP stream. The server receives and translate
the HTTP stream back into the original command number along with the parameters,
and pass it into the server widget. The widget's controller script perform the necessary
application logics and invokes the necessary function contained in the game script.
RESPONSE
Figure 3 Command response pipeline
The game script performs the necessary logic and writes a sequence of response back to
the client, completing the request-response flow.
6

7. Core Language
Comments
Only line based comments are supported. A comment is indicated by a leading '#'
character.
# this is a comment
Variables
Three variable types are supported:
 int
 string
 double
Variables must be declared before use, the synax is:-
int|string|double
<varname>[=<expression>][,<varname>*]
int counter,b,n
string name,address
double value
Variables may also be assigned a value during declaration
int counter=0,b,c
string link,path="/home/"+username+"/mydir",tmpstring
Variable names must start with A-Z or a-z, but numbers, "." and "_" can also used in
variable names.
int valid9_variable.name1
7

8. Operators
The usual selection of math and logic operators are supported:
+ - * / % == != >= <= <>&& || ! ( )
The mathematical operators (+ - * / %) are valid for all numeric types. The
operator + is also valid for string operands (which concatenates the strings).
The equality & inequality operators ( == !=) are valid for all types. These operators
yield an integer 1 or 0 as a result. All logical operators use the 'C' convention of false
being zero and true being any non-zero value.
The comparison operators ( ><>= <=) can be used to compare any type, again as
long as both operands are the same type. The result is (again) a 1 or 0 integer.
The boolean logic operators ( && || ) work only with integer operands.
int a=1, b=2
int sum
double average
# add then divide
sum = a + b
average = sum/2
Conditionals
The sole construct for conditional execution is the 'if' statement.
There are two forms of 'if' statements, multi line and single line. Multi-line If statements
may optionally contain 'elsif' and 'else'clauses. The 'then' keyword is optional for the
multi-line form of 'if' The syntax is :
if <expression> [then]
<statements>
[else
<statements>]
[elsif <expression>
<statements>]
endif
if a>300
a=a-145
b=b+3
8

9. elsif a > 500
a=a-245
b=b+4
else
a=a+10
endif
The single line form of 'if' is used if only one statement needs to be executed by the
'if'. There is no provision for 'else' or 'elsif' and the 'then' keyword is not
optional. For example:
if a>300 then a=0
Note that both elsif and elseif are valid for use in if statements.
Looping
The only loop construct supported by OWScript is while. The syntax is :
while <expression>
<statements>
endwhile
For example:
while count<500
count=count+1
value=value+calcvalue(count)
endwhile
Functions
OWScript supports the declaration of functions that may return a parameter, and accept
a pre-defined set of parameters. Functions may be recursive. It is not legal to nest
functions in code (i.e. declare functions within functions). Local variables may be
declared within the function scope. Within a function global scope variables are
available, and in the event of a naming conflict between the global and local scope, the
local scope wins. The 'return' keyword can be used to return a value to the calling code.
The syntax of a function declaration is:
func <function name>([[<param type><param name>][,]]*)
9

10. <statements>
endfunc
For example:
func test(int a,string b,double c)
int count
while count<10
count=count+1
endwhile
return count
endfunc
Arrays
OWScript does not directly support arrays, however it does support array like access to
variables that are defined in extensions/subclasses of OWScript The syntax is the same
as that found in Java (and C). e.g.
<varname>[<subscript>]
However in OWScript the subscript can be any supported variable type (string,int or
even double). For example:-
thisvar[n]=thatvar[2]
MyFunction(thisvar[n+1])
In the above example the variables thisvar and thatvar are supplied by the application
embedding OWScript
Objects
The object type is a special type used in OWScript to contain objects. There are a few
rules governing it's use.
An uninitialized variable may be set to any object (either external or one of OWScripts
own types). e.g:
object obj1,obj2
obj1=create("java.util.HashMap") # assume this creates a HashMap object
obj2="This is a string"
# methods are invoked via reflection beneath the hood
10

11. map.put("a","Apple")
map.put("b","Bear")
map.put("c","Car")
map.put("d","Demolition")
There are some limitations however. Only one level of indirection (dots) are allowed e.g.
object sys
sys=getClass("java.lang.System") # assume this creates System object
sys.out.println("Hello") # ERROR!
11

12. Standard Library
The standard library is a set of built-in functions provided along side the FSscript
scripting core for developer use. The library supplements the basic programming
constructs available in OWScript by pulling down commonly used application features
into the platform API level and exposing them to the developer who works at the
application scripting level via direct function calls.
Cross script invocation
 CALL(string functionName, ...parameters)
Cross script invocation allows a stateless controller script to delegate control to a
stateful game script. Depending on the nature and complexity of the application, a game
script may or may not be required. Consider the following examples:-
Echo Server - controller only
# Controller script
func main()
if CMD_ID == 1
LOG("Incoming request from " + SESSION_ID)
string msg = READ_UTF ()
WRITE_UTF("You sent: " + msg)
endif
endfunc
12

13. Game session initialization
# Controller script
func main()
if CMD_ID == 1
LOG(SESSION_ID + " called start game")
START_GAME(players) # client now bound to a game script session
instance
CALL("startGame", SESSION_ID)
endif
endfunc
# Game script
object players = NEW_SET() # stateful global variable
int CAN_START = 1
int WAIT = 0
func startGame(string session)
players.add(session)
if players.size() >= 2
LOG("Game can start now for " + session)
WRITE_BYTE(1)
else
LOG("Need to wait for an opponent")
WRITE_BYTE(0)
endif
endfunc
Built in Globals and Variables
 int SCRIPT_ID
This constant holds the widget integer ID of the currently executing script. The
application script does not usually need to use this.
 int CMD_ID
This constant holds the incoming integer ID of the command the client is calling.
The application script usually write conditionals around this variable at the
stateless controller script to route clients into their respective stateful sessions.
E.g.
13

14. # Controller script
func main()
if CMD_ID == 1
# initiate game session
elsif CMD_ID == 2
# make a move
elsif CMD_ID == 3
# check result
endif
endfunc
 string SESSION_ID
This constant holds the session ID of the incoming client. This is usually used
(added to a set) to keep track of how many/which clients are currently
participating in a game script session.
 int PLAYER_TIMEOUT
This variable setting controls the maximum duration, in milliseconds, a client can
go idle (without sending any commands to the game session) before he is
considered to have timed-out. Once a player has timed-out, the state of the
game will be flagged as PLAYER_TIMEDOUT.
 string GAME_STATE
This variable holds the current status of the game session, possible values are
o “ON_GOING”
This indicates a game session is going on normally. This state is usually
set by the Platform background game monitor.
o “PLAYER_TIMEDOUT”
This indicates one or more players in the game session has not
contacted the server for the set duration of time. This game session will
be swept and removed from the server by the background game
monitor after another set duration of time. This state is usually set by
the Platform background game monitor.
o “ENDED”
This indicates that the game session has completed normally, and the
background game monitor should remove this game session from the
server. This state is usually set by the application script.
14

15. IO (Input/Output)
The IO library abstracts the communication between the client and the server to a series
of Reads and Writes involving just numbers (Java int primitives) and text (Java String
objects). Beneath the hood, variable bit length representations are used for the data
types transfer, ensuring optimal bandwidth utilization.
 String READ_UTF()
Read and return a variable length text Java String from the incoming data
stream.
 int READ_UNSIGNEDSHORT()
Read and return a Java primitive int from the incoming data stream. The client is
expected to have sent an integer value between 0 through 65,535.
 int READ_INT()
Read and return a Java primitive int from the incoming data stream. The client is
expected to have sent an integer value between -2,147,483,648 through
2,147,483,647.
 int READ_BYTE()
Read and return a Java primitive int from the incoming data stream. The client is
expected to have sent an integer value between-128 through 127.
 boolean READ_BOOLEAN()
Read and return a Java primitive boolean true/false value from the incoming
data stream.
15

16.  void WRITE_UTF(string s)
Write a variable length text Java String into the outgoing data stream destined
for the client.
 void WRITE_UNSIGNEDSHORT(int value)
Write a integer value between 0 through 65,535 into the outgoing data stream
destined for the client.
 void WRITE_INT(int value)
Write a integer value between -2,147,483,648 through 2,147,483,647 into the
outgoing data stream destined for the client.
 void WRITE_BYTE(int value)
Write a integer value between -128 through 127 into the outgoing data stream
destined for the client.
 void WRITE_BOOLEAN(boolean value)
Write a boolean true/false value into the outgoing data stream destined for the
client.
16

17. Standard Objects
While OWScript does not support object oriented programming constructs, it supports
Java object access (through reflection). The Standard Library provides feature rich
standard objects which encapsulate generic functions and logic for utilization within the
scripting layer to achieve functionalities that may not be possible using OWScript
programming primitives alone.
 Game
The Game object is the heart of session management in the platform; the
following information are tracked in this stateful object:
o Game information
Number of players required to start this game
o Player information
Player sessions that are currently associated with this game
o Widget information
The Widget that this game belongs to.
o Scripts
The scripts and their runtime and states that makes up this game.
o Game state
The current state of the game, whether it is ongoing, timed out or
ended gracefully.
The Game object exposes these methods:
o int getGameId()
Returns the unique game session Id, for use in private game room logics.
The application scripts usually do not need to explicitly work with this object as
the session control library functions will implicitly construct and manipulate the
Game object.
 Store
The Store object is a persistence provision for the application scripts. This is a
simple key-value store available for each user per widget application. Data
inserted into the store will persist across sessions. Information such as character
profiles, scores can be saved here.
Widget 1 Widget 2 Widget 3
Store Store Store
User
The Store object exposes these methods:
17

18. o void PUT_UTF(String key, String value)
Associates the specified String value with the specified key in this store.
If this store already contains a mapping for this key, the old String value
is overwritten.
o void PUT_INT(String key, int value)
Associates the specified int value with the specified key in this store. If
this store already contains a mapping for this key, the old int value is
overwritten.
o String GET_UTF(String key)
Returns the String value to which the specified key is mapped, or an
empty String (“”) if this store contains no mapping for the key.
o int GET_INT(String key)
Returns the int value to which the specified key is mapped, or the value
0 if this store contains no mapping for the key.
o void SAVE()
Persists the current state of this store to disk.
Session Control
 Game START_GAME(int players)
Creates, associate the current user and return a public game session requiring a
minimum of players players. This game will be used for public matchmaking.
 Game CREATE_NEW_PRIVATE_GAME(int players)
Creates, associate the current user and return a private game session requiring a
minimum of players players. This game will not be used for public matchmaking.
 Game JOIN_PRIVATE_GAME(int gameId)
Associate the current user with the specific parameter gameId.
 Game FIND_GAME_BY_ID(int roomID)
Collections
 java.util.HashMap NEW_MAP()
Returns a new Java HashMap object for scripting use.
 java.util.HashSet NEW_SET()
Returns a new Java HashSet object for scripting use.
 java.util.ArrayList NEW_LIST()
Returns a new Java ArrayList object for scripting use.
18

19. Persistence
 Store GET_STORE(string sessionId)
Returns the user specific store for the user associated with the parameter
sessionId, for the current executing widget.
General
 void LOG(string msg)
Generates a widget logging message into the Platform widget logs. This log may
be viewed in the widget logging console in the Platform Dev Studio.
 int RANDOM_INT(int max)
Returns a random number between 0 and max – 1 inclusive.
19

20. Developing OWE application
OWE Script
OWE script development use fscript( embedded in java). The functions on OWE script
are defined in java which extends FScript class and called on fscript file. All functions will
be defined on overrided method callFunction().
For example, we can call QUIT() function on fscript
OWE IDE
In order to develop application, we absolutely need IDE. This is also applied to OWE,
OWE has web based IDE. We can open the IDE in the openworlds site.
OWE Development Outline
1. Open OWE IDE http://www.open-worlds.com/ow
2. Create widget.
We will be asked to upload apps thumbnail, choose pngpicture which its size is
small enough (xx KB).
3. Create script(client fscript, controller server side fscript, game server side
fscript).
For first trial, we can just create client fscript without connecting to server.
4. Upload image.
Uploaded image will be accessed from client fscript.
OWE client fscriptprogramming(CLIENT_MAIN)
Function should be implemented : init(), update().
OWE server fscriptprogramming(SERVER_CONTROLER, GAME_SCRIPT)
In controller, we should implement main().
20

21. Connecting client to server.
We can make a connection from client to controller using this code.
from the controller we can send response straight to client using WRITE_BYTE()
or we can call function on game script.
before make a call to game script function, we should make game object by calling
START_GAME(), this is required. And from the server game script we will send response
to client.
21

22. Getting Response from server
The server will send a response using WRITE_BYTE(), this method can be called on both
controller or game script. On client side this response will be catched using
READ_BYTE().
Put it all together
22

23. Tutorial: Kitty Guess
We will walk through the Open Worlds sample application Kitty Guess to achieve the
following objectives:
 Understand the RPC based command model of client-server interaction
 Understand the Controller and Game scripting contexts
 Exercise all of OWScript’s programming constructs
 Utilize the Platform’s session management functionalities
 Utilize Open Worlds’ Standard Library to realize game functionalities
Game flow
Kitty Guess is a game of scissors paper stone involving 2 players consisting of 3 rounds.
At the start of each round, each player will submit his choice of move to the Server. The
server waits for input from both players, compares the moves and sends the results back
to the players and ends the round. Players then progress to the next round. The player
who wins 2 or more rounds wins the game.
The game play can be expressed as a series of commands and response exchanges
between the client and the server:
1. Start Game
2. Start Round
3. Make Choice
4. Check Result
5. Go to step 2 again until game completes
The requirements of our design are as such:
1. The client should be as simplistic as possible, executing the commands in
sequence functionally, i.e. make a request call into the server and act on the
server’s response code
2. The clients will not communicate with each other, i.e. there is no peer handling
logic.
3. Thus, the server will collect keep states for the clients by
4. Receiving and tracking commands and parameters from the client, process the
input and
5. Direct the clients’ progress by returning differentiated response codes
Based on the above, we describe the client-server exchange as a sequence of commands
as such:
Client Client Client Server State Server
Action Command Command Response code
Code Parameters
23

24. Start Game 1 - Wait for another Player 0
Two players available, proceed to start 1
round
Start Round 2 - Wait for opponent to sync 0
Opponent synced, proceed to make choice 1
No more rounds to play, game ended 2
Make Choice 3 1 = Scissors Choice received, proceed to check back for 1
2 = Paper result
3 = Stone
Check Result 4 - Wait for opponent to sync 0
You won the round 1
You lost the round 2
It’s a draw 3
When waiting for opponent to sync, the client must repeat the requested command,
until it gets a different response code from the server.
24

25. The Controller script
The Controller script serves to direct the client request into the Game script by
translating the raw incoming numerical command code into the servicing function inside
the stateful game script.
int players = 2
func main()
if CMD_ID == 1
LOG(SESSION_ID + " called start game")
object game = START_GAME(players)
CALL("startGame", SESSION_ID)
endif
if CMD_ID == 2
LOG(SESSION_ID +" called start round")
CALL("startRound", SESSION_ID)
endif
if CMD_ID == 3
int choice = READ_BYTE()
LOG(SESSION_ID + " called makeChoice = " + choice)
CALL("makeChoice", SESSION_ID, choice)
endif
if CMD_ID == 4
LOG(SESSION_ID + " called checkResult")
int result = CALL("checkResult", SESSION_ID)
endif
endfunc
25

26. The Game script
The game script will have the following segments
 Constants
 Game state variables
 Handler functions for each possible client command
o startGame
o startRound
o makeChoice
o checkResult
Constants and game state variables are declared and initialized at the beginning of the
game script.
object playerStates = NEW_MAP()
object choices = NEW_MAP()
object players = NEW_SET()
int currentRound = 0
int maxRounds = 3
int roundReady = 0
int roundStarted = 0
int SCISSORS = 1
int PAPER = 2
int STONE = 3
int WIN = 1
int LOSE = 2
int DRAW = 3
int STARTED_GAME = 0
int STARTED_ROUND = 1
int MADE_CHOICE = 2
int WAITED_RESULT = 3
int PLAYER_ENDED = 4
The object playerStates = NEW_MAP() map is used to keep track of the individual
client states. Together with the int roundReady and int roundStarted flags, they are
used to form conditional Boolean barriers to keep the clients in sync.
The object players = NEW_SET() set keeps track of the current session Ids of the
players in this game.
26

27. Utility functions
func getOpponents(string session)
object opponents = NEW_SET()
opponents.addAll(players)
opponents.remove(session)
return opponents.iterator()
endfunc
func getOpponentState(string session)
object opponents = getOpponents(session)
return playerStates.get(opponents.next())
endfunc
func getOpponent(string session)
object opponents = getOpponents(session)
return opponents.next()
endfunc
These functions act on the global players and playerStates objects to return the
client’s opponent’s state and sessionId.
startGame
func startGame(string session)
players.add(session)
playerStates.put(session, STARTED_GAME)
if players.size() >= 2
LOG("game can start now for " + session)
WRITE_BYTE(1)
else
WRITE_BYTE(0)
endif
endfunc
The server script immediately marks the requesting client to be in the STARTED_GAME
state. This state capturing idiom is applied throughout the rest of the command
functions.
27

28. startRound
func startRound(string session)
int ret = 1
LOG(session + "'s currentRound=" + currentRound)
playerStates.put(session, STARTED_ROUND)
int opponentState = getOpponentState (session)
if opponentState != STARTED_ROUND && roundStarted == 0
ret = 0
elsif roundStarted == 0
roundStarted = 1
roundReady = 0
currentRound = currentRound + 1
LOG("progressing round! currentRound=" + currentRound)
endif
if currentRound > maxRounds
ret = 2
playerStates.put(session, PLAYER_ENDED)
if opponentState == PLAYER_ENDED
GAME_STATE = "ENDED"
endif
endif
WRITE_BYTE(ret)
endfunc
We observe the first use of the conditional state barrier to keep ensure client synchrony
in the first if block; this ensures that clients will progress through the logical command
sequence in tandem with each other.
makeChoice
func makeChoice(string session, int choice)
playerStates.put(session, MADE_CHOICE)
choices.put(session, choice)
WRITE_BYTE(1)
endfunc
This function serves only to capture the state and choice of the client. The client should
immediately proceed to the next command in the sequence.
28

29. checkResult
func checkResult(string session)
int ret = 0
playerStates.put(session, WAITED_RESULT)
int opponentState = playerStates.get(getOpponent(session))
if opponentState != WAITED_RESULT && roundReady == 0
LOG(session + " blocked by checkResult barrier")
WRITE_BYTE(0)
return 0
else
roundReady = 1
roundStarted = 0
endif
int myChoice = choices.get(session)
int opponentChoice = choices.get(getOpponent(session))
LOG("Evaluating game result for " + session)
if myChoice == SCISSORS
if opponentChoice == SCISSORS
ret = DRAW
elsif opponentChoice == PAPER
ret = WIN
elsif opponentChoice == STONE
ret = LOSE
endif
elsif myChoice == PAPER
if opponentChoice == SCISSORS
ret = LOSE
elsif opponentChoice == PAPER
ret = DRAW
elsif opponentChoice == STONE
ret = WIN
endif
elsif myChoice == STONE
if opponentChoice == SCISSORS
ret = WIN
elsif opponentChoice == PAPER
ret = LOSE
elsif opponentChoice == STONE
ret = DRAW
endif
endif
WRITE_BYTE(ret)
endfunc
This function places a conditional barrier to ensure both clients has received the round
result before allowing the game state to progress to the next round.
These 4 main command functions which we just covered combine to complete the basic
flow of the Kitty Guess game.
For a full version of the script involving persistence profile and score tracking, please
refer to the example source codes.
29

30. Tutorial: Structure of your Client
The client follows a specific flow to its basic functions. This is to ensure consistency and
reliability across the user interface.
It is mandatory that the 7 indicated sections are included in each build that the
developer creates. While the basic build is only restricted to 7 sections for the developer
to make use of, advanced users with access to the source code will be able to make
modifications by removing and adding sections to the commong Open Worlds Engine
build.
Profile Open Worlds Market
Platform
Login Messaging
Signup Contacts
Home
30

31. Login
1) The client is given 2 options when the initial login screen is initialized. This is
either to enter his current credentials or sign up for a new account.
2) 2 buttons, “Login” and “Sign Up” will only be displayed.
3) User will enter his username and password using the alphabets on his numeric
keypad.
4) Upon clicking the “Login” button, he will see the main home screen.
Signing Up
1) User will enter the new username and password using the alphabets on his
numeric keypad. At this stage of the sign-up process, minimal information is
required from the user as he will only update the rest of his particulars on the
other screen of the application.
2) Upon clicking the “Sign Up” button; the user will be redirected to the Login
screen.
3) The fields in Login screen should be automatically field once the user signs up
for the first time. This is to facilitate convenience.
31

32. Home Screen
1) The home screen displays a list of games that have been downloaded or already
pre-loaded with the client.
2) It should be recommended that the games are listed in alphabetical order to
minimize confusion when the user wishes to play a game.
Marketplace
1) The marketplace should display a list of main categories first, followed by the
sub-categories that link to each application or game.
2) Clicking on an application or game will link the user to a download information
page.
3) The download information page should contain these details:
a. Application / Game Description
b. No. Of Players supported
c. Price
d. “Download Now” button (this will appear by default)
Profile Screen
1) The profile screen contains the other details which pertain to the user’s
particulars.
2) The basic information needed for this profile screen should be included in all
client builds:
a. First Name
b. Last Name
c. Gender
d. Age
e. Country
f. Phone Number
32

33. 3) Additional details can be required by the client builder, as long the mandatory
fields are implemented.
Contact List
1) The contact list should contain the user’s contacts in alphabetical order.
2) Contacts are added through the Menu button at the bottom of the screen.
3) Contacts are added with their Username that is registered in the database, and
a Nick Name can be used to recognize them.
Instant Messaging
1) The screen should show a list of current contacts in alphabetical order.
2) 2 options are shown at the bottom of the menu, “New Message” and “Get
Message”.
33

34. Tutorial: Starting with DevStudio
DevStudio will be the point of entry for any developer that wishes to create a custom
Open World Engine client and the applications and games to be packaged with it.
Each developer will have access to the DevStudio per user account. Special requests can
be made to have multiple accounts per developer, but these are only given on a case-by-
case basis.
The development cycle for a first-time developer with the Open Worlds Engine is as
follows if a custom build were to be created, then by creation of applications and games.
In this flow, “Widget” refers to the Application or Game.
Create OWE
Build
Create
Widget
Create Script
for Widget
34

35. Create Build
A custom Open Worlds Engine is first created by accessing the “Create Build”. This
section provides the developer with a variety of cosmetic options to decorate his OWE
build with.
Title: Enter the name of the client that you wish to create. The character limit is 50
characters.
Extending over: Should you not wish to build a client from scratch, extend its style from
the list of templates that are available.
Title: Enter the name of the client that you wish to create. The character limit is 50
characters.
ICONS FOR MENU
In Foreground: These refer to the icons that you wish to upload that will show up on the
menu tabs. A strict adherence to a size of 30x25 is required to ensure optimal layout.
In Background: These refer to the background images that will be used for each screen.
Due to the nature of the LWUIT layout engine used, that background images will scale
automatically based on the resolution of the phone.
Available sections that are customized:
1) Home
2) Profile
3) Marketplace
4) Widgets
5) Instant Messaging
6) Contact List
TEXT/IMAGE FOR MENU
Use Text or Images: You can be given the option of using plain text or images for your
menu headers. Menu images should maintain a strict resolution of 50x25.
35

36. Text for Menu Items: These refer to the icons that you wish to upload that will show up
on the menu tabs. A strict adherence to a size of 30x25 is required to ensure optimal
layout.
Font Styling for Menu Items: Fonts that are used for the menu headers, should text be
used, can be given in bold, italic or underline styles.
Available sections that are customized:
1) Home
2) Profile
3) Marketplace
4) Widgets
5) Instant Messaging
6) Contact List
Upon submission, the build will be saved and recorded into the database as one of the
builds in the developer directory.
36

37. Create Widget
Once the Open World Engine build is created and instantiated, the process of building
widgets for the build can commence.
Each widget will be built and attached to the type of build that the developer has
created. Should the developer have 5 OWE builds, he will have to select which build the
widget should be created for.
Title: Enter the name of the widget that you wish to create. The character limit is 50
characters.
Major Version: Specify the major build number of the widget this is for.
Minor Version: Specify the minor build number of the widget this is for. This is useful for
designating incremental changes to the widget as updates and patches are uploaded.
Use generic platform: Check this if you’re prototyping the widget and want to test this
on a generic Open Worlds Engine builds. Useful for development purposes.
Use customized build: Should you have a list of customized builds that you have created,
select the specific build that this widget will be attached to.
Upon submission, the widget will be saved and recorded into the database as one of the
widgets in its respective build link.
37

38. 38

39. Create Script
A widget does not do anything without code written for it. In this section, the developer
writes the script that will
Select Widget: Select from a list of widget that you have created so far from the “Create
Widget” section.
Resource ID: Specify which ID this widget will conform to. This is useful to developers to
keep track of each Widget they have designed.
Code: Implement the code that is required for the widget to function. Do note that image
links and variables should still be specified within this area.
Upon submission, the widget will be saved and recorded into the database as one of the
widgets in its respective build link.
39

40. Support Information
Zingmobile Pte Ltd
Address: 229, Mountbatten Road, #02-03, Singapore 398007
Support Email: support@open-worlds.com
Bugs and Feedback on our product can be directed to feedback@open-worlds.com
40

41. 41