koobas.hobune.stream
Trading Card Game
Currently have a Trading Card game in development and new to Unity. We have over 300 cards and had a question. What is the best way to go about making them? Do you just create 300 game objects ( i.e. planes) or is there another way. And on top of that each card has different stats and abilities. Do you code each one separately and put that script on the game object (card) it self. Any help would be appreciated.
Hello, I hope u managed to do ur game! I'm asking the same Question as u and would like to know how did u approach it in the end? I'm concerned about the Abilities part ,, how to make each card has a different ability ? Thanks in advance
First you will want to create a parent class to inherit your card classes, something that holds each card like a container. It will have properties like: Cart Art Card Damage Card Cost
Then you will want to set up a delegate system to handle events that each card does because you don't want each card to have their own methods.
I am currently looking for the art for a card game I have been wanting to develop for some time. Email me D-b02a5vmwnkkc8q@maildrop.cc If you want to talk about more or are looking for someone to do the back end.
Good luck!
The email didn't send came back as an error. Is the address right? If anyone else would like to email us directly it is projectorb@hotmail.com .
By the way ProjectOrb is not the name of the game just used until we have an official name.
Creating all 300 at once probably won't be desirable (depending on your platform - if mobile definitely not). You should have a class called Card, it would contain all the data you need. I would suggest loading that data from some friendly format like a CSV file or XML. The data file would also contain the location of the image(s) to load for the card (likely in Resources). Then you'd have a Monobehaviour derived class that is added to the card's game object and has a variable for the Card class object. You would then load some on start (or all if you really want) then continue to load one or two per frame while the user is at a menu or when the card is needed. You could also actually create all of them, but hold off on loading the images until needed as the image loading will likely be the heaviest part.
Thank you for your help. It is a lot harder to make a game then i would have imagined. We actually have the core of the game mostly done. We just need to make the cards and make the game in unity. Unfortunately I'm new to unity. As of right now we have 2 people on the $$anonymous$$m but eventually looking for more. We believe we have a game that could be very successful and as we go through develop we might try to get funds going and hire more people.
Yes, making a game is not easy, but it's immensely rewarding. By core of the game I imagine you mean rules. That's an excellent start. I've worked on a lot of projects that didn't have clear rules and they suffered for it. $$anonymous$$y suggestion is to work through as many tutorials as you can and try to learn some general object oriented progra$$anonymous$$g principles.
Fortunately you'll find a bit of help here and in other forums, but many of your questions have likely been answered. So learning how to find the answers is an important skill too (i.e. what to search for).
If you're in need of some paid assistance, look me up. I do tutoring, one-on-one help, and contract work
Yes I did mean the rules. I would say at this point we are about 95% done with the rules. We just have to make the cards and code the game. We would love to hire you but we don't have the funds right now. Later on when that changes we can talk again. As of right now anyone is welcomed to help and start getting paid later on when we have the funds (we can also make contracts to make it official). We are looking to make $$anonymous$$m size of 5-10.
P.S. I tried clicking on your link but said it was broken.
Defining game rules is the biggest favor you've done yourself! Developers can be more easily found than a cool game idea, e.g. I would be willing to assist someone for a decent pay rate :P Totally agree with @Naphier's comment. Unity forums specially have a lot of help to offer.
Yes the rules are 95% finished. We would definitely love to hire more people. But unfortunately as of right now we don't have the funds. Later in development if we start to get some we will look into hiring. But anyone is welcomed to help at beginning stage and move into a paid career.
I'd first create a Metadata script, write its custom inspector, with inspector buttons to save the current state of metadata to file (I normally use Json.Net to serialize it to string). Then I'll write a 'CardProperties' class (with fields like cardID, texture2dPath, healthPoints, damage, ability, etc), make it serializable and add its list to Metadata.
Then if I ever want to instantiate a particular card (with a given id), I'll get its properties from metadata and populate it on screen. This will cover stats parts.
In order to tackle different abilities, I'll make separate concrete (MonoBehaviour) classes of an abstract base class "AbstractAbilities" for all the different abilities. Then, at the point where I populate stats, I'll AddComponent() the ability corresponding to ability in its stats object.
Assuming its a 2d game, I'd go a different route than you are suggesting. I'd avoid using planes when I can easily put a (Canvas and MonoBehaviour) card template that can be populated (both stats and abilities) with 'CardProperties' object. That way, I can ensure that all cards can be handled with the same flow, while ensuring that their stats and abilities are different.
Thank you for the useful information. If it were a 2d game, what would the best way to make the actually pictures of the cards (name, stats, abilities, picture, health). I was thinking photoshop and making a sprite off a lot of them. Then in unity importing and putting it into a sprite game object. There would be 100's of cards everywhere in unity though. Is that how it is suppose to be or is there a better way?
I'd personally go with more of a modular structure. For instance, most of the cards likely have the same design/background. That could be one piece, then the image on the card (like the main image with the pretty effect or character) would be another. There might be some icons on it like the $$anonymous$$TG cards in the upper right, these would be reuseable. Then title and description boxes would be text that you can fill out via script (I'd highly suggest Text $$anonymous$$esh Pro for this ins$$anonymous$$d of Unity's built-in Text$$anonymous$$eshes). So make stuff as modular as possible, then put all the pieces together via scripts. The piece filenames, card stats, description, etc would be best stored in a data file of some sort (CSV, JSON, X$$anonymous$$L, whichever is most comfortable for you to work with). CSV is likely the simplest, but lacks power. JSON is more compact than X$$anonymous$$L. Both can be deserialized directly into a class's variables which can be extremely helpful.
If it is all 2D then a UI canvas may be more to your liking. One nice thing about using UI canvases is that you have the power to user layout elements which will help a lot.
I also agree with farhanblu, you'll likely want some abstract class for abilities and concrete classes for each ability. You'll need to read up on OOP principles and maybe design patterns to get an understanding of this and decide what the best route to take will be (a lot depends on the rules and structure of your game).
You'd basically make one sprite sheet 1k x 1k to hold all your icons for different stats and your common card background/frame. Every card then goes as a raw image, packing them all in sprite will crash your game as soon as the sprite sheet gets loaded. You can't be showing all 300 on screen at the same time, so you have to come up with a good way to unload card images that are off screen and load only the ones you are showing on screen. You'll have to put more resistance on drag, for example, if you are showing them inside a scroll panel. If you are targeting mobile, you'll probably exceed on your build size if you pack all cards in your build. You'll have to make AssetBundles, put them on a server/G-Drive and download them on game launch. Get a paper and a pencil and take good time structuring your project to start development with.
To add to the others, you might also want to consider using Unity3D ins$$anonymous$$d of 2D. Even if the cards are flat, being able to tilt them or show them being dropped down onto the play area would be nice. Hearthstone is a good example, which is made with Unity3D
Yes thank you,,,, definitely using Unity3D.
Consider using this tutorial. https://www.youtube.com/playlist?list=PLivfKP2ufIK78r7nzfpIEH89Nlnb__RRG
Sure the tutorial covers making an Inventory system, but if you just imagine the words "items" and "inventory" as "cards" and "hand" respectively you've re-purposed this into a card came. After finishing the tutorial, you will have 1 card prefab, with 1 card script, and a json database to fill out your card (item) properties.
Of course some of the code in the tutorial should obviously be ignored such as the "slots" that pertain only to inventory systems.
After the tutorial you would only really need to add certain methods to the Card script such as onCast(Card card){do stuff based on card properties} onDeath(){do stuff based on card properties} onWhatverElse(){do stuff based on card properties}
After doing that adding new cards becomes a breeze and requires no additional coding because all you'll really have to do is create an entry into the json database file, supply all the relevant properties, make a new texture and make sure you name the file the same as the slug. Then boom, everything gets inducted to the system and just works.
The trick here is really just planning thoroughly and making sure that you have all the properties you'll need for the card e.g. "numberOfTargets": 2, "effect turn duration": 3,.
Hope this helps.
Edit: this tutorial is GUI based for dragging and dropping, but you could change this to work with GameObjects as the data structure is unaffected.
I suggest you to make an external file to hold the cards informations and load the content of that file into a class, a nested dictionary or a list which you can access at will.
Then you make a function to create a gameobject from the dictionary/class to display the card when you need it. You can use also the container to store the partial path of the image so the function knows where to find it.
That way you can load a card when ever you need it.
That is atleast the way i keep my data this way its easy to extend and mod.
