puzzud / gjweb Goto Github PK

Sometimes using a mouse or pointer is slow.

During development, it may be a lot quicker to hit a key to move through screens.

The cursor up and down keys should allow the user to navigate menu options, causing the same effect as a mouse over.

Only one option should be selected at once. A subsequent mouse over of an option should take precedence of what the keyboard selected (and vice versa).

Enter and space should activate the currently selected menu button, just as it actually pressing the button with the mouse cursor would.

On the game screen, cursors should not select the exit button. Instead, the Escape key should both select and activate it.

A lot of information stored in GameTitle that is used at runtime can be stored and pulled in from loading /package.json, such as project name, window title, author, contributors, etc.

This information should be loaded by Boot.js (not Preloader.js) and referenced as JSON structure by a single member on GameTitle called projectInfo.

All places where such information is referenced (main menu game title, author screen contributor list, contributor sorting function) will need to be updated.

Contribution is not, as far as I know, a key for contributors. Some mild research should go into whether it is harmful to add those values as keys (probably not a problem).

Add a new screen which is accessible from the main menu with a button that reads "About".
This button will display right above Exit.

The About screen should display the same game title as the main menu in the same position.
Below the game title, a vertical list of game contributors should be listed in 2 columns: Name, Roles.

The list of names and roles should originate on the main GameTitle object has a array of names to roles string.

At the bottom of the screen, there should be a button that reads "Back".
This button will navigate back to the main menu.

This game template is revisioned with git. However, it's not currently the intention to have this project forked and then given pull requests from games which were made with the template.

Therefore, it'd be good to have a script which copies the contents of this project to another directory while also stripping out all ".git" files and directories.

The git stripping should actually be its own script, as it can be used in other (future) use cases (like a release).

The script should be called copy.sh or copy.py.

Parameters:

• It should take a source path and a destination path.
• Optionally, it should take the string matching parameters of rename.py.

It the destination path does not exist, it should be created, otherwise, it should be used as is.

The git stripping script should be called unrevision.sh or unrevision.py.

Parameters

• It should take a source path which should be the root of the project.

