Collectible Card Game Headquarters

A random theme generator would be awesome, not just for the map part of the game, but also the "constructed" game mode of Forge. It would be vastly superior to the current way of randomizing decks, that's for sure

Of course they're samples... all of this is just brain storming. When I say something "should" be done... I'm not dictating anything.. though I wouldn't mind if it were done precisely as described.... It's just a lack of other grammar to imply the "strong suggestion"....

Let's say the percentage of engine cards is 20%. Let's say the average deck size is 45. (avg CMC of all cards in Forge currently is 3) 9 card slots will need to be filled, so there would be only 5 engine cards defined to select from. The extreme cases: 15 card deck (1cmc Goblin) = 3 card slots, likely only 1x of 3 different cards; 105 card deck (7cmc Beast) = 21 card slots, highly likely that all engine cards will show up at least 2x or 3x each, one or two of them will show up 4x.
If a selection is made for a card already present 4x, keep choosing cards until all slots filled or all selectable cards are 4x each (leaving room for extra chaff?))

BTW, I got another idea. I don't think starting with a creature on the battlefield is a good move, however... how about starting with some lands? Basically, have a computer start with some lands corresponding to the terrain you fight in. Perhaps 1 land for common opponent, 2 for uncommon, and 3 for rare, with the exception of legendary lands which would always start in one copy. Imagine going against an opponent in Mishra's Factory

Rob Cashwalker wrote:Of course they're samples... all of this is just brain storming. When I say something "should" be done... I'm not dictating anything.. though I wouldn't mind if it were done precisely as described.... It's just a lack of other grammar to imply the "strong suggestion"....

Let's say the percentage of engine cards is 20%. Let's say the average deck size is 45. (avg CMC of all cards in Forge currently is 3) 9 card slots will need to be filled, so there would be only 5 engine cards defined to select from. The extreme cases: 15 card deck (1cmc Goblin) = 3 card slots, likely only 1x of 3 different cards; 105 card deck (7cmc Beast) = 21 card slots, highly likely that all engine cards will show up at least 2x or 3x each, one or two of them will show up 4x.
If a selection is made for a card already present 4x, keep choosing cards until all slots filled or all selectable cards are 4x each (leaving room for extra chaff?))

I can't imagine a 15 card deck doing very well in most circumstances. Unless it's 15 cards with the primarily goal being a first turn win. With 33%-40% requirement for land in a 15 card deck is 5-6 cards, which gives only 9-10 cards that do anything. It seems really easy to drop a wall and deck your opponent everytime.

I feel it makes sense to have 40 cards be the minimum for any deck (as this is the case for limited deck building). If we still want to scale by Creature Level (CMC) for deck size then it should probably be more like 36 + 4(CMC). This would yield level 1s at 40 cards. And level 7s at 64. And putting the average at 48, which is similar to your average just with a tighter distribution.

But then the size od the deck would be almost irrelevant...

I've tried just about everything to get rid of this memory leak... even a very small background map image: an 800x600 gif - (which would be the minimum tilesize I'd use when chopping the whole thing into little pieces), and when I call getColorModel() on the corresponding BufferedImage loaded it says it is in fact 8 bits (not 24 nor 32) which amounts to less than half a megabyte in memory.

Clearly something else is going on. The funny thing is, stuff runs great until I start a battle from within the map (the map is supposed to be paused/disposed/asleep at this point), but even if I try setting the Map JFrame to null and also setting all of its child components to null, I still see rendering/update messages going on in the background, clogging up resources at an alarming rate (my task manager also shows a dramatic increase in memory used for the process). I hacked in a bunch of triggers to try and stop these render calls, and the messages stop, but it's obvious there's still some kind of reference to the Map classes, so garbage collection does not get rid of them.



Fortunately, I figured out some kind of solution. It's hacky, very unconventional, and probably a really bad idea
But I found and tested that if I use separate processes to do this, stuff runs great! This is how it would work:

(First a JAR is exported of the "Shandalar" class, then there's another JAR exported of a class that initializes all the necessary variables, and calls GameAction.newGame() with a bunch of parameters - it's basically the entry point for starting a BO3 game, which is done in Gui_NewGame usually... anyway, I call these JARs StartMap.jar and StartBattle.jar respectively).

