Spring - User contributions [en]

Lua UnsyncedRead

2011-03-04T01:27:18Z

Argh: Fixed TraceScreenRay to show includeSky

[[Engine_Development|Development]] < [[Lua_Scripting|Lua Scripting]] < {{FULLPAGENAME}}
=Unsynced Read=

== Replay/Spectating ==
'''Spring.IsReplay'''
( ) -> nil | boolean
'''Spring.GetSpectatingState'''
( ) -> boolean spectating, boolean fullView, boolean fullSelect

== ModUI ==
'''Spring.GetModUICtrl'''
( ) -> boolean

== MyInfo ==
'''Spring.GetMyAllyTeamID'''
( ) -> number
'''Spring.GetMyTeamID'''
( ) -> number
'''Spring.GetMyPlayerID'''
( ) -> number

== Local Player,Team,Ally ==
Redundant same as the GetMyXYZ functions!

'''Spring.GetLocalPlayerID'''
( ) -> number playerID
'''Spring.GetLocalTeamID'''
( ) -> number teamID
'''Spring.GetLocalAllyTeamID'''
( ) -> number allyID

== Team/Player Info ==
'''Spring.GetPlayerRoster'''
( [number sortType] ) ->
nil | playerTable = {
[1] = {
string name,
number playerID,
number teamID,
number allyTeamID,
boolean spectator,
number cpuUsage,
number pingTime
},
etc...
}

 Sort codes:
1 = Sort by allies (the default)
2 = Sort by teamID
3 = Sort by playerName
4 = Sort by CPU usage
5 = Sort by ping time
'''Spring.GetTeamColor'''
( number teamID ) -> nil | number r, number g, number b, number a
'''Spring.GetTeamOrigColor'''
( number teamID ) -> nil | number r, number g, number b, number a
'''Spring.GetPlayerTraffic'''
( number playerID [, number packetID] ) -> number

== Sound ==
'''Spring.GetSoundStreamTime'''
( ) -> number playedTime, number totalTime

== Camera ==
'''Spring.GetCameraNames'''
( ) -> { [camName] = number camNum, ... }
'''Spring.GetCameraState'''
( ) -> { "name" = string, "mode" = number camIdx, state1 = number, state2 = number, ... }

See [[Lua_camState]] for details about Spring.GetCameraState output.

'''Spring.GetCameraPosition'''
( ) -> number x, number y, number z
'''Spring.GetCameraDirection'''
( ) -> number forward_x, number forward_y, number forward_z
'''Spring.GetCameraFOV'''
( ) -> number fov
'''Spring.GetCameraVectors'''
( ) -> vectorTable = {
forward = { [1] = number x, [2] = number y, [3] = number z },
up = { [1] = number x, [2] = number y, [3] = number z },
right = { [1] = number x, [2] = number y, [3] = number z },
top = { [1] = number x, [2] = number y, [3] = number z },
bottom = { [1] = number x, [2] = number y, [3] = number z },
leftside = { [1] = number x, [2] = number y, [3] = number z },
rightside = { [1] = number x, [2] = number y, [3] = number z }
}

=== Inview ===
'''Spring.GetVisibleUnits'''
( [number teamID = -1 [, number radius = 30 [, boolean Icons = true ]]] )
-> nil | unitTable = { [1] = number unitID, ... }
'''Spring.GetVisibleFeatures'''
( [number allyTeamID = -1 [, number radius = 30 [, boolean Icons = true [, boolean geos = true ]]]] )
-> nil | featureTable = { [1] = number featureID, ... }

'''Spring.IsAABBInView'''
( number minX, number minY, number minZ,
number maxX, number maxY, number maxZ ) -> nil | boolean
'''Spring.IsSphereInView'''
( number x, number y, number z [, number radius ] ) -> nil | boolean
'''Spring.IsUnitIcon'''
( number unitID ) -> nil | boolean
'''Spring.IsUnitInView'''
( number unitID ) -> nil | boolean
'''Spring.IsUnitVisible'''
( number unitID [, number radius [, boolean checkIcons] ] ) -> nil | boolean

=== Screen Trace ===
'''Spring.WorldToScreenCoords'''
( number x, number y, number z ) -> number x, number y, number z
'''Spring.TraceScreenRay'''
( number mouseX, number mouseY [, boolean onlyCoords
[, boolean useMinimap, [boolean includeSky]] ] )
-> nil |
string "unit", number unitID |
string "feature", number featureID |
string "ground", { [1] = number x, [2] = number y, [3] = number z }

=== Screen & Window Geometry ===
'''Spring.GetViewGeometry'''
( ) -> number viewSizeX, number viewSizeY, number viewPosX, number viewPosY
'''Spring.GetWindowGeometry'''
( ) -> number winSizeX, number winSizeY, number winPosX, number winPosY
'''Spring.GetScreenGeometry''' (is missing multiscreen support!)
( ) -> number screenSizeX, number screenSizeY, number ZERO, number ZERO

== Unit ==
'''Spring.IsUnitAllied'''
( number unitID ) -> nil | boolean
'''Spring.GetUnitViewPosition'''
( number unitID [, boolean extrapolated ] ) -> nil | boolean
'''Spring.GetUnitTransformMatrix'''
( number unitID [, boolean invert = false] ) -> nil | number a11, number a12 ..., number a44 (4x4 matrix)

=== Selected Units ===
'''Spring.GetSelectedUnits'''
( ) -> { [1] = unitID, ... }
'''Spring.GetSelectedUnitsSorted'''
( ) -> { [number unitDefID] = { [1] = [number unitID], etc...}, ... }
'''Spring.GetSelectedUnitsCounts'''
( ) -> { [number unitDefID] = number count, etc... }
'''Spring.GetSelectedUnitsCount'''
( ) -> number count
'''Spring.IsUnitSelected'''
( number unitID ) -> nil | boolean

=== Unit Groups ===
'''Spring.GetUnitGroup'''
( number unitID ) -> nil | number

'''Spring.GetGroupList'''
( ) -> nil | {
[number] = number unitCount,
...
}
'''Spring.GetSelectedGroup'''
( ) -> number
'''Spring.GetGroupAIName'''
( number groupID ) -> string aiName
'''Spring.GetGroupAIList'''
( ) -> {
[1] = string aiName, ...
}

'''Spring.GetGroupUnits'''
( number groupID ) -> nil | {
[1] = number unitID, ...
}
'''Spring.GetGroupUnitsSorted'''
( number groupID ) -> nil | {
[number unitDefID] = {number unitID, ...}, ...
}
'''Spring.GetGroupUnitsCounts'''
( number groupID ) -> nil | {
[number unitDefID] = number count, ...
}
'''Spring.GetGroupUnitsCount'''
( number groupID ) -> nil | number count

== UI ==

=== GUI Settings ===
'''Spring.IsGUIHidden'''
( ) -> nil | boolean
'''Spring.HaveShadows'''
( ) -> nil | boolean
'''Spring.HaveAdvShading'''
( ) -> nil | boolean
'''Spring.GetWaterMode'''
( ) -> nil | number mode, string "mode"

 mode numbers:
0 - basic
1 - reflective
2 - dynamic
3 - refractive
4 - bumpwater
default - unknown
'''Spring.GetMapDrawMode'''
( ) -> nil | "normal" | "height" | "metal" | "path" | "los"
'''Spring.GetDrawSelectionInfo''' Returns whether "Selected units" text is displayed.
( ) -> boolean

=== Unit GUI States ===
'''Spring.GetUnitLuaDraw'''
( number unitID ) -> nil | boolean
'''Spring.GetUnitNoDraw'''
( number unitID ) -> nil | boolean
'''Spring.GetUnitNoMinimap'''
( number unitID ) -> nil | boolean
'''Spring.GetUnitNoSelect'''
( number unitID ) -> nil | boolean

=== Minimap ===
'''Spring.GetMiniMapGeometry'''
( ) -> number posX, number posY, number sizeX, number sizeY,
boolean minimized, boolean maximized
'''Spring.GetMiniMapDualScreen'''
( ) -> boolean false | string "left" | string "right"
'''Spring.IsAboveMiniMap'''
( number x, number y ) -> nil | boolean

=== (Build-)Menu ===
'''Spring.GetActiveCommand'''
( ) -> nil | number index (, number cmd_id, number cmd_type, string cmd_name)
'''Spring.GetDefaultCommand'''
( ) -> nil | number index (, number cmd_id, number cmd_type, string cmd_name)
'''Spring.GetActiveCmdDescs'''
( ) -> nil | {
[1] = {
id=number,
type=number,
name=string,
action=string,
tooltip=string,
texture=string,
cursor=string,
hidden=boolean,
disabled=boolean,
showUnique=boolean,
onlyTexture=boolean,
params = { [1] = string, .. }
}, ...
}
'''Spring.GetActiveCmdDesc'''
( number index ) -> nil | {
id=number,
type=number,
name=string,
action=string,
tooltip=string,
texture=string,
cursor=string,
hidden=boolean,
disabled=boolean,
showUnique=boolean,
onlyTexture=boolean,
params = { [1] = string, .. }
}
'''Spring.GetCmdDescIndex'''
( number cmdID ) -> nil | number index
'''Spring.GetActivePage'''
( ) -> nil | number pageNum, number maxPages

=== Build Facing ===
'''Spring.GetBuildFacing'''
( ) -> nil | number
'''Spring.GetBuildSpacing'''
( ) -> nil | number

=== GatherMode & InvertQueueKey ===
'''Spring.GetGatherMode'''
( ) -> nil | number
'''Spring.GetInvertQueueKey'''
( ) -> nil | boolean

=== Mouse States ===
'''Spring.GetMouseState'''
( ) -> number X, number Y,
boolean leftPressed, boolean middlePressed, boolean rightPressed
'''Spring.GetMouseCursor'''
( ) -> string name, number scale
'''Spring.GetMouseStartPosition'''
( number mouseButton ) -> nil | number pressedX, number pressedY,
number camPosX, number camPosY, number camPosZ,
number dirX, number dirY, number dirZ

=== (Hot-)Keys ===
'''Spring.GetKeyState'''
( number key ) -> nil | boolean
'''Spring.GetModKeyState'''
( ) -> boolean alt, boolean ctrl, boolean meta, boolean shift
'''Spring.GetPressedKeys'''
( ) -> {
[number] = boolean,
...
}
'''Spring.GetKeyCode'''
( string keysym ) -> number
'''Spring.GetKeySymbol'''
( number key ) -> string "keysym1", string "keysym2"
'''Spring.GetKeyBindings'''
( string keyset ) -> nil | { [1] = {[string actionCmd] = string actionExtra}, ... }
'''Spring.GetActionHotKeys'''
( string action ) -> nil | { [1] = string hotKey, ... }

=== Console ===
'''Spring.GetLastMessagePositions'''
( ) -> nil | {
[1] = { number X, number Y, number Z },
...
}
'''Spring.GetConsoleBuffer'''
( [number maxLines] ) -> nil | {
[1] = {
text = string,
priority = number
}, ...
}
'''Spring.GetCurrentTooltip'''
( ) -> string

== FPS & GetDrawFrame ==
'''Spring.GetFPS'''
( ) -> number
'''Spring.GetDrawFrame'''
( ) -> number low 16bit, number high 16bit

== Time ==
'''Spring.GetFrameTimeOffset'''
( ) -> nil | number
'''Spring.GetLastUpdateSeconds'''
( ) -> nil | number
'''Spring.GetHasLag'''
( ) -> boolean
'''Spring.GetTimer'''
( ) -> timer
'''Spring.DiffTimers'''
( timer cur, timer ago) -> number seconds

[[category: Lua]]

Games

2011-02-28T01:24:28Z

Argh: Snipped out references to P.U.R.E. here, no point to having a link to a dead project :-)

{{lang | France | Jeux | FranÃ§ais}}

__NOTOC__There are a number of games made for the Spring Engine. Some of the more popular ones are listed below, sorted by their terms of use. 

