Ideas 2011

From Unknown Horizons - Wiki

Your steps to apply

1. Find out that you would like to work together with us this summer!
2. Tell us about that and work on your project proposal. Do this together with us! Best place is your wiki user page, see below.
3. Fill out our public application template. This is best done by creating an account at this wiki and copying the template from its page.
   Important: You really only need to copy and answer the part public there, there is no need to showcase everything else to everybody reading your user page!
4. Fill out our private application template. This is best done by copying the template from its page and adding the required information to your application at Google (melange) .
   Only the organization admin and the possible mentors will see this data.
   Important: You can still edit it after submitting until the deadline!
5. Hang out in our IRC channel, ask questions, submit patches, show us that you are suited well. There sadly will be more applicants than we can mentor with high quality :-/
6. See that Google appreciates well prepared students and start implementing your very own proposal! ;-)

Our organization info page

Everything we told Google is found here: Application 2011.

You can browse this developer wiki for anything you'd like to know more about, but you can as well ask on our IRC channel and we will happy to give you a short introduction.

Get to know the team

Our IRC channel is the place where everybody steps by very regularly and where nearly all discussion and general chatter happens ;-)

Since there are many people in our chan (players and devs alike), it's hard sometimes to find out who can help you with a question.

To ease working with our channel, we have thus created a short list of devs you can go to.

There also are tips on how to handle questions in general, so make sure you check this page out!

What students could work on

New tile set structure, adapt editor and random maps

Our problem

We currently describe and display each tile independently. A ground tile rotated by 90° becomes a totally new tile with own ID instead of staying the same tile with a different rotation applied. This leads to the following main problems:

• all tiles are specified multiple times (in different rotations)
  • it is hard to add new tiles
  • unnecessary overhead of copying the same files all over the place
• current map files are very hard to edit
  • especially our editor needs attention
• we store the graphics for e.g. buildings in a different way, which is confusing

Our idea

We specified a new structure similar to the action_sets we use for building graphic sets. This includes grouping tiles which only differ in rotation and making the database (map file / savegame) store the basic tile + rotation. We also want to fix our editor and allow all players to create new islands based on this new structure.

If time is left: We'd like to have specifications of which tile can be connected to which other tile in a way that our random map generator can use. This way we could generate much nicer looking random maps.

What you need

• A tool to bulk-edit SQLite files
• Python programming skills
• basic understanding of the way our tiles and maps currently work (can easily be obtained while working on the project)
• Estimated difficulties: Needs quite some work with FIFE internals like animation management and the editor framework
• We expect a moderate difficulty after you got familiar with our graphics structure.

You find more information, related material and starting points here: Ideas 2011/Tile set

a first combat/battle and health system including pirates

Our problem

When in multiplayer mode of Unknown Horizons, the only interaction you have with other players is that you can play on the same map. Since that might not totally occupy one's instincts, we want to give our players more possibilities about what they can do. Not together, but against each other!

Our idea

We want to fight! Combat with ships, combat with units, fighting with something completely different. In the end, you might even be able to write a small combat AI, but that's only one of many tasks we can think of. Arrr!

• Implement basic and flexible attacking and defending of units (we want to apply this to buildings later, too)
• Implement statistics and properties of attacks
• Try your luck at combat AI (as opposed to settlement AI, another idea for SoC)

What you need

• Python programming skills
• a shade of pychan since you will also implement the combat UI
• stamina in dealing with game designers ;-)
• AI knowledge if desired
• Estimated difficulties: The design of our combat is not finished yet (and needs actual ingame impressions), so expect the requirements to vary while working on this idea.
• We expect a moderate difficulty if you do not touch the AI part.

You find more information, related material and starting points here: Ideas 2011/Combat system

an AI player that is able to build and administrate own settlements

Our problem

Currently our singleplayer mode really means that there only is one player. As you can imagine, players feel quite alone after some time and have no real interaction with the world anymore after pursuing their goals.

Our idea

As a first step we want to implement computer-controlled players that sail for the same Unknown Horizons as you. This AI (artificial intelligence) should be capable of the following:

• evaluate the world, manage a settlement
• imitate a human player as closely as possible
• follow certain goals and solve problems

Your goals and milestones will not include any combat or battle because this is right another point on our Ideas list for this year :)

What you need

• CS background, AI knowledge
• programming skills in the language you write AI in
• Python programming skills to bind it on UH
• understanding of the flow of the game and the commands issued by players (you should be able to pick that up quite fast)
• Estimated difficulties: Selecting a language to write AI in, defining its scope and structure
• We expect a hard difficulty because this idea involves different fields and knowledge of AI

You find more information, related material and starting points here: Ideas 2011/AI player

implementation of unit tests

Our problem

• we break stuff all the time and notice months later :)
• adding unit tests to our current code is really cumbersome and might be not worth it everywhere, but they should pay of at certain locations

Our idea

Well, you can probably imagine our idea here ;-)

• Restructure the code to allow unit tests in the first place where you think it makes sense
• Write several tests as proof of concept, and try to make them maintainable
• The unit test system has to be really flexible - we frequently change the behavior of our code
• Usage of a unit testing frame work such as PyUnit or nose

What you need

• Good python skills
• Testing experience
• Difficulty: Hard, a big part of our code is very difficult to test, as it needs an almost entirely running game to work
• Areas: Testing, Refactoring
• Estimated difficulties: Finding a way to test without running most parts of UH

You find more information, related material and starting points here: Ideas 2011/Unit tests

Rewriting many parts of our current menu / ingame GUI

Our problem

The files horizons/gui/gui.py and horizons/gui/ingamegui.py exist for several years now. Whenever something got added, everybody did a little bit of patchwork to it.

