ugml / php-client Goto Github PK

View Code? Open in Web Editor NEW

14.0 7.0 5.0 6.73 MB

ugamela is an open-source clone of the popular browsergame ogame.

Home Page: https://ugamela.org

License: GNU Affero General Public License v3.0

PHP 96.14% CSS 2.99% JavaScript 0.88%

browsergame php ogame ugamela

php-client's Introduction

What is ugamela?

ugamela is a open-source clone of the popular browsergame ogame, developed by the Gameforge 4D GmbH. It first appeared around the year 2006, when Peberos published the source-code for his version of ugamela. It stayed open-source until the version 0.2-r13, which can still be found for download. After this, Peberos continued to improve ugamela as a closed-source browsergame.

Now, many years later, ugamela is back, redone completely from scratch with the latest web-technologies available. Its goal is to be as close to the original ogame (also known as ogame classic) as possible.

Disclaimer

This open-source project is still in an alpha-state, please do not use this in an production-environment. Currently, not many features are available and this game is not fully playable. Feel free to contribute by making a pull-request.

Project-Structure

┌─── core/                       # → contains all necessary classes
│   │── classes/                 # → classes for the ORM-Mapping and parent-classes
│   │   │── data                 # → classes, which map database-values to objects
│   │   └── units                # → classes for various ingame-units
│   ├── controllers/             # → all needed controller-classes
│   ├── interfaces/              # → interfaces the classes
│   ├── language/                # → contains all translations in subfolders named after their ISO 639-1 language-code
│   ├── models/                  # → all needed model-classes
│   ├── templates/               # → template for each site (HTML)
│   └── views/                   # → all needed view-classes
├── css/                         # → css for all pages outside of the game
├── images/                      # → images for all pages outside of the game
├── install/                     # → contains the necessary files for a first-time setup
├── scripts/                     # → javascript-files
├── skins/                       # → skins, which are useable ingame (all images and css for the game must go here)
├── game.php                     # → the main php-file, which dynamically loads the needed pages
├── index.php                    # → redirects to the game.php if logged in, else to the login-page
├── login.php                    # → login-form for the user
├── logout.php                   # → user-logout
└── register.php                 # → registration

Quick Start

This project uses is being developed with the (currently) latest release of PHP (Version 7.1.9) and mariaDB (Version 10.2). For a easy quick start, use the latest release of XAMPP or use Docker with the necessary containers.
After setting up your environment, import the sql-file located in the install directory.
Edit the config.sample.php in the core-folder to match your server-configuration and rename it to config.php and change the classname to Config.

Documentation & Demo

A live-demo can be found here. This demo may not always contain the latest version of this repository.

The credentials for the test-account are:

Username: test
Password: test

The documentation is hosted on the same server as the game.

Roadmap

The current roadmap for the next version is listed below with their respective issues linked.

Support / Questions

For any further questions, support or general talk, please visit our Discord by clicking on the image below or follow the link.

https://discord.gg/YDUHM3k

php-client's People

Contributors

Stargazers

Watchers

Forkers

mdtrooper kaiserwerk darkliving jmahiques alexbander

php-client's Issues

basic statistics

display basic statistics for the players at position 1 to 1500 (500 on each page)

empire-view

create an administration-panel

this panel should have the following functionalities:

show currently online users
show all users/planets
ban/unban users
send messages to all players

techtree-view

create unit-tests

[registry] create user-registration

if a user is registered, create the following database-entries:

a new row in the user-table
a new row in the planet-table, which sets the new user as the owner
a new row in the buildings/fleet/defense-table, which has the planetID of the new planet
a new row in the tech-table, which hast the userID of the new user

remove unnecessary duplicates in loader

the variable $buildingData contains all buildings of the current planet as a D_Building-object. The variable $buildingList contains the same information as an associative array which is no longer needed.

The same holds for $defenseData/$defenseList, $techData/$techList and $fleetData/$fleetList.

Messaging via external services

Classic OGame has a system messaging system that also allow player communication, but this comes from a pre-instant-messenger-age.
I think reading system messages should be easier and not require clicks.
Inter-player-communication privacy should be handled by external services and alliances should be able to choose which service they want to use for their group chat.

