galaxyyao / touhougrave Goto Github PK

Accessing to Game arbitrarily from UI thread may possibly cause race condition. Either duplicate the game object per-frame or lock the Game while flushing commands

• deal with interaction correctly;
• don't block UI thread.

PlayerPlayer/PlayerController shall be unified for public interface;
OpponentPlayer/OpponentController shall be removed considering multi-player game of more than 2 players; use collection of enemy players instead.

Combats should be animated.

• After AI makes a move, pause the execution for a certain amount of time;
• When AI does targeting (attack, select spell target, etc.), UI hints shall be rendered (card highlights, arrows, etc.);
• Implement game logging, like the combat logging window in WoW.

Numbers shall be rendered with bigger fonts. Modified values caused by some buff/debuff shall be rendered in green/red or other effect.

Create Battle Network, which hold players' profile, default deck and so on

With card & skill number grows, there should be a deck builder in XNA application, for testing if a skill is designed properly, without modifying source code.

Implement multi-player game based on public p2p connection.

Problems like firewall penetrating could just be ignored: one could safely assume that at least one peer has public address because finally our public server will act as a bridge.

Commands are sent two-way-ly between clients. The granularity of command packing(how often or on what timing commands are sent packed) shall be carefully defined.

Proper command serialization shall be implemented then.

The whole game states need to be hashed and sent over to validate the synchronization.

Instead of Hard code, initialize deck from Local or server profile

As title

Resolve shall be done after each flush of command queue.ResolveBattlefieldCards could be removed afterwards.

Currently, effects for summon-able card & sacrifice-able card are the same(green border), which makes it difficulty to make them out.

Consider how to render them and how to let player inspect them in detail.

When new card is added to handset, automatically sort handset by:

1. Card type(warrior, assist, assault)
2. Mana Cost
3. Card Id(Marisa, Reimu, etc.)

Some behavior requires temporarily cancel current command in setuptrigger, and issue a new command.
For example, Passive_AttackFirst requires cancel DealDamageToCard first, and take it back if attacker is not killed
Another example, one behavior: cancel one spell, and deal N damage to enemy.

Filing Character Skills v0.3.0, based on Len's character design document

For dynamic create server if connection number meets limit

Card entering graveyard should be animated.

Succeeding task of #47.

Intended to test the effectiveness of the particle system.

Implement the server side of the game. Shall provide the following services:

• Player registration and authentication;
• Friends management;
• Player profile: cards, decks, level, rank, campaign progress, etc.;
• Automatic match making means when player hits the Play button, the server will automatically find other player with matching skill to start a multi-player game with;
• Alternatively, player shall be able to start a game with his/her friends, of course;
• Chat and world channel chat.

It definitely will be a very HUGE story. But only basic features will be implemented at the initial game launch. Players of 100-200 is the target number to be aimed at.

1. Font replacement for certain char set (alphabets, numerical digits, etc.);
2. Visually "High DPI" fonts which basically renders down-scaled glyphs, for sharper/higher visual quality;
3. Additional effects like outlining, shadowing, etc. Two approaches: A. directly import pre-rendered font sprites with these effects to replace certain chars; B. Employ Valve technique to render them in a custom fragment shader.

For a crude implementation, one may just write out the serialized form of commands into a file on disk, along with the initial parameters of a game (decks, hero, random seed).

Replay the written replay file in Console.

Resolve shall be done after each flush of command queue.ResolveBattlefieldCards could be removed afterwards.

Resolve shall be done after each flush of command queue.ResolveBattlefieldCards could be removed afterwards.

Before doing the actual task, either make some benchmarks or use profiling tools;
Prioritize the maintainability and usability of the public interface of behavior system.

BaseCard.BehaviorList currently has IList interface implemented, but for modding purpose this interface shall not be exposed publicly. Change it to a readonly collection.

The system will let the card (characters) chat with each other.

The detailed design is to be determined.

And some behaviors which let the card to be effective in sacrifice zone reveal their host cards in sacrifice zone.

Make it compile;
Redo some commands to adapt the change of interactions.

Card controls shall work correctly while game states are changing at background. That usually happens under multi-player games.

Specifically, MouseDown/MouseUp and MouseEnter/MouseLeave do not necessarily happen in pair. And effect icons tend to change.

Issue #27 also falls in this topic.

Refactor, rewrite or document; by any means, make the code cleaner & more maintainable.

Similar to MTG, sometimes it's necessary to show some special mark on Card. For example, poison mark.
It can be used to present a 2nd resource, or a dot.

Since new behaviors may possibly need to ask the player select targets from library/graveyard, UI should be implemented to allow such an action;
Also the graveyard shall be inspect-able by all players at any time during a game.

UI needs to be implemented to let player discard cards over the cap;
And the cap shall be modifiable by behaviors.

Resolve shall be done after each flush of command queue.ResolveBattlefieldCards could be removed afterwards.

Design, define and implement the countering process.

Local trigger shall be implemented for PlayCard, DrawCard, DealDamageToCard, Kill, Summon, AddBehavior and RemoveBehavior commands (which has a clear target). Local triggers are triggered only for those target cards so that writing new behaviors could be easier.

Allow button texts to be customized;
Allow icons or cards to be displayed for each option.