i guess the question is, are spells that buff a unit, spells that have a one time effect that can only be played during your turn, spells that can be played at any time with a one time effect, spells that trigger when some other thing happens, and spells that are always in effect, can all be considered the same thing, or should they be considered separately?
when you say creature classes, what do you mean exactly? right now in my head all the units just have attack and defense, and then whatever abilities are applied to them at either at creation or by some external effect
I'm thinking in terms of the "core" game mechanics... things that are a fixed set of rules, and the "vanilla" game, which is basically a mod just like modders could make
so as we design the game we need to decide what things are "core" and what things are part of "vanilla"
I'm thinking core would just define conceptual things, like there are unit cards, there are effect cards, there are players with hp, there are decks, hands, a playfield, a graveyard... but not actually define any units or effects, that's all up to the game mod
standard distribution would be core plus vanilla mod, this ensures the modder's API is flexible enough to handle at least the stuff we wanted to do. Modders can petition us for more features.
Unit
class_name advantage_penalty
Pawn Cheap, Weak
Knight Attack, Higher cost
Bishop Speed, Higher cost
Rook Defense, Higher cost
Queen Buff, Very high cost
King High attack & def, Slow, Very High Cost
@DaggNabbit ^^ this is what I meant, then we can work in numbers after we decide if this works
Then multiple cards of each type can be made with variations
Like maybe Pawn | Tier 1-3 with associated atk/def and cost
so the core stuff there would be units and casting costs, and the mod stuff would be the actual names of the units and the amounts of the casting costs
all of the talk so far seems to assume a few things, such as needing mana to fulfill casting costs (so we need a mana mechanic), and also that you play cards one at a time out of your hand (so the player will definitely have a hand of cards), and i suppose that you draw cards from the deck one at a time (so we need a deck); however, we do not necessarily need to conform to these mechanics?
for example, what about a game like this but where you always start the game with two cards already on the table, randomly chosen? or you always play two cards and draw two cards every turn regardless of costs? I'm not saying these are good ideas, just that they are possibilities that we may be ruling out too soon, or other ideas like them that are bigger changes to the typical mtg/hearthstone formula. if we want to go that route that is fine but i feel like we haven't set it in stone yet
i guess what i am getting at is that a core mechanic could completely change the gameplay of the game, for example, it is more than just a small nuance that in MTG you can block with whatever creature you want, and in Hearthstone you cannot choose to block at all, units with taunt must simply be killed before the other player can be attacked.
or another example, in one game you can run out of cards, in another game you can reshuffle your discards into your deck. its a core mechanic but it totally changes the gameplay
Code-wise, I think even such mechanics should be open for flexibility (Entity Component System!!) But it is good to have a specific core feature though.
@bazola blocking is something I'd like to see as a core mechanic, and we should decide how it works
does the attacker just attack in general and the defender decides who to block with, or does the attacker choose what unit to attack?
I sort of like the first option because you could always have a special unit like "sharpshooter" or whatever that has the ability to target whatever he wants with his attack
doing it the other way around could work though, you always choose who to attack but defender can have special "secret service" unit that jumps in front to block
@bazola i can think of ways you could kind of do both, but they may be overly complicated... like attacker always can attack who he wants, defender can choose to block but a blocking unit can't attack on next turn. Then the special "sharpshooter" unit couldn't be blocked like this, and the special "bodyguard" unit would be exempt from losing his attack on the next turn. Actually that doesn't sound too horribly complex?
Does the attacker choose targets for each of his attacking units? Does the attacker just attack in general and the defender chooses units to block with? Or something else?
Don't bash the underscores, @skiwi I have to use those in pg otherwise it will look like this: unitclass (it converts column & table to lcase when you select it)
one crazy idea for attack and block would be something like, there are two rows on the battlefield for each side, if you put it in the attack row it gets plus one attack / doesn't pay a penalty by attacking to not be able to block, then in the back row it gets plus one defense / doesn't pay a penalty by defending to not be able to attack
@Phrancis no java but when I read it I can typically understand the meat of it. Mostly objective-c at the moment but I'm the type who has no problems with the idea of learning new languages
If we go for the LIBGDX Java Library, that's the new thing I will learn as I haven't used that much. (A friend of mine has used it a little bit though)
I've designed and prototyped a few games with cardboard/paper and I'm working on coding a couple. my passion used to be writing but there is no money it in so i've switched it over to programming :) so those are my skills
@bazola yeah I picked up on that, I think you're good at being skeptical about mechanics and filtering out dumb ideas
@Phrancis I think so
@SimonAndréForsberg I sort of see you heading up the "core" team so you should pick something you like as long as it can deploy to all our target platforms pretty easily
@DaggNabbit The only bad thing about LIBGDX is that the iOS version costs a bit to buy a Xamarin license. But well... it's Apple so what could you expect?
i wonder how much work it would actually be to port it over. for all of the different platforms, we will have to code a different front end right? to interact with the actual scenes and views and UI?
@bazola From what I understand of LIBGDX, there's only one code base for all of the front-ends. So there's very little work that needs to be done for the different platforms
I really like the .effect(e.toMinion(e.combined(e.silencer(), e.damage(1)))) : "To a minion, silence it and then deal 1 damage", it should be possible to use such building blocks inside Lua as well though I think.
yeah that is very cool, trying to absorb all that now
it should absolutely be possible
one thing to decide is how much should actually be scripted, like the bindings could be pretty minimal and the fancy chaining stuff could all be scripted
@SimonAndréForsberg if everyone else wanted to do something like Scala instead I'd be willing to learn it, but I think something like Lua would really be more modder-friendly... it was designed for non-programmers and it doesn't have a lot of things that only make sense to programmers, like ternaries or pre/post increment and so on
@DaggNabbit Well, I'd have nothing against learning some Scala too. I didn't think of Scala as a "scripting language" though. For me it's more like a further developed version of Java. (With all the advantages and fewer of the disadvantages, as Mr. McLean normally say)
When you're talking about the absolute core foundation of the framework, you don't want a language as abstract and managed as Java. I certainly wouldn't want to build an iOS app over the top of a Java library for example.
The framework for the casting cost algorithm, listing out the available mechanics, etc., should be a library written in something like C or C++, something where you can really, REALLY control exactly what the algorithm is doing so it can be efficient as possible.
Now you compile the library and use Java/ObjC/C#/whatever and build the game on top of that library with the algorithms in it
@MattGiltaji For the mobile apps, it has to be installed :P But most of it would/could be server managed I think.... it's a good question, actually. At least the multiplayer stuff has to be server managed to prevent cheating
@nhgrif So the reason you're not prefer Java is because.... it's slower? I think the most important aspect is how the algorithm itself is written, not in what language the algorithm is written in.
@SimonAndréForsberg i don't know enough to know, but i would think that even 1000 players playing on the server could be enough bandwidth to incur a more than insignificant cost?
Do you know that if in your app name or app description, you misspell (including capitalization) iOS, iPhone, iPod, iPad, etc., your app will be rejected?
@nhgrif Why am I not surprised? (And actually, I think they're right in being strict about that. It's like you would write "This app was written in JAVA" on an Android app)
@nhgrif That C library for the algorithm(s), would that have to be included inside the mobile apps as well? (Or would running it on a server be enough?)
@MattGiltaji Yup. I've done Socket programming in PHP (ugh) and in Java. I'm quite glad TCG's are primarily turn-based and not real-time based btw :) I even did a little playing around with Websockets in GWT and JavaScript not so long ago.
If we do use Lua, I'm not sure how Lua integrates with Java. The Lua bindings could very well be written in C and then bridged to the Java server though JNI or whatever it's called
That would be cool if you have a row of medieval archers, that turn into elves, that turn into turrets, haha. I think it would get frustrating as well. Especially if all of a sudden it was a game changer when the cards shifted.
I think if a random theme is selected per match that would be cool. It would be like playing a different deck that you are familiar with, it would keep it fresh
You could have cards that have preferred themes that act well in a certain environment, but then that would creat mismatches too if the wrong theme was selected pregame. That would be a good way to incorporate switching themes mid game if you had a contingency plan for each theme. But it could get messy if you had a deck for one theme and it doesn't cycle back to that theme after turn 2 or 3
I feel like the ascetics could be the only thing that change, liek there's an open time portal in the middle of the game board that keeps pulling cards into different eras/dimensions.
one idea would be to have the different boards associated with the different aesthetics to have an actual impact on the gameplay somehow, like some boards have a constant effect on everyone
places quite a large advantage on a random factor though? one player could be basically screwed because the theme doesn't match his deck and he had no way of knowing what it would be before it started?
After quite a bit of discusson on this in the chat, I believe this question needs to be here. We have decided on a TCG, so what is going through our minds is MTG, Hearthstone, and the like. So what things should we set in stone now, and start building the game around? These would be things such as: Does the player have hitpoints? If so, how are they represented? Is th…
Yeah, but there would be no reason to build a deck based on one theme in that scenario. because if it never shows up you wouldn't win. Unless you picked a home theme for a deck you build and it's guaranteed to come up at some point in the match
I'm about to head home though. I'll definitely be watching the Q&A over the weekend. @SimonAndréForsberg hope you have a good trip, thanks for including me on this, very fun!
