🔒 Locked

[UFEC] Cycle

Started by XDigital Oct 30, 2009 at 2:42 PM 34 replies 19.7k views

Original Post

Oct 30, 2009 at 2:42 PM

Cycle is a strategy board game with trading card game elements. Stats Number of players: 1 or 2, Human vs Human or Human vs Computer Scenario: In casual mode no scenario available. In strategy mode player can select between Lords of Ice (Water) and Brotherhood of Flame (Fire). 4 Elements: Water (Lords of Ice), Fire (Brotherhood of Flame), Proliferation (collection of points in strategic gameplay), Evolution (player has to occupy as much fields as possible) Techniques: Renderer: OpenGL Sound: SDL Sound API Window management: SDL API User Interface: Self made circle menus Target Platform: Linux (Ubuntu), Windows and hopefully Maemo (which is Linux - not sure if I manage to install it there) Check out the Dev Log for further information. [Edited by - XDigital on January 9, 2010 3:00:55 PM]

XDigital

Nov 3, 2009 at 4:08 PM

I know you may laugh, anyway here is the first screenshot for UFEC 09...

It is more than just a black screen, even if it looks like just a black screen. Game mechanics are finished on paper and have to be implemented now.

Time/Task Schedule:

Define Game Mechanics (check)
Implement Game Mechanics (launched)
Define supporting features
Implement supporting features
Define graphics style
Artwork
Sound Design
Implementation of Art and Sound
Balancing
Testing
Documentation

Erik Rufelt

Nov 3, 2009 at 4:31 PM

Nice =) I'm still trying to decide on a game idea.

XDigital

Nov 6, 2009 at 3:13 PM

Find here the board of Cylcle. I descided to start with the mechanics completely without graphics and other stuff. It is hard to not open GIMP or Wings3D and just code the essentials, but I think it is important to have a robust core engine. Last time with Libertine I got lost in bugs. This time I try to avoid as much as possible (dare me father, for I must sin!). First interaction is available, fields and nodes are identified and accessable. Just one player.

XDigital

Nov 19, 2009 at 1:49 PM

No new screenshot available. I'm just coding all the basics and essentials, prepare the classes and game architecture. I hope that a clean and secure menu and game flow is worth to spend some more time and effort. However it makes no fun to have just lines of code and no eye candy. There is even no element included yet.

XDigital

Nov 21, 2009 at 1:35 PM

OK, weekend did its best. I finished the menu and user interface. As promissed, it's still ugly without shadows, bloom, blur, particles, high res textures and post processing effects. It's still a menu with a functionality. However it works without memory leak. 24 MB RAM usage for Cycle at this stage. The app itself has in debug configuration 624,8 KB. It would still fit on a 3.5'' disk.

Here the update of the schedule

Define Game Mechanics (check)
Implement Game Mechanics (check)
Define supporting features and AI (launched)
Implement supporting features and AI
Define graphics style
Artwork
Sound Design
Implementation of Art and Sound
Balancing
Testing
Documentation
Industrialisation on Windows/LINUX

And here the proof

XDigital

Dec 6, 2009 at 3:47 AM

After at least 2 weeks of pure coding, research and frustrating pointer errors, I needed to do something nicer than just looking at lines of code. Find the first texture within Cycle. Its the texture used by the player when desciding if human or AI plays.

Rendering with Wings3d - Post-processing with GIMP

plus KI

[Edited by - XDigital on December 6, 2009 10:47:08 AM]

Jason Petrasko

Dec 6, 2009 at 10:27 AM

Looks good!

"After at least 2 weeks of pure coding, research and frustrating pointer errors, I needed to do something nicer than just looking at lines of code."

Haha, that is what I've been doing too - code until I can't any more and then work on the graphics.

XDigital

Dec 6, 2009 at 1:39 PM

Thanks :)

and because the biggest bug (for now) is fixed, I rewarded myself with a first (kitschy) idea of the background scenery for the "lords of fire". OK, the dragon is taken from TurboSquid.com and he will not be part of the final game, but what is a vulcano without a dragon???

Glinka

Dec 7, 2009 at 12:59 PM

Nice work Xdigital.

XDigital