=Freeware/Open Source=
''These games are all free to download and play and may be open to modifications, however, be sure to read the licenses before doing so.''
{|
|-
| align="center" | <h2>[http://zero-k.info/ Zero-K]</h2>([http://code.google.com/p/zero-k/source/browse/trunk/mods/zk/legal.txt FOSS])
| width=40 |
| align="center" | <h2>'''[http://www.spring1944.org/ Spring: 1944]'''</h2>([http://spring1944.svn.sourceforge.net/viewvc/spring1944/trunk/S44Main.sdd/docs/License.txt CC-BY-NC])
|-
| align="center" | {{navimgx|xsize=300|ysize=225|image=Zero-k_image.png|link=http://zero-k.info/}}
|
| align="center" |{{navimgx|xsize=300|ysize=225|image=S44_tigers.jpg|link=http://www.spring1944.org}}
|-
| align="justify" valign="top" | Zero-K is a fast, competitive game with a focus on a streamlined economy and advanced interface that takes the focus off tedious tasks and back on the action. A huge roster of interesting, unique units and a variety of unit abilities provides tremendous tactical and strategic depth to the game. [[http://zero-k.info Download link]]
|
| align="justify" valign="top" | Spring:1944 is a WWII themed game with four fully functional sides (US, Germany, USSR, Britain), period-accurate units and strengths. Realism comes second only to creating a game that is fun and accessible to play.
|-
| align="center" | <h2>[http://www.evolutionrts.info Evolution RTS]</h2>([http://redmine.evolutionrts.info/repositories/entry/evolutionrts/Evolution%20RTS%20-%20Creative%20Commons%20Deed.pdf?format=raw CC-BY-NC-ND])
| width=40 |
| align="center" | <h2>[[Kernel Panic]]</h2>([[Kernel_Panic#License:|both proprietary and FOSS content]])
|-
| align="center" | {{navimgx|xsize=300|ysize=188|image=Evoimg.jpg|link=http://www.evolutionrts.info}}
|
| align="center" | {{navimg|xsize=300|ysize=225|image=Kernel_Panic_3.4.jpg|link=Kernel Panic}}
|-
| align="justify" valign="top" | A new war is brewing. A violent conflict, between the Six Colonies, each one convinced that it was in the right, each one sure of its own ability to defeat its enemies. But they need Generals. They need soldiers. They need you.
|
| align="justify" valign="top" | A game based around combat '''inside''' a computer, with 3 unique sides: the System, the Hacker and the Network waging war in a matrix of DOOM! No resource economy exists in KP, with the only constraints being time and space.
|-
| align="center" | <h2>'''[http://www.moddb.com/games/conflict-terra Conflict Terra]'''</h2>([http://code.google.com/p/conflictterra/issues/detail?id=104&q=license&colspec=ID%20Type%20Status%20Priority%20Owner%20Summary Unknown media license])
|
| align="center" | <h2>[[Spring Tanks]]</h2>([http://pastebin.com/pNkBtsb8 undecided, some obscure free license])
|-
| align="center" |{{navimgx|xsize=300|ysize=225|image=Conflict_terra.png|link=http://www.moddb.com/games/conflict-terra}}
|
| align="center" | {{navimg|xsize=300|ysize=221|image=Springtanks_wikipreview.png|link=Spring Tanks}}
|-
| align="justify" valign="top" | Based around the idea of a fictional faction fighting for the domination of Earth, Conflict Terra hopes to achieve balanced, interesting, intuitive and above all fun gameplay that tries to break some of the norms present in other Spring games.[[http://www.moddb.com/games/conflict-terra/downloads Download link]]
|
| align="justify" valign="top" | Some guys decided to attack each other with tanks and you can be one of them.
Build-in Single Player!
|}

=Proprietary=
''These games may or may not be free to play. Modifying their content (i.e. the art assets) is not allowed without the game authors explicit permission, although the code is GPL and some games (P.U.R.E.) include large GPL-friendly content collections.''
{|
|-
| width=40 |
| align="center" | <h2>[http://www.moddb.com/games/gundam-rts/news Gundam RTS]</h2>
|-
|
| align="center" |{{navimgx|xsize=300|ysize=225|image=Screen104.jpg|link=http://www.moddb.com/games/gundam-rts/news}}
|-
|
| align="justify" valign="top" | Set during the One-Year War in the Universal Century timeline of the Gundam Metaseries, Gundam RTS features fast, intense mech combat gameplay in a truly Gundam style.
|}

{|
|-
| align="center" | <h2>[http://www.imperialwinter.com Star Wars: Imperial Winter]</h2>
| width=40 |
| align="center" | <h2>[http://azaremoth.supremedesign.org The Cursed]</h2>
|-
| align="center" | {{navimgx|xsize=300|ysize=225|image=Imperial Winter assault.jpg|link=http://www.imperialwinter.com}}
|
| align="center" |{{navimgx|xsize=300|ysize=225|image=cursed_logo.jpg|link=http://azaremoth.supremedesign.org}}
|-
| align="justify" valign="top" | A Star Wars themed game set in the troubled post-Return of the Jedi era, SW:IW features over a hundred units for the fractured Galactic Empire and Rebel Alliance fighting for control of the galaxy.
|
| align="justify" valign="top" | The unique game is about bones, undead, demons and magic settled in a futuristic environment.[[http://azaremoth.supremedesign.org/data/cursed_latest.zip Download link]]
|}

=TA-derived=
''At least parts of these games are derived from data of the Total Annihilation game (copyright Atari). As such, their distribution is potentially in breach of copyright laws and therefore not officially endorsed by the Spring RTS team.''

{|
|-
| align="center" | <h2>[[Balanced Annihilation]]</h2>
| width=40 |
| align="center" | <h2> [http://www.springfiles.com/spring/games/tech-annihilation-2 Tech Annihilation] </h2>
|-
| align="center" | {{navimg|xsize=300|ysize=225|image=BAScreenShot.jpg|link=Balanced Annihilation}}
|
| align="center" |{{navimgx|xsize=300|ysize=200|image=Tech_Annihilation.png|link=http://www.springfiles.com/spring/games/tech-annihilation-2}}
|-
| align="justify" valign="top" |
Balanced Annihilation (BA) is currently the most popular game played using the Spring engine. BA is a mature game and new versions feature only minor balance tweaks.

BA gameplay develops in stages of progressively heavier units with a growing economy. Many strategies are viable in BA, including focusing on map control, aggression, defense, air power, sea power, or mobility.

|
| align="justify" valign="top" | This Game is bigger, greater and more epic! Tech your Commander from a tiny Commander to a Galactic Commander! (by ''[BoS]Senna'', currently no homepage)
|}

{|
|-
| align="center" | <h2>[[NOTA]]</h2>
| width=40 |
| align="center" | <h2>[[XTA]]</h2>
|-
| align="center" |{{navimg|xsize=300|ysize=225|image=Nota2nukes.jpg|link=NOTA}}
|
| align="center" | {{navimg|xsize=300|ysize=225|image=Screen508_s.jpg|link=XTA}}
|-
| align="justify" valign="top" | Not Original Total Annihilation is a rethink of the Total Annihilation universe with a focus on strategic, base oriented gameplay. With its revised unit scale, huge battles erupt engaging hundreds of units and scores of unit types. NOTA's completely rethought air and sea gameplay forces participation in all elements and places the tide of conflict in your hands.
|
| align="justify" valign="top" | Originally developed as a Total Annihilation game by the Swedish Yankspankers, XTA is the Original Public Game released with first versions of Spring. Development of this game by the SYs has stopped a while ago, but it is still played and actively developed by the community.
|
|}

=Installing Games in Spring=
Quite a few of the games listed above come with standalone installers - which makes things easy (check their website to find out!).

In some cases however, the game will only distribute a "game-file" - in this case you will need to have [[Download|an installation of the Spring-Engine]], and place the file in the .../Spring/games/ folder. If you are using a Lobby, this will often be able to do this for you automatically.

For an overview of information to get started, see the [[FAQ]].

=Game Development=
For information on creating games for the Spring engine, see the [[Game_and_Unit_development|Game Making]] page.

[[Category: Games]]

Lua ConstCOB

2011-02-21T16:28:30Z

Argh: Added note about where to find the equivalent list for COB (for the project devs who never read Spring's source)

[[Engine_Development|Development]] < [[Lua_Scripting|Lua Scripting]] < {{FULLPAGENAME}}

Note: At this time, this list is roughly equivalent to the supported COB instructions at spring / rts / Sim / Units / Scripts / CobDefines.h, but you don't need to use the proper constant values (see Git repo).

= Explode =
'''SFX.SHATTER''' 
'''SFX.EXPLODE''' 
'''SFX.EXPLODE_ON_HIT''' 
'''SFX.FALL''' 
'''SFX.SMOKE''' 
'''SFX.FIRE''' 
'''SFX.NONE''' 
'''SFX.NO_CEG_TRAIL''' 
'''SFX.NO_HEATCLOUD''' 

= EmitSfx =
'''SFX.VTOL''' 
'''SFX.WAKE''' 
'''SFX.REVERSE_WAKE''' 
'''SFX.WHITE_SMOKE''' 
'''SFX.BLACK_SMOKE''' 
'''SFX.BUBBLE''' 
'''SFX.CEG''' 
'''SFX.FIRE_WEAPON''' 
'''SFX.DETONATE_WEAPON''' 

= Get/Set =
'''COB.ACTIVATION''' 
'''COB.STANDINGMOVEORDERS''' 
'''COB.STANDINGFIREORDERS''' 
'''COB.HEALTH''' 
'''COB.INBUILDSTANCE''' 
'''COB.BUSY''' 
'''COB.PIECE_XZ''' 
'''COB.PIECE_Y''' 
'''COB.UNIT_XZ''' 
'''COB.UNIT_Y''' 
'''COB.UNIT_HEIGHT''' 
'''COB.XZ_ATAN''' 
'''COB.XZ_HYPOT''' 
'''COB.ATAN''' 
'''COB.HYPOT''' 
'''COB.GROUND_HEIGHT''' 
'''COB.BUILD_PERCENT_LEFT''' 
'''COB.YARD_OPEN''' 
'''COB.BUGGER_OFF''' 
'''COB.ARMORED''' 
'''COB.IN_WATER''' 
'''COB.CURRENT_SPEED''' 
'''COB.VETERAN_LEVEL''' 
'''COB.ON_ROAD''' 
'''COB.MAX_ID''' 
'''COB.MY_ID''' 
'''COB.UNIT_TEAM''' 
'''COB.UNIT_BUILD_PERCENT_LEFT''' 
'''COB.UNIT_ALLIED''' 
'''COB.MAX_SPEED''' 
'''COB.CLOAKED''' 
'''COB.WANT_CLOAK''' 
'''COB.GROUND_WATER_HEIGHT''' 
'''COB.UPRIGHT''' 
'''COB.POW''' 
'''COB.PRINT''' 
'''COB.HEADING''' 
'''COB.TARGET_ID''' 
'''COB.LAST_ATTACKER_ID''' 
'''COB.LOS_RADIUS''' 
'''COB.AIR_LOS_RADIUS''' 
'''COB.RADAR_RADIUS''' 
'''COB.JAMMER_RADIUS''' 
'''COB.SONAR_RADIUS''' 
'''COB.SONAR_JAM_RADIUS''' 
'''COB.SEISMIC_RADIUS''' 
'''COB.DO_SEISMIC_PING''' 
'''COB.CURRENT_FUEL''' 
'''COB.TRANSPORT_ID''' 
'''COB.SHIELD_POWER''' 
'''COB.STEALTH''' 
'''COB.CRASHING''' 
'''COB.CHANGE_TARGET''' 
'''COB.CEG_DAMAGE''' 
'''COB.COB_ID''' 
'''COB.PLAY_SOUND''' 
'''COB.KILL_UNIT''' 
'''COB.ALPHA_THRESHOLD''' 
'''COB.SET_WEAPON_UNIT_TARGET''' 
'''COB.SET_WEAPON_GROUND_TARGET''' 
'''COB.SONAR_STEALTH''' 
'''COB.REVERSING''' 
'''COB.FLANK_B_MODE''' 
'''COB.FLANK_B_DIR''' 
'''COB.FLANK_B_MOBILITY_ADD''' 
'''COB.FLANK_B_MAX_DAMAGE''' 
'''COB.FLANK_B_MIN_DAMAGE''' 
'''COB.WEAPON_RELOADSTATE''' 
'''COB.WEAPON_RELOADTIME''' 
'''COB.WEAPON_ACCURACY''' 
'''COB.WEAPON_SPRAY''' 
'''COB.WEAPON_RANGE''' 
'''COB.WEAPON_PROJECTILE_SPEED''' 
'''COB.MIN''' 
'''COB.MAX''' 
'''COB.ABS''' 
'''COB.GAME_FRAME''' 

[[category: Lua]]

Google Summer of Code 2010

2010-03-12T04:53:13Z

Argh: /* Proposal: Sensor handling redesign / simplification */

[[Image:GSOC.png]]

= Project proposals =

This is the list of project ideas for students willing to work on the Spring engine during the Google Summer of Code 2010. If you wish, you may read our [[Google_Summer_of_Code_2010_student_application|student application]].

== Proposal: Limited Play Area ==

'''Why:''' Spring uses a finite-world model, where the scene has distinct bounds that all actors must obey. Currently, this system uses a rectangular definition of the bounds, which is not sufficiently flexible for some types of simulation or game designs.

'''What:''' The new system should allow the map's developer to restrict the playable area to a subset of the global area, possibly adding support for multiple shapes and/or non rectangular shape restrictions.

The restriction shapes should be readable and changeable mid-game through the engine's Lua API. Proper handling of Units which are suddenly off-map needs to be implemented.

'''Requirements:''' Understanding of C++ / Lua.

[[GSoC_Limited_play_area]]

== Proposal: Sensor System Redesign ==

'''Why:''' The Spring Engine is currently capable of significant real-world applications in the area of simulation of certain types of events or situations; a better sensor system could greatly improve Spring's applicability to an even wider range of projects.

'''What:''' Currently there are a number of different "sensor" systems in the engine: LineOfSight, Radar, Sonar, and Seismic. Some can be "jammed", some cannot. Some use a LineOfSight algorithm to determine coverage, and some are circular in area.

A new sensor system should integrate the current systems into a streamlined codebase, to reduce amount of code per function, and it should add additional features which would be then available for all types, while improving efficiency where possible.

'''Requirements:''' Understanding of C++ / Lua

[[GSoC_Sensor_handling_redesign]]

== Proposal: Abstraction of Resource System ==

'''Why:''' The Spring engine has its roots in an older Real-Time Strategy title, where only two major resources ("metal" and "energy") were incorporated into the game design.

This model has proven to be too inflexible to support certain types of gameplay, and is an obvious disadvantage to the Spring Engine when it is compared to other available software for constructing certain types of simulations. Furthermore, the use of Lua to support alternative models has not always proven satisfactory to game developers, who may lack the programming experience to build a resource-distribution system from scratch.

'''What:''' Therefore, we propose to write a new, more-flexible system that will support more than two resources, and possibly implement new behavioral models.

'''Requirements:''' Understanding of C++

[[GSoC_Engine_resource_abstraction]]

== Proposal: Ingame Lobby ==

'''Why:''' All existing Spring online player match-making systems ('lobbies') are either difficult to customize for game developers or have a different look and feel from the games which are expected to operate with them. While they are Open Source, and are being actively maintained, they do not provide the same end-user experience one finds in commercial titles.

'''What:''' An in-game Lobby, leveraging the Spring Engine's strong Lua scripting support, should be implemented with customization and control in mind. This may possibly be integrated with Spring's codebase, or it may be designed as a separate process overlaying to the game's UI.

This could also serve as a practical "front end" for the Spring Engine, giving all games developed on the engine a standardized, yet flexible, system to support their players.

'''Requirements:''' Understanding of C++ / Lua

[[GSoC_Ingame_lobby]]

== Proposal: Smarter Pathfinder ==

'''Why:''' Given the Spring Engine's need to routinely handle responsive and bug-free pathfinding and path-following for large numbers of actors, this project could become a useful showcase and useful codebase for projects needing pathfinders, and could expand the world's understanding of pathfinding and path-following in realtime systems.

'''What:''' Spring's current pathfinder uses a 2d grid and is somewhat limited in functionality.
A partial/full rewrite should be introduced to add support for navigating using more than 8 primary directions and selectively ignore certain unit types for performance reasons.

Spring's Lua API should be extended to allow game developers to push new nodes/links and be able to alter or delete existing ones (for pathfinder-aware tunnels/teleporting/etc.).

Preferably this should all be faster than the current system, or a compelling argument/experiment should be made that shows there cannot be a faster system with the same features.

'''Requirements:''' Understanding of C++; moderate understanding of pathfinding / following concepts and coding strategies

[[GSoC_Smarter_pathfinder]]

== Proposal: More AI interfaces ==

'''Why:''' The Spring Engine is already a popular engine for academic projects to study Artificial Intelligence, given the Open Source model of development and strong support within the A.I. community. This project could enhance Spring's attractiveness to developers and teachers wanting to explore or teach about A.I.

'''What:''' The Spring engine's A.I. interface supports bindings for multiple languages. Currently C++, C and java are supported, and AIs may be constructed using Lua.

We propose to add more bindings for more languages and/or virtual machines would be added, to allow broader AI developing audience (for example: Ruby, Perl, JavaScript, Python, D, Go, Mono, LLVM, Parrot).

'''Requirements:''' Understanding of C++; understanding of the languages to be binded to

[[GSoC_More_AI_interfaces]]

== Proposal: Improved Rendering System ==

'''Why:''' The Spring Engine's rendering system remains near the cutting edge of practical, functional OpenGL in a realtime environment, and is certainly notable amongst free, Open Source projects for its realism and flexibility. While it is not as advanced as the latest commercial engines, Spring's developers have made great strides in the last year, adding significant new features to the engine.

However, the core Spring rendering engine still includes many fixed function pipeline OpenGL functions. This rendering system is becoming deprecated and is generally slower and less flexible than more modern approaches.

'''What:''' Under this proposal, the rendering pipeline would be given a complete overhaul using modern graphic programming techniques, including shaders, standardised model formats that are easier for new artists to adapt to, and other enhancements, such as bump mapping, normal mapping, and multiple textures per Unit, while utilizing code that adheres to the OpenGL ES 2.0 specification.

'''Requirements:''' Understanding of C++ and some experience with modern rendering concepts.

[[GSoC_New_rendering_system]]

== Proposal: Resumption of Desynchronised Client States ==

'''Why:''' Spring's network model implies the existence of a server to host a battle. For various reasons the network link between host and clients can be interrupted, or "desync". This causes an end-user to lose the true state of the simulation, and is a significant problem for players.

'''What:''' Our proposal is that a new system should be designed to allow manual and/or automatic switching of the game's host (possibly using an existing player's state, after testing load handling capabilities) and manual and/or automatic reconnection from client side if host remains the same.

'''Requirements:''' Understanding of C++; some expertise of networking concepts is required

[[GSoC_Reconnect_Host_change]]

Google Summer of Code 2010

2010-03-12T04:52:44Z

Argh: /* Proposal: Smarter pathfinder */

[[Image:GSOC.png]]

= Project proposals =

This is the list of project ideas for students willing to work on the Spring engine during the Google Summer of Code 2010. If you wish, you may read our [[Google_Summer_of_Code_2010_student_application|student application]].

== Proposal: Limited Play Area ==

'''Why:''' Spring uses a finite-world model, where the scene has distinct bounds that all actors must obey. Currently, this system uses a rectangular definition of the bounds, which is not sufficiently flexible for some types of simulation or game designs.

'''What:''' The new system should allow the map's developer to restrict the playable area to a subset of the global area, possibly adding support for multiple shapes and/or non rectangular shape restrictions.

The restriction shapes should be readable and changeable mid-game through the engine's Lua API. Proper handling of Units which are suddenly off-map needs to be implemented.

'''Requirements:''' Understanding of C++ / Lua.

[[GSoC_Limited_play_area]]

== Proposal: Sensor handling redesign / simplification ==

'''Why:''' The Spring Engine is currently capable of significant real-world applications in the area of simulation of certain types of events or situations; a better sensor system could greatly improve Spring's applicability to an even wider range of projects.

'''What:''' Currently there are a number of different "sensor" systems in the engine: LineOfSight, Radar, Sonar, and Seismic. Some can be "jammed", some cannot. Some use a LineOfSight algorithm to determine coverage, and some are circular in area.

A new sensor system should integrate the current systems into a streamlined codebase, to reduce amount of code per function, and it should add additional features which would be then available for all types, while improving efficiency where possible.

'''Requirements:''' Understanding of C++ / Lua

[[GSoC_Sensor_handling_redesign]]

== Proposal: Abstraction of Resource System ==

'''Why:''' The Spring engine has its roots in an older Real-Time Strategy title, where only two major resources ("metal" and "energy") were incorporated into the game design.

This model has proven to be too inflexible to support certain types of gameplay, and is an obvious disadvantage to the Spring Engine when it is compared to other available software for constructing certain types of simulations. Furthermore, the use of Lua to support alternative models has not always proven satisfactory to game developers, who may lack the programming experience to build a resource-distribution system from scratch.

'''What:''' Therefore, we propose to write a new, more-flexible system that will support more than two resources, and possibly implement new behavioral models.

'''Requirements:''' Understanding of C++

[[GSoC_Engine_resource_abstraction]]

== Proposal: Ingame Lobby ==

'''Why:''' All existing Spring online player match-making systems ('lobbies') are either difficult to customize for game developers or have a different look and feel from the games which are expected to operate with them. While they are Open Source, and are being actively maintained, they do not provide the same end-user experience one finds in commercial titles.

'''What:''' An in-game Lobby, leveraging the Spring Engine's strong Lua scripting support, should be implemented with customization and control in mind. This may possibly be integrated with Spring's codebase, or it may be designed as a separate process overlaying to the game's UI.

This could also serve as a practical "front end" for the Spring Engine, giving all games developed on the engine a standardized, yet flexible, system to support their players.

'''Requirements:''' Understanding of C++ / Lua

[[GSoC_Ingame_lobby]]

== Proposal: Smarter Pathfinder ==

'''Why:''' Given the Spring Engine's need to routinely handle responsive and bug-free pathfinding and path-following for large numbers of actors, this project could become a useful showcase and useful codebase for projects needing pathfinders, and could expand the world's understanding of pathfinding and path-following in realtime systems.

'''What:''' Spring's current pathfinder uses a 2d grid and is somewhat limited in functionality.
A partial/full rewrite should be introduced to add support for navigating using more than 8 primary directions and selectively ignore certain unit types for performance reasons.

Spring's Lua API should be extended to allow game developers to push new nodes/links and be able to alter or delete existing ones (for pathfinder-aware tunnels/teleporting/etc.).

Preferably this should all be faster than the current system, or a compelling argument/experiment should be made that shows there cannot be a faster system with the same features.

'''Requirements:''' Understanding of C++; moderate understanding of pathfinding / following concepts and coding strategies

[[GSoC_Smarter_pathfinder]]

== Proposal: More AI interfaces ==

'''Why:''' The Spring Engine is already a popular engine for academic projects to study Artificial Intelligence, given the Open Source model of development and strong support within the A.I. community. This project could enhance Spring's attractiveness to developers and teachers wanting to explore or teach about A.I.

'''What:''' The Spring engine's A.I. interface supports bindings for multiple languages. Currently C++, C and java are supported, and AIs may be constructed using Lua.

We propose to add more bindings for more languages and/or virtual machines would be added, to allow broader AI developing audience (for example: Ruby, Perl, JavaScript, Python, D, Go, Mono, LLVM, Parrot).

'''Requirements:''' Understanding of C++; understanding of the languages to be binded to

[[GSoC_More_AI_interfaces]]

== Proposal: Improved Rendering System ==

'''Why:''' The Spring Engine's rendering system remains near the cutting edge of practical, functional OpenGL in a realtime environment, and is certainly notable amongst free, Open Source projects for its realism and flexibility. While it is not as advanced as the latest commercial engines, Spring's developers have made great strides in the last year, adding significant new features to the engine.

However, the core Spring rendering engine still includes many fixed function pipeline OpenGL functions. This rendering system is becoming deprecated and is generally slower and less flexible than more modern approaches.

'''What:''' Under this proposal, the rendering pipeline would be given a complete overhaul using modern graphic programming techniques, including shaders, standardised model formats that are easier for new artists to adapt to, and other enhancements, such as bump mapping, normal mapping, and multiple textures per Unit, while utilizing code that adheres to the OpenGL ES 2.0 specification.

'''Requirements:''' Understanding of C++ and some experience with modern rendering concepts.

[[GSoC_New_rendering_system]]

== Proposal: Resumption of Desynchronised Client States ==

'''Why:''' Spring's network model implies the existence of a server to host a battle. For various reasons the network link between host and clients can be interrupted, or "desync". This causes an end-user to lose the true state of the simulation, and is a significant problem for players.

'''What:''' Our proposal is that a new system should be designed to allow manual and/or automatic switching of the game's host (possibly using an existing player's state, after testing load handling capabilities) and manual and/or automatic reconnection from client side if host remains the same.

'''Requirements:''' Understanding of C++; some expertise of networking concepts is required

[[GSoC_Reconnect_Host_change]]

Google Summer of Code 2010

2010-03-12T04:49:17Z

Argh: /* Limited Play Area */

[[Image:GSOC.png]]

= Project proposals =

This is the list of project ideas for students willing to work on the Spring engine during the Google Summer of Code 2010. If you wish, you may read our [[Google_Summer_of_Code_2010_student_application|student application]].

== Proposal: Limited Play Area ==

'''Why:''' Spring uses a finite-world model, where the scene has distinct bounds that all actors must obey. Currently, this system uses a rectangular definition of the bounds, which is not sufficiently flexible for some types of simulation or game designs.

'''What:''' The new system should allow the map's developer to restrict the playable area to a subset of the global area, possibly adding support for multiple shapes and/or non rectangular shape restrictions.

The restriction shapes should be readable and changeable mid-game through the engine's Lua API. Proper handling of Units which are suddenly off-map needs to be implemented.

'''Requirements:''' Understanding of C++ / Lua.

[[GSoC_Limited_play_area]]

== Proposal: Sensor handling redesign / simplification ==

'''Why:''' The Spring Engine is currently capable of significant real-world applications in the area of simulation of certain types of events or situations; a better sensor system could greatly improve Spring's applicability to an even wider range of projects.

'''What:''' Currently there are a number of different "sensor" systems in the engine: LineOfSight, Radar, Sonar, and Seismic. Some can be "jammed", some cannot. Some use a LineOfSight algorithm to determine coverage, and some are circular in area.

A new sensor system should integrate the current systems into a streamlined codebase, to reduce amount of code per function, and it should add additional features which would be then available for all types, while improving efficiency where possible.

'''Requirements:''' Understanding of C++ / Lua

[[GSoC_Sensor_handling_redesign]]

== Proposal: Abstraction of Resource System ==

'''Why:''' The Spring engine has its roots in an older Real-Time Strategy title, where only two major resources ("metal" and "energy") were incorporated into the game design.

This model has proven to be too inflexible to support certain types of gameplay, and is an obvious disadvantage to the Spring Engine when it is compared to other available software for constructing certain types of simulations. Furthermore, the use of Lua to support alternative models has not always proven satisfactory to game developers, who may lack the programming experience to build a resource-distribution system from scratch.

'''What:''' Therefore, we propose to write a new, more-flexible system that will support more than two resources, and possibly implement new behavioral models.

'''Requirements:''' Understanding of C++

[[GSoC_Engine_resource_abstraction]]

== Proposal: Ingame Lobby ==

'''Why:''' All existing Spring online player match-making systems ('lobbies') are either difficult to customize for game developers or have a different look and feel from the games which are expected to operate with them. While they are Open Source, and are being actively maintained, they do not provide the same end-user experience one finds in commercial titles.

'''What:''' An in-game Lobby, leveraging the Spring Engine's strong Lua scripting support, should be implemented with customization and control in mind. This may possibly be integrated with Spring's codebase, or it may be designed as a separate process overlaying to the game's UI.

This could also serve as a practical "front end" for the Spring Engine, giving all games developed on the engine a standardized, yet flexible, system to support their players.

'''Requirements:''' Understanding of C++ / Lua

[[GSoC_Ingame_lobby]]

== Proposal: Smarter pathfinder ==

'''Why:''' Given the Spring Engine's need to routinely handle responsive and bug-free pathfinding and path-following for large numbers of actors, this project could become a useful showcase and useful codebase for projects needing pathfinders, and could expand the world's understanding of pathfinding and path-following in realtime systems.

'''What:''' Spring's current pathfinder uses a 2d grid and is somewhat limited in functionality.
A partial/full rewrite should be introduced to add support for navigating using more than 8 primary directions and selectively ignore certain unit types for performance reasons.

Spring's Lua API should be extended to allow game developers to push new nodes/links and be able to alter or delete existing ones (for pathfinder-aware tunnels/teleporting/etc.).

Preferably this should all be faster than the current system, or a compelling argument/experiment should be made that shows there cannot be a faster system with the same features.

'''Requirements:''' Understanding of C++; moderate understanding of pathfinding / following concepts and coding strategies

[[GSoC_Smarter_pathfinder]]

== Proposal: More AI interfaces ==

'''Why:''' The Spring Engine is already a popular engine for academic projects to study Artificial Intelligence, given the Open Source model of development and strong support within the A.I. community. This project could enhance Spring's attractiveness to developers and teachers wanting to explore or teach about A.I.

'''What:''' The Spring engine's A.I. interface supports bindings for multiple languages. Currently C++, C and java are supported, and AIs may be constructed using Lua.

We propose to add more bindings for more languages and/or virtual machines would be added, to allow broader AI developing audience (for example: Ruby, Perl, JavaScript, Python, D, Go, Mono, LLVM, Parrot).

'''Requirements:''' Understanding of C++; understanding of the languages to be binded to

[[GSoC_More_AI_interfaces]]

== Proposal: Improved Rendering System ==

'''Why:''' The Spring Engine's rendering system remains near the cutting edge of practical, functional OpenGL in a realtime environment, and is certainly notable amongst free, Open Source projects for its realism and flexibility. While it is not as advanced as the latest commercial engines, Spring's developers have made great strides in the last year, adding significant new features to the engine.

However, the core Spring rendering engine still includes many fixed function pipeline OpenGL functions. This rendering system is becoming deprecated and is generally slower and less flexible than more modern approaches.

'''What:''' Under this proposal, the rendering pipeline would be given a complete overhaul using modern graphic programming techniques, including shaders, standardised model formats that are easier for new artists to adapt to, and other enhancements, such as bump mapping, normal mapping, and multiple textures per Unit, while utilizing code that adheres to the OpenGL ES 2.0 specification.

'''Requirements:''' Understanding of C++ and some experience with modern rendering concepts.

[[GSoC_New_rendering_system]]

== Proposal: Resumption of Desynchronised Client States ==

'''Why:''' Spring's network model implies the existence of a server to host a battle. For various reasons the network link between host and clients can be interrupted, or "desync". This causes an end-user to lose the true state of the simulation, and is a significant problem for players.

'''What:''' Our proposal is that a new system should be designed to allow manual and/or automatic switching of the game's host (possibly using an existing player's state, after testing load handling capabilities) and manual and/or automatic reconnection from client side if host remains the same.

'''Requirements:''' Understanding of C++; some expertise of networking concepts is required

[[GSoC_Reconnect_Host_change]]

Google Summer of Code 2010

2010-03-12T04:41:21Z

Argh: /* Reconnect / Host change during a match */

[[Image:GSOC.png]]

= Project proposals =

This is the list of project ideas for students willing to work on the Spring engine during the Google Summer of Code 2010. If you wish, you may read our [[Google_Summer_of_Code_2010_student_application|student application]].

== Limited Play Area ==

Estimated difficulty: '''Medium'''

Spring uses a finite-world model, where the scene has distinct bounds that all actors must obey. Currently, this system uses a rectangular definition of the bounds, which is not sufficiently flexible for some types of simulation or game designs.

The new system should allow the map's developer to restrict the playable area to a subset of the global area, possibly adding support for multiple shapes and/or non rectangular shape restrictions.

The restriction shapes should be readable and changeable mid-game through the engine's Lua API. Proper handling of Units which are suddenly off-map needs to be implemented.

[[GSoC_Limited_play_area]]

== Proposal: Sensor handling redesign / simplification ==

'''Why:''' The Spring Engine is currently capable of significant real-world applications in the area of simulation of certain types of events or situations; a better sensor system could greatly improve Spring's applicability to an even wider range of projects.

'''What:''' Currently there are a number of different "sensor" systems in the engine: LineOfSight, Radar, Sonar, and Seismic. Some can be "jammed", some cannot. Some use a LineOfSight algorithm to determine coverage, and some are circular in area.

A new sensor system should integrate the current systems into a streamlined codebase, to reduce amount of code per function, and it should add additional features which would be then available for all types, while improving efficiency where possible.

'''Requirements:''' Understanding of C++ / Lua

[[GSoC_Sensor_handling_redesign]]

== Proposal: Abstraction of Resource System ==

'''Why:''' The Spring engine has its roots in an older Real-Time Strategy title, where only two major resources ("metal" and "energy") were incorporated into the game design.

This model has proven to be too inflexible to support certain types of gameplay, and is an obvious disadvantage to the Spring Engine when it is compared to other available software for constructing certain types of simulations. Furthermore, the use of Lua to support alternative models has not always proven satisfactory to game developers, who may lack the programming experience to build a resource-distribution system from scratch.

'''What:''' Therefore, we propose to write a new, more-flexible system that will support more than two resources, and possibly implement new behavioral models.

'''Requirements:''' Understanding of C++

[[GSoC_Engine_resource_abstraction]]

== Proposal: Ingame Lobby ==

'''Why:''' All existing Spring online player match-making systems ('lobbies') are either difficult to customize for game developers or have a different look and feel from the games which are expected to operate with them. While they are Open Source, and are being actively maintained, they do not provide the same end-user experience one finds in commercial titles.

'''What:''' An in-game Lobby, leveraging the Spring Engine's strong Lua scripting support, should be implemented with customization and control in mind. This may possibly be integrated with Spring's codebase, or it may be designed as a separate process overlaying to the game's UI.

This could also serve as a practical "front end" for the Spring Engine, giving all games developed on the engine a standardized, yet flexible, system to support their players.

'''Requirements:''' Understanding of C++ / Lua

[[GSoC_Ingame_lobby]]

== Proposal: Smarter pathfinder ==

'''Why:''' Given the Spring Engine's need to routinely handle responsive and bug-free pathfinding and path-following for large numbers of actors, this project could become a useful showcase and useful codebase for projects needing pathfinders, and could expand the world's understanding of pathfinding and path-following in realtime systems.

'''What:''' Spring's current pathfinder uses a 2d grid and is somewhat limited in functionality.
A partial/full rewrite should be introduced to add support for navigating using more than 8 primary directions and selectively ignore certain unit types for performance reasons.

Spring's Lua API should be extended to allow game developers to push new nodes/links and be able to alter or delete existing ones (for pathfinder-aware tunnels/teleporting/etc.).

Preferably this should all be faster than the current system, or a compelling argument/experiment should be made that shows there cannot be a faster system with the same features.

'''Requirements:''' Understanding of C++; moderate understanding of pathfinding / following concepts and coding strategies

[[GSoC_Smarter_pathfinder]]

== Proposal: More AI interfaces ==

'''Why:''' The Spring Engine is already a popular engine for academic projects to study Artificial Intelligence, given the Open Source model of development and strong support within the A.I. community. This project could enhance Spring's attractiveness to developers and teachers wanting to explore or teach about A.I.

'''What:''' The Spring engine's A.I. interface supports bindings for multiple languages. Currently C++, C and java are supported, and AIs may be constructed using Lua.

We propose to add more bindings for more languages and/or virtual machines would be added, to allow broader AI developing audience (for example: Ruby, Perl, JavaScript, Python, D, Go, Mono, LLVM, Parrot).

'''Requirements:''' Understanding of C++; understanding of the languages to be binded to

[[GSoC_More_AI_interfaces]]

== Proposal: Improved Rendering System ==

'''Why:''' The Spring Engine's rendering system remains near the cutting edge of practical, functional OpenGL in a realtime environment, and is certainly notable amongst free, Open Source projects for its realism and flexibility. While it is not as advanced as the latest commercial engines, Spring's developers have made great strides in the last year, adding significant new features to the engine.

However, the core Spring rendering engine still includes many fixed function pipeline OpenGL functions. This rendering system is becoming deprecated and is generally slower and less flexible than more modern approaches.

'''What:''' Under this proposal, the rendering pipeline would be given a complete overhaul using modern graphic programming techniques, including shaders, standardised model formats that are easier for new artists to adapt to, and other enhancements, such as bump mapping, normal mapping, and multiple textures per Unit, while utilizing code that adheres to the OpenGL ES 2.0 specification.

'''Requirements:''' Understanding of C++ and some experience with modern rendering concepts.

[[GSoC_New_rendering_system]]

== Proposal: Resumption of Desynchronised Client States ==

'''Why:''' Spring's network model implies the existence of a server to host a battle. For various reasons the network link between host and clients can be interrupted, or "desync". This causes an end-user to lose the true state of the simulation, and is a significant problem for players.

'''What:''' Our proposal is that a new system should be designed to allow manual and/or automatic switching of the game's host (possibly using an existing player's state, after testing load handling capabilities) and manual and/or automatic reconnection from client side if host remains the same.

'''Requirements:''' Understanding of C++; some expertise of networking concepts is required

[[GSoC_Reconnect_Host_change]]

Google Summer of Code 2010

2010-03-12T04:39:29Z

Argh: /* New Rendering System */

[[Image:GSOC.png]]

= Project proposals =

This is the list of project ideas for students willing to work on the Spring engine during the Google Summer of Code 2010. If you wish, you may read our [[Google_Summer_of_Code_2010_student_application|student application]].

== Limited Play Area ==

Estimated difficulty: '''Medium'''

Spring uses a finite-world model, where the scene has distinct bounds that all actors must obey. Currently, this system uses a rectangular definition of the bounds, which is not sufficiently flexible for some types of simulation or game designs.

The new system should allow the map's developer to restrict the playable area to a subset of the global area, possibly adding support for multiple shapes and/or non rectangular shape restrictions.

The restriction shapes should be readable and changeable mid-game through the engine's Lua API. Proper handling of Units which are suddenly off-map needs to be implemented.

[[GSoC_Limited_play_area]]

== Proposal: Sensor handling redesign / simplification ==

'''Why:''' The Spring Engine is currently capable of significant real-world applications in the area of simulation of certain types of events or situations; a better sensor system could greatly improve Spring's applicability to an even wider range of projects.

'''What:''' Currently there are a number of different "sensor" systems in the engine: LineOfSight, Radar, Sonar, and Seismic. Some can be "jammed", some cannot. Some use a LineOfSight algorithm to determine coverage, and some are circular in area.

A new sensor system should integrate the current systems into a streamlined codebase, to reduce amount of code per function, and it should add additional features which would be then available for all types, while improving efficiency where possible.

'''Requirements:''' Understanding of C++ / Lua

[[GSoC_Sensor_handling_redesign]]

== Proposal: Abstraction of Resource System ==

'''Why:''' The Spring engine has its roots in an older Real-Time Strategy title, where only two major resources ("metal" and "energy") were incorporated into the game design.

This model has proven to be too inflexible to support certain types of gameplay, and is an obvious disadvantage to the Spring Engine when it is compared to other available software for constructing certain types of simulations. Furthermore, the use of Lua to support alternative models has not always proven satisfactory to game developers, who may lack the programming experience to build a resource-distribution system from scratch.

'''What:''' Therefore, we propose to write a new, more-flexible system that will support more than two resources, and possibly implement new behavioral models.

'''Requirements:''' Understanding of C++

[[GSoC_Engine_resource_abstraction]]

== Proposal: Ingame Lobby ==

'''Why:''' All existing Spring online player match-making systems ('lobbies') are either difficult to customize for game developers or have a different look and feel from the games which are expected to operate with them. While they are Open Source, and are being actively maintained, they do not provide the same end-user experience one finds in commercial titles.

'''What:''' An in-game Lobby, leveraging the Spring Engine's strong Lua scripting support, should be implemented with customization and control in mind. This may possibly be integrated with Spring's codebase, or it may be designed as a separate process overlaying to the game's UI.

This could also serve as a practical "front end" for the Spring Engine, giving all games developed on the engine a standardized, yet flexible, system to support their players.

'''Requirements:''' Understanding of C++ / Lua

[[GSoC_Ingame_lobby]]

== Proposal: Smarter pathfinder ==

'''Why:''' Given the Spring Engine's need to routinely handle responsive and bug-free pathfinding and path-following for large numbers of actors, this project could become a useful showcase and useful codebase for projects needing pathfinders, and could expand the world's understanding of pathfinding and path-following in realtime systems.

'''What:''' Spring's current pathfinder uses a 2d grid and is somewhat limited in functionality.
A partial/full rewrite should be introduced to add support for navigating using more than 8 primary directions and selectively ignore certain unit types for performance reasons.

Spring's Lua API should be extended to allow game developers to push new nodes/links and be able to alter or delete existing ones (for pathfinder-aware tunnels/teleporting/etc.).

Preferably this should all be faster than the current system, or a compelling argument/experiment should be made that shows there cannot be a faster system with the same features.

'''Requirements:''' Understanding of C++; moderate understanding of pathfinding / following concepts and coding strategies

[[GSoC_Smarter_pathfinder]]

== Proposal: More AI interfaces ==

'''Why:''' The Spring Engine is already a popular engine for academic projects to study Artificial Intelligence, given the Open Source model of development and strong support within the A.I. community. This project could enhance Spring's attractiveness to developers and teachers wanting to explore or teach about A.I.

'''What:''' The Spring engine's A.I. interface supports bindings for multiple languages. Currently C++, C and java are supported, and AIs may be constructed using Lua.

We propose to add more bindings for more languages and/or virtual machines would be added, to allow broader AI developing audience (for example: Ruby, Perl, JavaScript, Python, D, Go, Mono, LLVM, Parrot).

'''Requirements:''' Understanding of C++; understanding of the languages to be binded to

[[GSoC_More_AI_interfaces]]

== Proposal: Improved Rendering System ==

'''Why:''' The Spring Engine's rendering system remains near the cutting edge of practical, functional OpenGL in a realtime environment, and is certainly notable amongst free, Open Source projects for its realism and flexibility. While it is not as advanced as the latest commercial engines, Spring's developers have made great strides in the last year, adding significant new features to the engine.

However, the core Spring rendering engine still includes many fixed function pipeline OpenGL functions. This rendering system is becoming deprecated and is generally slower and less flexible than more modern approaches.

'''What:''' Under this proposal, the rendering pipeline would be given a complete overhaul using modern graphic programming techniques, including shaders, standardised model formats that are easier for new artists to adapt to, and other enhancements, such as bump mapping, normal mapping, and multiple textures per Unit, while utilizing code that adheres to the OpenGL ES 2.0 specification.

'''Requirements:''' Understanding of C++ and some experience with modern rendering concepts.

[[GSoC_New_rendering_system]]

== Reconnect / Host change during a match ==

Estimated difficulty: '''Hard'''

Spring's network model implies the existence of a server to host a battle. For various reasons the network link between host and clients can be interrupted, or "desync". This causes an end-user to lose the true state of the simulation, and is a significant problem for players.

Our proposal is that a new system should be designed to allow manual and/or automatic switching of the game's host (possibly using an existing player's state, after testing load handling capabilities) and manual and/or automatic reconnection from client side if host remains the same.

[[GSoC_Reconnect_Host_change]]

Google Summer of Code 2010

2010-03-12T04:38:26Z

Argh: /* Smarter pathfinder */

[[Image:GSOC.png]]

= Project proposals =

This is the list of project ideas for students willing to work on the Spring engine during the Google Summer of Code 2010. If you wish, you may read our [[Google_Summer_of_Code_2010_student_application|student application]].

== Limited Play Area ==

Estimated difficulty: '''Medium'''

Spring uses a finite-world model, where the scene has distinct bounds that all actors must obey. Currently, this system uses a rectangular definition of the bounds, which is not sufficiently flexible for some types of simulation or game designs.

The new system should allow the map's developer to restrict the playable area to a subset of the global area, possibly adding support for multiple shapes and/or non rectangular shape restrictions.

The restriction shapes should be readable and changeable mid-game through the engine's Lua API. Proper handling of Units which are suddenly off-map needs to be implemented.

[[GSoC_Limited_play_area]]

== Proposal: Sensor handling redesign / simplification ==

'''Why:''' The Spring Engine is currently capable of significant real-world applications in the area of simulation of certain types of events or situations; a better sensor system could greatly improve Spring's applicability to an even wider range of projects.

'''What:''' Currently there are a number of different "sensor" systems in the engine: LineOfSight, Radar, Sonar, and Seismic. Some can be "jammed", some cannot. Some use a LineOfSight algorithm to determine coverage, and some are circular in area.

A new sensor system should integrate the current systems into a streamlined codebase, to reduce amount of code per function, and it should add additional features which would be then available for all types, while improving efficiency where possible.

'''Requirements:''' Understanding of C++ / Lua

[[GSoC_Sensor_handling_redesign]]

== Proposal: Abstraction of Resource System ==

'''Why:''' The Spring engine has its roots in an older Real-Time Strategy title, where only two major resources ("metal" and "energy") were incorporated into the game design.

This model has proven to be too inflexible to support certain types of gameplay, and is an obvious disadvantage to the Spring Engine when it is compared to other available software for constructing certain types of simulations. Furthermore, the use of Lua to support alternative models has not always proven satisfactory to game developers, who may lack the programming experience to build a resource-distribution system from scratch.

'''What:''' Therefore, we propose to write a new, more-flexible system that will support more than two resources, and possibly implement new behavioral models.

'''Requirements:''' Understanding of C++

[[GSoC_Engine_resource_abstraction]]

== Proposal: Ingame Lobby ==

'''Why:''' All existing Spring online player match-making systems ('lobbies') are either difficult to customize for game developers or have a different look and feel from the games which are expected to operate with them. While they are Open Source, and are being actively maintained, they do not provide the same end-user experience one finds in commercial titles.

'''What:''' An in-game Lobby, leveraging the Spring Engine's strong Lua scripting support, should be implemented with customization and control in mind. This may possibly be integrated with Spring's codebase, or it may be designed as a separate process overlaying to the game's UI.

This could also serve as a practical "front end" for the Spring Engine, giving all games developed on the engine a standardized, yet flexible, system to support their players.

'''Requirements:''' Understanding of C++ / Lua

[[GSoC_Ingame_lobby]]

== Proposal: Smarter pathfinder ==

'''Why:''' Given the Spring Engine's need to routinely handle responsive and bug-free pathfinding and path-following for large numbers of actors, this project could become a useful showcase and useful codebase for projects needing pathfinders, and could expand the world's understanding of pathfinding and path-following in realtime systems.

'''What:''' Spring's current pathfinder uses a 2d grid and is somewhat limited in functionality.
A partial/full rewrite should be introduced to add support for navigating using more than 8 primary directions and selectively ignore certain unit types for performance reasons.

Spring's Lua API should be extended to allow game developers to push new nodes/links and be able to alter or delete existing ones (for pathfinder-aware tunnels/teleporting/etc.).

Preferably this should all be faster than the current system, or a compelling argument/experiment should be made that shows there cannot be a faster system with the same features.

'''Requirements:''' Understanding of C++; moderate understanding of pathfinding / following concepts and coding strategies

[[GSoC_Smarter_pathfinder]]

== Proposal: More AI interfaces ==

'''Why:''' The Spring Engine is already a popular engine for academic projects to study Artificial Intelligence, given the Open Source model of development and strong support within the A.I. community. This project could enhance Spring's attractiveness to developers and teachers wanting to explore or teach about A.I.

'''What:''' The Spring engine's A.I. interface supports bindings for multiple languages. Currently C++, C and java are supported, and AIs may be constructed using Lua.

We propose to add more bindings for more languages and/or virtual machines would be added, to allow broader AI developing audience (for example: Ruby, Perl, JavaScript, Python, D, Go, Mono, LLVM, Parrot).

'''Requirements:''' Understanding of C++; understanding of the languages to be binded to

[[GSoC_More_AI_interfaces]]

== New Rendering System ==

Estimated difficulty: '''Medium'''

The Spring Engine's rendering system remains near the cutting edge of practical, functional OpenGL in a realtime environment, and is certainly notable amongst free, Open Source projects for its realism and flexibility. While it is not as advanced as the latest commercial engines, Spring's developers have made great strides in the last year, adding significant new features to the engine.

However, the core Spring rendering engine still includes many fixed function pipeline OpenGL functions. This rendering system is becoming deprecated and is generally slower and less flexible than more modern approaches.

Under this proposal, the rendering pipeline would be given a complete overhaul using modern graphic programming techniques, including shaders, standardised model formats that are easier for new artists to adapt to, and other enhancements, such as bump mapping, normal mapping, and multiple textures per Unit, while utilizing code that adheres to the OpenGL ES 2.0 specification.

[[GSoC_New_rendering_system]]

== Reconnect / Host change during a match ==

Estimated difficulty: '''Hard'''

Spring's network model implies the existence of a server to host a battle. For various reasons the network link between host and clients can be interrupted, or "desync". This causes an end-user to lose the true state of the simulation, and is a significant problem for players.

Our proposal is that a new system should be designed to allow manual and/or automatic switching of the game's host (possibly using an existing player's state, after testing load handling capabilities) and manual and/or automatic reconnection from client side if host remains the same.

[[GSoC_Reconnect_Host_change]]

Google Summer of Code 2010

2010-03-12T04:38:07Z

Argh: /* More AI interfaces */

[[Image:GSOC.png]]

= Project proposals =

This is the list of project ideas for students willing to work on the Spring engine during the Google Summer of Code 2010. If you wish, you may read our [[Google_Summer_of_Code_2010_student_application|student application]].

== Limited Play Area ==

Estimated difficulty: '''Medium'''

Spring uses a finite-world model, where the scene has distinct bounds that all actors must obey. Currently, this system uses a rectangular definition of the bounds, which is not sufficiently flexible for some types of simulation or game designs.

The new system should allow the map's developer to restrict the playable area to a subset of the global area, possibly adding support for multiple shapes and/or non rectangular shape restrictions.

The restriction shapes should be readable and changeable mid-game through the engine's Lua API. Proper handling of Units which are suddenly off-map needs to be implemented.

[[GSoC_Limited_play_area]]

== Proposal: Sensor handling redesign / simplification ==

'''Why:''' The Spring Engine is currently capable of significant real-world applications in the area of simulation of certain types of events or situations; a better sensor system could greatly improve Spring's applicability to an even wider range of projects.

'''What:''' Currently there are a number of different "sensor" systems in the engine: LineOfSight, Radar, Sonar, and Seismic. Some can be "jammed", some cannot. Some use a LineOfSight algorithm to determine coverage, and some are circular in area.

A new sensor system should integrate the current systems into a streamlined codebase, to reduce amount of code per function, and it should add additional features which would be then available for all types, while improving efficiency where possible.

'''Requirements:''' Understanding of C++ / Lua

[[GSoC_Sensor_handling_redesign]]

== Proposal: Abstraction of Resource System ==

'''Why:''' The Spring engine has its roots in an older Real-Time Strategy title, where only two major resources ("metal" and "energy") were incorporated into the game design.

This model has proven to be too inflexible to support certain types of gameplay, and is an obvious disadvantage to the Spring Engine when it is compared to other available software for constructing certain types of simulations. Furthermore, the use of Lua to support alternative models has not always proven satisfactory to game developers, who may lack the programming experience to build a resource-distribution system from scratch.

'''What:''' Therefore, we propose to write a new, more-flexible system that will support more than two resources, and possibly implement new behavioral models.

'''Requirements:''' Understanding of C++

[[GSoC_Engine_resource_abstraction]]

== Proposal: Ingame Lobby ==

'''Why:''' All existing Spring online player match-making systems ('lobbies') are either difficult to customize for game developers or have a different look and feel from the games which are expected to operate with them. While they are Open Source, and are being actively maintained, they do not provide the same end-user experience one finds in commercial titles.

'''What:''' An in-game Lobby, leveraging the Spring Engine's strong Lua scripting support, should be implemented with customization and control in mind. This may possibly be integrated with Spring's codebase, or it may be designed as a separate process overlaying to the game's UI.

This could also serve as a practical "front end" for the Spring Engine, giving all games developed on the engine a standardized, yet flexible, system to support their players.

'''Requirements:''' Understanding of C++ / Lua

[[GSoC_Ingame_lobby]]

== Smarter pathfinder ==

'''Why:''' Given the Spring Engine's need to routinely handle responsive and bug-free pathfinding and path-following for large numbers of actors, this project could become a useful showcase and useful codebase for projects needing pathfinders, and could expand the world's understanding of pathfinding and path-following in realtime systems.

'''What:''' Spring's current pathfinder uses a 2d grid and is somewhat limited in functionality.
A partial/full rewrite should be introduced to add support for navigating using more than 8 primary directions and selectively ignore certain unit types for performance reasons.

Spring's Lua API should be extended to allow game developers to push new nodes/links and be able to alter or delete existing ones (for pathfinder-aware tunnels/teleporting/etc.).

Preferably this should all be faster than the current system, or a compelling argument/experiment should be made that shows there cannot be a faster system with the same features.

'''Requirements:''' Understanding of C++; moderate understanding of pathfinding / following concepts and coding strategies

[[GSoC_Smarter_pathfinder]]

== Proposal: More AI interfaces ==

'''Why:''' The Spring Engine is already a popular engine for academic projects to study Artificial Intelligence, given the Open Source model of development and strong support within the A.I. community. This project could enhance Spring's attractiveness to developers and teachers wanting to explore or teach about A.I.

'''What:''' The Spring engine's A.I. interface supports bindings for multiple languages. Currently C++, C and java are supported, and AIs may be constructed using Lua.

We propose to add more bindings for more languages and/or virtual machines would be added, to allow broader AI developing audience (for example: Ruby, Perl, JavaScript, Python, D, Go, Mono, LLVM, Parrot).

'''Requirements:''' Understanding of C++; understanding of the languages to be binded to

[[GSoC_More_AI_interfaces]]

== New Rendering System ==

Estimated difficulty: '''Medium'''

The Spring Engine's rendering system remains near the cutting edge of practical, functional OpenGL in a realtime environment, and is certainly notable amongst free, Open Source projects for its realism and flexibility. While it is not as advanced as the latest commercial engines, Spring's developers have made great strides in the last year, adding significant new features to the engine.

However, the core Spring rendering engine still includes many fixed function pipeline OpenGL functions. This rendering system is becoming deprecated and is generally slower and less flexible than more modern approaches.

Under this proposal, the rendering pipeline would be given a complete overhaul using modern graphic programming techniques, including shaders, standardised model formats that are easier for new artists to adapt to, and other enhancements, such as bump mapping, normal mapping, and multiple textures per Unit, while utilizing code that adheres to the OpenGL ES 2.0 specification.

[[GSoC_New_rendering_system]]

== Reconnect / Host change during a match ==

Estimated difficulty: '''Hard'''

Spring's network model implies the existence of a server to host a battle. For various reasons the network link between host and clients can be interrupted, or "desync". This causes an end-user to lose the true state of the simulation, and is a significant problem for players.

Our proposal is that a new system should be designed to allow manual and/or automatic switching of the game's host (possibly using an existing player's state, after testing load handling capabilities) and manual and/or automatic reconnection from client side if host remains the same.

[[GSoC_Reconnect_Host_change]]

Google Summer of Code 2010

2010-03-12T04:36:15Z

Argh: /* Smarter pathfinder */

[[Image:GSOC.png]]

= Project proposals =

This is the list of project ideas for students willing to work on the Spring engine during the Google Summer of Code 2010. If you wish, you may read our [[Google_Summer_of_Code_2010_student_application|student application]].

== Limited Play Area ==

Estimated difficulty: '''Medium'''

Spring uses a finite-world model, where the scene has distinct bounds that all actors must obey. Currently, this system uses a rectangular definition of the bounds, which is not sufficiently flexible for some types of simulation or game designs.

The new system should allow the map's developer to restrict the playable area to a subset of the global area, possibly adding support for multiple shapes and/or non rectangular shape restrictions.

The restriction shapes should be readable and changeable mid-game through the engine's Lua API. Proper handling of Units which are suddenly off-map needs to be implemented.

[[GSoC_Limited_play_area]]

== Proposal: Sensor handling redesign / simplification ==

'''Why:''' The Spring Engine is currently capable of significant real-world applications in the area of simulation of certain types of events or situations; a better sensor system could greatly improve Spring's applicability to an even wider range of projects.

'''What:''' Currently there are a number of different "sensor" systems in the engine: LineOfSight, Radar, Sonar, and Seismic. Some can be "jammed", some cannot. Some use a LineOfSight algorithm to determine coverage, and some are circular in area.

A new sensor system should integrate the current systems into a streamlined codebase, to reduce amount of code per function, and it should add additional features which would be then available for all types, while improving efficiency where possible.

'''Requirements:''' Understanding of C++ / Lua

[[GSoC_Sensor_handling_redesign]]

== Proposal: Abstraction of Resource System ==

'''Why:''' The Spring engine has its roots in an older Real-Time Strategy title, where only two major resources ("metal" and "energy") were incorporated into the game design.

This model has proven to be too inflexible to support certain types of gameplay, and is an obvious disadvantage to the Spring Engine when it is compared to other available software for constructing certain types of simulations. Furthermore, the use of Lua to support alternative models has not always proven satisfactory to game developers, who may lack the programming experience to build a resource-distribution system from scratch.

'''What:''' Therefore, we propose to write a new, more-flexible system that will support more than two resources, and possibly implement new behavioral models.

'''Requirements:''' Understanding of C++

[[GSoC_Engine_resource_abstraction]]

== Proposal: Ingame Lobby ==

'''Why:''' All existing Spring online player match-making systems ('lobbies') are either difficult to customize for game developers or have a different look and feel from the games which are expected to operate with them. While they are Open Source, and are being actively maintained, they do not provide the same end-user experience one finds in commercial titles.

'''What:''' An in-game Lobby, leveraging the Spring Engine's strong Lua scripting support, should be implemented with customization and control in mind. This may possibly be integrated with Spring's codebase, or it may be designed as a separate process overlaying to the game's UI.

This could also serve as a practical "front end" for the Spring Engine, giving all games developed on the engine a standardized, yet flexible, system to support their players.

'''Requirements:''' Understanding of C++ / Lua

[[GSoC_Ingame_lobby]]

== Smarter pathfinder ==

'''Why:''' Given the Spring Engine's need to routinely handle responsive and bug-free pathfinding and path-following for large numbers of actors, this project could become a useful showcase and useful codebase for projects needing pathfinders, and could expand the world's understanding of pathfinding and path-following in realtime systems.

'''What:''' Spring's current pathfinder uses a 2d grid and is somewhat limited in functionality.
A partial/full rewrite should be introduced to add support for navigating using more than 8 primary directions and selectively ignore certain unit types for performance reasons.

Spring's Lua API should be extended to allow game developers to push new nodes/links and be able to alter or delete existing ones (for pathfinder-aware tunnels/teleporting/etc.).

Preferably this should all be faster than the current system, or a compelling argument/experiment should be made that shows there cannot be a faster system with the same features.

'''Requirements:''' Understanding of C++; moderate understanding of pathfinding / following concepts and coding strategies

[[GSoC_Smarter_pathfinder]]

== More AI interfaces ==

Estimated difficulty: '''Medium'''

The Spring Engine is already a popular engine for academic projects to study Artificial Intelligence, given the Open Source model of development and strong support within the A.I. community. This project could enhance Spring's attractiveness to developers and teachers wanting to explore or teach about A.I.

The Spring engine's A.I. interface supports bindings for multiple languages. Currently C++, C and java are supported, and AIs may be constructed using Lua.

Bindings for more languages and/or virtual machines would be added, to allow broader AI developing audience (for example: Ruby, Perl, JavaScript, Python, D, Go, Mono, LLVM, Parrot).

[[GSoC_More_AI_interfaces]]

== New Rendering System ==

Estimated difficulty: '''Medium'''

The Spring Engine's rendering system remains near the cutting edge of practical, functional OpenGL in a realtime environment, and is certainly notable amongst free, Open Source projects for its realism and flexibility. While it is not as advanced as the latest commercial engines, Spring's developers have made great strides in the last year, adding significant new features to the engine.

However, the core Spring rendering engine still includes many fixed function pipeline OpenGL functions. This rendering system is becoming deprecated and is generally slower and less flexible than more modern approaches.

Under this proposal, the rendering pipeline would be given a complete overhaul using modern graphic programming techniques, including shaders, standardised model formats that are easier for new artists to adapt to, and other enhancements, such as bump mapping, normal mapping, and multiple textures per Unit, while utilizing code that adheres to the OpenGL ES 2.0 specification.

[[GSoC_New_rendering_system]]

== Reconnect / Host change during a match ==

Estimated difficulty: '''Hard'''

Spring's network model implies the existence of a server to host a battle. For various reasons the network link between host and clients can be interrupted, or "desync". This causes an end-user to lose the true state of the simulation, and is a significant problem for players.

Our proposal is that a new system should be designed to allow manual and/or automatic switching of the game's host (possibly using an existing player's state, after testing load handling capabilities) and manual and/or automatic reconnection from client side if host remains the same.

[[GSoC_Reconnect_Host_change]]

Google Summer of Code 2010

2010-03-12T04:34:52Z

Argh: /* Proposal: Abstraction of Resource System */

[[Image:GSOC.png]]

= Project proposals =

This is the list of project ideas for students willing to work on the Spring engine during the Google Summer of Code 2010. If you wish, you may read our [[Google_Summer_of_Code_2010_student_application|student application]].

== Limited Play Area ==

Estimated difficulty: '''Medium'''

Spring uses a finite-world model, where the scene has distinct bounds that all actors must obey. Currently, this system uses a rectangular definition of the bounds, which is not sufficiently flexible for some types of simulation or game designs.

The new system should allow the map's developer to restrict the playable area to a subset of the global area, possibly adding support for multiple shapes and/or non rectangular shape restrictions.

The restriction shapes should be readable and changeable mid-game through the engine's Lua API. Proper handling of Units which are suddenly off-map needs to be implemented.

[[GSoC_Limited_play_area]]

== Proposal: Sensor handling redesign / simplification ==

'''Why:''' The Spring Engine is currently capable of significant real-world applications in the area of simulation of certain types of events or situations; a better sensor system could greatly improve Spring's applicability to an even wider range of projects.

'''What:''' Currently there are a number of different "sensor" systems in the engine: LineOfSight, Radar, Sonar, and Seismic. Some can be "jammed", some cannot. Some use a LineOfSight algorithm to determine coverage, and some are circular in area.

A new sensor system should integrate the current systems into a streamlined codebase, to reduce amount of code per function, and it should add additional features which would be then available for all types, while improving efficiency where possible.

'''Requirements:''' Understanding of C++ / Lua

[[GSoC_Sensor_handling_redesign]]

== Proposal: Abstraction of Resource System ==

'''Why:''' The Spring engine has its roots in an older Real-Time Strategy title, where only two major resources ("metal" and "energy") were incorporated into the game design.

This model has proven to be too inflexible to support certain types of gameplay, and is an obvious disadvantage to the Spring Engine when it is compared to other available software for constructing certain types of simulations. Furthermore, the use of Lua to support alternative models has not always proven satisfactory to game developers, who may lack the programming experience to build a resource-distribution system from scratch.

'''What:''' Therefore, we propose to write a new, more-flexible system that will support more than two resources, and possibly implement new behavioral models.

'''Requirements:''' Understanding of C++

[[GSoC_Engine_resource_abstraction]]

== Proposal: Ingame Lobby ==

'''Why:''' All existing Spring online player match-making systems ('lobbies') are either difficult to customize for game developers or have a different look and feel from the games which are expected to operate with them. While they are Open Source, and are being actively maintained, they do not provide the same end-user experience one finds in commercial titles.

'''What:''' An in-game Lobby, leveraging the Spring Engine's strong Lua scripting support, should be implemented with customization and control in mind. This may possibly be integrated with Spring's codebase, or it may be designed as a separate process overlaying to the game's UI.

This could also serve as a practical "front end" for the Spring Engine, giving all games developed on the engine a standardized, yet flexible, system to support their players.

'''Requirements:''' Understanding of C++ / Lua

[[GSoC_Ingame_lobby]]

== Smarter pathfinder ==

Estimated difficulty: '''Hard'''

Given the Spring Engine's need to routinely handle responsive and bug-free pathfinding and path-following for large numbers of actors, this project could become a useful showcase and useful codebase for projects needing pathfinders, and could expand the world's understanding of pathfinding and path-following in realtime systems.

Spring's pathfinder uses a 2d grid and is somewhat limited in functionality.
A partial/full rewrite should be introduced to add support for navigating using more than 8 primary directions and selectively ignore certain unit types for performance reasons.

Spring's Lua API should be extended to allow game developers to push new nodes/links and be able to alter or delete existing ones (for pathfinder-aware tunnels/teleporting/etc.).

Preferably this should all be faster than the current system, or a compelling argument/experiment should be made that shows there cannot be a faster system with the same features.

[[GSoC_Smarter_pathfinder]]

== More AI interfaces ==

Estimated difficulty: '''Medium'''

The Spring Engine is already a popular engine for academic projects to study Artificial Intelligence, given the Open Source model of development and strong support within the A.I. community. This project could enhance Spring's attractiveness to developers and teachers wanting to explore or teach about A.I.

The Spring engine's A.I. interface supports bindings for multiple languages. Currently C++, C and java are supported, and AIs may be constructed using Lua.

Bindings for more languages and/or virtual machines would be added, to allow broader AI developing audience (for example: Ruby, Perl, JavaScript, Python, D, Go, Mono, LLVM, Parrot).

[[GSoC_More_AI_interfaces]]

== New Rendering System ==

Estimated difficulty: '''Medium'''

The Spring Engine's rendering system remains near the cutting edge of practical, functional OpenGL in a realtime environment, and is certainly notable amongst free, Open Source projects for its realism and flexibility. While it is not as advanced as the latest commercial engines, Spring's developers have made great strides in the last year, adding significant new features to the engine.

However, the core Spring rendering engine still includes many fixed function pipeline OpenGL functions. This rendering system is becoming deprecated and is generally slower and less flexible than more modern approaches.

Under this proposal, the rendering pipeline would be given a complete overhaul using modern graphic programming techniques, including shaders, standardised model formats that are easier for new artists to adapt to, and other enhancements, such as bump mapping, normal mapping, and multiple textures per Unit, while utilizing code that adheres to the OpenGL ES 2.0 specification.

[[GSoC_New_rendering_system]]

== Reconnect / Host change during a match ==

Estimated difficulty: '''Hard'''

Spring's network model implies the existence of a server to host a battle. For various reasons the network link between host and clients can be interrupted, or "desync". This causes an end-user to lose the true state of the simulation, and is a significant problem for players.

Our proposal is that a new system should be designed to allow manual and/or automatic switching of the game's host (possibly using an existing player's state, after testing load handling capabilities) and manual and/or automatic reconnection from client side if host remains the same.

[[GSoC_Reconnect_Host_change]]

Google Summer of Code 2010

2010-03-12T04:34:35Z

Argh: /* Basic ingame lobby */

[[Image:GSOC.png]]

= Project proposals =

This is the list of project ideas for students willing to work on the Spring engine during the Google Summer of Code 2010. If you wish, you may read our [[Google_Summer_of_Code_2010_student_application|student application]].

== Limited Play Area ==

Estimated difficulty: '''Medium'''

Spring uses a finite-world model, where the scene has distinct bounds that all actors must obey. Currently, this system uses a rectangular definition of the bounds, which is not sufficiently flexible for some types of simulation or game designs.

The new system should allow the map's developer to restrict the playable area to a subset of the global area, possibly adding support for multiple shapes and/or non rectangular shape restrictions.

The restriction shapes should be readable and changeable mid-game through the engine's Lua API. Proper handling of Units which are suddenly off-map needs to be implemented.

[[GSoC_Limited_play_area]]

== Proposal: Sensor handling redesign / simplification ==

'''Why:''' The Spring Engine is currently capable of significant real-world applications in the area of simulation of certain types of events or situations; a better sensor system could greatly improve Spring's applicability to an even wider range of projects.

'''What:''' Currently there are a number of different "sensor" systems in the engine: LineOfSight, Radar, Sonar, and Seismic. Some can be "jammed", some cannot. Some use a LineOfSight algorithm to determine coverage, and some are circular in area.

A new sensor system should integrate the current systems into a streamlined codebase, to reduce amount of code per function, and it should add additional features which would be then available for all types, while improving efficiency where possible.

'''Requirements:''' Understanding of C++ / Lua

[[GSoC_Sensor_handling_redesign]]

== Proposal: Abstraction of Resource System ==

'''Why:''' The Spring engine has its roots in an older Real-Time Strategy title, where only two major resources ("metal" and "energy") were incorporated into the game design.

This model has proven to be too inflexible to support certain types of gameplay, and is an obvious disadvantage to the Spring Engine when it is compared to other available software for constructing certain types of simulations. Furthermore, the use of Lua to support alternative models has not always proven satisfactory to game developers, who may lack the programming experience to build a resource-distribution system from scratch.

'''What:''' Therefore, we propose to write a new, more-flexible system that will support more than two resources, and possibly implement new behavioral models.

Requirements: Understanding of C++

[[GSoC_Engine_resource_abstraction]]

== Proposal: Ingame Lobby ==

'''Why:''' All existing Spring online player match-making systems ('lobbies') are either difficult to customize for game developers or have a different look and feel from the games which are expected to operate with them. While they are Open Source, and are being actively maintained, they do not provide the same end-user experience one finds in commercial titles.

'''What:''' An in-game Lobby, leveraging the Spring Engine's strong Lua scripting support, should be implemented with customization and control in mind. This may possibly be integrated with Spring's codebase, or it may be designed as a separate process overlaying to the game's UI.

This could also serve as a practical "front end" for the Spring Engine, giving all games developed on the engine a standardized, yet flexible, system to support their players.

'''Requirements:''' Understanding of C++ / Lua

[[GSoC_Ingame_lobby]]

== Smarter pathfinder ==

Estimated difficulty: '''Hard'''

Given the Spring Engine's need to routinely handle responsive and bug-free pathfinding and path-following for large numbers of actors, this project could become a useful showcase and useful codebase for projects needing pathfinders, and could expand the world's understanding of pathfinding and path-following in realtime systems.

Spring's pathfinder uses a 2d grid and is somewhat limited in functionality.
A partial/full rewrite should be introduced to add support for navigating using more than 8 primary directions and selectively ignore certain unit types for performance reasons.

Spring's Lua API should be extended to allow game developers to push new nodes/links and be able to alter or delete existing ones (for pathfinder-aware tunnels/teleporting/etc.).

Preferably this should all be faster than the current system, or a compelling argument/experiment should be made that shows there cannot be a faster system with the same features.

[[GSoC_Smarter_pathfinder]]

== More AI interfaces ==

Estimated difficulty: '''Medium'''

The Spring Engine is already a popular engine for academic projects to study Artificial Intelligence, given the Open Source model of development and strong support within the A.I. community. This project could enhance Spring's attractiveness to developers and teachers wanting to explore or teach about A.I.

The Spring engine's A.I. interface supports bindings for multiple languages. Currently C++, C and java are supported, and AIs may be constructed using Lua.

Bindings for more languages and/or virtual machines would be added, to allow broader AI developing audience (for example: Ruby, Perl, JavaScript, Python, D, Go, Mono, LLVM, Parrot).

[[GSoC_More_AI_interfaces]]

== New Rendering System ==

Estimated difficulty: '''Medium'''

The Spring Engine's rendering system remains near the cutting edge of practical, functional OpenGL in a realtime environment, and is certainly notable amongst free, Open Source projects for its realism and flexibility. While it is not as advanced as the latest commercial engines, Spring's developers have made great strides in the last year, adding significant new features to the engine.

However, the core Spring rendering engine still includes many fixed function pipeline OpenGL functions. This rendering system is becoming deprecated and is generally slower and less flexible than more modern approaches.

Under this proposal, the rendering pipeline would be given a complete overhaul using modern graphic programming techniques, including shaders, standardised model formats that are easier for new artists to adapt to, and other enhancements, such as bump mapping, normal mapping, and multiple textures per Unit, while utilizing code that adheres to the OpenGL ES 2.0 specification.

[[GSoC_New_rendering_system]]

== Reconnect / Host change during a match ==

Estimated difficulty: '''Hard'''

Spring's network model implies the existence of a server to host a battle. For various reasons the network link between host and clients can be interrupted, or "desync". This causes an end-user to lose the true state of the simulation, and is a significant problem for players.

Our proposal is that a new system should be designed to allow manual and/or automatic switching of the game's host (possibly using an existing player's state, after testing load handling capabilities) and manual and/or automatic reconnection from client side if host remains the same.

[[GSoC_Reconnect_Host_change]]

Google Summer of Code 2010

2010-03-12T04:33:22Z

Argh: /* Proposal: Sensor handling redesign / simplification */

[[Image:GSOC.png]]

= Project proposals =

This is the list of project ideas for students willing to work on the Spring engine during the Google Summer of Code 2010. If you wish, you may read our [[Google_Summer_of_Code_2010_student_application|student application]].

== Limited Play Area ==

Estimated difficulty: '''Medium'''

Spring uses a finite-world model, where the scene has distinct bounds that all actors must obey. Currently, this system uses a rectangular definition of the bounds, which is not sufficiently flexible for some types of simulation or game designs.

The new system should allow the map's developer to restrict the playable area to a subset of the global area, possibly adding support for multiple shapes and/or non rectangular shape restrictions.

The restriction shapes should be readable and changeable mid-game through the engine's Lua API. Proper handling of Units which are suddenly off-map needs to be implemented.

[[GSoC_Limited_play_area]]

== Proposal: Sensor handling redesign / simplification ==

'''Why:''' The Spring Engine is currently capable of significant real-world applications in the area of simulation of certain types of events or situations; a better sensor system could greatly improve Spring's applicability to an even wider range of projects.

'''What:''' Currently there are a number of different "sensor" systems in the engine: LineOfSight, Radar, Sonar, and Seismic. Some can be "jammed", some cannot. Some use a LineOfSight algorithm to determine coverage, and some are circular in area.

A new sensor system should integrate the current systems into a streamlined codebase, to reduce amount of code per function, and it should add additional features which would be then available for all types, while improving efficiency where possible.

'''Requirements:''' Understanding of C++ / Lua

[[GSoC_Sensor_handling_redesign]]

== Proposal: Abstraction of Resource System ==

'''Why:''' The Spring engine has its roots in an older Real-Time Strategy title, where only two major resources ("metal" and "energy") were incorporated into the game design.

This model has proven to be too inflexible to support certain types of gameplay, and is an obvious disadvantage to the Spring Engine when it is compared to other available software for constructing certain types of simulations. Furthermore, the use of Lua to support alternative models has not always proven satisfactory to game developers, who may lack the programming experience to build a resource-distribution system from scratch.

'''What:''' Therefore, we propose to write a new, more-flexible system that will support more than two resources, and possibly implement new behavioral models.

Requirements: Understanding of C++

[[GSoC_Engine_resource_abstraction]]

== Basic ingame lobby ==

Estimated difficulty: '''Hard'''

All existing Spring online player match-making systems ('lobbies') are either difficult to customize for game developers or have a different look and feel from the games which are expected to operate with them. While they are Open Source, and are being actively maintained, they do not provide the same end-user experience one finds in commercial titles.

An in-game Lobby, leveraging the Spring Engine's strong Lua scripting support, should be implemented with customization and control in mind. This may possibly be integrated with Spring's codebase, or it may be designed as a separate process overlaying to the game's UI.

This could also serve as a practical "front end" for the Spring Engine, giving all games developed on the engine a standardized, yet flexible, system to support their players.

[[GSoC_Ingame_lobby]]

== Smarter pathfinder ==

Estimated difficulty: '''Hard'''

Given the Spring Engine's need to routinely handle responsive and bug-free pathfinding and path-following for large numbers of actors, this project could become a useful showcase and useful codebase for projects needing pathfinders, and could expand the world's understanding of pathfinding and path-following in realtime systems.

Spring's pathfinder uses a 2d grid and is somewhat limited in functionality.
A partial/full rewrite should be introduced to add support for navigating using more than 8 primary directions and selectively ignore certain unit types for performance reasons.

Spring's Lua API should be extended to allow game developers to push new nodes/links and be able to alter or delete existing ones (for pathfinder-aware tunnels/teleporting/etc.).

Preferably this should all be faster than the current system, or a compelling argument/experiment should be made that shows there cannot be a faster system with the same features.

[[GSoC_Smarter_pathfinder]]

== More AI interfaces ==

Estimated difficulty: '''Medium'''

The Spring Engine is already a popular engine for academic projects to study Artificial Intelligence, given the Open Source model of development and strong support within the A.I. community. This project could enhance Spring's attractiveness to developers and teachers wanting to explore or teach about A.I.

The Spring engine's A.I. interface supports bindings for multiple languages. Currently C++, C and java are supported, and AIs may be constructed using Lua.

Bindings for more languages and/or virtual machines would be added, to allow broader AI developing audience (for example: Ruby, Perl, JavaScript, Python, D, Go, Mono, LLVM, Parrot).

[[GSoC_More_AI_interfaces]]

== New Rendering System ==

Estimated difficulty: '''Medium'''

The Spring Engine's rendering system remains near the cutting edge of practical, functional OpenGL in a realtime environment, and is certainly notable amongst free, Open Source projects for its realism and flexibility. While it is not as advanced as the latest commercial engines, Spring's developers have made great strides in the last year, adding significant new features to the engine.

However, the core Spring rendering engine still includes many fixed function pipeline OpenGL functions. This rendering system is becoming deprecated and is generally slower and less flexible than more modern approaches.

Under this proposal, the rendering pipeline would be given a complete overhaul using modern graphic programming techniques, including shaders, standardised model formats that are easier for new artists to adapt to, and other enhancements, such as bump mapping, normal mapping, and multiple textures per Unit, while utilizing code that adheres to the OpenGL ES 2.0 specification.

[[GSoC_New_rendering_system]]

== Reconnect / Host change during a match ==

Estimated difficulty: '''Hard'''

Spring's network model implies the existence of a server to host a battle. For various reasons the network link between host and clients can be interrupted, or "desync". This causes an end-user to lose the true state of the simulation, and is a significant problem for players.

Our proposal is that a new system should be designed to allow manual and/or automatic switching of the game's host (possibly using an existing player's state, after testing load handling capabilities) and manual and/or automatic reconnection from client side if host remains the same.

[[GSoC_Reconnect_Host_change]]

Google Summer of Code 2010

2010-03-12T04:32:53Z

Argh: /* Abstraction of Resources */

[[Image:GSOC.png]]

= Project proposals =

This is the list of project ideas for students willing to work on the Spring engine during the Google Summer of Code 2010. If you wish, you may read our [[Google_Summer_of_Code_2010_student_application|student application]].

== Limited Play Area ==

Estimated difficulty: '''Medium'''

Spring uses a finite-world model, where the scene has distinct bounds that all actors must obey. Currently, this system uses a rectangular definition of the bounds, which is not sufficiently flexible for some types of simulation or game designs.

The new system should allow the map's developer to restrict the playable area to a subset of the global area, possibly adding support for multiple shapes and/or non rectangular shape restrictions.

The restriction shapes should be readable and changeable mid-game through the engine's Lua API. Proper handling of Units which are suddenly off-map needs to be implemented.

[[GSoC_Limited_play_area]]

== Proposal: Sensor handling redesign / simplification ==

'''Why:''' The Spring Engine is currently capable of significant real-world applications in the area of simulation of certain types of events or situations; a better sensor system could greatly improve Spring's applicability to an even wider range of projects.

'''What:''' Currently there are a number of different "sensor" systems in the engine: LineOfSight, Radar, Sonar, and Seismic. Some can be "jammed", some cannot. Some use a LineOfSight algorithm to determine coverage, and some are circular in area.

A new sensor system should integrate the current systems into a streamlined codebase, to reduce amount of code per function, and it should add additional features which would be then available for all types, while improving efficiency where possible.

'''Requirements:''' Knowledge of C++ / Lua

[[GSoC_Sensor_handling_redesign]]

== Proposal: Abstraction of Resource System ==

'''Why:''' The Spring engine has its roots in an older Real-Time Strategy title, where only two major resources ("metal" and "energy") were incorporated into the game design.

This model has proven to be too inflexible to support certain types of gameplay, and is an obvious disadvantage to the Spring Engine when it is compared to other available software for constructing certain types of simulations. Furthermore, the use of Lua to support alternative models has not always proven satisfactory to game developers, who may lack the programming experience to build a resource-distribution system from scratch.

'''What:''' Therefore, we propose to write a new, more-flexible system that will support more than two resources, and possibly implement new behavioral models.

Requirements: Understanding of C++

[[GSoC_Engine_resource_abstraction]]

== Basic ingame lobby ==

Estimated difficulty: '''Hard'''

All existing Spring online player match-making systems ('lobbies') are either difficult to customize for game developers or have a different look and feel from the games which are expected to operate with them. While they are Open Source, and are being actively maintained, they do not provide the same end-user experience one finds in commercial titles.

An in-game Lobby, leveraging the Spring Engine's strong Lua scripting support, should be implemented with customization and control in mind. This may possibly be integrated with Spring's codebase, or it may be designed as a separate process overlaying to the game's UI.

This could also serve as a practical "front end" for the Spring Engine, giving all games developed on the engine a standardized, yet flexible, system to support their players.

[[GSoC_Ingame_lobby]]

== Smarter pathfinder ==

Estimated difficulty: '''Hard'''

Given the Spring Engine's need to routinely handle responsive and bug-free pathfinding and path-following for large numbers of actors, this project could become a useful showcase and useful codebase for projects needing pathfinders, and could expand the world's understanding of pathfinding and path-following in realtime systems.

Spring's pathfinder uses a 2d grid and is somewhat limited in functionality.
A partial/full rewrite should be introduced to add support for navigating using more than 8 primary directions and selectively ignore certain unit types for performance reasons.

Spring's Lua API should be extended to allow game developers to push new nodes/links and be able to alter or delete existing ones (for pathfinder-aware tunnels/teleporting/etc.).

Preferably this should all be faster than the current system, or a compelling argument/experiment should be made that shows there cannot be a faster system with the same features.

[[GSoC_Smarter_pathfinder]]

== More AI interfaces ==

Estimated difficulty: '''Medium'''

The Spring Engine is already a popular engine for academic projects to study Artificial Intelligence, given the Open Source model of development and strong support within the A.I. community. This project could enhance Spring's attractiveness to developers and teachers wanting to explore or teach about A.I.

The Spring engine's A.I. interface supports bindings for multiple languages. Currently C++, C and java are supported, and AIs may be constructed using Lua.

Bindings for more languages and/or virtual machines would be added, to allow broader AI developing audience (for example: Ruby, Perl, JavaScript, Python, D, Go, Mono, LLVM, Parrot).

[[GSoC_More_AI_interfaces]]

== New Rendering System ==

Estimated difficulty: '''Medium'''

The Spring Engine's rendering system remains near the cutting edge of practical, functional OpenGL in a realtime environment, and is certainly notable amongst free, Open Source projects for its realism and flexibility. While it is not as advanced as the latest commercial engines, Spring's developers have made great strides in the last year, adding significant new features to the engine.

However, the core Spring rendering engine still includes many fixed function pipeline OpenGL functions. This rendering system is becoming deprecated and is generally slower and less flexible than more modern approaches.

Under this proposal, the rendering pipeline would be given a complete overhaul using modern graphic programming techniques, including shaders, standardised model formats that are easier for new artists to adapt to, and other enhancements, such as bump mapping, normal mapping, and multiple textures per Unit, while utilizing code that adheres to the OpenGL ES 2.0 specification.

[[GSoC_New_rendering_system]]

== Reconnect / Host change during a match ==

Estimated difficulty: '''Hard'''

Spring's network model implies the existence of a server to host a battle. For various reasons the network link between host and clients can be interrupted, or "desync". This causes an end-user to lose the true state of the simulation, and is a significant problem for players.

Our proposal is that a new system should be designed to allow manual and/or automatic switching of the game's host (possibly using an existing player's state, after testing load handling capabilities) and manual and/or automatic reconnection from client side if host remains the same.

[[GSoC_Reconnect_Host_change]]

Google Summer of Code 2010

2010-03-12T04:31:42Z

Argh: /* Sensor handling redesign / simplification */

[[Image:GSOC.png]]

= Project proposals =

This is the list of project ideas for students willing to work on the Spring engine during the Google Summer of Code 2010. If you wish, you may read our [[Google_Summer_of_Code_2010_student_application|student application]].

== Limited Play Area ==

Estimated difficulty: '''Medium'''

Spring uses a finite-world model, where the scene has distinct bounds that all actors must obey. Currently, this system uses a rectangular definition of the bounds, which is not sufficiently flexible for some types of simulation or game designs.

The new system should allow the map's developer to restrict the playable area to a subset of the global area, possibly adding support for multiple shapes and/or non rectangular shape restrictions.

The restriction shapes should be readable and changeable mid-game through the engine's Lua API. Proper handling of Units which are suddenly off-map needs to be implemented.

[[GSoC_Limited_play_area]]

== Proposal: Sensor handling redesign / simplification ==

'''Why:''' The Spring Engine is currently capable of significant real-world applications in the area of simulation of certain types of events or situations; a better sensor system could greatly improve Spring's applicability to an even wider range of projects.

'''What:''' Currently there are a number of different "sensor" systems in the engine: LineOfSight, Radar, Sonar, and Seismic. Some can be "jammed", some cannot. Some use a LineOfSight algorithm to determine coverage, and some are circular in area.

A new sensor system should integrate the current systems into a streamlined codebase, to reduce amount of code per function, and it should add additional features which would be then available for all types, while improving efficiency where possible.

'''Requirements:''' Knowledge of C++ / Lua

[[GSoC_Sensor_handling_redesign]]

== Abstraction of Resources ==

Estimated difficulty: '''Medium'''

The Spring engine has its roots in an older Real-Time Strategy title, where only two major resources ("metal" and "energy") were incorporated into the game design.

This model has proven to be too inflexible to support certain types of gameplay, and is an obvious disadvantage to the Spring Engine when it is compared to other available software for constructing certain types of simulations. Furthermore, the use of Lua to support alternative models has not always proven satisfactory to game developers, who may lack the programming experience to build a resource-distribution system from scratch.

Therefore, we propose to write a new, more-flexible system that will support more than two resources, and possibly implement new behavioral models.

[[GSoC_Engine_resource_abstraction]]

== Basic ingame lobby ==

Estimated difficulty: '''Hard'''

All existing Spring online player match-making systems ('lobbies') are either difficult to customize for game developers or have a different look and feel from the games which are expected to operate with them. While they are Open Source, and are being actively maintained, they do not provide the same end-user experience one finds in commercial titles.

An in-game Lobby, leveraging the Spring Engine's strong Lua scripting support, should be implemented with customization and control in mind. This may possibly be integrated with Spring's codebase, or it may be designed as a separate process overlaying to the game's UI.

This could also serve as a practical "front end" for the Spring Engine, giving all games developed on the engine a standardized, yet flexible, system to support their players.

[[GSoC_Ingame_lobby]]

== Smarter pathfinder ==

Estimated difficulty: '''Hard'''

Given the Spring Engine's need to routinely handle responsive and bug-free pathfinding and path-following for large numbers of actors, this project could become a useful showcase and useful codebase for projects needing pathfinders, and could expand the world's understanding of pathfinding and path-following in realtime systems.

Spring's pathfinder uses a 2d grid and is somewhat limited in functionality.
A partial/full rewrite should be introduced to add support for navigating using more than 8 primary directions and selectively ignore certain unit types for performance reasons.

Spring's Lua API should be extended to allow game developers to push new nodes/links and be able to alter or delete existing ones (for pathfinder-aware tunnels/teleporting/etc.).

Preferably this should all be faster than the current system, or a compelling argument/experiment should be made that shows there cannot be a faster system with the same features.

[[GSoC_Smarter_pathfinder]]

== More AI interfaces ==

Estimated difficulty: '''Medium'''

The Spring Engine is already a popular engine for academic projects to study Artificial Intelligence, given the Open Source model of development and strong support within the A.I. community. This project could enhance Spring's attractiveness to developers and teachers wanting to explore or teach about A.I.

The Spring engine's A.I. interface supports bindings for multiple languages. Currently C++, C and java are supported, and AIs may be constructed using Lua.

Bindings for more languages and/or virtual machines would be added, to allow broader AI developing audience (for example: Ruby, Perl, JavaScript, Python, D, Go, Mono, LLVM, Parrot).

[[GSoC_More_AI_interfaces]]

== New Rendering System ==

Estimated difficulty: '''Medium'''

The Spring Engine's rendering system remains near the cutting edge of practical, functional OpenGL in a realtime environment, and is certainly notable amongst free, Open Source projects for its realism and flexibility. While it is not as advanced as the latest commercial engines, Spring's developers have made great strides in the last year, adding significant new features to the engine.

However, the core Spring rendering engine still includes many fixed function pipeline OpenGL functions. This rendering system is becoming deprecated and is generally slower and less flexible than more modern approaches.

Under this proposal, the rendering pipeline would be given a complete overhaul using modern graphic programming techniques, including shaders, standardised model formats that are easier for new artists to adapt to, and other enhancements, such as bump mapping, normal mapping, and multiple textures per Unit, while utilizing code that adheres to the OpenGL ES 2.0 specification.

[[GSoC_New_rendering_system]]

== Reconnect / Host change during a match ==

Estimated difficulty: '''Hard'''

Spring's network model implies the existence of a server to host a battle. For various reasons the network link between host and clients can be interrupted, or "desync". This causes an end-user to lose the true state of the simulation, and is a significant problem for players.

Our proposal is that a new system should be designed to allow manual and/or automatic switching of the game's host (possibly using an existing player's state, after testing load handling capabilities) and manual and/or automatic reconnection from client side if host remains the same.

[[GSoC_Reconnect_Host_change]]

Google Summer of Code 2010

2010-03-12T04:13:13Z

Argh: /* Limited play area */

[[Image:GSOC.png]]

= Project proposals =

This is the list of project ideas for students willing to work on the Spring engine during the Google Summer of Code 2010. If you wish, you may read our [[Google_Summer_of_Code_2010_student_application|student application]].

== Limited Play Area ==

Estimated difficulty: '''Medium'''

Spring uses a finite-world model, where the scene has distinct bounds that all actors must obey. Currently, this system uses a rectangular definition of the bounds, which is not sufficiently flexible for some types of simulation or game designs.

The new system should allow the map's developer to restrict the playable area to a subset of the global area, possibly adding support for multiple shapes and/or non rectangular shape restrictions.

The restriction shapes should be readable and changeable mid-game through the engine's Lua API. Proper handling of Units which are suddenly off-map needs to be implemented.

[[GSoC_Limited_play_area]]

== Sensor handling redesign / simplification ==

Estimated difficulty: '''Hard'''

The Spring Engine is currently capable of significant real-world applications in the area of simulation of certain types of events or situations; a better sensor system could greatly improve Spring's applicability to an even wider range of projects.

Currently there are a number of different "sensor" systems in the engine: LineOfSight, Radar, Sonar, and Seismic. Some can be "jammed", some cannot. Some use a LineOfSight algorithm to determine coverage, and some are circular in area.

A new sensor system should integrate the current systems into a streamlined codebase, to reduce amount of code per function, and it should add additional features which would be then available for all types, while improving efficiency where possible.

[[GSoC_Sensor_handling_redesign]]

== Abstraction of Resources ==

Estimated difficulty: '''Medium'''

The Spring engine has its roots in an older Real-Time Strategy title, where only two major resources ("metal" and "energy") were incorporated into the game design.

This model has proven to be too inflexible to support certain types of gameplay, and is an obvious disadvantage to the Spring Engine when it is compared to other available software for constructing certain types of simulations. Furthermore, the use of Lua to support alternative models has not always proven satisfactory to game developers, who may lack the programming experience to build a resource-distribution system from scratch.

Therefore, we propose to write a new, more-flexible system that will support more than two resources, and possibly implement new behavioral models.

[[GSoC_Engine_resource_abstraction]]

== Basic ingame lobby ==

Estimated difficulty: '''Hard'''

All existing Spring online player match-making systems ('lobbies') are either difficult to customize for game developers or have a different look and feel from the games which are expected to operate with them. While they are Open Source, and are being actively maintained, they do not provide the same end-user experience one finds in commercial titles.

An in-game Lobby, leveraging the Spring Engine's strong Lua scripting support, should be implemented with customization and control in mind. This may possibly be integrated with Spring's codebase, or it may be designed as a separate process overlaying to the game's UI.

This could also serve as a practical "front end" for the Spring Engine, giving all games developed on the engine a standardized, yet flexible, system to support their players.

[[GSoC_Ingame_lobby]]

== Smarter pathfinder ==

Estimated difficulty: '''Hard'''

Given the Spring Engine's need to routinely handle responsive and bug-free pathfinding and path-following for large numbers of actors, this project could become a useful showcase and useful codebase for projects needing pathfinders, and could expand the world's understanding of pathfinding and path-following in realtime systems.

Spring's pathfinder uses a 2d grid and is somewhat limited in functionality.
A partial/full rewrite should be introduced to add support for navigating using more than 8 primary directions and selectively ignore certain unit types for performance reasons.

Spring's Lua API should be extended to allow game developers to push new nodes/links and be able to alter or delete existing ones (for pathfinder-aware tunnels/teleporting/etc.).

Preferably this should all be faster than the current system, or a compelling argument/experiment should be made that shows there cannot be a faster system with the same features.

[[GSoC_Smarter_pathfinder]]

== More AI interfaces ==

Estimated difficulty: '''Medium'''

The Spring Engine is already a popular engine for academic projects to study Artificial Intelligence, given the Open Source model of development and strong support within the A.I. community. This project could enhance Spring's attractiveness to developers and teachers wanting to explore or teach about A.I.

The Spring engine's A.I. interface supports bindings for multiple languages. Currently C++, C and java are supported, and AIs may be constructed using Lua.

Bindings for more languages and/or virtual machines would be added, to allow broader AI developing audience (for example: Ruby, Perl, JavaScript, Python, D, Go, Mono, LLVM, Parrot).

[[GSoC_More_AI_interfaces]]

== New Rendering System ==

Estimated difficulty: '''Medium'''

The Spring Engine's rendering system remains near the cutting edge of practical, functional OpenGL in a realtime environment, and is certainly notable amongst free, Open Source projects for its realism and flexibility. While it is not as advanced as the latest commercial engines, Spring's developers have made great strides in the last year, adding significant new features to the engine.

However, the core Spring rendering engine still includes many fixed function pipeline OpenGL functions. This rendering system is becoming deprecated and is generally slower and less flexible than more modern approaches.

Under this proposal, the rendering pipeline would be given a complete overhaul using modern graphic programming techniques, including shaders, standardised model formats that are easier for new artists to adapt to, and other enhancements, such as bump mapping, normal mapping, and multiple textures per Unit, while utilizing code that adheres to the OpenGL ES 2.0 specification.

[[GSoC_New_rendering_system]]

== Reconnect / Host change during a match ==

Estimated difficulty: '''Hard'''

Spring's network model implies the existence of a server to host a battle. For various reasons the network link between host and clients can be interrupted, or "desync". This causes an end-user to lose the true state of the simulation, and is a significant problem for players.

Our proposal is that a new system should be designed to allow manual and/or automatic switching of the game's host (possibly using an existing player's state, after testing load handling capabilities) and manual and/or automatic reconnection from client side if host remains the same.

[[GSoC_Reconnect_Host_change]]

Google Summer of Code 2010

2010-03-12T04:10:53Z

Argh: /* Sensor handling redesign / simplification */

[[Image:GSOC.png]]

= Project proposals =

This is the list of project ideas for students willing to work on the Spring engine during the Google Summer of Code 2010. If you wish, you may read our [[Google_Summer_of_Code_2010_student_application|student application]].

== Limited play area ==

Estimated difficulty: medium

Current Spring map formats have a hardcoded rectangle geometry; also they provide very limited support for defining aesthetics of the surrounding environment outside the play area.

The new system should allow the map to restrict the playable area to a subset of the global area, possibly adding support for multiple shapes and/or non rectangular shape restrictions.

The restriction shapes should be readable and changeable mid-game through the engine's Lua API. Proper handling of units which are suddenly off-map needs to be implemented.

[[GSoC_Limited_play_area]]

== Sensor handling redesign / simplification ==

Estimated difficulty: '''Hard'''

The Spring Engine is currently capable of significant real-world applications in the area of simulation of certain types of events or situations; a better sensor system could greatly improve Spring's applicability to an even wider range of projects.

Currently there are a number of different "sensor" systems in the engine: LineOfSight, Radar, Sonar, and Seismic. Some can be "jammed", some cannot. Some use a LineOfSight algorithm to determine coverage, and some are circular in area.

A new sensor system should integrate the current systems into a streamlined codebase, to reduce amount of code per function, and it should add additional features which would be then available for all types, while improving efficiency where possible.

[[GSoC_Sensor_handling_redesign]]

== Abstraction of Resources ==

Estimated difficulty: '''Medium'''

The Spring engine has its roots in an older Real-Time Strategy title, where only two major resources ("metal" and "energy") were incorporated into the game design.

This model has proven to be too inflexible to support certain types of gameplay, and is an obvious disadvantage to the Spring Engine when it is compared to other available software for constructing certain types of simulations. Furthermore, the use of Lua to support alternative models has not always proven satisfactory to game developers, who may lack the programming experience to build a resource-distribution system from scratch.

Therefore, we propose to write a new, more-flexible system that will support more than two resources, and possibly implement new behavioral models.

[[GSoC_Engine_resource_abstraction]]

== Basic ingame lobby ==

Estimated difficulty: '''Hard'''

All existing Spring online player match-making systems ('lobbies') are either difficult to customize for game developers or have a different look and feel from the games which are expected to operate with them. While they are Open Source, and are being actively maintained, they do not provide the same end-user experience one finds in commercial titles.

An in-game Lobby, leveraging the Spring Engine's strong Lua scripting support, should be implemented with customization and control in mind. This may possibly be integrated with Spring's codebase, or it may be designed as a separate process overlaying to the game's UI.

This could also serve as a practical "front end" for the Spring Engine, giving all games developed on the engine a standardized, yet flexible, system to support their players.

[[GSoC_Ingame_lobby]]

== Smarter pathfinder ==

Estimated difficulty: '''Hard'''

Given the Spring Engine's need to routinely handle responsive and bug-free pathfinding and path-following for large numbers of actors, this project could become a useful showcase and useful codebase for projects needing pathfinders, and could expand the world's understanding of pathfinding and path-following in realtime systems.

Spring's pathfinder uses a 2d grid and is somewhat limited in functionality.
A partial/full rewrite should be introduced to add support for navigating using more than 8 primary directions and selectively ignore certain unit types for performance reasons.

Spring's Lua API should be extended to allow game developers to push new nodes/links and be able to alter or delete existing ones (for pathfinder-aware tunnels/teleporting/etc.).

Preferably this should all be faster than the current system, or a compelling argument/experiment should be made that shows there cannot be a faster system with the same features.

[[GSoC_Smarter_pathfinder]]

== More AI interfaces ==

Estimated difficulty: '''Medium'''

The Spring Engine is already a popular engine for academic projects to study Artificial Intelligence, given the Open Source model of development and strong support within the A.I. community. This project could enhance Spring's attractiveness to developers and teachers wanting to explore or teach about A.I.

The Spring engine's A.I. interface supports bindings for multiple languages. Currently C++, C and java are supported, and AIs may be constructed using Lua.

Bindings for more languages and/or virtual machines would be added, to allow broader AI developing audience (for example: Ruby, Perl, JavaScript, Python, D, Go, Mono, LLVM, Parrot).

[[GSoC_More_AI_interfaces]]

== New Rendering System ==

Estimated difficulty: '''Medium'''

The Spring Engine's rendering system remains near the cutting edge of practical, functional OpenGL in a realtime environment, and is certainly notable amongst free, Open Source projects for its realism and flexibility. While it is not as advanced as the latest commercial engines, Spring's developers have made great strides in the last year, adding significant new features to the engine.

However, the core Spring rendering engine still includes many fixed function pipeline OpenGL functions. This rendering system is becoming deprecated and is generally slower and less flexible than more modern approaches.

Under this proposal, the rendering pipeline would be given a complete overhaul using modern graphic programming techniques, including shaders, standardised model formats that are easier for new artists to adapt to, and other enhancements, such as bump mapping, normal mapping, and multiple textures per Unit, while utilizing code that adheres to the OpenGL ES 2.0 specification.

[[GSoC_New_rendering_system]]

== Reconnect / Host change during a match ==

Estimated difficulty: '''Hard'''

Spring's network model implies the existence of a server to host a battle. For various reasons the network link between host and clients can be interrupted, or "desync". This causes an end-user to lose the true state of the simulation, and is a significant problem for players.

Our proposal is that a new system should be designed to allow manual and/or automatic switching of the game's host (possibly using an existing player's state, after testing load handling capabilities) and manual and/or automatic reconnection from client side if host remains the same.

[[GSoC_Reconnect_Host_change]]

Google Summer of Code 2010

2010-03-12T04:08:28Z

Argh: /* Engine level abstraction of resources */

[[Image:GSOC.png]]

= Project proposals =

This is the list of project ideas for students willing to work on the Spring engine during the Google Summer of Code 2010. If you wish, you may read our [[Google_Summer_of_Code_2010_student_application|student application]].

== Limited play area ==

Estimated difficulty: medium

Current Spring map formats have a hardcoded rectangle geometry; also they provide very limited support for defining aesthetics of the surrounding environment outside the play area.

The new system should allow the map to restrict the playable area to a subset of the global area, possibly adding support for multiple shapes and/or non rectangular shape restrictions.

The restriction shapes should be readable and changeable mid-game through the engine's Lua API. Proper handling of units which are suddenly off-map needs to be implemented.

[[GSoC_Limited_play_area]]

== Sensor handling redesign / simplification ==

Estimated difficulty: hard

The Spring Engine is currently capable of significant real-world applications in the areas of simulation; a better sensor system could greatly improve Spring's applicability to an even wider range of projects.

Currently there are a number of different "sensor" systems in the engine: LineOfSight, Radar, Sonar, and Seismic, some can be jammed, some cannot. Some respect terrain, and some are always circular.

A new sensor system should integrate the current LOS, Radar, Sonar, Seismic systems, to reduce amount of code per functionality, and eventually add additional features which would be then available for all types.

Preferably this all should also be faster than the current system or a compelling argument/experiment should be made that shows there cannot be a faster system with the same features.

[[GSoC_Sensor_handling_redesign]]

== Abstraction of Resources ==

Estimated difficulty: '''Medium'''

The Spring engine has its roots in an older Real-Time Strategy title, where only two major resources ("metal" and "energy") were incorporated into the game design.

This model has proven to be too inflexible to support certain types of gameplay, and is an obvious disadvantage to the Spring Engine when it is compared to other available software for constructing certain types of simulations. Furthermore, the use of Lua to support alternative models has not always proven satisfactory to game developers, who may lack the programming experience to build a resource-distribution system from scratch.

Therefore, we propose to write a new, more-flexible system that will support more than two resources, and possibly implement new behavioral models.

[[GSoC_Engine_resource_abstraction]]

== Basic ingame lobby ==

Estimated difficulty: '''Hard'''

All existing Spring online player match-making systems ('lobbies') are either difficult to customize for game developers or have a different look and feel from the games which are expected to operate with them. While they are Open Source, and are being actively maintained, they do not provide the same end-user experience one finds in commercial titles.

An in-game Lobby, leveraging the Spring Engine's strong Lua scripting support, should be implemented with customization and control in mind. This may possibly be integrated with Spring's codebase, or it may be designed as a separate process overlaying to the game's UI.

This could also serve as a practical "front end" for the Spring Engine, giving all games developed on the engine a standardized, yet flexible, system to support their players.

[[GSoC_Ingame_lobby]]

== Smarter pathfinder ==

Estimated difficulty: '''Hard'''

Given the Spring Engine's need to routinely handle responsive and bug-free pathfinding and path-following for large numbers of actors, this project could become a useful showcase and useful codebase for projects needing pathfinders, and could expand the world's understanding of pathfinding and path-following in realtime systems.

Spring's pathfinder uses a 2d grid and is somewhat limited in functionality.
A partial/full rewrite should be introduced to add support for navigating using more than 8 primary directions and selectively ignore certain unit types for performance reasons.

Spring's Lua API should be extended to allow game developers to push new nodes/links and be able to alter or delete existing ones (for pathfinder-aware tunnels/teleporting/etc.).

Preferably this should all be faster than the current system, or a compelling argument/experiment should be made that shows there cannot be a faster system with the same features.

[[GSoC_Smarter_pathfinder]]

== More AI interfaces ==

Estimated difficulty: '''Medium'''

The Spring Engine is already a popular engine for academic projects to study Artificial Intelligence, given the Open Source model of development and strong support within the A.I. community. This project could enhance Spring's attractiveness to developers and teachers wanting to explore or teach about A.I.

The Spring engine's A.I. interface supports bindings for multiple languages. Currently C++, C and java are supported, and AIs may be constructed using Lua.

Bindings for more languages and/or virtual machines would be added, to allow broader AI developing audience (for example: Ruby, Perl, JavaScript, Python, D, Go, Mono, LLVM, Parrot).

[[GSoC_More_AI_interfaces]]

== New Rendering System ==

Estimated difficulty: '''Medium'''

The Spring Engine's rendering system remains near the cutting edge of practical, functional OpenGL in a realtime environment, and is certainly notable amongst free, Open Source projects for its realism and flexibility. While it is not as advanced as the latest commercial engines, Spring's developers have made great strides in the last year, adding significant new features to the engine.

However, the core Spring rendering engine still includes many fixed function pipeline OpenGL functions. This rendering system is becoming deprecated and is generally slower and less flexible than more modern approaches.

Under this proposal, the rendering pipeline would be given a complete overhaul using modern graphic programming techniques, including shaders, standardised model formats that are easier for new artists to adapt to, and other enhancements, such as bump mapping, normal mapping, and multiple textures per Unit, while utilizing code that adheres to the OpenGL ES 2.0 specification.

[[GSoC_New_rendering_system]]

== Reconnect / Host change during a match ==

Estimated difficulty: '''Hard'''

Spring's network model implies the existence of a server to host a battle. For various reasons the network link between host and clients can be interrupted, or "desync". This causes an end-user to lose the true state of the simulation, and is a significant problem for players.

Our proposal is that a new system should be designed to allow manual and/or automatic switching of the game's host (possibly using an existing player's state, after testing load handling capabilities) and manual and/or automatic reconnection from client side if host remains the same.

[[GSoC_Reconnect_Host_change]]

Google Summer of Code 2010

2010-03-12T04:03:02Z

Argh: /* Basic ingame lobby */

[[Image:GSOC.png]]

= Project proposals =

This is the list of project ideas for students willing to work on the Spring engine during the Google Summer of Code 2010. If you wish, you may read our [[Google_Summer_of_Code_2010_student_application|student application]].

== Limited play area ==

Estimated difficulty: medium

Current Spring map formats have a hardcoded rectangle geometry; also they provide very limited support for defining aesthetics of the surrounding environment outside the play area.

The new system should allow the map to restrict the playable area to a subset of the global area, possibly adding support for multiple shapes and/or non rectangular shape restrictions.

The restriction shapes should be readable and changeable mid-game through the engine's Lua API. Proper handling of units which are suddenly off-map needs to be implemented.

[[GSoC_Limited_play_area]]

== Sensor handling redesign / simplification ==

Estimated difficulty: hard

The Spring Engine is currently capable of significant real-world applications in the areas of simulation; a better sensor system could greatly improve Spring's applicability to an even wider range of projects.

Currently there are a number of different "sensor" systems in the engine: LineOfSight, Radar, Sonar, and Seismic, some can be jammed, some cannot. Some respect terrain, and some are always circular.

A new sensor system should integrate the current LOS, Radar, Sonar, Seismic systems, to reduce amount of code per functionality, and eventually add additional features which would be then available for all types.

Preferably this all should also be faster than the current system or a compelling argument/experiment should be made that shows there cannot be a faster system with the same features.

[[GSoC_Sensor_handling_redesign]]

== Engine level abstraction of resources ==

Estimated difficulty: medium to hard

The Spring engine has its roots in being a Total Annihilation clone; even if such intent has been dropped since quite some time, the TA resource system is largely present in the codebase being hardcoded in a lot of critical places.

The old system needs to be replaced, the new one should be flexible enough to reproduce everything that the old system did and be able to imitate the behaviour of most common RTS game titles.

The engine's Lua API to fetch resources will have to be adapted to the new system, and new calls will have to be added to edit it.

[[GSoC_Engine_resource_abstraction]]

== Basic ingame lobby ==

Estimated difficulty: '''Hard'''

All existing Spring online player match-making systems ('lobbies') are either difficult to customize for game developers or have a different look and feel from the games which are expected to operate with them. While they are Open Source, and are being actively maintained, they do not provide the same end-user experience one finds in commercial titles.

An in-game Lobby, leveraging the Spring Engine's strong Lua scripting support, should be implemented with customization and control in mind. This may possibly be integrated with Spring's codebase, or it may be designed as a separate process overlaying to the game's UI.

This could also serve as a practical "front end" for the Spring Engine, giving all games developed on the engine a standardized, yet flexible, system to support their players.

[[GSoC_Ingame_lobby]]

== Smarter pathfinder ==

Estimated difficulty: '''Hard'''

Given the Spring Engine's need to routinely handle responsive and bug-free pathfinding and path-following for large numbers of actors, this project could become a useful showcase and useful codebase for projects needing pathfinders, and could expand the world's understanding of pathfinding and path-following in realtime systems.

Spring's pathfinder uses a 2d grid and is somewhat limited in functionality.
A partial/full rewrite should be introduced to add support for navigating using more than 8 primary directions and selectively ignore certain unit types for performance reasons.

Spring's Lua API should be extended to allow game developers to push new nodes/links and be able to alter or delete existing ones (for pathfinder-aware tunnels/teleporting/etc.).

Preferably this should all be faster than the current system, or a compelling argument/experiment should be made that shows there cannot be a faster system with the same features.

[[GSoC_Smarter_pathfinder]]

== More AI interfaces ==

Estimated difficulty: '''Medium'''

The Spring Engine is already a popular engine for academic projects to study Artificial Intelligence, given the Open Source model of development and strong support within the A.I. community. This project could enhance Spring's attractiveness to developers and teachers wanting to explore or teach about A.I.

The Spring engine's A.I. interface supports bindings for multiple languages. Currently C++, C and java are supported, and AIs may be constructed using Lua.

Bindings for more languages and/or virtual machines would be added, to allow broader AI developing audience (for example: Ruby, Perl, JavaScript, Python, D, Go, Mono, LLVM, Parrot).

[[GSoC_More_AI_interfaces]]

== New Rendering System ==

Estimated difficulty: '''Medium'''

The Spring Engine's rendering system remains near the cutting edge of practical, functional OpenGL in a realtime environment, and is certainly notable amongst free, Open Source projects for its realism and flexibility. While it is not as advanced as the latest commercial engines, Spring's developers have made great strides in the last year, adding significant new features to the engine.

However, the core Spring rendering engine still includes many fixed function pipeline OpenGL functions. This rendering system is becoming deprecated and is generally slower and less flexible than more modern approaches.

Under this proposal, the rendering pipeline would be given a complete overhaul using modern graphic programming techniques, including shaders, standardised model formats that are easier for new artists to adapt to, and other enhancements, such as bump mapping, normal mapping, and multiple textures per Unit, while utilizing code that adheres to the OpenGL ES 2.0 specification.

[[GSoC_New_rendering_system]]

== Reconnect / Host change during a match ==

Estimated difficulty: '''Hard'''

Spring's network model implies the existence of a server to host a battle. For various reasons the network link between host and clients can be interrupted, or "desync". This causes an end-user to lose the true state of the simulation, and is a significant problem for players.

Our proposal is that a new system should be designed to allow manual and/or automatic switching of the game's host (possibly using an existing player's state, after testing load handling capabilities) and manual and/or automatic reconnection from client side if host remains the same.

[[GSoC_Reconnect_Host_change]]

Google Summer of Code 2010

2010-03-12T04:02:48Z

Argh: /* Basic ingame lobby */

[[Image:GSOC.png]]

= Project proposals =

This is the list of project ideas for students willing to work on the Spring engine during the Google Summer of Code 2010. If you wish, you may read our [[Google_Summer_of_Code_2010_student_application|student application]].

== Limited play area ==

Estimated difficulty: medium

Current Spring map formats have a hardcoded rectangle geometry; also they provide very limited support for defining aesthetics of the surrounding environment outside the play area.

The new system should allow the map to restrict the playable area to a subset of the global area, possibly adding support for multiple shapes and/or non rectangular shape restrictions.

The restriction shapes should be readable and changeable mid-game through the engine's Lua API. Proper handling of units which are suddenly off-map needs to be implemented.

[[GSoC_Limited_play_area]]

== Sensor handling redesign / simplification ==

Estimated difficulty: hard

The Spring Engine is currently capable of significant real-world applications in the areas of simulation; a better sensor system could greatly improve Spring's applicability to an even wider range of projects.

Currently there are a number of different "sensor" systems in the engine: LineOfSight, Radar, Sonar, and Seismic, some can be jammed, some cannot. Some respect terrain, and some are always circular.

A new sensor system should integrate the current LOS, Radar, Sonar, Seismic systems, to reduce amount of code per functionality, and eventually add additional features which would be then available for all types.

Preferably this all should also be faster than the current system or a compelling argument/experiment should be made that shows there cannot be a faster system with the same features.

[[GSoC_Sensor_handling_redesign]]

== Engine level abstraction of resources ==

Estimated difficulty: medium to hard

The Spring engine has its roots in being a Total Annihilation clone; even if such intent has been dropped since quite some time, the TA resource system is largely present in the codebase being hardcoded in a lot of critical places.

The old system needs to be replaced, the new one should be flexible enough to reproduce everything that the old system did and be able to imitate the behaviour of most common RTS game titles.

The engine's Lua API to fetch resources will have to be adapted to the new system, and new calls will have to be added to edit it.

[[GSoC_Engine_resource_abstraction]]

== Basic ingame lobby ==

Estimated difficulty: Hard

All existing Spring online player match-making systems ('lobbies') are either difficult to customize for game developers or have a different look and feel from the games which are expected to operate with them. While they are Open Source, and are being actively maintained, they do not provide the same end-user experience one finds in commercial titles.

An in-game Lobby, leveraging the Spring Engine's strong Lua scripting support, should be implemented with customization and control in mind. This may possibly be integrated with Spring's codebase, or it may be designed as a separate process overlaying to the game's UI.

This could also serve as a practical "front end" for the Spring Engine, giving all games developed on the engine a standardized, yet flexible, system to support their players.

[[GSoC_Ingame_lobby]]

== Smarter pathfinder ==

Estimated difficulty: '''Hard'''

Given the Spring Engine's need to routinely handle responsive and bug-free pathfinding and path-following for large numbers of actors, this project could become a useful showcase and useful codebase for projects needing pathfinders, and could expand the world's understanding of pathfinding and path-following in realtime systems.

Spring's pathfinder uses a 2d grid and is somewhat limited in functionality.
A partial/full rewrite should be introduced to add support for navigating using more than 8 primary directions and selectively ignore certain unit types for performance reasons.

Spring's Lua API should be extended to allow game developers to push new nodes/links and be able to alter or delete existing ones (for pathfinder-aware tunnels/teleporting/etc.).

Preferably this should all be faster than the current system, or a compelling argument/experiment should be made that shows there cannot be a faster system with the same features.

[[GSoC_Smarter_pathfinder]]

== More AI interfaces ==

Estimated difficulty: '''Medium'''

The Spring Engine is already a popular engine for academic projects to study Artificial Intelligence, given the Open Source model of development and strong support within the A.I. community. This project could enhance Spring's attractiveness to developers and teachers wanting to explore or teach about A.I.

The Spring engine's A.I. interface supports bindings for multiple languages. Currently C++, C and java are supported, and AIs may be constructed using Lua.

Bindings for more languages and/or virtual machines would be added, to allow broader AI developing audience (for example: Ruby, Perl, JavaScript, Python, D, Go, Mono, LLVM, Parrot).

[[GSoC_More_AI_interfaces]]

== New Rendering System ==

Estimated difficulty: '''Medium'''

The Spring Engine's rendering system remains near the cutting edge of practical, functional OpenGL in a realtime environment, and is certainly notable amongst free, Open Source projects for its realism and flexibility. While it is not as advanced as the latest commercial engines, Spring's developers have made great strides in the last year, adding significant new features to the engine.

However, the core Spring rendering engine still includes many fixed function pipeline OpenGL functions. This rendering system is becoming deprecated and is generally slower and less flexible than more modern approaches.

Under this proposal, the rendering pipeline would be given a complete overhaul using modern graphic programming techniques, including shaders, standardised model formats that are easier for new artists to adapt to, and other enhancements, such as bump mapping, normal mapping, and multiple textures per Unit, while utilizing code that adheres to the OpenGL ES 2.0 specification.

[[GSoC_New_rendering_system]]

== Reconnect / Host change during a match ==

Estimated difficulty: '''Hard'''

Spring's network model implies the existence of a server to host a battle. For various reasons the network link between host and clients can be interrupted, or "desync". This causes an end-user to lose the true state of the simulation, and is a significant problem for players.

Our proposal is that a new system should be designed to allow manual and/or automatic switching of the game's host (possibly using an existing player's state, after testing load handling capabilities) and manual and/or automatic reconnection from client side if host remains the same.

[[GSoC_Reconnect_Host_change]]

Google Summer of Code 2010

2010-03-12T03:57:39Z

Argh: /* Smarter pathfinder */

[[Image:GSOC.png]]

= Project proposals =

This is the list of project ideas for students willing to work on the Spring engine during the Google Summer of Code 2010. If you wish, you may read our [[Google_Summer_of_Code_2010_student_application|student application]].

== Limited play area ==

Estimated difficulty: medium

Current Spring map formats have a hardcoded rectangle geometry; also they provide very limited support for defining aesthetics of the surrounding environment outside the play area.

The new system should allow the map to restrict the playable area to a subset of the global area, possibly adding support for multiple shapes and/or non rectangular shape restrictions.

The restriction shapes should be readable and changeable mid-game through the engine's Lua API. Proper handling of units which are suddenly off-map needs to be implemented.

[[GSoC_Limited_play_area]]

== Sensor handling redesign / simplification ==

Estimated difficulty: hard

The Spring Engine is currently capable of significant real-world applications in the areas of simulation; a better sensor system could greatly improve Spring's applicability to an even wider range of projects.

Currently there are a number of different "sensor" systems in the engine: LineOfSight, Radar, Sonar, and Seismic, some can be jammed, some cannot. Some respect terrain, and some are always circular.

A new sensor system should integrate the current LOS, Radar, Sonar, Seismic systems, to reduce amount of code per functionality, and eventually add additional features which would be then available for all types.

Preferably this all should also be faster than the current system or a compelling argument/experiment should be made that shows there cannot be a faster system with the same features.

[[GSoC_Sensor_handling_redesign]]

== Engine level abstraction of resources ==

Estimated difficulty: medium to hard

The Spring engine has its roots in being a Total Annihilation clone; even if such intent has been dropped since quite some time, the TA resource system is largely present in the codebase being hardcoded in a lot of critical places.

The old system needs to be replaced, the new one should be flexible enough to reproduce everything that the old system did and be able to imitate the behaviour of most common RTS game titles.

The engine's Lua API to fetch resources will have to be adapted to the new system, and new calls will have to be added to edit it.

[[GSoC_Engine_resource_abstraction]]

== Basic ingame lobby ==

Estimated difficulty: hard

All existing Spring interfaces (lobbies) are either difficult to customize for game developers or have a different look 'n feel from the game itself and require focus switch from the game itself to operate.

A new, Lua scriptable lobby should be implemented with customization and control in mind, possibly integrated with Spring codebase and/or running as a separate process overlaying to the game's UI.

Optionally, the engine's start screen should be replaced and integrated with it.

[[GSoC_Ingame_lobby]]

== Smarter pathfinder ==

Estimated difficulty: '''Hard'''

Given the Spring Engine's need to routinely handle responsive and bug-free pathfinding and path-following for large numbers of actors, this project could become a useful showcase and useful codebase for projects needing pathfinders, and could expand the world's understanding of pathfinding and path-following in realtime systems.

Spring's pathfinder uses a 2d grid and is somewhat limited in functionality.
A partial/full rewrite should be introduced to add support for navigating using more than 8 primary directions and selectively ignore certain unit types for performance reasons.

Spring's Lua API should be extended to allow game developers to push new nodes/links and be able to alter or delete existing ones (for pathfinder-aware tunnels/teleporting/etc.).

Preferably this should all be faster than the current system, or a compelling argument/experiment should be made that shows there cannot be a faster system with the same features.

[[GSoC_Smarter_pathfinder]]

== More AI interfaces ==

Estimated difficulty: '''Medium'''

The Spring Engine is already a popular engine for academic projects to study Artificial Intelligence, given the Open Source model of development and strong support within the A.I. community. This project could enhance Spring's attractiveness to developers and teachers wanting to explore or teach about A.I.

The Spring engine's A.I. interface supports bindings for multiple languages. Currently C++, C and java are supported, and AIs may be constructed using Lua.

Bindings for more languages and/or virtual machines would be added, to allow broader AI developing audience (for example: Ruby, Perl, JavaScript, Python, D, Go, Mono, LLVM, Parrot).

[[GSoC_More_AI_interfaces]]

== New Rendering System ==

Estimated difficulty: '''Medium'''

The Spring Engine's rendering system remains near the cutting edge of practical, functional OpenGL in a realtime environment, and is certainly notable amongst free, Open Source projects for its realism and flexibility. While it is not as advanced as the latest commercial engines, Spring's developers have made great strides in the last year, adding significant new features to the engine.

However, the core Spring rendering engine still includes many fixed function pipeline OpenGL functions. This rendering system is becoming deprecated and is generally slower and less flexible than more modern approaches.

Under this proposal, the rendering pipeline would be given a complete overhaul using modern graphic programming techniques, including shaders, standardised model formats that are easier for new artists to adapt to, and other enhancements, such as bump mapping, normal mapping, and multiple textures per Unit, while utilizing code that adheres to the OpenGL ES 2.0 specification.

[[GSoC_New_rendering_system]]

== Reconnect / Host change during a match ==

Estimated difficulty: '''Hard'''

Spring's network model implies the existence of a server to host a battle. For various reasons the network link between host and clients can be interrupted, or "desync". This causes an end-user to lose the true state of the simulation, and is a significant problem for players.

Our proposal is that a new system should be designed to allow manual and/or automatic switching of the game's host (possibly using an existing player's state, after testing load handling capabilities) and manual and/or automatic reconnection from client side if host remains the same.

[[GSoC_Reconnect_Host_change]]

Google Summer of Code 2010

2010-03-12T03:57:04Z

Argh: /* Smarter pathfinder */

[[Image:GSOC.png]]

= Project proposals =

This is the list of project ideas for students willing to work on the Spring engine during the Google Summer of Code 2010. If you wish, you may read our [[Google_Summer_of_Code_2010_student_application|student application]].

== Limited play area ==

Estimated difficulty: medium

Current Spring map formats have a hardcoded rectangle geometry; also they provide very limited support for defining aesthetics of the surrounding environment outside the play area.

The new system should allow the map to restrict the playable area to a subset of the global area, possibly adding support for multiple shapes and/or non rectangular shape restrictions.

The restriction shapes should be readable and changeable mid-game through the engine's Lua API. Proper handling of units which are suddenly off-map needs to be implemented.

[[GSoC_Limited_play_area]]

== Sensor handling redesign / simplification ==

Estimated difficulty: hard

The Spring Engine is currently capable of significant real-world applications in the areas of simulation; a better sensor system could greatly improve Spring's applicability to an even wider range of projects.

Currently there are a number of different "sensor" systems in the engine: LineOfSight, Radar, Sonar, and Seismic, some can be jammed, some cannot. Some respect terrain, and some are always circular.

A new sensor system should integrate the current LOS, Radar, Sonar, Seismic systems, to reduce amount of code per functionality, and eventually add additional features which would be then available for all types.

Preferably this all should also be faster than the current system or a compelling argument/experiment should be made that shows there cannot be a faster system with the same features.

[[GSoC_Sensor_handling_redesign]]

== Engine level abstraction of resources ==

Estimated difficulty: medium to hard

The Spring engine has its roots in being a Total Annihilation clone; even if such intent has been dropped since quite some time, the TA resource system is largely present in the codebase being hardcoded in a lot of critical places.

The old system needs to be replaced, the new one should be flexible enough to reproduce everything that the old system did and be able to imitate the behaviour of most common RTS game titles.

The engine's Lua API to fetch resources will have to be adapted to the new system, and new calls will have to be added to edit it.

[[GSoC_Engine_resource_abstraction]]

== Basic ingame lobby ==

Estimated difficulty: hard

All existing Spring interfaces (lobbies) are either difficult to customize for game developers or have a different look 'n feel from the game itself and require focus switch from the game itself to operate.

A new, Lua scriptable lobby should be implemented with customization and control in mind, possibly integrated with Spring codebase and/or running as a separate process overlaying to the game's UI.

Optionally, the engine's start screen should be replaced and integrated with it.

[[GSoC_Ingame_lobby]]

== Smarter pathfinder ==

Estimated difficulty: '''Hard'''

Given the Spring Engine's need to routinely handle responsive and bug-free pathfinding and path-following for large numbers of actors, such a project could become a useful showcase and useful codebase for projects needing pathfinders, and could expand the world's understanding of pathfinding and path-following in realtime systems.

Spring's pathfinder uses a 2d grid and is somewhat limited in functionality.
A partial/full rewrite should be introduced to add support for navigating using more than 8 primary directions and selectively ignore certain unit types for performance reasons.

Spring's Lua API should be extended to allow game developers to push new nodes/links and be able to alter or delete existing ones (for pathfinder-aware tunnels/teleporting/etc.).

Preferably this should all be faster than the current system, or a compelling argument/experiment should be made that shows there cannot be a faster system with the same features.

[[GSoC_Smarter_pathfinder]]

== More AI interfaces ==

Estimated difficulty: '''Medium'''

The Spring Engine is already a popular engine for academic projects to study Artificial Intelligence, given the Open Source model of development and strong support within the A.I. community. This project could enhance Spring's attractiveness to developers and teachers wanting to explore or teach about A.I.

The Spring engine's A.I. interface supports bindings for multiple languages. Currently C++, C and java are supported, and AIs may be constructed using Lua.

Bindings for more languages and/or virtual machines would be added, to allow broader AI developing audience (for example: Ruby, Perl, JavaScript, Python, D, Go, Mono, LLVM, Parrot).

[[GSoC_More_AI_interfaces]]

== New Rendering System ==

Estimated difficulty: '''Medium'''

The Spring Engine's rendering system remains near the cutting edge of practical, functional OpenGL in a realtime environment, and is certainly notable amongst free, Open Source projects for its realism and flexibility. While it is not as advanced as the latest commercial engines, Spring's developers have made great strides in the last year, adding significant new features to the engine.

However, the core Spring rendering engine still includes many fixed function pipeline OpenGL functions. This rendering system is becoming deprecated and is generally slower and less flexible than more modern approaches.

Under this proposal, the rendering pipeline would be given a complete overhaul using modern graphic programming techniques, including shaders, standardised model formats that are easier for new artists to adapt to, and other enhancements, such as bump mapping, normal mapping, and multiple textures per Unit, while utilizing code that adheres to the OpenGL ES 2.0 specification.

[[GSoC_New_rendering_system]]

== Reconnect / Host change during a match ==

Estimated difficulty: '''Hard'''

Spring's network model implies the existence of a server to host a battle. For various reasons the network link between host and clients can be interrupted, or "desync". This causes an end-user to lose the true state of the simulation, and is a significant problem for players.

Our proposal is that a new system should be designed to allow manual and/or automatic switching of the game's host (possibly using an existing player's state, after testing load handling capabilities) and manual and/or automatic reconnection from client side if host remains the same.

[[GSoC_Reconnect_Host_change]]

Google Summer of Code 2010

2010-03-12T03:56:51Z

Argh: /* Reconnect / Host change during a match */

[[Image:GSOC.png]]

= Project proposals =

This is the list of project ideas for students willing to work on the Spring engine during the Google Summer of Code 2010. If you wish, you may read our [[Google_Summer_of_Code_2010_student_application|student application]].

== Limited play area ==

Estimated difficulty: medium

Current Spring map formats have a hardcoded rectangle geometry; also they provide very limited support for defining aesthetics of the surrounding environment outside the play area.

The new system should allow the map to restrict the playable area to a subset of the global area, possibly adding support for multiple shapes and/or non rectangular shape restrictions.

The restriction shapes should be readable and changeable mid-game through the engine's Lua API. Proper handling of units which are suddenly off-map needs to be implemented.

[[GSoC_Limited_play_area]]

== Sensor handling redesign / simplification ==

Estimated difficulty: hard

The Spring Engine is currently capable of significant real-world applications in the areas of simulation; a better sensor system could greatly improve Spring's applicability to an even wider range of projects.

Currently there are a number of different "sensor" systems in the engine: LineOfSight, Radar, Sonar, and Seismic, some can be jammed, some cannot. Some respect terrain, and some are always circular.

A new sensor system should integrate the current LOS, Radar, Sonar, Seismic systems, to reduce amount of code per functionality, and eventually add additional features which would be then available for all types.

Preferably this all should also be faster than the current system or a compelling argument/experiment should be made that shows there cannot be a faster system with the same features.

[[GSoC_Sensor_handling_redesign]]

== Engine level abstraction of resources ==

Estimated difficulty: medium to hard

The Spring engine has its roots in being a Total Annihilation clone; even if such intent has been dropped since quite some time, the TA resource system is largely present in the codebase being hardcoded in a lot of critical places.

The old system needs to be replaced, the new one should be flexible enough to reproduce everything that the old system did and be able to imitate the behaviour of most common RTS game titles.

The engine's Lua API to fetch resources will have to be adapted to the new system, and new calls will have to be added to edit it.

[[GSoC_Engine_resource_abstraction]]

== Basic ingame lobby ==

Estimated difficulty: hard

All existing Spring interfaces (lobbies) are either difficult to customize for game developers or have a different look 'n feel from the game itself and require focus switch from the game itself to operate.

A new, Lua scriptable lobby should be implemented with customization and control in mind, possibly integrated with Spring codebase and/or running as a separate process overlaying to the game's UI.

Optionally, the engine's start screen should be replaced and integrated with it.

[[GSoC_Ingame_lobby]]

== Smarter pathfinder ==

Estimated difficulty: '''hard'''

Given the Spring Engine's need to routinely handle responsive and bug-free pathfinding and path-following for large numbers of actors, such a project could become a useful showcase and useful codebase for projects needing pathfinders, and could expand the world's understanding of pathfinding and path-following in realtime systems.

Spring's pathfinder uses a 2d grid and is somewhat limited in functionality.
A partial/full rewrite should be introduced to add support for navigating using more than 8 primary directions and selectively ignore certain unit types for performance reasons.

Spring's Lua API should be extended to allow game developers to push new nodes/links and be able to alter or delete existing ones (for pathfinder-aware tunnels/teleporting/etc.).

Preferably this should all be faster than the current system, or a compelling argument/experiment should be made that shows there cannot be a faster system with the same features.

[[GSoC_Smarter_pathfinder]]

== More AI interfaces ==

Estimated difficulty: '''Medium'''

The Spring Engine is already a popular engine for academic projects to study Artificial Intelligence, given the Open Source model of development and strong support within the A.I. community. This project could enhance Spring's attractiveness to developers and teachers wanting to explore or teach about A.I.

The Spring engine's A.I. interface supports bindings for multiple languages. Currently C++, C and java are supported, and AIs may be constructed using Lua.

Bindings for more languages and/or virtual machines would be added, to allow broader AI developing audience (for example: Ruby, Perl, JavaScript, Python, D, Go, Mono, LLVM, Parrot).

[[GSoC_More_AI_interfaces]]

== New Rendering System ==

Estimated difficulty: '''Medium'''

The Spring Engine's rendering system remains near the cutting edge of practical, functional OpenGL in a realtime environment, and is certainly notable amongst free, Open Source projects for its realism and flexibility. While it is not as advanced as the latest commercial engines, Spring's developers have made great strides in the last year, adding significant new features to the engine.

However, the core Spring rendering engine still includes many fixed function pipeline OpenGL functions. This rendering system is becoming deprecated and is generally slower and less flexible than more modern approaches.

Under this proposal, the rendering pipeline would be given a complete overhaul using modern graphic programming techniques, including shaders, standardised model formats that are easier for new artists to adapt to, and other enhancements, such as bump mapping, normal mapping, and multiple textures per Unit, while utilizing code that adheres to the OpenGL ES 2.0 specification.

[[GSoC_New_rendering_system]]

== Reconnect / Host change during a match ==

Estimated difficulty: '''Hard'''

Spring's network model implies the existence of a server to host a battle. For various reasons the network link between host and clients can be interrupted, or "desync". This causes an end-user to lose the true state of the simulation, and is a significant problem for players.

Our proposal is that a new system should be designed to allow manual and/or automatic switching of the game's host (possibly using an existing player's state, after testing load handling capabilities) and manual and/or automatic reconnection from client side if host remains the same.

[[GSoC_Reconnect_Host_change]]

Google Summer of Code 2010

2010-03-12T03:54:52Z

Argh: /* New Rendering System */

[[Image:GSOC.png]]

= Project proposals =

This is the list of project ideas for students willing to work on the Spring engine during the Google Summer of Code 2010. If you wish, you may read our [[Google_Summer_of_Code_2010_student_application|student application]].

== Limited play area ==

Estimated difficulty: medium

Current Spring map formats have a hardcoded rectangle geometry; also they provide very limited support for defining aesthetics of the surrounding environment outside the play area.

The new system should allow the map to restrict the playable area to a subset of the global area, possibly adding support for multiple shapes and/or non rectangular shape restrictions.

The restriction shapes should be readable and changeable mid-game through the engine's Lua API. Proper handling of units which are suddenly off-map needs to be implemented.

[[GSoC_Limited_play_area]]

== Sensor handling redesign / simplification ==

Estimated difficulty: hard

The Spring Engine is currently capable of significant real-world applications in the areas of simulation; a better sensor system could greatly improve Spring's applicability to an even wider range of projects.

Currently there are a number of different "sensor" systems in the engine: LineOfSight, Radar, Sonar, and Seismic, some can be jammed, some cannot. Some respect terrain, and some are always circular.

A new sensor system should integrate the current LOS, Radar, Sonar, Seismic systems, to reduce amount of code per functionality, and eventually add additional features which would be then available for all types.

Preferably this all should also be faster than the current system or a compelling argument/experiment should be made that shows there cannot be a faster system with the same features.

[[GSoC_Sensor_handling_redesign]]

== Engine level abstraction of resources ==

Estimated difficulty: medium to hard

The Spring engine has its roots in being a Total Annihilation clone; even if such intent has been dropped since quite some time, the TA resource system is largely present in the codebase being hardcoded in a lot of critical places.

The old system needs to be replaced, the new one should be flexible enough to reproduce everything that the old system did and be able to imitate the behaviour of most common RTS game titles.

The engine's Lua API to fetch resources will have to be adapted to the new system, and new calls will have to be added to edit it.

[[GSoC_Engine_resource_abstraction]]

== Basic ingame lobby ==

Estimated difficulty: hard

All existing Spring interfaces (lobbies) are either difficult to customize for game developers or have a different look 'n feel from the game itself and require focus switch from the game itself to operate.

A new, Lua scriptable lobby should be implemented with customization and control in mind, possibly integrated with Spring codebase and/or running as a separate process overlaying to the game's UI.

Optionally, the engine's start screen should be replaced and integrated with it.

[[GSoC_Ingame_lobby]]

== Smarter pathfinder ==

Estimated difficulty: '''hard'''

Given the Spring Engine's need to routinely handle responsive and bug-free pathfinding and path-following for large numbers of actors, such a project could become a useful showcase and useful codebase for projects needing pathfinders, and could expand the world's understanding of pathfinding and path-following in realtime systems.

Spring's pathfinder uses a 2d grid and is somewhat limited in functionality.
A partial/full rewrite should be introduced to add support for navigating using more than 8 primary directions and selectively ignore certain unit types for performance reasons.

Spring's Lua API should be extended to allow game developers to push new nodes/links and be able to alter or delete existing ones (for pathfinder-aware tunnels/teleporting/etc.).

Preferably this should all be faster than the current system, or a compelling argument/experiment should be made that shows there cannot be a faster system with the same features.

[[GSoC_Smarter_pathfinder]]

== More AI interfaces ==

Estimated difficulty: '''Medium'''

The Spring Engine is already a popular engine for academic projects to study Artificial Intelligence, given the Open Source model of development and strong support within the A.I. community. This project could enhance Spring's attractiveness to developers and teachers wanting to explore or teach about A.I.

The Spring engine's A.I. interface supports bindings for multiple languages. Currently C++, C and java are supported, and AIs may be constructed using Lua.

Bindings for more languages and/or virtual machines would be added, to allow broader AI developing audience (for example: Ruby, Perl, JavaScript, Python, D, Go, Mono, LLVM, Parrot).

[[GSoC_More_AI_interfaces]]

== New Rendering System ==

Estimated difficulty: '''Medium'''

The Spring Engine's rendering system remains near the cutting edge of practical, functional OpenGL in a realtime environment, and is certainly notable amongst free, Open Source projects for its realism and flexibility. While it is not as advanced as the latest commercial engines, Spring's developers have made great strides in the last year, adding significant new features to the engine.

However, the core Spring rendering engine still includes many fixed function pipeline OpenGL functions. This rendering system is becoming deprecated and is generally slower and less flexible than more modern approaches.

Under this proposal, the rendering pipeline would be given a complete overhaul using modern graphic programming techniques, including shaders, standardised model formats that are easier for new artists to adapt to, and other enhancements, such as bump mapping, normal mapping, and multiple textures per Unit, while utilizing code that adheres to the OpenGL ES 2.0 specification.

[[GSoC_New_rendering_system]]

== Reconnect / Host change during a match ==

Estimated difficulty: medium to hard

Spring's network model implies the existence of a server to host a battle. For various reasons the network link between host and clients can die, so a system should be designed to allow manual and/or automatic switching of the game's host (possibly using an existing player after testing load handling capabilities) and manual and/or automatic reconnection from client side if host remains the same.

[[GSoC_Reconnect_Host_change]]

Google Summer of Code 2010

2010-03-12T03:47:21Z

Argh: /* More AI interfaces */

[[Image:GSOC.png]]

= Project proposals =

This is the list of project ideas for students willing to work on the Spring engine during the Google Summer of Code 2010. If you wish, you may read our [[Google_Summer_of_Code_2010_student_application|student application]].

== Limited play area ==

Estimated difficulty: medium

Current Spring map formats have a hardcoded rectangle geometry; also they provide very limited support for defining aesthetics of the surrounding environment outside the play area.

The new system should allow the map to restrict the playable area to a subset of the global area, possibly adding support for multiple shapes and/or non rectangular shape restrictions.

The restriction shapes should be readable and changeable mid-game through the engine's Lua API. Proper handling of units which are suddenly off-map needs to be implemented.

[[GSoC_Limited_play_area]]

== Sensor handling redesign / simplification ==

Estimated difficulty: hard

The Spring Engine is currently capable of significant real-world applications in the areas of simulation; a better sensor system could greatly improve Spring's applicability to an even wider range of projects.

Currently there are a number of different "sensor" systems in the engine: LineOfSight, Radar, Sonar, and Seismic, some can be jammed, some cannot. Some respect terrain, and some are always circular.

A new sensor system should integrate the current LOS, Radar, Sonar, Seismic systems, to reduce amount of code per functionality, and eventually add additional features which would be then available for all types.

Preferably this all should also be faster than the current system or a compelling argument/experiment should be made that shows there cannot be a faster system with the same features.

[[GSoC_Sensor_handling_redesign]]

== Engine level abstraction of resources ==

Estimated difficulty: medium to hard

The Spring engine has its roots in being a Total Annihilation clone; even if such intent has been dropped since quite some time, the TA resource system is largely present in the codebase being hardcoded in a lot of critical places.

The old system needs to be replaced, the new one should be flexible enough to reproduce everything that the old system did and be able to imitate the behaviour of most common RTS game titles.

The engine's Lua API to fetch resources will have to be adapted to the new system, and new calls will have to be added to edit it.

[[GSoC_Engine_resource_abstraction]]

== Basic ingame lobby ==

Estimated difficulty: hard

All existing Spring interfaces (lobbies) are either difficult to customize for game developers or have a different look 'n feel from the game itself and require focus switch from the game itself to operate.

A new, Lua scriptable lobby should be implemented with customization and control in mind, possibly integrated with Spring codebase and/or running as a separate process overlaying to the game's UI.

Optionally, the engine's start screen should be replaced and integrated with it.

[[GSoC_Ingame_lobby]]

== Smarter pathfinder ==

Estimated difficulty: '''hard'''

Given the Spring Engine's need to routinely handle responsive and bug-free pathfinding and path-following for large numbers of actors, such a project could become a useful showcase and useful codebase for projects needing pathfinders, and could expand the world's understanding of pathfinding and path-following in realtime systems.

Spring's pathfinder uses a 2d grid and is somewhat limited in functionality.
A partial/full rewrite should be introduced to add support for navigating using more than 8 primary directions and selectively ignore certain unit types for performance reasons.

Spring's Lua API should be extended to allow game developers to push new nodes/links and be able to alter or delete existing ones (for pathfinder-aware tunnels/teleporting/etc.).

Preferably this should all be faster than the current system, or a compelling argument/experiment should be made that shows there cannot be a faster system with the same features.

[[GSoC_Smarter_pathfinder]]

== More AI interfaces ==

Estimated difficulty: '''Medium'''

The Spring Engine is already a popular engine for academic projects to study Artificial Intelligence, given the Open Source model of development and strong support within the A.I. community. This project could enhance Spring's attractiveness to developers and teachers wanting to explore or teach about A.I.

The Spring engine's A.I. interface supports bindings for multiple languages. Currently C++, C and java are supported, and AIs may be constructed using Lua.

Bindings for more languages and/or virtual machines would be added, to allow broader AI developing audience (for example: Ruby, Perl, JavaScript, Python, D, Go, Mono, LLVM, Parrot).

[[GSoC_More_AI_interfaces]]

== New Rendering System ==

Estimated difficulty: medium

The Spring rendering engine uses a lot of FFP (fixed function pipeline) OpenGL functions. This model is becoming deprecated and is generally slower and less flexible than shader usage.

The rendering code should get a complete overhaul using modern graphic programming techniques such as shaders, implement load support for more standardised model formats (backwards compatibility with current available formats is mandatory either through direct load or automatic conversion to the new types) and eventually introduce some graphic enhancing features (bump mapping, normal mapping, multitexturing, etc.).

OpenGL ES 2.0 compatibility should be aimed at where possible.

[[GSoC_New_rendering_system]]

== Reconnect / Host change during a match ==

Estimated difficulty: medium to hard

Spring's network model implies the existence of a server to host a battle. For various reasons the network link between host and clients can die, so a system should be designed to allow manual and/or automatic switching of the game's host (possibly using an existing player after testing load handling capabilities) and manual and/or automatic reconnection from client side if host remains the same.

[[GSoC_Reconnect_Host_change]]

Google Summer of Code 2010

2010-03-12T03:43:19Z

Argh: /* Smarter pathfinder */

[[Image:GSOC.png]]

= Project proposals =

This is the list of project ideas for students willing to work on the Spring engine during the Google Summer of Code 2010. If you wish, you may read our [[Google_Summer_of_Code_2010_student_application|student application]].

== Limited play area ==

Estimated difficulty: medium

Current Spring map formats have a hardcoded rectangle geometry; also they provide very limited support for defining aesthetics of the surrounding environment outside the play area.

The new system should allow the map to restrict the playable area to a subset of the global area, possibly adding support for multiple shapes and/or non rectangular shape restrictions.

The restriction shapes should be readable and changeable mid-game through the engine's Lua API. Proper handling of units which are suddenly off-map needs to be implemented.

[[GSoC_Limited_play_area]]

== Sensor handling redesign / simplification ==

Estimated difficulty: hard

The Spring Engine is currently capable of significant real-world applications in the areas of simulation; a better sensor system could greatly improve Spring's applicability to an even wider range of projects.

Currently there are a number of different "sensor" systems in the engine: LineOfSight, Radar, Sonar, and Seismic, some can be jammed, some cannot. Some respect terrain, and some are always circular.

A new sensor system should integrate the current LOS, Radar, Sonar, Seismic systems, to reduce amount of code per functionality, and eventually add additional features which would be then available for all types.

Preferably this all should also be faster than the current system or a compelling argument/experiment should be made that shows there cannot be a faster system with the same features.

[[GSoC_Sensor_handling_redesign]]

== Engine level abstraction of resources ==

Estimated difficulty: medium to hard

The Spring engine has its roots in being a Total Annihilation clone; even if such intent has been dropped since quite some time, the TA resource system is largely present in the codebase being hardcoded in a lot of critical places.

The old system needs to be replaced, the new one should be flexible enough to reproduce everything that the old system did and be able to imitate the behaviour of most common RTS game titles.

The engine's Lua API to fetch resources will have to be adapted to the new system, and new calls will have to be added to edit it.

[[GSoC_Engine_resource_abstraction]]

== Basic ingame lobby ==

Estimated difficulty: hard

All existing Spring interfaces (lobbies) are either difficult to customize for game developers or have a different look 'n feel from the game itself and require focus switch from the game itself to operate.

A new, Lua scriptable lobby should be implemented with customization and control in mind, possibly integrated with Spring codebase and/or running as a separate process overlaying to the game's UI.

Optionally, the engine's start screen should be replaced and integrated with it.

[[GSoC_Ingame_lobby]]

== Smarter pathfinder ==

Estimated difficulty: '''hard'''

Given the Spring Engine's need to routinely handle responsive and bug-free pathfinding and path-following for large numbers of actors, such a project could become a useful showcase and useful codebase for projects needing pathfinders, and could expand the world's understanding of pathfinding and path-following in realtime systems.

Spring's pathfinder uses a 2d grid and is somewhat limited in functionality.
A partial/full rewrite should be introduced to add support for navigating using more than 8 primary directions and selectively ignore certain unit types for performance reasons.

Spring's Lua API should be extended to allow game developers to push new nodes/links and be able to alter or delete existing ones (for pathfinder-aware tunnels/teleporting/etc.).

Preferably this should all be faster than the current system, or a compelling argument/experiment should be made that shows there cannot be a faster system with the same features.

[[GSoC_Smarter_pathfinder]]

== More AI interfaces ==

Estimated difficulty: medium

The Spring engine's AI interface supports bindings for multiple languages, currently legacy C++, C and java are supported.

Bindings for more languages and/or virtual machines should be added to allow broader AI developing audience (for example: Ruby, Perl, JavaScript, Python, D, Go, Mono, LLVM, Parrot).

[[GSoC_More_AI_interfaces]]

== New Rendering System ==

Estimated difficulty: medium

The Spring rendering engine uses a lot of FFP (fixed function pipeline) OpenGL functions. This model is becoming deprecated and is generally slower and less flexible than shader usage.

The rendering code should get a complete overhaul using modern graphic programming techniques such as shaders, implement load support for more standardised model formats (backwards compatibility with current available formats is mandatory either through direct load or automatic conversion to the new types) and eventually introduce some graphic enhancing features (bump mapping, normal mapping, multitexturing, etc.).

OpenGL ES 2.0 compatibility should be aimed at where possible.

[[GSoC_New_rendering_system]]

== Reconnect / Host change during a match ==

Estimated difficulty: medium to hard

Spring's network model implies the existence of a server to host a battle. For various reasons the network link between host and clients can die, so a system should be designed to allow manual and/or automatic switching of the game's host (possibly using an existing player after testing load handling capabilities) and manual and/or automatic reconnection from client side if host remains the same.

[[GSoC_Reconnect_Host_change]]

Google Summer of Code 2010

2010-03-12T03:42:55Z

Argh: /* Smarter pathfinder */

[[Image:GSOC.png]]

= Project proposals =

This is the list of project ideas for students willing to work on the Spring engine during the Google Summer of Code 2010. If you wish, you may read our [[Google_Summer_of_Code_2010_student_application|student application]].

== Limited play area ==

Estimated difficulty: medium

Current Spring map formats have a hardcoded rectangle geometry; also they provide very limited support for defining aesthetics of the surrounding environment outside the play area.

The new system should allow the map to restrict the playable area to a subset of the global area, possibly adding support for multiple shapes and/or non rectangular shape restrictions.

The restriction shapes should be readable and changeable mid-game through the engine's Lua API. Proper handling of units which are suddenly off-map needs to be implemented.

[[GSoC_Limited_play_area]]

== Sensor handling redesign / simplification ==

Estimated difficulty: hard

The Spring Engine is currently capable of significant real-world applications in the areas of simulation; a better sensor system could greatly improve Spring's applicability to an even wider range of projects.

Currently there are a number of different "sensor" systems in the engine: LineOfSight, Radar, Sonar, and Seismic, some can be jammed, some cannot. Some respect terrain, and some are always circular.

A new sensor system should integrate the current LOS, Radar, Sonar, Seismic systems, to reduce amount of code per functionality, and eventually add additional features which would be then available for all types.

Preferably this all should also be faster than the current system or a compelling argument/experiment should be made that shows there cannot be a faster system with the same features.

[[GSoC_Sensor_handling_redesign]]

== Engine level abstraction of resources ==

Estimated difficulty: medium to hard

The Spring engine has its roots in being a Total Annihilation clone; even if such intent has been dropped since quite some time, the TA resource system is largely present in the codebase being hardcoded in a lot of critical places.

The old system needs to be replaced, the new one should be flexible enough to reproduce everything that the old system did and be able to imitate the behaviour of most common RTS game titles.

The engine's Lua API to fetch resources will have to be adapted to the new system, and new calls will have to be added to edit it.

[[GSoC_Engine_resource_abstraction]]

== Basic ingame lobby ==

Estimated difficulty: hard

All existing Spring interfaces (lobbies) are either difficult to customize for game developers or have a different look 'n feel from the game itself and require focus switch from the game itself to operate.

A new, Lua scriptable lobby should be implemented with customization and control in mind, possibly integrated with Spring codebase and/or running as a separate process overlaying to the game's UI.

Optionally, the engine's start screen should be replaced and integrated with it.

[[GSoC_Ingame_lobby]]

== Smarter pathfinder ==

Estimated difficulty: hard

Given the Spring Engine's need to routinely handle responsive and bug-free pathfinding and path-following for large numbers of actors, such a project could become a useful showcase and useful codebase for projects needing pathfinders, and could expand the world's understanding of pathfinding and path-following in realtime systems.

Spring's pathfinder uses a 2d grid and is somewhat limited in functionality.
A partial/full rewrite should be introduced to add support for navigating using more than 8 primary directions and selectively ignore certain unit types for performance reasons.

Spring's Lua API should be extended to allow game developers to push new nodes/links and be able to alter or delete existing ones (for pathfinder-aware tunnels/teleporting/etc.).

Preferably this should all be faster than the current system, or a compelling argument/experiment should be made that shows there cannot be a faster system with the same features.

[[GSoC_Smarter_pathfinder]]

== More AI interfaces ==

Estimated difficulty: medium

The Spring engine's AI interface supports bindings for multiple languages, currently legacy C++, C and java are supported.

Bindings for more languages and/or virtual machines should be added to allow broader AI developing audience (for example: Ruby, Perl, JavaScript, Python, D, Go, Mono, LLVM, Parrot).

[[GSoC_More_AI_interfaces]]

== New Rendering System ==

Estimated difficulty: medium

The Spring rendering engine uses a lot of FFP (fixed function pipeline) OpenGL functions. This model is becoming deprecated and is generally slower and less flexible than shader usage.

The rendering code should get a complete overhaul using modern graphic programming techniques such as shaders, implement load support for more standardised model formats (backwards compatibility with current available formats is mandatory either through direct load or automatic conversion to the new types) and eventually introduce some graphic enhancing features (bump mapping, normal mapping, multitexturing, etc.).

OpenGL ES 2.0 compatibility should be aimed at where possible.

[[GSoC_New_rendering_system]]

== Reconnect / Host change during a match ==

Estimated difficulty: medium to hard

Spring's network model implies the existence of a server to host a battle. For various reasons the network link between host and clients can die, so a system should be designed to allow manual and/or automatic switching of the game's host (possibly using an existing player after testing load handling capabilities) and manual and/or automatic reconnection from client side if host remains the same.

[[GSoC_Reconnect_Host_change]]

Google Summer of Code 2010

2010-03-12T03:42:32Z

Argh: /* Sensor handling redesign / simplification */

[[Image:GSOC.png]]

= Project proposals =

This is the list of project ideas for students willing to work on the Spring engine during the Google Summer of Code 2010. If you wish, you may read our [[Google_Summer_of_Code_2010_student_application|student application]].

== Limited play area ==

Estimated difficulty: medium

Current Spring map formats have a hardcoded rectangle geometry; also they provide very limited support for defining aesthetics of the surrounding environment outside the play area.

The new system should allow the map to restrict the playable area to a subset of the global area, possibly adding support for multiple shapes and/or non rectangular shape restrictions.

The restriction shapes should be readable and changeable mid-game through the engine's Lua API. Proper handling of units which are suddenly off-map needs to be implemented.

[[GSoC_Limited_play_area]]

== Sensor handling redesign / simplification ==

Estimated difficulty: hard

The Spring Engine is currently capable of significant real-world applications in the areas of simulation; a better sensor system could greatly improve Spring's applicability to an even wider range of projects.

Currently there are a number of different "sensor" systems in the engine: LineOfSight, Radar, Sonar, and Seismic, some can be jammed, some cannot. Some respect terrain, and some are always circular.

A new sensor system should integrate the current LOS, Radar, Sonar, Seismic systems, to reduce amount of code per functionality, and eventually add additional features which would be then available for all types.

Preferably this all should also be faster than the current system or a compelling argument/experiment should be made that shows there cannot be a faster system with the same features.

[[GSoC_Sensor_handling_redesign]]

== Engine level abstraction of resources ==

Estimated difficulty: medium to hard

The Spring engine has its roots in being a Total Annihilation clone; even if such intent has been dropped since quite some time, the TA resource system is largely present in the codebase being hardcoded in a lot of critical places.

The old system needs to be replaced, the new one should be flexible enough to reproduce everything that the old system did and be able to imitate the behaviour of most common RTS game titles.

The engine's Lua API to fetch resources will have to be adapted to the new system, and new calls will have to be added to edit it.

[[GSoC_Engine_resource_abstraction]]

== Basic ingame lobby ==

Estimated difficulty: hard

All existing Spring interfaces (lobbies) are either difficult to customize for game developers or have a different look 'n feel from the game itself and require focus switch from the game itself to operate.

A new, Lua scriptable lobby should be implemented with customization and control in mind, possibly integrated with Spring codebase and/or running as a separate process overlaying to the game's UI.

Optionally, the engine's start screen should be replaced and integrated with it.

[[GSoC_Ingame_lobby]]

== Smarter pathfinder ==

Estimated difficulty: hard

Spring's pathfinder uses a 2d grid and is somewhat limited in functionality.
A partial/full rewrite should be introduced to add support for navigating using more than 8 primary directions and selectively ignore certain unit types for performance reasons.

Spring's Lua API should be extended to allow game developers to push new nodes/links and be able to alter or delete existing ones (for pathfinder-aware tunnels/teleporting/etc.).

Preferably this should all be faster than the current system, or a compelling argument/experiment should be made that shows there cannot be a faster system with the same features.

Given the Spring Engine's need to routinely handle responsive and bug-free pathfinding and path-following for large numbers of actors, such a project could become a useful showcase and useful codebase for projects needing pathfinders, and could expand the world's understanding of pathfinding and path-following in realtime systems.

[[GSoC_Smarter_pathfinder]]

== More AI interfaces ==

Estimated difficulty: medium

The Spring engine's AI interface supports bindings for multiple languages, currently legacy C++, C and java are supported.

Bindings for more languages and/or virtual machines should be added to allow broader AI developing audience (for example: Ruby, Perl, JavaScript, Python, D, Go, Mono, LLVM, Parrot).

[[GSoC_More_AI_interfaces]]

== New Rendering System ==

Estimated difficulty: medium

The Spring rendering engine uses a lot of FFP (fixed function pipeline) OpenGL functions. This model is becoming deprecated and is generally slower and less flexible than shader usage.

The rendering code should get a complete overhaul using modern graphic programming techniques such as shaders, implement load support for more standardised model formats (backwards compatibility with current available formats is mandatory either through direct load or automatic conversion to the new types) and eventually introduce some graphic enhancing features (bump mapping, normal mapping, multitexturing, etc.).

OpenGL ES 2.0 compatibility should be aimed at where possible.

[[GSoC_New_rendering_system]]

== Reconnect / Host change during a match ==

Estimated difficulty: medium to hard

Spring's network model implies the existence of a server to host a battle. For various reasons the network link between host and clients can die, so a system should be designed to allow manual and/or automatic switching of the game's host (possibly using an existing player after testing load handling capabilities) and manual and/or automatic reconnection from client side if host remains the same.

[[GSoC_Reconnect_Host_change]]

Google Summer of Code 2010

2010-03-12T03:40:41Z

Argh: /* Smarter pathfinder */

[[Image:GSOC.png]]

= Project proposals =

This is the list of project ideas for students willing to work on the Spring engine during the Google Summer of Code 2010. If you wish, you may read our [[Google_Summer_of_Code_2010_student_application|student application]].

== Limited play area ==

Estimated difficulty: medium

Current Spring map formats have a hardcoded rectangle geometry; also they provide very limited support for defining aesthetics of the surrounding environment outside the play area.

The new system should allow the map to restrict the playable area to a subset of the global area, possibly adding support for multiple shapes and/or non rectangular shape restrictions.

The restriction shapes should be readable and changeable mid-game through the engine's Lua API. Proper handling of units which are suddenly off-map needs to be implemented.

[[GSoC_Limited_play_area]]

== Sensor handling redesign / simplification ==

Estimated difficulty: hard

Currently there are a number of different "sensor" systems in the engine: LineOfSight, Radar, Sonar, and Seismic, some can be jammed, some cannot. Some respect terrain, and some are always circular.

A new sensor system should integrate the current LOS, Radar, Sonar, Seismic systems, to reduce amount of code per functionality, and eventually add additional features which would be then available for all types.

Preferably this all should also be faster than the current system or a compelling argument/experiment should be made that shows there cannot be a faster system with the same features.

[[GSoC_Sensor_handling_redesign]]

== Engine level abstraction of resources ==

Estimated difficulty: medium to hard

The Spring engine has its roots in being a Total Annihilation clone; even if such intent has been dropped since quite some time, the TA resource system is largely present in the codebase being hardcoded in a lot of critical places.

The old system needs to be replaced, the new one should be flexible enough to reproduce everything that the old system did and be able to imitate the behaviour of most common RTS game titles.

The engine's Lua API to fetch resources will have to be adapted to the new system, and new calls will have to be added to edit it.

[[GSoC_Engine_resource_abstraction]]

== Basic ingame lobby ==

Estimated difficulty: hard

All existing Spring interfaces (lobbies) are either difficult to customize for game developers or have a different look 'n feel from the game itself and require focus switch from the game itself to operate.

A new, Lua scriptable lobby should be implemented with customization and control in mind, possibly integrated with Spring codebase and/or running as a separate process overlaying to the game's UI.

Optionally, the engine's start screen should be replaced and integrated with it.

[[GSoC_Ingame_lobby]]

== Smarter pathfinder ==

Estimated difficulty: hard

Spring's pathfinder uses a 2d grid and is somewhat limited in functionality.
A partial/full rewrite should be introduced to add support for navigating using more than 8 primary directions and selectively ignore certain unit types for performance reasons.

Spring's Lua API should be extended to allow game developers to push new nodes/links and be able to alter or delete existing ones (for pathfinder-aware tunnels/teleporting/etc.).

Preferably this should all be faster than the current system, or a compelling argument/experiment should be made that shows there cannot be a faster system with the same features.

Given the Spring Engine's need to routinely handle responsive and bug-free pathfinding and path-following for large numbers of actors, such a project could become a useful showcase and useful codebase for projects needing pathfinders, and could expand the world's understanding of pathfinding and path-following in realtime systems.

[[GSoC_Smarter_pathfinder]]

== More AI interfaces ==

Estimated difficulty: medium

The Spring engine's AI interface supports bindings for multiple languages, currently legacy C++, C and java are supported.

Bindings for more languages and/or virtual machines should be added to allow broader AI developing audience (for example: Ruby, Perl, JavaScript, Python, D, Go, Mono, LLVM, Parrot).

[[GSoC_More_AI_interfaces]]

== New Rendering System ==

Estimated difficulty: medium

The Spring rendering engine uses a lot of FFP (fixed function pipeline) OpenGL functions. This model is becoming deprecated and is generally slower and less flexible than shader usage.

The rendering code should get a complete overhaul using modern graphic programming techniques such as shaders, implement load support for more standardised model formats (backwards compatibility with current available formats is mandatory either through direct load or automatic conversion to the new types) and eventually introduce some graphic enhancing features (bump mapping, normal mapping, multitexturing, etc.).

OpenGL ES 2.0 compatibility should be aimed at where possible.

[[GSoC_New_rendering_system]]

== Reconnect / Host change during a match ==

Estimated difficulty: medium to hard

Spring's network model implies the existence of a server to host a battle. For various reasons the network link between host and clients can die, so a system should be designed to allow manual and/or automatic switching of the game's host (possibly using an existing player after testing load handling capabilities) and manual and/or automatic reconnection from client side if host remains the same.

[[GSoC_Reconnect_Host_change]]

Game and Unit development

2010-03-08T02:34:03Z

Argh:

[[Engine_Development|Development]] < {{FULLPAGENAME}}

=Game development=
This information is meant to help newcomers learn how to develop their own games for the Spring Engine.
==General==
*[[Mod specification|Game specification]] 
*[http://springrts.com/phpbb/viewtopic.php?t=6015 What do I need to create a game?]
*[[Simple Mod Tutorial|Simple Game Tutorial]]
*[[Freely available and reusable content|Freely available and reusable content for maps and games]]

==Unit Development==
===Units - Models===
*[http://user.supradigital.org/jcnossen/UpspringInstaller-1.54-EulerAngles.exe Click here to download UpSpring, our content support tool.]
* [[Basic s3o unit making guide]]
* [http://springrts.com/phpbb/viewtopic.php?f=9&t=15106 Argh's UpSpring Easy Workflow Guide]
* [[Trouble-shooting s3o units]]
* [http://lassie.student.utwente.nl/vliet/springtut.pdf Maestro's tutorial of Upspring and textures- very outdated].

====Models - Modeling, UV Mapping====
* [http://springrts.com/phpbb/viewtopic.php?t=10612 Wings UV Mapping Tutorial]
* [http://springrts.com/phpbb/viewtopic.php?f=9&t=12354 Saving polygons in Wings3d Tutorial]
* [http://springrts.com/phpbb/viewtopic.php?t=10503 Runecrafter's 3DS Max UV Mapping Tutorial]

====Models - Textures====
* [http://springrts.com/phpbb/viewtopic.php?f=57&t=22392 DDS Textures: How To]
* [http://springrts.com/phpbb/viewtopic.php?t=10947 Greeble Tutorial 1]
* [http://springrts.com/phpbb/viewtopic.php?f=9&t=12356 Greeble Tutorial 2]

====Models - 3do Files====
-NOTE- this is an outdated model format used by OTA models (Balanced Annihilation, NOTA, etc.). 
(Note: UpSpring has some problems with empty objects and groundplates)
*use [http://springrts.com/phpbb/viewtopic.php?f=12&t=7208&p=126129&hilit=upspring#p126129 UpSpring] and [http://springfiles.com/1755 3doBuilder] to edit those files

===[http://springrts.com/wiki/Category:Animation Scripting and Animation - COB/BOS Files]===
To edit .bos files you need a program/compiler. The most famous one is [http://jobjol.nl/1384 Scriptor]
*[[Animation-LuaScripting]]
**[[Animation-LuaCallins]]
**[[Animation-LuaCallouts]]
**[[Animation-CobLuaDifferences]]
*[[Animation-CobOverview]]
**[[Animation-CobExamples]]
**[[Animation-CobAnimation]]
**[[Animation-CobCallins]]
**[[Animation-CobConstants]]
**[[Animation-CobThreads]]
**[[Animation-CobHitByWeaponID]]
*[http://www.planetannihilation.com/tadc/tut_unit_01_1.asp PlanetAnnihilation] has a nice tutorial
*[[Units:LuaCOB]] - how to interface COB with LUA
*[[CEG_For_Units|Game Development:Calling basic CEGs from COB]]
* [http://springrts.com/phpbb/viewtopic.php?p=132943#132943 GPL-compliant sourcecode, scripting code examples, and other things.]

===Units - FBI Files===
*[[Units:FBI]]
*[[All_FBI-variable_values:_min,_max,_default,_type|Units:FBI (variable datatype list)]]
*[[Unit_Categories]]

===Units - MoveTypes===
*[[Units:MoveTypes]]

===Weapons - TDF Files===
*[[Weapon Variables]] : This is the most up to date
*[[Units:WeaponMainDir]]
*[[Units:Weapons]] : Various informations about the weapontypes (uncompleted)
*[[All_Weapons_variable_values:_min%2C_max%2C_default%2C_type|Weapon datatype list]] : All weapon variables min/max/default values and datatypes listed.
*[[Weapons:Antinukes]]: All about antinukes.

===Explosions===
*[[CEG]]
**[[CEG-Calls]]
**[[CEG-Format]]
**[[CEG-Classes]]
**[[CEG-Operators]]
**[[CEG-Miscellaneous]]
**[[CEG-OldInfo]]

===Misc===
*[[Units:Design]]
*[[Units:Textures]]
*[[Units:Buildpics]]
*[[Units:SideData TDF]]
*[[Units:Download TDF]]
*[[Units:FlankingBonus]]
*[[Mod Development:Armor|Game Development:Armor]]
*[[Mod Development:Cursors|Game Development:Cursors]]
*[[Mod Development:Archives|Game Development:Archives]]
*[[Mod Development:Sidepics|Game Development:Sidepics]]
*[[CustomUnitIcons|Game Development:Custom unit icons]]

===Legacy Porting Tools===
====Automated Game Creation====
* [[TA2Spring]] - Automatically adds and converts Total Annihilation unit packs (.ufo files, etc..) into Spring games (requires a base game for the game rules, XTA is recommended, it is probably not properly supported by current Spring)

Game and Unit development

2010-03-08T02:33:16Z

Argh:

[[Engine_Development|Development]] < {{FULLPAGENAME}}

=Game development=
This information is meant to help newcomers learn how to develop their own games for the Spring Engine.
==General==
*[[Mod specification|Game specification]] 
*[http://springrts.com/phpbb/viewtopic.php?t=6015 What do I need to create a game?]
*[[Simple Mod Tutorial|Simple Game Tutorial]]
*[[Freely available and reusable content|Freely available and reusable content for maps and games]]

==Unit Development==
===Units - Models===
*[http://user.supradigital.org/jcnossen/UpspringInstaller-1.54-EulerAngles.exe Click here to download UpSpring, our content support tool.]
* [[Basic s3o unit making guide]]
* [http://springrts.com/phpbb/viewtopic.php?f=9&t=15106 Argh's UpSpring Easy Workflow Guide]
* [[Trouble-shooting s3o units]]
* [http://lassie.student.utwente.nl/vliet/springtut.pdf Maestro's tutorial of Upspring and textures- very outdated].

====Models - Modeling, UV Mapping====
* [http://springrts.com/phpbb/viewtopic.php?t=10612 Wings UV Mapping Tutorial]
* [http://springrts.com/phpbb/viewtopic.php?f=9&t=12354 Saving polygons in Wings3d Tutorial]
* [http://springrts.com/phpbb/viewtopic.php?t=10503 Runecrafter's 3DS Max UV Mapping Tutorial]

====Models - Textures====
* [http://springrts.com/phpbb/viewtopic.php?f=57&t=22392 DDS Textures: How To]
* [http://springrts.com/phpbb/viewtopic.php?t=10947 Greeble Tutorial 1]
* [http://springrts.com/phpbb/viewtopic.php?f=9&t=12356 Greeble Tutorial 2]

====Models - 3do Files====
-NOTE- this is an outdated model format used by OTA models (Balanced Annihilation, NOTA, etc.). 
(Note: UpSpring has some problems with empty objects and groundplates)
*use [http://springrts.com/phpbb/viewtopic.php?f=12&t=7208&p=126129&hilit=upspring#p126129 UpSpring] and [http://springfiles.com/1755 3doBuilder] to edit those files

===[http://springrts.com/wiki/Category:Animation Scripting and Animation - COB/BOS Files]===
To edit .bos files you need a program/compiler. The most famous one is [http://jobjol.nl/1384 Scriptor]
*[[Animation-LuaScripting]]
**[[Animation-LuaCallins]]
**[[Animation-LuaCallouts]]
**[[Animation-CobLuaDifferences]]
*[[Animation-CobOverview]]
**[[Animation-CobExamples]]
**[[Animation-CobAnimation]]
**[[Animation-CobCallins]]
**[[Animation-CobConstants]]
**[[Animation-CobThreads]]
**[[Animation-CobHitByWeaponID]]
*[http://www.planetannihilation.com/tadc/tut_unit_01_1.asp PlanetAnnihilation] has a nice tutorial
*[[Units:LuaCOB]] - how to interface COB with LUA
*[[CEG_For_Units|Game Development:Calling basic CEGs from COB]]
* [http://springrts.com/phpbb/viewtopic.php?p=132943#132943 GPL-compliant sourcecode, scripting code examples, and other things.]

===Legacy Porting Tools===
====Automated Game Creation====
* [[TA2Spring]] - Automatically adds and converts Total Annihilation unit packs (.ufo files, etc..) into Spring games (requires a base game for the game rules, XTA is recommended, it is probably not properly supported by current Spring)

===Units - FBI Files===
*[[Units:FBI]]
*[[All_FBI-variable_values:_min,_max,_default,_type|Units:FBI (variable datatype list)]]
*[[Unit_Categories]]

===Units - MoveTypes===
*[[Units:MoveTypes]]

===Weapons - TDF Files===
*[[Weapon Variables]] : This is the most up to date
*[[Units:WeaponMainDir]]
*[[Units:Weapons]] : Various informations about the weapontypes (uncompleted)
*[[All_Weapons_variable_values:_min%2C_max%2C_default%2C_type|Weapon datatype list]] : All weapon variables min/max/default values and datatypes listed.
*[[Weapons:Antinukes]]: All about antinukes.

===Explosions===
*[[CEG]]
**[[CEG-Calls]]
**[[CEG-Format]]
**[[CEG-Classes]]
**[[CEG-Operators]]
**[[CEG-Miscellaneous]]
**[[CEG-OldInfo]]

===Misc===
*[[Units:Design]]
*[[Units:Textures]]
*[[Units:Buildpics]]
*[[Units:SideData TDF]]
*[[Units:Download TDF]]
*[[Units:FlankingBonus]]
*[[Mod Development:Armor|Game Development:Armor]]
*[[Mod Development:Cursors|Game Development:Cursors]]
*[[Mod Development:Archives|Game Development:Archives]]
*[[Mod Development:Sidepics|Game Development:Sidepics]]
*[[CustomUnitIcons|Game Development:Custom unit icons]]

Game and Unit development

2010-03-08T02:31:48Z

Argh: Minor re-write and restructuring for better flow; included link about texture article I wrote

[[Engine_Development|Development]] < {{FULLPAGENAME}}

=Game development=
This information is meant to help newcomers learn how to develop their own games for the Spring Engine.
==General==
*[[Mod specification|Game specification]] 
*[http://springrts.com/phpbb/viewtopic.php?t=6015 What do I need to create a game?]
*[[Simple Mod Tutorial|Simple Game Tutorial]]
*[[Freely available and reusable content|Freely available and reusable content for maps and games]]

==Unit Development==
====Units - Models====
*[http://user.supradigital.org/jcnossen/UpspringInstaller-1.54-EulerAngles.exe Click here to download UpSpring, our content support tool.]
* [[Basic s3o unit making guide]]
* [http://springrts.com/phpbb/viewtopic.php?f=9&t=15106 Argh's UpSpring Easy Workflow Guide]
* [[Trouble-shooting s3o units]]
* [http://lassie.student.utwente.nl/vliet/springtut.pdf Maestro's tutorial of Upspring and textures- very outdated].

====Models - Modeling, UV Mapping====
* [http://springrts.com/phpbb/viewtopic.php?t=10612 Wings UV Mapping Tutorial]
* [http://springrts.com/phpbb/viewtopic.php?f=9&t=12354 Saving polygons in Wings3d Tutorial]
* [http://springrts.com/phpbb/viewtopic.php?t=10503 Runecrafter's 3DS Max UV Mapping Tutorial]

====Models - Textures====
* [http://springrts.com/phpbb/viewtopic.php?f=57&t=22392 DDS Textures: How To]
* [http://springrts.com/phpbb/viewtopic.php?t=10947 Greeble Tutorial 1]
* [http://springrts.com/phpbb/viewtopic.php?f=9&t=12356 Greeble Tutorial 2]

====Models - 3do Files====
-NOTE- this is an outdated model format used by OTA models (Balanced Annihilation, NOTA, etc.). 
(Note: UpSpring has some problems with empty objects and groundplates)
*use [http://springrts.com/phpbb/viewtopic.php?f=12&t=7208&p=126129&hilit=upspring#p126129 UpSpring] and [http://springfiles.com/1755 3doBuilder] to edit those files

====[http://springrts.com/wiki/Category:Animation Scripting and Animation - COB/BOS Files]====
To edit .bos files you need a program/compiler. The most famous one is [http://jobjol.nl/1384 Scriptor]
*[[Animation-LuaScripting]]
**[[Animation-LuaCallins]]
**[[Animation-LuaCallouts]]
**[[Animation-CobLuaDifferences]]
*[[Animation-CobOverview]]
**[[Animation-CobExamples]]
**[[Animation-CobAnimation]]
**[[Animation-CobCallins]]
**[[Animation-CobConstants]]
**[[Animation-CobThreads]]
**[[Animation-CobHitByWeaponID]]
*[http://www.planetannihilation.com/tadc/tut_unit_01_1.asp PlanetAnnihilation] has a nice tutorial
*[[Units:LuaCOB]] - how to interface COB with LUA
*[[CEG_For_Units|Game Development:Calling basic CEGs from COB]]
* [http://springrts.com/phpbb/viewtopic.php?p=132943#132943 GPL-compliant sourcecode, scripting code examples, and other things.]

===Legacy Porting Tools===
====Automated Game Creation====
* [[TA2Spring]] - Automatically adds and converts Total Annihilation unit packs (.ufo files, etc..) into Spring games (requires a base game for the game rules, XTA is recommended, it is probably not properly supported by current Spring)

====Units - FBI Files====
*[[Units:FBI]]
*[[All_FBI-variable_values:_min,_max,_default,_type|Units:FBI (variable datatype list)]]
*[[Unit_Categories]]

====Units - MoveTypes====
*[[Units:MoveTypes]]

====Weapons - TDF Files====
*[[Weapon Variables]] : This is the most up to date
*[[Units:WeaponMainDir]]
*[[Units:Weapons]] : Various informations about the weapontypes (uncompleted)
*[[All_Weapons_variable_values:_min%2C_max%2C_default%2C_type|Weapon datatype list]] : All weapon variables min/max/default values and datatypes listed.
*[[Weapons:Antinukes]]: All about antinukes.

====Explosions====
*[[CEG]]
**[[CEG-Calls]]
**[[CEG-Format]]
**[[CEG-Classes]]
**[[CEG-Operators]]
**[[CEG-Miscellaneous]]
**[[CEG-OldInfo]]

====Misc====
*[[Units:Design]]
*[[Units:Textures]]
*[[Units:Buildpics]]
*[[Units:SideData TDF]]
*[[Units:Download TDF]]
*[[Units:FlankingBonus]]
*[[Mod Development:Armor|Game Development:Armor]]
*[[Mod Development:Cursors|Game Development:Cursors]]
*[[Mod Development:Archives|Game Development:Archives]]
*[[Mod Development:Sidepics|Game Development:Sidepics]]
*[[CustomUnitIcons|Game Development:Custom unit icons]]

Game and Unit development

2010-02-25T11:16:27Z

Argh: Fixed all dead links, standardized to springrts.com domain

[[Engine_Development|Development]] < {{FULLPAGENAME}}

=Game development=
This information is meant to help newcomers learn how to develop their own games for the Spring Engine.
==General==
*[[Mod specification|Game specification]] 
*[http://springrts.com/phpbb/viewtopic.php?t=6015 What do I need to create a game?]
*[[Simple Mod Tutorial|Simple Game Tutorial]]
*[[Freely available and reusable content|Freely available and reusable content for maps and games]]

==Unit Development==
====Models - s3o Files====
*[http://user.supradigital.org/jcnossen/UpspringInstaller-1.54-EulerAngles.exe UpSpring, our second-gen import / export / rigging / animation tool.]
* [http://lassie.student.utwente.nl/vliet/springtut.pdf Maestro's tutorial of Upspring and textures].
* [[Basic s3o unit making guide]]
* [[Simple Mod Tutorial|Simple Game Tutorial]]
* [http://springrts.com/phpbb/viewtopic.php?t=10612 Wings UV Mapping Tutorial]
* [http://springrts.com/phpbb/viewtopic.php?f=9&t=12354 Saving polygons in Wings3d Tutorial]
* [http://springrts.com/phpbb/viewtopic.php?t=10947 Greeble Tutorial 1]
* [http://springrts.com/phpbb/viewtopic.php?f=9&t=12356 Greeble Tutorial 2]
* [http://springrts.com/phpbb/viewtopic.php?p=75495 various things about unit making. (Also contains an illustrated alpha-channel tut)]
* [http://springrts.com/phpbb/viewtopic.php?t=10503 Runecrafter's 3DS Max UV Mapping Tutorial]
* [http://springrts.com/phpbb/viewtopic.php?f=9&t=15106 Argh's UpSpring Easy Workflow Guide]
* [[Trouble-shooting s3o units]]

====[http://springrts.com/wiki/Category:Animation Scripting and Animation - COB/BOS Files]====
To edit .bos files you need a program/compiler. The most famous one is [http://jobjol.nl/1384 Scriptor]
*[[Animation-LuaScripting]]
**[[Animation-LuaCallins]]
**[[Animation-LuaCallouts]]
**[[Animation-CobLuaDifferences]]
*[[Animation-CobOverview]]
**[[Animation-CobExamples]]
**[[Animation-CobAnimation]]
**[[Animation-CobCallins]]
**[[Animation-CobConstants]]
**[[Animation-CobThreads]]
**[[Animation-CobHitByWeaponID]]
*[http://www.planetannihilation.com/tadc/tut_unit_01_1.asp PlanetAnnihilation] has a nice tutorial
*[[Units:LuaCOB]] - how to interface COB with LUA
*[[CEG_For_Units|Game Development:Calling basic CEGs from COB]]
* [http://springrts.com/phpbb/viewtopic.php?p=132943#132943 GPL-compliant sourcecode, scripting code examples, and other things.]

===Legacy Porting Tools===
====Models - 3do Files====
-NOTE- this is and outdated model format used by OTA 
(Note: UpSpring has some problems with empty objects and groundplates)
*use [http://springrts.com/phpbb/viewtopic.php?f=12&t=7208&p=126129&hilit=upspring#p126129 UpSpring] and [http://springfiles.com/1755 3doBuilder] to edit those files

====Automated Game Creation====
* [[TA2Spring]] - Automatically adds and converts Total Annihilation unit packs (.ufo files, etc..) into Spring games (requires a base gameification for the game rules, XTA is recommended)

====Units - FBI Files====
*[[Units:FBI]]
*[[All_FBI-variable_values:_min,_max,_default,_type|Units:FBI (variable datatype list)]]
*[[Unit_Categories]]

====Units - MoveTypes====
*[[Units:MoveTypes]]

====Weapons - TDF Files====
*[[Weapon Variables]] : This is the most up to date
*[[Units:WeaponMainDir]]
*[[Units:Weapons]] : Various informations about the weapontypes (uncompleted)
*[[All_Weapons_variable_values:_min%2C_max%2C_default%2C_type|Weapon datatype list]] : All weapon variables min/max/default values and datatypes listed.
*[[Weapons:Antinukes]]: All about antinukes.

====Explosions====
*[[CEG]]
**[[CEG-Calls]]
**[[CEG-Format]]
**[[CEG-Classes]]
**[[CEG-Operators]]
**[[CEG-Miscellaneous]]
**[[CEG-OldInfo]]

====Misc====
*[[Units:Design]]
*[[Units:Textures]]
*[[Units:Buildpics]]
*[[Units:SideData TDF]]
*[[Units:Download TDF]]
*[[Units:FlankingBonus]]
*[[Mod Development:Armor|Game Development:Armor]]
*[[Mod Development:Cursors|Game Development:Cursors]]
*[[Mod Development:Archives|Game Development:Archives]]
*[[Mod Development:Sidepics|Game Development:Sidepics]]
*[[CustomUnitIcons|Game Development:Custom unit icons]]

General Resources

2010-02-25T11:13:09Z

Argh: /* Features */

[[Engine_Development|Development]] < General Resources

=Textures=
[http://springrts.com/phpbb/viewtopic.php?t=7093&start=0 Texture Competition 0001 - Metal] 
[http://springrts.com/phpbb/viewtopic.php?t=7188&start=0 Texture Competition 0002 - Camo] 
[http://springrts.com/phpbb/viewtopic.php?t=7731 Texture Competition 0003 - Stone/Concrete] 
[http://www.cgtextures.com/ CG Textures]

=Code=
[http://springrts.com/phpbb/viewtopic.php?t=7457 GPL Code Repository] 
[http://springrts.com/phpbb/viewtopic.php?t=6569&postdays=0&postorder=asc&start=0 The Millionth Monkey Gets Its Typewriter - Movement Optimization]

=Sounds=
[http://freesound.iua.upf.edu/ Freesound] free sounds and samples, distributed under the [http://creativecommons.org/licenses/sampling+/1.0/ Creative Commons License]

=Features=
[http://springrts.com/phpbb/viewtopic.php?t=4047 Compilation List of Features for Maps]

=Models=
[http://planet-wars.eu/ModelBase/Units.aspx Model Base]

General Resources

2010-02-25T11:12:53Z

Argh: /* Code */

[[Engine_Development|Development]] < General Resources

=Textures=
[http://springrts.com/phpbb/viewtopic.php?t=7093&start=0 Texture Competition 0001 - Metal] 
[http://springrts.com/phpbb/viewtopic.php?t=7188&start=0 Texture Competition 0002 - Camo] 
[http://springrts.com/phpbb/viewtopic.php?t=7731 Texture Competition 0003 - Stone/Concrete] 
[http://www.cgtextures.com/ CG Textures]

=Code=
[http://springrts.com/phpbb/viewtopic.php?t=7457 GPL Code Repository] 
[http://springrts.com/phpbb/viewtopic.php?t=6569&postdays=0&postorder=asc&start=0 The Millionth Monkey Gets Its Typewriter - Movement Optimization]

=Sounds=
[http://freesound.iua.upf.edu/ Freesound] free sounds and samples, distributed under the [http://creativecommons.org/licenses/sampling+/1.0/ Creative Commons License]

=Features=
[http://spring.clan-sy.com/phpbb/viewtopic.php?t=4047 Compilation List of Features for Maps]

=Models=
[http://planet-wars.eu/ModelBase/Units.aspx Model Base]

General Resources

2010-02-25T11:09:43Z

Argh: /* Textures */

[[Engine_Development|Development]] < General Resources

=Textures=
[http://springrts.com/phpbb/viewtopic.php?t=7093&start=0 Texture Competition 0001 - Metal] 
[http://springrts.com/phpbb/viewtopic.php?t=7188&start=0 Texture Competition 0002 - Camo] 
[http://springrts.com/phpbb/viewtopic.php?t=7731 Texture Competition 0003 - Stone/Concrete] 
[http://www.cgtextures.com/ CG Textures]

=Code=
[http://taspring.clan-sy.com/phpbb/viewtopic.php?t=7457 GPL Code Repository] 
[http://taspring.clan-sy.com/phpbb/viewtopic.php?t=6569&postdays=0&postorder=asc&start=0 The Millionth Monkey Gets Its Typewriter - Movement Optimization]

=Sounds=
[http://freesound.iua.upf.edu/ Freesound] free sounds and samples, distributed under the [http://creativecommons.org/licenses/sampling+/1.0/ Creative Commons License]

=Features=
[http://spring.clan-sy.com/phpbb/viewtopic.php?t=4047 Compilation List of Features for Maps]

=Models=
[http://planet-wars.eu/ModelBase/Units.aspx Model Base]

Monthly Topic Rotation

2010-02-25T10:42:29Z

Argh: Removed old topics for MTR; believe or not, none of that stuff is now not supported by Spring...

Monthly Topic Rotation

2010-02-25T10:38:59Z

Argh: /* Custom Resources */

[[Engine_Development|Development]] < Monthly Topic Rotation

"Monthy Topic Rotation" is a term coined by Gnome referring to the fact that people keep coming into the forums and posting messages on the same subject. It seems that as Spring becomes more popular, more new people keep coming up with the same ideas and questions... think of this as the "Is your idea original?" FAQ as opposed to the "real" [[FAQ]].

Now in some situations it's okay to repost on the same topic, if it has been only mentioned before in other people's topics or if you make reference to the fact that it is a known issue you are addressing with new ideas... but that doesn't excuse you from the list. One way or the other, the community might make fun of you for rehashing old topics, expecially when they aren't forgotten so much as people are bored of talking about them.

This has now turned into a sort of game. You can see the current scores here: http://maelstrom.niiil.com/?l=mtr (Note from a visitor: link seems to be down)

=The Topics=
'''List of Generic Topics with brief discussion and list of topics posted on these subjects for quick reference:'''

===Custom Resources===
Requests or Suggestions that involve anything from different names for the resources we have, better control over the handling of resources, resources like those in other games etc. The best generalized suggestion is for a more dynamic, mod controlled resource and unit limit. Often coupled with suggestions for hacking or script based work arounds for the lack of the requested feature.

*[http://springrts.com/phpbb/viewtopic.php?t=5932 A Third Resource PLEASE!]
*[http://springrts.com/phpbb/viewtopic.php?t=6277 A proposed System]
*[http://springrts.com/phpbb/viewtopic.php?t=6342 Mentioned in conjunction with other requests for resource related features]
*[http://springrts.com/phpbb/viewtopic.php?p=121014 Carbon or Something]
*[http://springrts.com/phpbb/viewtopic.php?t=5966 Reserach as a Resource]
*[http://springrts.com/phpbb/viewtopic.php?p=121186 spicing up economy]

===OTA Style Music===
Requests or Suggestions that the engine include music playback, especially music that changes depending on what kind of action is happening in game. Associated with requests for a sound track of any kind or asking for a link to get the orriginal TA Soundtrack in MP3 format.

*[http://taspring.clan-sy.com/phpbb/viewtopic.php?t=2856 Soundtracks.]
*[http://taspring.clan-sy.com/phpbb/viewtopic.php?t=2786 Original OTA Music]

Getting Spring Content and Links

2010-02-25T10:37:03Z

Argh: Removed redudant links

===Content download websites for Spring===
[http://spring.clan-sy.com/wiki/Where_files_go '''Where files go''', '''Their purpose'''] (Maps. Mods, Lua Widgets, Base ota content, AIs)

http://spring.jobjol.nl << a favorite site for getting Spring content - thanks to JJ

http://www.springinfo.info/ << a Spring Player's Portal (does not represent all Spring Development but is quite helpful)

http://spring-portal.com/ << a nice Spring site with a short Getting Spring to play tutorial + more - thanks to BLC

http://www.tasdownloads.com/ - thanks to M_A_D

http://www.darkstars.co.uk/downloads/ << Has the best bandwidth you will get - thanks to AF (a Dev with a running Spring blog)

http://evolutionrts.info/maps/ - thanks to AF

http://www.unknown-files.net/spring/ << one of the most popular sources for Spring content until its prolonged downtime - thanks to iamacup.

===Developer Sites===
Note that some Mods just use the Message board and not a site.

http://springlobby.info << The Site for the Devs who work on the SpringLobby which lets us play together << there u can write a ticket if some thing [about the lobby] needs fixing.

http://trac.caspring.org/wiki/sd << CA mod site << The link for DLing the CaUpdater - you can also write a ticket about some ting CA needs fixed

http://nota.strategyboards.com/ << NOTA's Independent forum and Bug Report site

===General Links For Spring===

http://springladder.no-ip.org/ << Ladder game Ranks + Scores

http://www.portforward.com/ << see our wiki on port forwarding to make use of this

http://modinfo.adune.nl << gives detailed info for mods <> (if some mod is missing, PM at TradeMark). Modinfo has also an "error reporting" tool, which shows errors in the TDF files, like missing ; marks. "find errors" utility shows several types of errors, and other useful information about cleaning up your mod.

http://replays.adune.nl << for getting and uploading replays - note: 2 see a

replay you will need the Map and Mod played

http://pastebin.com << used for easily sharing code, or large blocks of text

''' [[FAQ|<- Back to Help page]]'''

Game specification

2010-02-25T10:20:31Z

Argh:

===Overview===

This is a specification of how Spring will support mods and switching between them.

Spring looks for games in the folders "maps", "base" and "mods", and all their subfolders. It is recommended to put your game in a subfolder of /mods. Spring supports multiple subfolders within /mods: '''/mods/my_nifty_game/game.sdd''' and '''/mods/my_nifty_game/game_support.sdz''' are both correct.

On startup, Spring will search these folders and their subfolders for files called "modinfo.lua". This file declares all ''dependencies'' of this game, such as additional graphics, sounds and the like.

The general idea is that this file should be used as a manifest file to let Spring know what to do with the archive it is found inside, so each archive file in the mods directory is supposed to have one. Archive files that do not contain this file are ignored, and aren't available to Spring's Virtual File System.

===Modinfo.lua Example===
Modinfo.lua, like any Lua language file, can contain active code, should you want it to. But it is mainly just designed to refer Spring's Virtual File System (VFS) to the correct game files and any dependencies of your project.

Here is an example:

<pre>return
{
game='myNiftyGame',
shortGame='mNg',
name='My Nifty Game',
mutator='official',
version='1.0',
description='The Awesome Game I Made.',
url='http://www.my_nifty_url.com/',
modtype=1,
depend= {
depend01.sdd,
depend02.sdd,
},
}</pre>

'''Dependencies''' are files that your game depends on to operate. This may be anything- a map, another game, a folder named "my_nifty_sounds.sdd" that has a bunch of sounds in it and a modinfo.lua file to identify it as a valid file archive to Spring- basically anything goes, so long as it, like your game, is identified as a usable archive by having a modinfo.lua file in it.

These files are loaded in the order listed. So if depend02.sdd contains a file with the same name as depend01.sdd, it will overwrite that file.

'''Modtype''' determines whether Spring's archive system sees the game as a game, or as an "invisible" file that can only be called as a Dependency. If set to any number except for 1, it will not be visible to end-users as a "game", but you can still refer to it in the depend table.

===Replacements===

When releasing new versions of a mod it is recommended that a new unique filename is used. In this manner it would be possible for the lobby to download archives from a fast webserver based on the filename.

But if a new name is used for a support archive with content for example, it would break other mods that depend on the archive. To avoid this, replacements can be used.

Replacements simply specifies which other archives this one replaces. So if a new archive specifies that it replaces old_archive.sdz, any other mod that depends on old_archive.sdz would now use the new one instead.

It is probably not always a good idea to use this for new versions of a mod however, since if you hide the old version people would not be able to switch between the old and the new version. So only use replacements when you are sure that it is what you want.

===Distribution===

If a player does not have a certain game's files when trying to join a game online, the Lobbies are designed to let them know that they don't have the game. If you have uploaded your game to the various services that are supported by the Lobby applications, players can automatically download the game. Also, SpringDownloader allows players to share the game's file with others easily. Modinfo.lua lets both the Lobby application and Spring know what your game is, and whether it "knows" where it can be downloaded from.

[[Category:Mod development]]

Game specification

2010-02-25T10:14:19Z

Argh: /* Modinfo.lua Example */

===Overview===

This is a specification of how Spring will support mods and switching between them.

Spring looks for games in the folders "maps", "base" and "mods", and all their subfolders. It is recommended to put your game in a subfolder of /mods. Spring supports multiple subfolders within /mods: '''/mods/my_nifty_game/game.sdd''' and '''/mods/my_nifty_game/game_support.sdz''' are both correct.

On startup, Spring will search these folders and their subfolders for files called "modinfo.lua". This file declares all ''dependencies'' of this game, such as additional graphics, sounds and the like.

The general idea is that this file should be used as a manifest file to let Spring know what to do with the archive it is found inside, so each archive file in the mods directory is supposed to have one. Archive files that do not contain this file are ignored, and aren't available to Spring's Virtual File System.

===Modinfo.lua Example===
Modinfo.lua, like any Lua language file, can contain active code, should you want it to. But it is mainly just designed to refer Spring's Virtual File System (VFS) to the correct game files and any dependencies of your project.

Here is an example:

<pre>return
{
game='myNiftyGame',
shortGame='mNg',
name='My Nifty Game',
mutator='official',
version='1.0',
description='The Awesome Game I Made.',
url='http://www.my_nifty_url.com/',
modtype=1,
depend= {
depend01.sdd,
depend02.sdd,
},
}</pre>

'''Dependencies''' are files that your game depends on to operate. This may be anything- a map, another game, a folder named "my_nifty_sounds.sdd" that has a bunch of sounds in it and a modinfo.lua file to identify it as a valid file archive to Spring- basically anything goes, so long as it, like your game, is identified as a usable archive by having a modinfo.lua file in it.

These files are loaded in the order listed. So if depend02.sdd contains a file with the same name as depend01.sdd, it will overwrite that file.

'''Modtype''' determines whether Spring's archive system sees the game as a game, or as an "invisible" file that can only be called as a Dependency. If set to any number except for 1, it will not be visible to end-users as a "game", but you can still refer to it in the depend table.

===Dependencies===

Listing the dependencies allows a mod to not load the OTA textures at all for example, if it only uses original textures. Only one mod of type 1 can be selected at one time. Also, if a mod of type 2 is depending on a type 1 mod, that mod has to be selected first.

Some examples on how this could be used:

* An OTA mod that restores balance to be more similar to OTA could use modtype=1 and depend on XTA. Since XTA is now in the dependency graph, type 2 mods that depend on XTA would now also be usable.
* A new total conversion with a few extra options (not sure what that could be.. but anyway) could use a hidden base package and provide several type 1 mods that are small files that depend on the base.

When playing, the files would be loaded in the order defined by the dependency graph. The files could also be checked with an MD5 checksum or similar to make sure all players have the same file.

===Replacements===

When releasing new versions of a mod it is recommended that a new unique filename is used. In this manner it would be possible for the lobby to download archives from a fast webserver based on the filename. But if a new name is used for a support archive with content for example, it would break other mods that depends on the archive. To avoid this, replacements can be used.

Replacements simply specifies which other archives this one replaces. So if a new archive specifies that it replaces old_archive.sdz, any other mod that depends on old_archive.sdz would now use the new one instead.

It is probably not always a good idea to use this for new versions of a mod however, since if you hide the old version people would not be able to switch between the old and the new version. So only use replacements when you are sure that it is what you want.

===Final words===

If a player does not have a certain mod when trying to join a game, the info in description etc could be sent to allow the player to download it.. The filename could be sent as well, so that the client could try to download it automatically from a few predefined redirect servers (similar to the system unreal tournament uses).

[[Category:Mod development]]

Game specification

2010-02-25T10:12:08Z

Argh: Removed TDF reference; cleaned up, added current example

===Overview===

This is a specification of how Spring will support mods and switching between them.

Spring looks for games in the folders "maps", "base" and "mods", and all their subfolders. It is recommended to put your game in a subfolder of /mods. Spring supports multiple subfolders within /mods: '''/mods/my_nifty_game/game.sdd''' and '''/mods/my_nifty_game/game_support.sdz''' are both correct.

On startup, Spring will search these folders and their subfolders for files called "modinfo.lua". This file declares all ''dependencies'' of this game, such as additional graphics, sounds and the like.

The general idea is that this file should be used as a manifest file to let Spring know what to do with the archive it is found inside, so each archive file in the mods directory is supposed to have one. Archive files that do not contain this file are ignored, and aren't available to Spring's Virtual File System.

===Modinfo.lua Example===
Modinfo.lua, like any Lua language file, can contain active code, should you want it to. But it is mainly just designed to refer Spring's Virtual File System (VFS) to the correct game files and any dependencies of your project.

Here is an example:

<pre>return
{
game='myNiftyGame',
shortGame='mNg',
name='My Nifty Game',
mutator='official',
version='1.0',
description='The Awesome Game I Made.',
url='http://www.my_nifty_url.com/',
modtype=1,
depend= {
depend01.sdd,
depend02.sdd,
},
}</pre>

'''Dependencies''' are files that your game depends on to operate. This may be anything- a map, another game, a folder named "my_nifty_sounds.sdd" that has a bunch of sounds in it and a modinfo.lua file to identify it as a valid file archive to Spring- basically anything goes, so long as it, like your game, is identified as a usable archive by having a modinfo.lua file in it.

'''Modtype''' determines whether Spring's archive system sees the game as a game, or as an "invisible" file that can only be called as a Dependency. If set to any number except for 1, it will not be visible to end-users as a "game", but you can still refer to it in the depend table.

===Dependencies===

Listing the dependencies allows a mod to not load the OTA textures at all for example, if it only uses original textures. Only one mod of type 1 can be selected at one time. Also, if a mod of type 2 is depending on a type 1 mod, that mod has to be selected first.

Some examples on how this could be used:

* An OTA mod that restores balance to be more similar to OTA could use modtype=1 and depend on XTA. Since XTA is now in the dependency graph, type 2 mods that depend on XTA would now also be usable.
* A new total conversion with a few extra options (not sure what that could be.. but anyway) could use a hidden base package and provide several type 1 mods that are small files that depend on the base.

When playing, the files would be loaded in the order defined by the dependency graph. The files could also be checked with an MD5 checksum or similar to make sure all players have the same file.

===Replacements===

When releasing new versions of a mod it is recommended that a new unique filename is used. In this manner it would be possible for the lobby to download archives from a fast webserver based on the filename. But if a new name is used for a support archive with content for example, it would break other mods that depends on the archive. To avoid this, replacements can be used.

Replacements simply specifies which other archives this one replaces. So if a new archive specifies that it replaces old_archive.sdz, any other mod that depends on old_archive.sdz would now use the new one instead.

It is probably not always a good idea to use this for new versions of a mod however, since if you hide the old version people would not be able to switch between the old and the new version. So only use replacements when you are sure that it is what you want.

===Final words===

If a player does not have a certain mod when trying to join a game, the info in description etc could be sent to allow the player to download it.. The filename could be sent as well, so that the client could try to download it automatically from a few predefined redirect servers (similar to the system unreal tournament uses).

[[Category:Mod development]]

Game specification

2010-02-25T09:56:22Z

Argh: /* Overview */

===Overview===

This is a specification of how Spring will support mods and switching between them.

Spring looks for games in the folders "maps", "base" and "mods", and all their subfolders. It is recommended to put your game in a subfolder of /mods. Spring supports multiple subfolders within /mods: '''/mods/my_nifty_game/game.sdd''' and '''/mods/my_nifty_game/game_support.sdz''' are both correct.

On startup, Spring will search these folders and their subfolders for files called "modinfo.lua". This file declares all ''dependencies'' of this game, such as additional graphics, sounds and the like.

The general idea is that this file should be used as a manifest file to let Spring know what to do with the archive it is found inside, so each archive file in the mods directory is supposed to have one. Archive files that do not contain this file are ignored, and aren't available to Spring's Virtual File System.

===Specification===

This is an example of what this file should look like:

<tt>
// Description of the mod control file recognized by spring:

[MOD]
{
// The name is shown in the selection interface
Name=XTA version 0.61;

// These can be shown by the selection interface
Description=XTA 0.61 beta makes stuff balanced and cool;
URL=http://www.clan-sy.com/;

// What kind of mod this is
// 0 - Hidden (support mod that can't be selected, such as OTA_textures)
// 1 - Normal, only one can be selected at a time
// 2 - Addon, any number of these can be selected. Could be used
// for single units for example.
// others - perhaps mutators and addon races that can be
// enabled in addition to xta for example?
ModType=1;

// Number of other archives this one depends on
NumDependencies=1;
Depend0=taenheter.sdz;

// Number of other archives this one replaces
NumReplaces=1;
Replace0=xta_se_v060.sdz;
}
</tt>

Most of these entries should be easy to understand. Dependencies and replacements needs some consideration though.

Note: the order in which depencies are numerated, is inverse to the hierarchy,
i.e. (example taken from OTA mod pack made by zwzsg):

<tt>
[MOD]
{
Name=Shiny TA v5.5;
Description=OTA Evolva new BP v5.5;
URL=http://www.fileuniverse.com/spring/;

ModType=1;

NumDependencies=1;
Depend4=tacontent.sdz;
Depend3=tatextures.sdz;
Depend2=OTA_data.sd7;
Depend1=Evolva_models.sd7;
Depend0=UTASP_UnitPics.sd7;
}
</tt>

the last item in this list is Depend0=UTASP_UnitPics.sd7, which should overwrite the buildpics contained into otacontent.sdz, which is included in the tacontent.sdz, thus UTASP_UnitPics.sd7 should be loaded the last to overwrite the previously loaded unitpic files.

Altough the list is written in the right order, the dependencies seem to be numerated inversely, with UTASP_UnitPics.sd7 having the lower number and tacontent the higher, this is anyhow the correct way to do it.

===Dependencies===

Listing the dependencies allows a mod to not load the OTA textures at all for example, if it only uses original textures. Only one mod of type 1 can be selected at one time. Also, if a mod of type 2 is depending on a type 1 mod, that mod has to be selected first.

Some examples on how this could be used:

* An OTA mod that restores balance to be more similar to OTA could use modtype=1 and depend on XTA. Since XTA is now in the dependency graph, type 2 mods that depend on XTA would now also be usable.
* A new total conversion with a few extra options (not sure what that could be.. but anyway) could use a hidden base package and provide several type 1 mods that are small files that depend on the base.

When playing, the files would be loaded in the order defined by the dependency graph. The files could also be checked with an MD5 checksum or similar to make sure all players have the same file.

===Replacements===

When releasing new versions of a mod it is recommended that a new unique filename is used. In this manner it would be possible for the lobby to download archives from a fast webserver based on the filename. But if a new name is used for a support archive with content for example, it would break other mods that depends on the archive. To avoid this, replacements can be used.

Replacements simply specifies which other archives this one replaces. So if a new archive specifies that it replaces old_archive.sdz, any other mod that depends on old_archive.sdz would now use the new one instead.

It is probably not always a good idea to use this for new versions of a mod however, since if you hide the old version people would not be able to switch between the old and the new version. So only use replacements when you are sure that it is what you want.

===Final words===

If a player does not have a certain mod when trying to join a game, the info in description etc could be sent to allow the player to download it.. The filename could be sent as well, so that the client could try to download it automatically from a few predefined redirect servers (similar to the system unreal tournament uses).

[[Category:Mod development]]

Game and Unit development

2010-02-25T09:49:45Z

Argh: Removed an old Emmanuel edit; 'mod' is now 'game', removed some dead links

[[Engine_Development|Development]] < {{FULLPAGENAME}}

=Game development=
This information is meant to help newcomers learn how to develop their own games for the Spring Engine.
==General==
*[[Mod specification|Game specification]] 
*[http://spring.clan-sy.com/phpbb/viewtopic.php?t=6015 What do I need to create a game?]
*[[Simple Mod Tutorial|Simple Game Tutorial]]
*[[Freely available and reusable content|Freely available and reusable content for maps and games]]

==Unit Development==
====Models - s3o Files====
*[http://user.supradigital.org/jcnossen/UpspringInstaller-1.54-EulerAngles.exe UpSpring, our second-gen import / export / rigging / animation tool.]
* [http://lassie.student.utwente.nl/vliet/springtut.pdf Maestro's tutorial of Upspring and textures].
* [[Basic s3o unit making guide]]
* [[Simple Mod Tutorial|Simple Game Tutorial]]
* [http://spring.clan-sy.com/phpbb/viewtopic.php?t=10612 Wings UV Mapping Tutorial]
* [http://spring.clan-sy.com/phpbb/viewtopic.php?f=9&t=12354 Saving polygons in Wings3d Tutorial]
* [http://spring.clan-sy.com/phpbb/viewtopic.php?t=10947 Greeble Tutorial 1]
* [http://spring.clan-sy.com/phpbb/viewtopic.php?f=9&t=12356 Greeble Tutorial 2]
* [http://spring.clan-sy.com/phpbb/viewtopic.php?p=75495 various things about unit making. (Also contains an illustrated alpha-channel tut)]
* [http://spring.clan-sy.com/phpbb/viewtopic.php?t=10503 Runecrafter's 3DS Max UV Mapping Tutorial]
* [http://spring.clan-sy.com/phpbb/viewtopic.php?f=9&t=15106 Argh's UpSpring Easy Workflow Guide]
* [[Trouble-shooting s3o units]]

====[http://springrts.com/wiki/Category:Animation Scripting and Animation - COB/BOS Files]====
To edit .bos files you need a program/compiler. The most famous one is [http://jobjol.nl/1384 Scriptor]
*[[Animation-LuaScripting]]
**[[Animation-LuaCallins]]
**[[Animation-LuaCallouts]]
**[[Animation-CobLuaDifferences]]
*[[Animation-CobOverview]]
**[[Animation-CobExamples]]
**[[Animation-CobAnimation]]
**[[Animation-CobCallins]]
**[[Animation-CobConstants]]
**[[Animation-CobThreads]]
**[[Animation-CobHitByWeaponID]]
*[http://www.planetannihilation.com/tadc/tut_unit_01_1.asp PlanetAnnihilation] has a nice tutorial
*[[Units:LuaCOB]] - how to interface COB with LUA
*[[CEG_For_Units|Game Development:Calling basic CEGs from COB]]
* [http://spring.clan-sy.com/phpbb/viewtopic.php?p=132943#132943 GPL-compliant sourcecode, scripting code examples, and other things.]

===Legacy Porting Tools===
====Models - 3do Files====
-NOTE- this is and outdated model format used by OTA 
(Note: UpSpring has some problems with empty objects and groundplates)
*use [http://spring.clan-sy.com/phpbb/viewtopic.php?f=12&t=7208&p=126129&hilit=upspring#p126129 UpSpring] and [http://springfiles.com/1755 3doBuilder] to edit those files

====Automated Game Creation====
* [[TA2Spring]] - Automatically adds and converts Total Annihilation unit packs (.ufo files, etc..) into Spring games (requires a base gameification for the game rules, XTA is recommended)

====Units - FBI Files====
*[[Units:FBI]]
*[[All_FBI-variable_values:_min,_max,_default,_type|Units:FBI (variable datatype list)]]
*[[Unit_Categories]]

====Units - MoveTypes====
*[[Units:MoveTypes]]

====Weapons - TDF Files====
*[[Weapon Variables]] : This is the most up to date
*[[Units:WeaponMainDir]]
*[[Units:Weapons]] : Various informations about the weapontypes (uncompleted)
*[[All_Weapons_variable_values:_min%2C_max%2C_default%2C_type|Weapon datatype list]] : All weapon variables min/max/default values and datatypes listed.
*[[Weapons:Antinukes]]: All about antinukes.

====Explosions====
*[[CEG]]
**[[CEG-Calls]]
**[[CEG-Format]]
**[[CEG-Classes]]
**[[CEG-Operators]]
**[[CEG-Miscellaneous]]
**[[CEG-OldInfo]]

====Misc====
*[[Units:Design]]
*[[Units:Textures]]
*[[Units:Buildpics]]
*[[Units:SideData TDF]]
*[[Units:Download TDF]]
*[[Units:FlankingBonus]]
*[[Mod Development:Armor|Game Development:Armor]]
*[[Mod Development:Cursors|Game Development:Cursors]]
*[[Mod Development:Archives|Game Development:Archives]]
*[[Mod Development:Sidepics|Game Development:Sidepics]]
*[[CustomUnitIcons|Game Development:Custom unit icons]]

Development:Main

2010-02-25T09:30:46Z

Argh: Removed links that aren't relevant to working on the engine or AI for the engine.

{|width="100%" style="border: 0px; border-spacing:0px"
|width="500px" valign="top" style="padding-left:10px; padding-right:10px"|
'''[[Building spring|Building/Compiling the Spring Engine]]'''

How to build Spring from source. 
[[Building Spring on Windows|Windows]], [[Building Spring on Linux|Linux]], [[Building Spring on MacOSX|MacOSX]], [[Building Spring Cross Compiled|Cross-compiler]] or [[Building Spring on Buildbot|Buildbot]].

'''[[Getting_Started_Development|Spring Engine Development]]'''

Information regarding contributing to the source code of Spring.

'''[[Lobby_Development|Lobby Clients and Servers Development]]'''

Information regarding contributing to the source code of the different lobby clients and servers available for Spring.

'''[[AI:Development|Skirmish AI Development]]'''

All you ever wanted to know about Skirmish AI Development for Spring, and more. This includes Skirmish and Lua AIs.

'''[[Linux_Page |Linux and Mac OS]]'''

Mac OSX / NetBSD / Solaris / Linux / Cross-platform information.

'''[[Debugging_sync_errors|Sync Debugging]]'''

Contains instructions for debugging sync related errors in spring.

|valign="top" style="padding:0px"|

{|width="100%" class="legend"
! '''[http://spring.clan-sy.com/phpbb/viewforum.php?f=12 Development forums]'''
|-
| Look at the development forums for ongoing progress and discussion
|}

{|width="100%" class="legend"
! '''[http://springrts.com/mantis/ Report Bugs/Submit a Patch]'''
|-
| Submit patches and bug reports here
|}

{|width="100%" class="legend"
! '''[http://github.com/feeds/spring/commits/spring/master Commit Newsfeed]'''
|-
| View git commits as they happen.
|}

|}

Main Page

2010-02-25T09:28:28Z

Argh: Removed "Engine Development"; redundant

{{Languages}}
{|border="0" cellpadding="4" cellspacing="10" width="100%"
|width="50%" valign="top" style="background: #41545c; border: 1px #aaa solid;"|
== General ==

'''[[Read Me First]]''' Answers to questions often asked - Everyone should read this first.

'''[[FAQ]]''' Has it been asked before?

'''[[Using_Spring|Playing Spring]]''' How to play the game. Controls, issuing orders, and related topics.

'''[[Games]]''' Games that use the Spring engine.

'''[[Getting Spring Content and Links]]''' Lists sites related to spring, and sites from which you can download spring Mods/Games, Maps, and more

'''[[Maps]]''' All about maps for the Spring engine and where to get them.

'''[[AIs]]''' Skirmish AIs, Helper AIs...

'''[[Lua Widgets]]''' All about installing and using LuaUI widgets...

'''[[Spreading Spring]]''' Read before advertising.

'''[[Hosting Spring]]''' Autohosting and related topics.

'''[[Linux_Page |Linux and Mac OS]]''' Mac OSX / NetBSD / Solaris / Linux / Cross-platform information.

'''[[The Lighter Side Of Spring]]''' Humour, comics and quotations.
|width="50%" valign="top" style="background: #41545c; border: 1px #aaa solid;"|
== Game Development ==
'''[[Mod_and_Unit_development#Mod_development|Game Development And Unit Creation]]''' Lots of links to valuable Articles and forum threads regarding Mod/Unit Development.

'''[[Map_development|Map Development]]''' Tutorials and other useful information for creating maps.

'''[[Debugging_sync_errors|Debugging sync errors]]''' Guide to debugging sync errors for engine developers, mod developers and testers.

'''[[Lua Scripting]]''' Information regarding the use of the supplementary Lua scripting language for Widgets and beyond...

'''[[Map, Mod, And Unit Development Programs|Content Development Programs]]''' Links to all kind of useful programs.

'''[[AI:Development|AI Development]]''' Lots of information about developing Skirmish, Unit and Group AIs for Spring.

'''[[Monthly Topic Rotation]]''' Generally related to development of the engine or particular mods. Read before posting on the forums.

'''[[General Resources]]''' Usable textures, sounds and code snippets by the community, for the community.

'''[[Associated Development Groups]]''' Teams, Forums and Groups associated with Spring content and code development.
|}

{|width="100%" style="margin:10px; background:#2d3b43; padding:5px; border:1px #aaa solid;"
|
<center>'''This wiki needs your help!'''</center>

''"A wiki is a web application that allows users to add content, as on an Internet forum, but also allows anyone to edit the content."''
- [http://en.wikipedia.org/wiki/Wiki Wikipedia.org]

The spring project is very dependent on its community of users to help new players and developers. If you see anything here where a change would be helpful, please put it in. We are currently working together at the [[Wiki ToDo]] page to help coordinate improvements.

Any contributions you make to this Wiki are in the public domain. If you need help with the wiki markup, the [[Help:Editing|help page]] is an excellent resource.
|}
__NOTOC__
__NOEDITSECTION__

If you wish to comment on this page (or the wiki) you need to login and then you can go [http://taspring.clan-sy.com/w/index.php?title=Talk:Main_Page&action=edit&section=new here], and post your thoughts.
[[Category:Spring]]

Main Page

2010-02-25T09:28:28Z

Argh: Removed "Engine Development"; redundant

Using Spring

2010-02-25T09:26:03Z

Argh: Removed "Starting a Game"; redundant

{|border="0" cellpadding="4" cellspacing="10" width="100%"
|width="100%" valign="top" style="background: #41545c; border: 1px #aaa solid;"|
===Using Spring===

This is a fairly exhaustive description of controls, interface and features. For basic information, check the most current readme [[Readme|here]] or [[Read_Me_First|Read me first]]. For an introduction to the strategy and overall gameplay in XTA (and most mods based on the original Cavedog units) check out the [[Spring_guide%21|Spring Guide!]]. Other mods should have more specific documentation on their web sites or on the Wiki. Please see the links in the [[Games]] section.

For more advanced/current information check the most recent [http://taspring.clan-sy.com/changelog.txt changelog] (''fixme'') or the [http://taspring.clan-sy.com/phpbb/ Spring Forums].
|}

{|border="0" cellpadding="4" cellspacing="10" width="100%"
|width="100%" valign="top" style="background: #41545c; border: 1px #aaa solid;"|

===Articles===
'''[[Using_Selections|Selections/Groups/Group Commands/Group AI]]'''

'''[[Using_Orders|Issuing Orders]]'''

'''[[Command_Reference|Command Quick Reference]]'''

'''[[Printable_Reference|Printable Command Reference]]'''

'''[http://img108.imagevenue.com/img.php?image=03721_PK06A_Compact_Keyboard_ProdImage_Black_V2_122_972lo.jpg Spring default Keyboard layout] (OLD)

'''[[Using_Camera | Using the Cameras]]'''

'''[[Using_chat|Chat, Cheats, and Text Commands]]'''

'''[[Using_doodles|Map drawing/doodles]]'''

'''[[Using_custom_keys| Customized key shortcuts/bindings and the key/selection editor]]'''

'''[[Spring on a LAN]]'''

[[Category:Playing]]

[[category:Using Spring]]

Where files go

2010-02-25T09:24:03Z

Argh: Removed "download BA / NOTA".

===What It Is===
'''Maps:''' those neat places you will play your games in
'''Mods:''' those games you will play on the maps
'''Base ota content:''' material needed to run the games which use content from
the Total Annihilation Product demo and /or Main Product
'''Lua Widgets:''' configured settings for game play. they often make it much
easier to control your troops etc.
'''AI:''' an AI pot to give you an opponent in a game

===Where It Goes===
Maps go in the Maps folder in your Spring directory
Example: ''My Documents\My Games\Spring\maps''
Example Map File: "ExpandedTropics.sd7"

Mods(Games) go in the Mods folder in your Spring directory
Example: ''My Documents\My Games\Spring\mods''
Example Mod File: "NOTA154.sd7"
Example Mod File: "NanoBlobs065.sdz"

Base ota content is needed for all those lovely Mods like [[NOTA]]. It goes in your Base folder
in the Spring directory.
Example: ''My Documents\My Games\Spring\base''
An Example File: "otacontent.sdz"

Lua Widgets typically go in your Lua > Widgets folder
Example 1: ''My Documents\My Games\Spring\LuaUI\Widgets''
Some times you will find that they go here: "C:\Program Files\Spring\LuaUI"
Mods also come with widgets in their mod folder altering that is not for beguines so I will
not tell you here.
Example Widget File: "unit_customformations2.lua"

===What You Want===
'''Lua Widgets:'''
unit_customformations2.lua: Lets you draw orders in a line formation by dragging the mouse
while button is held down. Lets you draw attack lines, move lines, fight lines, unload
lines. Units/orders will be spread out along the line you draw
gui_clock.lua
unit_immobile_buider.lua: for BA and CA, not for NOTA sets keeps certain units active
unit_stockpile.lua: auto loads anti nuke silos and other such units not needed but very
useful
Transporter_2.lua: auto mathematically moves units with move orders which are guarded by a
transport with the transport nearly invaluable once you get a handle for every thing else
you need to do
gui_build_eta.lua: gives you eta for things under construction very useful but not needed
unit_improved_metal_maker.lua: helps metal makers run not needed but very helpful
[http://spring.clan-sy.com/wiki/NOTA#Team_Speak Team Speak] Lets you speak to your allies while in game

===What To Know===

If you use TASClient to find games hit F1 for help.
NOTA has some Single player missions.
S44 has a decent AI created for it.
SWIW has a decent AI created for it.
Many mods have "chicken modes" or "Space Bug modes" which are basically a defense against waves of forces.
'''drawing messages''' on the game map while in game uses "~" (found under
the Esc key)and the left
mouse button.
Hold the "~" key and Single click your wheel button to place a point on the map and double
click to place a point with text. Use "~" and the right mouse button to erase.

''' [[Getting_Spring_Content_and_Links|<- Back to "Getting_Spring_Content_and_Links" page]]'''

[[Category:old]] [[Category:unsorted]]