Then:
1. Gui_NewGame is run (just like normal).
2. A new button on the main menu is clicked to run the "Shandalar" part of the game, the code that's executed basically makes a new process, running "java -jar StartMap.jar", followed by a System.exit(0);
3. The "Shandalar" map opens (if present, loading questData - therefore remembering coordinates where the player started last game and of course all of the other stats such as cards, max life, pet levels, etc. ).
4. Now, running around on the map and attacking a monster, will do something very similar to step 2. A save is called on the questData, a new process is created which runs "java -jar StartBattle.jar arg1 arg2 arg3 ... " (bunch of arguments such as decknames, computer life, credits / cards awarded, etc.) followed by a System.exit(0);
5. The match will start (after having loaded QuestData and all of the other variables).
6. After the match is over, the reward windows will show up (just like in Quest Mode - all of the crap happening in Gui_WinLose basically) and another QuestData save will happen, a new process running "java -jar StartMap.jar", System.exit(0);
7. etc.

Anyway, the reason I'm posting this is because you guys (Snacko / Silly Freak in particular) might have a better idea of doing this.
I realize this approach has a bunch of downsides, apart from being just really weird and strange.... it definitely does add some unnecessary loading times, and the inconvenience of having to export JARs all of the time once code is updated. Although perhaps the latter point could be fixed by just executing processes that call "java StartBattle.class" and "java StartMap.class"? I haven't actually tried that yet...

Anyway, the major upside of this is that it actually works!!! So, I will just go ahead with this for now, soon (in a week or two?) I should have some kind of test map I'll upload on mediafire.

Using separate processes isn't a bad idea. That's excatly how Google Chrome manages itself.

However, it's entirely possible that it might introduce some issues on other systems with unconventional java installs.

Instead of Mediafire, you should start a branch in the SVN so the GUI gods can start playing around with it sooner.

Yeah I will, my local copy of Forge is just kind of a mess right now... I'd have to do a bunch of cleanups first, plus I'd like to make sure the thing is at least semi-stable before I pollute the SVN with it.

By the way, should we keep the format of BO3 in the matches, or end after a single game (like in Shandalar)?

My gut reaction, is that random encounters should be quick, single games, so they can be more frequent.
When facing the "boss" for a specific "mission" (like our current quest decks) it should be a regular full match.
A tournament would be 4 regular matches, but a match loss at any point would end the player's participation in the tournament.

Cool, these are great suggestions!
I'll go with those.

Progress on this has been a bit slow, but I've been working on it steadily nevertheless

This stuff currently works:

- Walking around the map and performance is great!
- Defining quests in a text file (much like the current quest assignments text file), and playing them from the map. I've used a few of the currently existing ones and moved them over to the map, and it works!
- Running around the map will generate a random battle against a random opponent which is defined in another text file. I'm all in favour of using actual random magic creature cards as opponents, but I'd need some kind of Theme deck generator (like Marek suggested earlier). If someone would be so kind to implement one, I'd be happy to move over to that system (of course, we would still have to define a bunch of themes).
- Running around the map will have a (very small) chance of finding a random rare.
- Editing / adding and saving decks.
- Saving the game will remember the last location on the map, all edited decks and added cards.

What doesn't work yet:

- Rewards after beating a quest / random opponent.
- Towns (with shops / tournaments / quests etc.)

Among other things, I'd like to add:

- A "stamina" system... Shandalar had the food counter, this would be very similar. Every move the player makes drains stamina, and movement would be impossible unless rested (by setting up camp or visiting a town). Upgrades could be bought to increase the max amount of stamina.
- XP / level system (levelling up will give more life, stamina and possibly other benefits).
- Some kind of in-game time system, with a day/night cycle - certain quests will only be available at night/during the day, certain opponents only show up at night... etc. Also, finishing repeatable quests could be limited to once every 24 (in-game) hours.
- Some kind of main story line perhaps? Anyone got ideas for this one?

Wow, awesome stuff. What did you do to fix the map performance issues?

DennisBergkamp wrote:Progress on this has been a bit slow, but I've been working on it steadily nevertheless

`
Awesome.

Huggybaby wrote:Wow, awesome stuff. What did you do to fix the map performance issues?

Using separate processes for the map and starting a game seemed to do the trick.