Dec 8, 2009 at 12:21 PM

Oh, well. The tecture is terrible and I'm not quite confident with the mesh of the vulcano, but it is an idea of a possible solution.

So far for the "eye candy". Yesterday I managed to install the target environment on my computer. Guess what... Yes it's Maemo 5. I hope the community manages to migrate SDL to Maemo in time. Otherwise, I have to shift my time schedule...

So far for the screen-shot spamming. Have to get back to Code::Blocks :/

XDigital

Dec 13, 2009 at 2:36 PM

Again a complete week related to only one topic. The AI. This is my first attemp to code a working AI not with differential equations. A ton of if loops needed to be designed - for just one function. It took me the complete weekend to assemble the basic AI function. All AI functions return a factor with which the computer makes its selection (if everything works correctly). After creation of all functions I thought of a kind of brute force mechanism to guess future steps (a little bit like check). But this is not decided yet.

Here a screeny from Cycle with the casual gameplay mode and a snap-shot from my main function, which calls the AI functions.

...what a brainteaser...

Updated Schedule

Define Game Mechanics (check)
Implement Game Mechanics (check)
Define supporting features (launched) and AI (check)
Implement supporting features (launched) and AI (launched)
Define graphics style (launched)
Artwork (launched)
Sound Design
Implementation of Art and Sound (launched)
Balancing
Testing
Documentation
Industrialisation on Windows/LINUX (UBUNTU and MAEMO)

XDigital

Dec 19, 2009 at 1:52 PM

I started coding one of the core bits, thats puts depth into the gameplay - the trading card game mode. I still am not convinced with the actual approach on how to rate the cards when played by the computer, but the functionality is improved compared to the status 1 month ago. See below a screenshot of two parties (called pacts) play each other. Brotherhood of Flame vs. Lords of Ice. Both in their own scenario, with own decks (cards). The art-style of the cards is close to final, the one of the background not.

XDigital

Jan 2, 2010 at 2:38 PM

Sluggish progress during christmas vacation. Maybe due to christmas. Who knows. However here are the first designs of the trading cards. More in progress, this is just a teaser.

Lords of Ice

Brotherhood of Flame

I recognized, that creating just one card takes more than 2 hours (design, art, text, implementation, source code). Maybe I have to skip the two other pacts. It starts to become time consuming.

Happy new year to everybody.

XDigital

Jan 9, 2010 at 2:56 PM

Today I finished the decks of Brotherhood of Flame and Lords of Ice. This is a big milestone, because the human vs human gamelplay is finished now. The AI is still outstanding and the graphics are ugly. No screenshot because of spoiler alert. But it's time to update the schedule.

Updated Schedule

Define Game Mechanics (check)
Implement Game Mechanics (check)
Define supporting features (check) and AI (check) <-------!!!
Implement supporting features (check) and AI (launched) <------!!!
Define graphics style (launched)
Artwork (launched)
Sound Design
Implementation of Art and Sound (launched)
Balancing
Testing
Documentation
Industrialisation on Windows/LINUX (UBUNTU and MAEMO)

Looking at the schedule, I realized that it is again challenging to finish in time. AI is probably taking a month. For artwork I think I need another week for definition phase and 3 weeks for implementation (painting, particle engine, other effects...). Gives me not enough time for balancing and testing.

Argh, it's just a board game. WTF am I doing wrong?!?

XDigital

Jan 17, 2010 at 8:44 AM

It took the complete last week to figure out how the computer plays with cards. After a lot of trial and errors I found a way using function pointers, which are very similar to virtual functions. I descided to use function pointers and not virtual functions, because the basic architecture is not designed to make derivatives of the card class...
Unfortunately the main function grows and grows, which makes it very hard to keep overview over the code. It's still structured, well... somehow...

Here a new screenshot

p.s. the computer wins too often.

Jason Petrasko

Jan 22, 2010 at 11:37 AM

Could you provide an overview of how the game plays? I mean, question one: how do the cards map to the interesting and visually cool board?

I have more questions, but an overview would be nice :)

popsoftheyear

Jan 22, 2010 at 11:48 AM