• nobody understands how the widgets work anymore
• a lot of methods are too huge and need to be split up into smaller pieces

Besides this, we miss several features already defined in our current GUI and want others improved. See below for a detailed list.

Our idea

We have collected ideas on how to improve the following parts by adding new features:

• island inventory display (top bar when hovering settlements)
• build menu
• new chat widget

Besides this, we want a documented rewrite of gui.py and ingamegui.py with eydocified comments for each method.

What you need

• Python skills, basic xml knowledge
• delight in pychan
• A lot of communication with everybody when implementing new or altering current UI elements
• motivation to tackle several smaller parts instead of one large task
• Estimated difficulties: Pychan interaction, very clear documentation
• We expect a moderate difficulty -- most of the stuff is already done, you just ;-) need to understand how.

You find more information, related material and starting points here: Ideas 2011/GUI overhaul

Improve the overall performance of FIFE

Our problem

There are certain areas in the FIFE code base which are not very well optimized for performance. Some of these parts are frequently used by Unknown Horizons, tile overlay coloring for example (Used to display the building radius).

Our idea

Check the code for possible areas of improvement. Ideas:

• Tile coloring
  • Needs caching
• Texture drawing
  • Textures are drawn in a way that is compatible with very old OpenGL specifications. Therefore it is far away from optimal performance.

Probably there are more areas that could be improved.

What you need

• Excellent C++ programming skills
• Possibly skills in OpenGL and SDL
• Self motivated work, FIFE devs are not always available.
• Estimated difficulties: other FIFE clients, testing and profiling, OpenGL & SDL
• We expect a hard difficulty: You will need to dig into the FIFE code and bindings, proposing own ideas for improvements.

You find more information, related material and starting points here: Ideas 2011/FIFE

Improve FIFE's SoundManager

Our problem

The current FIFE SoundManager along with it's Python extension leaves something to be desired. It uses OpenAL as a cross platform sound engine which works well for our purposes but it is lacking some features. See FIFE ticket F#485. We would like the Sound Manager completely re-vamped and the Sound Manager python extension removed completely.

Our idea

List of possible improvements to the SoundManager:

• some features from the SoundManager Python extension should be implemented in C++ and the SoundManager extension should be removed altogether.
• have it's own Update function to be called directly by the engine
• callbacks when sounds have finished being played (including streamed audio)
• manage the number of sounds being played and limit if required (must choose which sounds to stop playing)
• should not rely on timers (the manager should have it's own update function as described above)
• ability to apply sound effects to specific emitters (you can change which clip to play for a specific emitter)
• manage the creation and deletion of emitters (emitters should be handed out by the engine)
• manage OpenAL sources

Probably there are more areas that could be improved.

What you need

• Excellent C++ programming skills
• Possibly skills in OpenAL
• Self motivated work, FIFE devs are not always available.
• Estimated difficulties: Reduce the impact on FIFE clients (keeping the python API changes to a minimum).
• We expect a hard difficulty: You will need to dig into the FIFE code and python bindings, possibly proposing your own ideas for improvements.

You find more information, related material and starting points here: Ideas 2011/FIFE Sound

Decouple FIFE from Guichan/Pychan

Our problem

One of our major issues we have encountered over the years has been how closely coupled FIFE is with Guichan. Because Guichan is no longer being actively developed many guichan bugs remain problems for FIFE. We have found ourselves stuck with Guichan.

Our idea

The basic idea would be to define a generic FIFE -> GUI interface and write an implementation of that interface for Guichan. Theoretically we could then use any 3rd party GUI library with FIFE by writing an interface for it.

Some features we would like to see implemented, but not limited to are:

• Make Guichan an optional dependency for FIFE
• Rename Guichan and modify/rename Pychan to use the new library (we are open to ideas here)
• Fix some Guichan/Pychan tickets
• Add some new features

Probably there are more areas that could be improved.

What you need

• Excellent C++ programming skills
• Possibly skills with Guichan or other GUI libraries
• Self motivated work, FIFE devs are not always available.
• Estimated difficulties: Reduce the impact on FIFE clients (keeping the python API changes to a minimum).
• We expect a hard difficulty: You will need to dig into the FIFE code and python bindings, possibly proposing your own ideas for improvements.

You find more information, related material and starting points here: Ideas 2011/FIFE Pychan

What students should know before starting work

• All coding happens in our git repository. You thus need to be able to clone this repo and to compile FIFE trunk. Both is explained on our homepage. If you are stuck or have any questions, please join our IRC channel!
• You can further outline your idea on your personal user page in this wiki, including proposals for milestones and project scope. Make arrangements with your possible mentor!
• We offer help on getting started with the project for each interested developer. Even if this article is not only valid for SoC students, we highly recommend the lecture of Getting started.
• To push your commits to github, you need an account there. Be sure to check GitHub How-to and Git cheatsheet - if you hesitate to work because you're not familiar enough with git, that is very bad and will slow down overall progress. Ask whenever something is unclear!

What we expect from students working on UH ideas

This is a list of everything you should agree on when joining our team. If you have any concerns, be sure to mention these in your application. This especially includes the scheduling of our regular meetings. We will then try to find a solution together with you.

• You spend your time on our IRC channel within your means when working on Unknown Horizons. This eases communication, makes brainstorming possible and boosts our overall productivity. Cf. Getting started#IRC activity
• You attend each of our weekly meetings (sunday; 17:00 UTC; #unknown-horizons) and present your work to all members of the dev team and interested players there. They will review it and provide corrections or new ideas where necessary.
• Commit early, commit often. This review can only happen if you regularly commit your work and break it down into a lot of sensible commits. How could your mentor look after your work if you hide it from everybody? Reviewing a huge patch like hundreds of code lines is unnecessary and a time sink.