The Wizards Wiki

Welcome to The Wizards Wiki! - [Welcome to The Wizards Wiki!]

mhgamework (mhgamework@undisclosed.example.com) — 2015-05-13T15:28:58+00:00

2015/05/13 15:27		current
Line 2:		Line 2:


-	This wiki contains information collected about the development of The Wizards Engine. More recent information used to be available at the confluence wiki. This wiki has however been taken offlline, a static version of its content is available at [[http://thewizards.be/archive/skymerchantconfluence/DEV/The-Wizards-Engine-Home_491524.html\|Engine documentation]] and the [[http://thewizards.be/archive/skymerchantconfluence/DEV/index.html\|Game Design documentation]]	+	This wiki contains information collected about the development of The Wizards Engine. More recent information used to be available at the confluence wiki. This wiki has however been taken offlline, a static version of its content is available at [[http://thewizards.be/archive/skymerchantconfluence/DEV/\|Engine documentation]] and the [[http://thewizards.be/archive/skymerchantconfluence/DESIGN/\|Game Design documentation]]

Installing the wizards for development

mhgamework (mhgamework@undisclosed.example.com) — 2015-03-17T15:55:12+00:00

2013/09/03 10:08		current
Line 1:		Line 1:
	====== Installing the wizards for development ======		====== Installing the wizards for development ======
		+
		+	SEE the confluence page for an up-to-date install guide [[https://skymerchant.atlassian.net/wiki/display/DEV/Installation]]
		+

	===== Requirements =====		===== Requirements =====

- removed

mhgamework (mhgamework@undisclosed.example.com) — 2015-03-16T16:07:28+00:00

2011/09/01 14:26		current
Line 1:		Line 1:
-	====== Concept ======
-
-	These pages will contain the specification of all features in The Wizards (mainly gameplay-features). This information is subdivided in sections:
-
-	* The actual specification of the feature.
-	This section specifies all aspects of the feature in a strict way, it does not contain suggestions, ideas, possible extensions, ...
-
-	* A blackboard section.
-	Contains suggested changes, more ideas or extensions to the features.
-	This can contain any kind of applicable information and does not have to follow any of the other specifications.
-	This way, it can act as the features' blackboard
-
-	Anyone can add to these blackboard's at will, add anything you like! There is also a [[concept:generalblackboard]].
-
-	===== Contents =====
-
-
-	The [[concept:general]] explains the main goals and features. It provides a high-level guideline.
-
-	More specific information can be found in corresponding pages below
-	* [[concept:fortressbattles]]
-	* [[concept:combatsystem]]
-	* [[concept:world]]
-	* [[concept:building]]
-
-

- removed

mhgamework (mhgamework@undisclosed.example.com) — 2015-03-16T16:05:53+00:00

2011/09/02 15:38		current
Line 1:		Line 1:
-	====== Building ======

-	A building crystal can be used to build your own structures. The crystal can compose building blocks out of materials or other building blocks, and place them in the world.
-
-	There are 4 types of blocks: 3D cubes(block), 2D planes(wall/ceiling), 1D pillars, or composite blocks. These are to be placed in a world grid with resolution 1m. Walls are placed at the grid cube faces, and pillar's at the edges.
-
-	The player holds several helper crystals on his belt. These crystals can contain 1 building block TYPE. They are used to place the building blocks.
-	Upon block placement, the building crystal collects resources from within its range, and builds the placed blocks. This happens instantly (for the moment)
-
-	Block can be combined. 2 walls can be combined into a double length wall. This allows for creating any kind of curved wall.
-
-	Block combining is done by placing blocks using your typed crystals. The building crystal projects a grid 3x3 somewhere. The user can place blocks in the grid, and when a correct combination is made, the building crystal projects that new combined block at a nearby location. By clicking that block with an empty type crystal, the type crystal gets the type of the combined block.
-
-	Each time a block is placed in the world, the tile engine will try to combine blocks into more detailed tiles, starting its search from the placed block. These tiles are part data: the only change when a block is placed.

- removed

mhgamework (mhgamework@undisclosed.example.com) — 2015-03-16T16:05:36+00:00

2011/06/08 14:43		current
Line 1:		Line 1:
-	====== Combat System ======
-
-	===== Blackboard =====
-
-	Coop-combat: includes spell synergies, basic spells usable in coop (ie deflecting shields to shoot around corners, player levitation), spells that can only be cast by multiple players (ie beams between 2 players to mow the enemy down), spell mixing effects, ...
-
-
-	Different types of spells
-
-	==== Shot ====
-
-	Some kind of shooting skill, which should feel like in Fable III.
-
-	You charge some form of barely stable energy. When you release it, due to its instability you can shoot it away at high speed.
-	It is possible to charge this spell, only the energy will get more and more unstable.
-
-	Some kind of very simple minigame could make this instability real to the player. This gets harder with increasing instabiltiy.
-	Also some blurring effects should occur. The player needs to focus on the casting so can't focus as much on the battlefield.
-
-	Suggestion for the minigame: Can't move while charging. Movement keys are used to move a point on a circle.
-	There is your focus point, which you control, and a energy focus point, which is a second point that moves away from the focus point,
-	faster when distance is greater. When the 2 points coincide, they are in a metastable state.
-	This state gets less stable when the energy gets less stable.
-
-
-	For short bursts this should be easy, and it should also be able to shoot bursts like this while moving and doing combos.
-
-
-	==== Shield ====
-
-
-
-
-
-
-
-
-
-
-

- removed

mhgamework (mhgamework@undisclosed.example.com) — 2015-03-16T16:05:05+00:00

2011/06/09 16:23		current
Line 1:		Line 1:
-	====== Fortress Battles ======
-
-
-
-	===== Blackboard =====
-
-	The play can roam the world and capture outposts.
-
-	Outpost can be reinforced
-
-	A Fortress protects the outpost. It stores gathered resources and maybe expensive production facilities.
-	A fortress contains a Spawn Crystal, that can spawn minions to protect the fortress. (todo: rename spawn crystal to something more ingame)
-
-	Spawn crystal has an amount of energy, which is consumed by spawning minions and other tasks it performs.
-	The crystal also supports the creatures existing on the battlefield.
-
-	The attacker also brings a spawn crystal, which performs the same functionality. When one of the crystal runs out of energy, the battle is over.
-	This will not happen in the common way 'YOU LOST'. The run-out crystal will simply stop spawning and providing energy to the combatants,
-	causing them to loose power (and die in case of minions). This way the battle is lost in a more gameplay-featured way.
-	It also allows for features like retreating.
-
-	The Players fighting in the battle will also drain from the energy of the crystal. This way it might be possible to fight wars with different player setup:
-	* Battle of 2 players capturing an empty fortress. The fortress' crystal will spawn more minions then the attacking crystal, which should cause a balance in the battle
-	* When in 1v1 or 2v2, minion count will be equal, but 1v1 will have more than 2v2
-
-	This system implies that Players can't cast spells from their own energy. The Fortress Battle has to be a closed system:
-
-	All possible skills must be predictable at the start of the battle.
-	This points to a combat system where the environment is used for spellcasting. Players could carry those energy crystals to draw power from,
-	but entering a fortress battle should somehow disable all damage or power increasing effects there might be in a game.
-
-	The Combat moves learned by the Players or self-created moves, are considered predictable. It is part of the gameplay to know what moves exist,
-	much like knowing what openings exist in RTS.
-
-
-	==== Building ====
-
-	It should be possible to use the TileEngine in some way to build your outposts. An easy feature that implements this would be cave creation:
-
-	Create a room somewhere (preferably in the outpost centre, the fortress should have a room (circular) with a crystal in the center at the ceiling.
-	This crystal 'visualizes' the fortress, like a hologram. Players can move around in it and place virtual tile pieces,
-	making build tasks while doing so.
-
-	It might be possible to morph the dungeon tiles when building. Create a mesh that has the nb of vertices of the target mesh (ev. tesselate).
-	Then map every target vertex to the closest source vertex. Tween these vertices between start and end vertex.
-	Textures can be blended using source and target texcoords, normals can be tweened. \\
-	A solution must still be found for source vertices not having a target vertex. Maybe map these to the closest target, and map that one.
-	Otherwise, some kind of weighing function can be used to map the vertices.
-

- removed

mhgamework (mhgamework@undisclosed.example.com) — 2015-03-16T16:04:51+00:00

2011/06/30 10:15		current
Line 1:		Line 1:
-	====== General Concept ======

-	===== Blackboard =====
-
-	* Interactive 'skilled' combat system: real time combat system about same complexity as rts
-	* No GUI: inventory? open bagpack, others can also watch and take. (ex: Spell building? building composing ==> virtual environment , ...)
-	* Independent world (no player disconnect, creatures, vegetation, economy)
-	* Central cities, outposts, guards, resources
-	* RTS elements
-	* Grinding == combat training == in-game character combat intuition generation
-	* Outpost + City battles
-
-	* Minions through spawn crystal, use for defending outposts.
-	* The world consists of some major cities (currently 2: the good main story city, and the Eeeevil city of the black monsters). Scattered across the world are outpost, which provide resources amongst other things.
-
-
-
-	==== Main goals ====
-
-	* You are in an interactive movie. You are NOT playing a computer game. <code>
-	The game should do everything to not break the virtual world it creates. All pc specific things should be minimized.
-	You are moving around in a real world, and you do everything as if it would be a real world.
-	Example: there is no inventory screen, you only have a backpak where you have to take things out of.
-	Note that the game is still allowed to 'hint' actions. This is what are in real-life automated actions, or intuition.
-	Example: auto-aiming of spellcasting, autotargeting for item pickup, or even for laying it out in shops, opening doors,...
-	</code>
-
-	* Always Allow Multiplayer, everything can be done in team <code>
-	This is also true for even GUI should be mp, preferably do this by making all gui ingame.
-	Example: Spell training happens in a magic created environment, telepathy,...
-	Trading is laying out items on the ground and picking them up.
-	</code>
-
-	* Jump into game, play immediately, jump out (about 20 mins?)
-
-	* Can do everything!! (can be guard, shopkeeper,... can be useless and boring, but its possible)

- removed

mhgamework (mhgamework@undisclosed.example.com) — 2015-03-16T16:04:36+00:00

2011/06/08 14:51		current
Line 1:		Line 1:
-	====== World ======

-
-	===== Blackboard =====
-
-	The Wizards should be one vast world.
-
-	There should be some major cities, and a lot of outpost scattered around them. There should also be island, which requires sea-travel.
-	Not sure sea-travel should be in the first version, allthough an ocean should.
-
-	One of the major cities should be the [[assets:modeling:the_city\|City Model]]

- removed

mhgamework (mhgamework@undisclosed.example.com) — 2013-09-05T09:48:47+00:00

2013/08/29 10:02		current
Line 1:		Line 1:
-	====== Coding Guidelines ======
-
-	(Higher has more priority)
-
-	Do not use underscores!
-	Classes: PascalCasing
-	Public: PascalCasing
-	Private: camelCasing
-
-
-	We are now using IoC for the wizards. This means:
-
-	Do not use the 'new' keyword, unless you are using it within a factory class or a factory method. The only allowed usages of new are with structures and for collections.
-
-	Use Responsibility driven design. This means that you should list each responsibility of the class above the class (documentation). There should be only one class with for each responsibility.
-	Having a responsibility means: If some other part of the system needs this responsibily, it HAS to use that single class implementing the responsibility. If this is not possible, your design is flawed.

Source code directory structure - created

mhgamework (mhgamework@undisclosed.example.com) — 2013-09-03T10:08:58+00:00

2026/04/07 20:28	current
Line 1:	Line 1:
	+	====== Source code directory structure ======
	+
	+	Here's some info about the source code:
	+
	+	* /The Wizards.sln contains the full solution for the wizards. This gives you access to all the code. It takes some time to compile though.
	+	* /The Wizards Gameplay/The Wizards Gameplay.sln contains the solution or gameplay development. Use this when not working on the core engine, this solution will compile a lot faster.
	+	* /BuildAll.bat compiles all of the wizards! Use this when you do not want to start visual studio or open the entire wizards solution (eg when working on gameplay).
	+	* /bin/ is the root folder containing all the run-time files. This folder should contain all the necessary files to run The Wizards.
	+	* /bin/Binaries/ contains all the compiled binaries from the source code.
	+	* /bin/Binaries/NewModules.exe is the engine executable. Run this file to run the engine!
	+	* /bin/GameData/ contains all the assets used when running The Wizards. The 'GameData' folder in the assets dropbox should be copied to this folder in order to get all the assets! (will be automated in the future)
	+	* /bin/GameData/Core/ folder is under version control, so add crucial files for unit testing here. However do not add large files here since they will be in the repository forever! For large files use the assets dropbox!

graph3drelaxerline.png - created

mhgamework (mhgamework@undisclosed.example.com) — 2013-05-25T20:44:24+00:00

	current

project020004noclipmixed.mp3 - created

chuptys (chuptys@undisclosed.example.com) — 2012-09-18T11:54:34+00:00

	current

project019002.mp3 - created

chuptys (chuptys@undisclosed.example.com) — 2012-09-06T12:46:27+00:00

	current

project016001.mp3 - created

chuptys (chuptys@undisclosed.example.com) — 2012-06-24T08:06:48+00:00

	current

cavescene01.png

chuptys (chuptys@undisclosed.example.com) — 2012-05-02T06:49:00+00:00

	current

cavescene.png

chuptys (chuptys@undisclosed.example.com) — 2012-04-29T15:18:28+00:00

	current

anaglyph3dcombiner.png

chuptys (chuptys@undisclosed.example.com) — 2012-04-29T11:02:39+00:00

	current

output131.png

chuptys (chuptys@undisclosed.example.com) — 2012-04-29T10:57:02+00:00

	current

right0131.png

chuptys (chuptys@undisclosed.example.com) — 2012-04-29T10:56:30+00:00

	current

left0131.png

chuptys (chuptys@undisclosed.example.com) — 2012-04-29T10:56:03+00:00

	current

2026/04/07 20:28	current
Line 1:	Line 1:
	+	====== Source code directory structure ======
	+
	+	Here's some info about the source code:
	+
	+	* /The Wizards.sln contains the full solution for the wizards. This gives you access to all the code. It takes some time to compile though.
	+	* /The Wizards Gameplay/The Wizards Gameplay.sln contains the solution or gameplay development. Use this when not working on the core engine, this solution will compile a lot faster.
	+	* /BuildAll.bat compiles all of the wizards! Use this when you do not want to start visual studio or open the entire wizards solution (eg when working on gameplay).
	+	* /bin/ is the root folder containing all the run-time files. This folder should contain all the necessary files to run The Wizards.
	+	* /bin/Binaries/ contains all the compiled binaries from the source code.
	+	* /bin/Binaries/NewModules.exe is the engine executable. Run this file to run the engine!
	+	* /bin/GameData/ contains all the assets used when running The Wizards. The 'GameData' folder in the assets dropbox should be copied to this folder in order to get all the assets! (will be automated in the future)
	+	* /bin/GameData/Core/ folder is under version control, so add crucial files for unit testing here. However do not add large files here since they will be in the repository forever! For large files use the assets dropbox!