Quote:
Original post by XDigital
It took the complete last week to figure out how the computer plays with cards. After a lot of trial and errors I found a way using function pointers, which are very similar to virtual functions. I descided to use function pointers and not virtual functions, because the basic architecture is not designed to make derivatives of the card class...

If you haven't already, you may want to look at
FastDelegate or boost::function (or std::tr1::function if your compiler supports it).

Life with function pointers gets much easier this way.

XDigital

Jan 23, 2010 at 7:00 AM

@popsoftheyear:
I'm satisfied with the solution I have right now. Most important: I understand my code even after 3 days of absence.

the assignment is:

   deck_BoF[0].LoadResource("./deck/BoF_Fireball.txt");   deck_BoF[0].SetAction(ActionBoF_Fireball);   deck_BoF[0].SetTryAction(TryActionBoF_Fireball);

the implementation is:

   void  (*Action)    (void);   float (*TryAction) (void);

and:

   inline void SetAction(void (*_fcn_handle)(void))     { Action  = (*_fcn_handle); }   inline void SetTryAction(float (*_fcn_handle)(void)) { TryAction = (*_fcn_handle); }

It's possible to call the functions from outside, because they are member functions from class "card". It was easier to do it this way, than to use virtual functions.

See the implementation inside the AI function part, which is used to balance the chances, which card to be played. It works without memory leak and increasment.

   if (play_with_cards){      //Maximum of three active cards available      //Chance, which card to be played best      std::vector<int> index;      index = player[active_player].GetActiveCards();      std::vector<float> chance;      for (int iCard = 0; iCard < (int)index.size(); ++iCard){         active_card = index[iCard];         chance.push_back(player[active_player].deck[index[iCard]]->TryAction());      }      if (chance.size() > 0) {         //Which card has highest chance to be played?         int best = Math::MaxFIndex(chance);         //Play Card if Chance higher than 60%         if (chance[best] >= 60){            effect_player = active_player;            effect_card   = index[best];            active_card   = index[best];            Action();         }      }   }

The Action is used by AI and by player, therefore I needed to capsulate it:

//------------------------------------------------------------------------------void Action(void){//------------------------------------------------------------------------------   if (player[active_player].deck[active_card]->Action != NULL &&      !player[active_player].deck[active_card]->IsBlocked()){      player[active_player].deck[active_card]->Action();      if (player[active_player].deck[active_card]->IsTagged())         player[active_player].deck[active_card]->SetBlock(true);   }}

@Jason:
Goal of Cycle is to occupy the most fields. You see the red nodes at the crossings? Those have to be occupied by tokens. The player with the most occupied tokens around a field occupies the field. If the number of player and enemy tokens are the same, the field is freed. The cards can be used to delete enemy nodes, steal enemy nodes, reduce enemy points (needed to play cards), modify card status (block, discard, draw new) or similar stuff. To increase the strategic part, I need to do a bit more balancing. The cards are finished in design, but need to be improved a bit. Right now, Brotherhood of Flame is a bit too strong. However, the computer is able to play itself.

XDigital

Feb 25, 2010 at 2:02 PM

This is the latest update of Cycle development. I put a complete week into sound engineering and descided to skip the whole sound stuff because of the following:
SDL_sound does not match 100% with existing code architecture -> redesign would take a week
OpenAL too few knowledge (however it seems to be not so difficult) -> get in touch and implementation would take a week
FMod C (Windows) vs C++ (Linux) -> additional cross compilation efford would take a week
Additional sound effects, ambient sounds and sound engineering would take another week.

Leading to two weeks for ear-candy. Cycle is playable without sound effects. Therefor it is just "nice to have". I know that it reduces atmosphere, but priorities have to be set.

Updated Schedule:

Define Game Mechanics (check)
Implement Game Mechanics (check)
Define supporting features (check) and AI (check)
Implement supporting features (check) and AI (check)
Define graphics style (check)
Artwork (check)
Sound Design (skipped)
Implementation of Art (check) and Sound (skipped)
Balancing (check)
Testing (check)
Documentation (launched)
Industrialisation on Windows/LINUX (launched)

Outstanding Items:
QRG
Small Improvements (ESC, QUIT buttons, ...)
Installation Script LINUX
Windows Compile
Installation Wizard Windows

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.