They key lies in integrating well with for example Discord to push out moderational requirements for group chatting

display activity for planets

display different indicators according to the planets time of last update

-> updated in the last 15 minutes
x min -> updated in the last x minutes (max 59 min)

[galaxy] popup for sf/player/alliance/planets

display a popup which contains further informations about the object and possible actions

add actions for each user

add the ability to take actions e.g. send message, spy, send buddy-request

for v0.1, sending messages is the only possible action (issue #12 has to be solved first)

make techs usefull

drive techs make ships go faster etc.

use XLIFF format as a base for i18n for portability instead of php arrays

build XLIFF from the current arrays in language/en by hand or with https://github.com/oyagev/PHP-XLIFF
check which annotations and attributes of the XLIFF format are going to be used for ugamela
load XLIFF (in a way like symphony does it?)

Pro

Not only professional translators can profit of annotations for translation
XLIFF can be interpreted and thereby reused in other clients (not only PHP)
Separation of concerns: controller logic and translations don't necessarily need to be coupled

Contra

Performance (parsing without caching the XLIFF globally)
Added complexity: any other i18n technique will be more complex than PHP arrays
Other formats like gettext and .po files might be more recognised by the PHP community currently

Semantic versioning

v.X.Y.Z
- X major version
- Y minor version
- Z patch/bugfix version

Since there is existing ugamela sourcecode has had versions up to 0.5. It would make sense to switch to semantic versioning and use version numbers above that, e.g. 1.0.0 or 0.7.0 as soon as possible.

create a settings menu

create a settings menu, which allows the user to change his username, password, email-address and various other settings

[galaxy] ability to switch between galaxies/systems

ability to build defense on a planet

update production-factor

the current production-factor should be set according to the set percentages

game-installer

create a installer for the game which generates a config-file and imports the database-dump

switching galaxies/system should cost 10 deuterium

for this issue, issue #4 must be implemented

implement basic messaging feature

implement feature to allow players to send messages to each other

display the current status of the player (vacation/banned/inactive)

JSON API for data access

A PHP centered system always renders its template into HTML, but Web 2.0 SPAs render the DOM directly in the browser. Such web applications usually consume a REST JSON API .

short term:
render variables that would be rendered into the html as a nested object/array JSON datastructure, so simple getJSON requests (requesting "application/json" datatype) can grab a state of the game too - this will achieve data access freedom (with session authorization, or better token bearer based authentication).
- IMHO this would synergize well with the open(-source)ess of the project.
- data serialization can be easily accomplished, e.g. U_Unit { .. public json_serialize: { json_encode($this) .. }
longterm:
develop the interface design defining and refining it, covering all entities in further iterations
benefits:
API spec is shared between client and server and is a perfect layer to write tests against. the spec wont depend on any implementation or language details - concentrating on the domain model entities and possible actions and their validation upon them.

display all other planets

all other planets should be listed next to the current planet

Resources: Scale production down properly when energy consumption is too high

When energy consumption is too high, production should scale down not just cut in a half.
Instead calculate the quotient.

https://github.com/mamen/ugamela/blob/acb7ae51c04cbebdd65d321633f4f71c910e4ba1/core/classes/units/planet.php#L187

But this might be only the tip of the iceberg of inaccuracies of the resource calculation.

What about finishing buildings, are they giving off their production right after building time finished or just when the planet updates the next time?
The fusion power plant consumes deuterium and thereby should turn off when deuterium runs out, also changing production at that point in time

Improving over OGame

TLDR: This issue shall be more of a collection of ideas with high risk of going offtopic than something that can actually be accomplished.

There might be some minor or major enhancements we could introduce to the game that might make more or less different to the original:

optional building fleet and defense categorisation(al views) with sorting
fleet transport helpers (like xorbit has via tampermonkey extension)
dynamic imperial overview (with fleet control)
extensibility (tech, buildings, units and resource types)
more realistic game physics than just using fuel when starting
extensible composite battle engine

Feel free to add more ideas to this list or rather open a new issue if you think one is actually feasable.

player-name
alliance-name (to implement in v0.3)
alliance-tag (to implement in v0.3)
planet-name

dynamically display moon

the moon-icon should only be visible, if the current planet has a moon (and is not a moon himself)