I have submitted already.
My idea is focus in strategy and RPG like games. Very much like
ikariam, travian, fallen sword and a long etcetera.
My draft proposal (later I show that the template for RoR is different
and change proposal slightly) is:
Abstract
Web based gaming has become an important branch of gaming with
advantages as been platform independent and accesible from any
location.
Web games are currently single player, casual flash games or
multiplayer html + javascript based games mostly programmed with PHP.
Ruby and more specifically Ruby on Rails has proven that an strong
framework with sensible defaults and tailored for web programming
needs can improve productivity of web programmers enormously.
The aim of this project is use the Ruby on Rails philosophy and apply
it to web game development, improve the web games programming
landscape (currently mostly lots of PHP code) as Rails improved the
web programming landscape.
Specifically the project will create plugins and facilities to allow
easy creation of games with Ruby language.
The goal is a flexible framework for multiplayer games of the type
strategic game and RPG.
== Detailed description ==
The following no exahustive list are general characteristics found in
RPG or strategy like games:
- Maps. Either world map or the map the player is interacting with or
both. Maps are 2D tiled zoomable canvas connected via portals where
each tile is potentially of a different class where events can happen
(characters, buildings, etc.)
- Characters. Playing and not playing characters will have stats
(strengh, level, etc.), biography, portrait, capabilities in the
world, inventary, AI, etc.
- Buildings. Can have maps and characters inside. Provide special
properties.
- Players. Each player will have his own stats. One or more character
under control, inbox, outbox, notepad, preferences, etc.
- Players' groups. Players can make groups, with in-group and intra-
group comunication capabilities.
- Highscores. From players and players groups. Hall of fame pages,
milestones, etc.
- Artificial Intelligence. Many characters in the world has simple
missions like give information, trade, give quests or exchange items.
Many have path based movement.
- Fight. Fundamental in most games y usually based in simple
parameters and rules.
- Authentification. Authentification must be build in. Also a unique
address for each player, usable to invite other people to the game.
- Resources/inventary.
This project will focus in providing these core functionalities as
time would allow.
Also, it is a priority of the project to create a high quality
framework over create all the functionality mentioned above (long term
goal) . RESTful and MVC technologies will be followed.
== Timeline ==
Till May 26: Community bonding. Discussion on ML and with mentor
over priorities, drafts of the design, create page about the project,
etc.
May 26 - June 12: players : authentification, invitations, players
communication mecanisms (on game and off game), notepad, portrait,
etc.
June 13 - June 23: Map as set of tiles
Each tile can potentially have:
- Portal to other map (enter in a house for
instance) with or without menu (travel agency)
- Characters
- Buildings
- Events
- Tile (or terrain) properties, resources
- Visual representation
June 24 - July 2: Basic map functionality and API. Map
definition file loader?
July 2 - July 9 : Buildings and characters (stats, capabilities in
the world), integration on the player and map.
July 10 - August 3: Basic game engine. Trading. story line,
levering up, fight system, resource gathering, inventory gathering,
rewards compensation, etc.
August 4 - August 13: AI, capabilities of characters (tell stories,
trade, etc.)
August 14 - August 20: Documentation and GSoC report
== Technical details ==
Some predefined models are needed for the platform to work. For
instance a model for players.
Thus the platform will define some base models with some basic
properties considered general enough to be useful in a good percentage
of use cases.
For the sake of simplicity, I will choose an authentification/register/
login solution and integrate it with the invitation system.
Each player will have his own URL in the system (derived from the
playername), that can be given when other players register.
With different levels of protection, players will have inbox, outbox,
notepad, portrait, etc resources.
Maps are 2D and tile based, so a simple squema with X/Y data should be
enough. GET will discover extra resources of each tile.
In the GSoC time there will be very basic if any rendering of maps,
etc.
Most of the work will be focused on the game engine. Most controllers
actions will in one way or another call the game engine. It will
ensure the whole is coherent.
It will also get most of the configuration and is responsable of
loading the game data.
For instance the trade system. In the variant where the game sells to
the user (via special shops or characters). The engine loads the
tables from all the asserts available in the game. A Seller base class
has the methods to define what asserts is selling and possible
modifiers to the base properties of the asserts.
The user of the framework will insert in the map a object that inherit
from Seller and select the desired asserts.
== Project extra functionality ==
Some functionalities that surely will be impossible to implement in
GSoC time are:
- Players' groups
- Highscores
- Path based movements
Also, as stated, some functionalities may be sacrified for estability
or quality of the platform.
== Profit for Ruby and Ruby on Rails ==
Rails can become the obvious platform of choice when it comes to
deploying web based games.
The aim of the project is 3-fold:
- Sucessfully create a basic platform worth of GSoC
- Create a long time project. GSoC will act as kickoff of the
platform. It is hoped that by September the platform attracts some
more contributors
- Create a community of game builders over the platform sharing
information and solutions (that eventually will flow down to the
platform itself much like rails itself)
Ruby can be a pretty amazing programming language for games (the
instropection functionality of objects itself is amazing) but there
are not may resources in the web front. This project aims at solving
this issue.
== Success Criteria ==
Create a basic usable platform. Ideally, all the tasks listed in the
timeline should be accomplished.
== Availability ==
Except from June where I will be only available for one week, from May
to September I can work on this project around 30 hours/week, most of
the rest of my time will be dedicated to work on the related project
explained below.
== Biography ==
My name is Jordi Polo Carres (mumismo@gmail.com), I finished computer
science and electronic engineering, currently I am a PhD student at
the natural language processing lab of the Nara Advance Science and
Tecnology Institute.
I am active or sporadic contributor of several open source projects so
I am pretty used to tools (git, etc) and procedures (mailing list, bug
tracking, etc).
I have written most of my code in C++, but since one year now I have
being using Ruby for most of my own projects and prototypes, I am
using rails from some months now.
My next step in my PhD involves using Rails for the next 3 months to
create Quiz like games. I hope that both projects can create positive
synergies that let me improve the framework with a better insight.
My native language is spanish, even with some grammar errors, I think
I won't have any problem communicating with my mentor in English.
Currently I live in Japan.
I think the views of graphics like map, characters etc, eventually
will be a HTML5 canvas + javascript. I have no much idea of those
technologies so views will be very basic as included in this project.
This project is more about the models and controllers needed for the
data backend and general logic of the game. As such is already worthy
and difficult to get done in a GSoC. Also as it is the first time I
attempt this (even when I just started some very related work) my
timeline is a big guess work. What I can provide is a best effort
toward the goals and the timeline of the GSoC plan. Halfway the
implementation we can discover something was missing in the plan for
instance and redefine the timeline. I am not worried about that as
long as the final "product" is worthy and useful. If it is, users and
developers will appear and start contributing, then the project will
have been a success.