When a user presses the Back button, it should be intercepted and be handled like the Escape key is currently. It should only cause the application to close / reset when on the main menu (and after any "are you sure?" prompts #10).

Load an image sprite and audio sample which is use during the game screen.

Mouse / pointer down on entire screen should:

• Cue the audio to play once.
• Cause the image sprite to tween to that location.

The style of the image and audio should be minimalist and clean, like the rest of the skeleton game template.

There's currently no way to adjust whether sounds play in game (volume or mute).

For the time being, pair this button up with the Exit button, position-wise.

It should provide some kind of state indicator as to whether sounds are disabled (muted) or not. Phaser may have a Button mechanism already for such (maybe just graphically). In the least, make the button text alternate between Mute and Muted.

Obviously, all currently playing sounds need to be silenced (ideally, the sounds are not ended, in case the user immediately disables mute).

Extra credit or its own story:
The state of mute could be persisted across game sessions with web based local storage.

Scalable

The About screen is not set up to have more than 4 contributors on the screen.

Perhaps it's possible to determine how much room it has to fill with contributor text lines (provided there is sufficient room for the Back button).

In which case, shrink or expand the text to fit. A threshold should be put in place, which will limit how small the text can get. When this threshold is met, the text will scroll vertically (clever use of positional and alpha tweening).

Columns and Alignment

Each contributor line is a single (and centered) text string which is a concatenation of contributor first name, last name, and contribution in parentheses. It should function more like a structured table.

Instead, each row should have 2 columns: Name, Contribution.

Each row as a whole should be centered to the screen.

Each columns' contents should be aligned to the left. Therefore, some intelligence needs to go into how much space every row's contents take up horizontally in order to get the best alignment (with adequate space between the 2 columns, as visual separation).

Contributor Website Hyperlink:

Each contributor's name should optionally be a button which directs the user to a URL specified by a new member in the GameTitle::contributorList structure called website. Ideally, this user redirection to a website should open a new tab in their web browser.

Extra credit: If the user is using a native application runtime (eg Cocoon, Cordova), the button should open the system's default web browser to the page. This portion may need to be its own future enhancement.

By default (and when website is specified for a contributor), the text style for the name should be underlined.

The contribution text should not be hyperlinked.

Misc.

Contributions should no longer be wrapped in parentheses.

Sounds made in the main Game state linger if they are still playing after the user selects Exit.

Implement an easy to add solution which will silence all registered sounds.

There may be exceptions where one would want to have sounds not be silenced between states. That'd be another enhancement or a one off change.

A script should be created to facilitate providing a released or releasable version of the game.

It should use the copy script (and not use its renaming parameters).

The script should be called release.py.

Parameters:

• Optionally, it should take a source path as the first parameter.

If a source path is provided, it will instruct the copy script to use the provided path. If the root directory of the provided path does not exist, it should create it.

By default, if no source path is provided, a root level subdirectory called "build" should be used. The build directory should be deleted if it already exists.

The copy script will function as it normally does. However, immediately after copying, the copied project's "tools" directory should be deleted. All references to such tool scripts used within the release.py script should come from the originating / working project.

In the future, this script will have other parameters which will indicate how the game project is to be released. For example,

• Whether / how to minify the project.
• Provide a release target type, which may affect how the released version is packaged (eg zipped, etc.).

Some settings should be remembered when a user returns to the application--like Mute.

The first step is to create a member called "settings" on GameTitle.

The next step is to have that settings be an object which contains 2 sub objects:

• local
• session

Settings which should persist from session to session should be stored in local (eg Mute).

Settings which should not persist past the current session should be stored in session.

The last step is to develop a mechanism in which the "local" object is stored as JSON in the localStorage browser system. It may be too expensive to store this entire structure every time a small change is made (eg mute or not). Careful consideration should be made when choosing when to store these settings (eg between state changes or confirmations). Maybe it's possible to ensure these settings are saved when the application is closed (pretty certain this is possible with a Chrome app).

The local settings should be loaded on startup (during Boot.js).

Preloader.js needs to have some kind of minimal & simple asset loading progress indicator.

A simple left to right progress bar would suffice. But perhaps it could be a circle / pie which fills clockwise.

As of this writing, there are no assets being loaded. Perhaps this requirement could be fulfilled by another enhancement.

The project currently depends on a third party library called Phaser.

Also, some provisions allow for the optional use of a 3D graphics library called Three.

Although many actual game projects maintain and revision a checkout of a full or minified version of Phaser or Three, this project does not.

A script could be written to speed up the download or checkout of these third parties; as well as placing them in the appropriate locations for the game template to run.

The script should be called libsetup.sh or libsetup.py.

The script should take a hypothetical unlimited number of parameters. For now, it should acknowledge the following:

• three

The script should ensure that it can download files from some set URLs. If it cannot (eg unavailability of wget), it should return with a error and message.

The script should download the following files:

• https://raw.githubusercontent.com/photonstorm/phaser/master/build/phaser.js
• https://raw.githubusercontent.com/photonstorm/phaser/master/build/phaser.map.js
• https://raw.githubusercontent.com/photonstorm/phaser/master/build/phaser.min.js

If the "three" parameter is specified, the script should download the following files:

• https://raw.githubusercontent.com/mrdoob/three.js/master/build/three.js
• https://raw.githubusercontent.com/mrdoob/three.js/master/build/three.min.js

The script should create the following subdirectories (if they don't already exist) in the project directory (for three, only create if "three" parameter supplied):

• src/phaser
• src/three

The downloaded phaser files should populate the phaser directory.
The downloaded three files should populate the three directory.

If any downloaded files are replacing existing files in their respective directories, it should replace such files.

Right now, pressing Exit in the Game state will immediately kill the state and return the user to the main menu.

Pressing Exit could be an accident. Therefore, we want to pop up a modal prompt dialog asking the user if they really want to exit the game. The user has the options of Yes or No.

In the case of Yes, the user is proceeded to the main menu (as usual).
In the case of No, the user is returned back to game play as the modal prompt is removed.

When the modal prompt is first displayed, a Game state method called setPaused is given the parameter "true". Similarly, when the prompt is removed, setPaused is called with the parameter "false". setPaused should be implemented and it should set a Game state member called paused to "true" or "false". However, that is the limit of this enhancement. It is up to the game logic to determine completely how setPaused behaves and how paused is observed.

This enhancement is intended to speed up development by allowing developers to quickly jump to the game state they are currently working on.

Phaser has an API that provides for easy parsing and access to parameters that the user can provide via the web URL.

For example,
http://locahost:8081/gjweb/index.html?state=MainMenu
http://locahost:8081/gjweb/index.html?state=Game

When the Preloader state is ready to progress to the "next" state, it should look to see if the user provided the "state" parameter. If so, the value should drive the name of the state which is changed to next.

Extra credit or additional enhancement:
If possible, do a quick check to see if such a state with the supplied name exists. If it does not, issue an error message to the console error log.

There are a lot of source files that reference GameTitle. However, no one wants to name or namespace their game with this title.

As more files and functions are added to this project, the more time it will take to manually or even semi-automatically update all the references.

A script or suite of scripts should be available to change these references to a different desired name.

Some file names may even contain the game name as well. These files' names as well as the content of files that reference these file names need to be updated.

The user should be able to specify a variable safe name (no spaces, etc.) and optionally a nice name (one that can be anything). If the latter is not specified, it will default to the former.

All references to GameTitle should be changed to the variable safe name.

All references to Game Title should be changed to the nice name.

These scripts should not reside in the src directory. Instead, it should reside under tools off of the root directory.

Ideally, these scripts should be BASH and utilize standard Unix utilities like sed and awk.