讲解Game play、辅导SQL设计、讲解SQL编程语言、讲解program留学生 解析Java程序|调试C/C++编程
- 首页 >> Web Game play
The game play will be mostly identical to that of
Project 1 with this difference: Rather than handing a
device to a second person when playing, your
program will send the current state to a second
device for that player's move. The game goes from
a game played on a single device to a game played
on two devices. You are only required to support two
devices, though you can support more if you want to
(in pairs).
User Management
In order for this to work, each user must log into a
remote server to play the game. Hence, the server
must have a way to manage user ids and passwords.
Your system must also support the ability for a user
to create a new account on the server.
The following scenario is a suggestion. You are
welcome to come up with an alternative approach if
you like, but you must get your alternative approach
approved by a member of the course staff.
Here is a basic scenario for a player who has a valid
login in the system: When the game starts it should
present an opening activity with a box where the
player can enter a user id and password. There is a
button that logs the player into the server using that
id and password. If the player does not exist or the
password is incorrect, the login should be rejected.
Otherwise, it should move the player to either a
screen where they wait for a second player if they
are the first player or to a game play screen if
another player is available.
The opening page must also have a button that you
can click to create a new user. That should open a
new activity where the user can enter an id and the
password twice (for verification purposes). Then a
button should allow the player to create the new
account. They should then be returned to the
opening screen to log in.
The opening page must have a checkbox labeled
"Remember". If checked, the user id and password
must be saved in the preferences on the device. You are not required to encrypt the password, though
feel free to do so if you like. This avoids entering the
id and password every time you start the program.
You are not required to provide a way to change
passwords, delete a user, or verify the user when
creating a new user (most systems will send out an
email message with a link you must click to
acknowledge you are the user).
There must be a way to exit the game both actively
and passively. Actively exiting the game can be done
with the surrender option. Passively exiting the
game should occur if the player does not
communicate with the server within some period of
time. This is how the server will recognize a lost
connection.
Your program must be able to handle a temporary
loss of a connection with the server.
Game Play
Right now you have a game play activity. You will
need some new activities. You will need an activity
that waits for a second player as described above.
Network Communications and Server State
Polling: Each device has to update the game state in
the database when its turn is over. The other device
has to keep checking the server to find out when it
is its turn. When the device gets a turn, it should
contact the server to get the current game state
before it lets the user to play the turn. Keep in mind
that if you send many requests in short period of
time, the server kicks you out. I recommend
checking the turn only once every second.
You will have to maintain all game state in an SQL
database on the server. PHP scripts will make
changes to the database to indicate the current state
of the game.
You must use XML to send data between the server
and the client. You may send data from the client to
the server either in XML packets or using key/value
pairs on GET or POST queries.You can use Firebase in project 2. Don't try to send
game state in the message, only an indication that a
turn has occurred. When the receiving device gets
the message, it should contact the server to get the
current game state.
Specific team requirements
Team members will be personally responsible for one
or more elements of the program. The three
elements that the team members will be responsible
for are:
1. The sequencing of the activities
2. Client-side communications
3. Server-side communications
As before, these components are related to each
other. Those responsible for communications need
to decide early on what protocols to use. Though
individuals are responsible for their parts, the parts
must work together. This is a team project, not three
or four individual projects.
The team as a whole is responsible for ensuring the
components work together.
Grading
50% of the grade is for the individual components
and 50% is for the team. Any deductions specific to
an individual component will be against the
individual grade. For example, warnings in Serverside
communications will deduct from that
participant's individual grade. Problems in other
components will deduct from the team grade.
Deductions will include, but are not limited to:
Functionality problems
Violations of the technical requirements
Redundant code
Crashes and bugs
Of the total grade, 25% is allocated to the
checkpoint submission.Submission - Checkpoint
The checkpoint submission is required to include
these items:
The opening activity and the new user activity
The ability to create a user
The ability for the user to log into the system
All that is required is that the system be able to
create a user and the user be able to log onto the
system. Once the user is logged in, move to some
dummy activity. The error indications for failure to
log in must be provided.
When you are done with the checkpoint submission,
go to the submission page for details on submitting
your project.
There will be an automatic 10 point penalty for failing
to include a completed project2submit.txt or
improperly naming your
submission. project2submit.txt must be turned
in with both the checkpoint and final
submission!
Submission - Final
Be sure the file project2submit.txt is finalized prior
to final submission and is included in the submission.
Note that your solution will be tested with your
server-side implementation, so do not make
changes to the PHP after the due date.
Suggestions
Use https for all communications, not http. This only
changes the URL in your program.
You can use PHP sessions to keep track of the
logged-in state (see the lecture notes) or you can
create your own session id mechanism. Do not use
uniqid() as a session ID, though. You can use
openssl_random_pseudo_bytes() if you like. PHP
sessions are probably the easiest solution, though.
But you do have to support Cookies to use them.Polling and such requires a thread, of course. Be sure
you can abort the thread. Use Thread.sleep() to
delay within a thread. Thread.sleep() can be
interrupted to end the thread early using
Thread.interrupt().
Decide early what the protocols will be between the
client and the server. Then the person working on
the client communications can send packets to the
server as they are created and create dummy scripts
to respond. The person working on the server can
use a web browser to fake a client in many cases to
get their code up and running. But, be sure to try to
put things together as soon as possible.
When writing PHP scripts, consider using a web
browser to fake the client before the client is done.
See the page Faking a Client using a Web Browserfor
details.
Use phpMyAdmin to examine the contents of the
database to see what is working at any given time.
If I have an XML document, I can save it in a
database by creating appropriate fields for the data.
Or, I can just put the entire XML document into a
TEXT field of one record.
The game play will be mostly identical to that of
Project 1 with this difference: Rather than handing a
device to a second person when playing, your
program will send the current state to a second
device for that player's move. The game goes from
a game played on a single device to a game played
on two devices. You are only required to support two
devices, though you can support more if you want to
(in pairs).
User Management
In order for this to work, each user must log into a
remote server to play the game. Hence, the server
must have a way to manage user ids and passwords.
Your system must also support the ability for a user
to create a new account on the server.
The following scenario is a suggestion. You are
welcome to come up with an alternative approach if
you like, but you must get your alternative approach
approved by a member of the course staff.
Here is a basic scenario for a player who has a valid
login in the system: When the game starts it should
present an opening activity with a box where the
player can enter a user id and password. There is a
button that logs the player into the server using that
id and password. If the player does not exist or the
password is incorrect, the login should be rejected.
Otherwise, it should move the player to either a
screen where they wait for a second player if they
are the first player or to a game play screen if
another player is available.
The opening page must also have a button that you
can click to create a new user. That should open a
new activity where the user can enter an id and the
password twice (for verification purposes). Then a
button should allow the player to create the new
account. They should then be returned to the
opening screen to log in.
The opening page must have a checkbox labeled
"Remember". If checked, the user id and password
must be saved in the preferences on the device. You are not required to encrypt the password, though
feel free to do so if you like. This avoids entering the
id and password every time you start the program.
You are not required to provide a way to change
passwords, delete a user, or verify the user when
creating a new user (most systems will send out an
email message with a link you must click to
acknowledge you are the user).
There must be a way to exit the game both actively
and passively. Actively exiting the game can be done
with the surrender option. Passively exiting the
game should occur if the player does not
communicate with the server within some period of
time. This is how the server will recognize a lost
connection.
Your program must be able to handle a temporary
loss of a connection with the server.
Game Play
Right now you have a game play activity. You will
need some new activities. You will need an activity
that waits for a second player as described above.
Network Communications and Server State
Polling: Each device has to update the game state in
the database when its turn is over. The other device
has to keep checking the server to find out when it
is its turn. When the device gets a turn, it should
contact the server to get the current game state
before it lets the user to play the turn. Keep in mind
that if you send many requests in short period of
time, the server kicks you out. I recommend
checking the turn only once every second.
You will have to maintain all game state in an SQL
database on the server. PHP scripts will make
changes to the database to indicate the current state
of the game.
You must use XML to send data between the server
and the client. You may send data from the client to
the server either in XML packets or using key/value
pairs on GET or POST queries.You can use Firebase in project 2. Don't try to send
game state in the message, only an indication that a
turn has occurred. When the receiving device gets
the message, it should contact the server to get the
current game state.
Specific team requirements
Team members will be personally responsible for one
or more elements of the program. The three
elements that the team members will be responsible
for are:
1. The sequencing of the activities
2. Client-side communications
3. Server-side communications
As before, these components are related to each
other. Those responsible for communications need
to decide early on what protocols to use. Though
individuals are responsible for their parts, the parts
must work together. This is a team project, not three
or four individual projects.
The team as a whole is responsible for ensuring the
components work together.
Grading
50% of the grade is for the individual components
and 50% is for the team. Any deductions specific to
an individual component will be against the
individual grade. For example, warnings in Serverside
communications will deduct from that
participant's individual grade. Problems in other
components will deduct from the team grade.
Deductions will include, but are not limited to:
Functionality problems
Violations of the technical requirements
Redundant code
Crashes and bugs
Of the total grade, 25% is allocated to the
checkpoint submission.Submission - Checkpoint
The checkpoint submission is required to include
these items:
The opening activity and the new user activity
The ability to create a user
The ability for the user to log into the system
All that is required is that the system be able to
create a user and the user be able to log onto the
system. Once the user is logged in, move to some
dummy activity. The error indications for failure to
log in must be provided.
When you are done with the checkpoint submission,
go to the submission page for details on submitting
your project.
There will be an automatic 10 point penalty for failing
to include a completed project2submit.txt or
improperly naming your
submission. project2submit.txt must be turned
in with both the checkpoint and final
submission!
Submission - Final
Be sure the file project2submit.txt is finalized prior
to final submission and is included in the submission.
Note that your solution will be tested with your
server-side implementation, so do not make
changes to the PHP after the due date.
Suggestions
Use https for all communications, not http. This only
changes the URL in your program.
You can use PHP sessions to keep track of the
logged-in state (see the lecture notes) or you can
create your own session id mechanism. Do not use
uniqid() as a session ID, though. You can use
openssl_random_pseudo_bytes() if you like. PHP
sessions are probably the easiest solution, though.
But you do have to support Cookies to use them.Polling and such requires a thread, of course. Be sure
you can abort the thread. Use Thread.sleep() to
delay within a thread. Thread.sleep() can be
interrupted to end the thread early using
Thread.interrupt().
Decide early what the protocols will be between the
client and the server. Then the person working on
the client communications can send packets to the
server as they are created and create dummy scripts
to respond. The person working on the server can
use a web browser to fake a client in many cases to
get their code up and running. But, be sure to try to
put things together as soon as possible.
When writing PHP scripts, consider using a web
browser to fake the client before the client is done.
See the page Faking a Client using a Web Browserfor
details.
Use phpMyAdmin to examine the contents of the
database to see what is working at any given time.
If I have an XML document, I can save it in a
database by creating appropriate fields for the data.
Or, I can just put the entire XML document into a
TEXT field of one record.