代做Game play、代写SQL设计、代做SQL编程语言、代做program留学生

日期：2019-04-09 11:36

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.