ID:1088276
 
Hello everybody,

Starting a new game project, I would like to ask you guys about the way I should design this game, such that it can be above the level of just 'playable' and that it is easy to code (I am mainly java programmer and new to BYOND engine, studying Software Engineering).

The game is about a huge inheritance tree, everything (objects) is an ID card, but then, this ID card is used to compare, command, affect and so on depending on this object's properties. Think about it as a chemistry chart for elements.. (duh .. lol).

I would really appreciate it too if a programmer is happy to chat with me and inspiring me with ideas, especially if he/she has knowledge in other languages and with programming concepts. I am also considering people who are happy to join a new game project.

Thanks in advance!
Killua :)
I don't understand the ID card thing :(

So the player is an ID card?
I am trying to make all objects available in two states, one is their usual shape. say torch for example, it lights the place, another one is its ID card a card which is the torch's description, and may be used in trading with other players for example, having discovered items list and so on. I am lacking the experience for designing BYOND games (never done one before, and wonder if it worth the time). Thanks for trying to help!
To make it clear, the same object can be in two states: normal state, and ID card state. It cannot be the two of them at the same time (it is converted by in-game command).
Sounds like the cards on Hunter x Hunter's Greed Island.
In response to Jemai1
Jemai1 wrote:
Sounds like the cards on Hunter x Hunter's Greed Island.

Spot!


I have the written plan for this game ready, all seems like obvious code - even this Card state does not seem much like a challenge (from programming perspective), but with BYOND, I prefer to adopt the ideas of expert programmers in that field (not to design a failure engine!).
You should have posted this in developer help; You can go about this in a few ways, the easiest way would probably be html. client.Topic() is perfect for stuff like this. The way you can handle the 'only exists in one state' bit is to move the object (on the map) to a location outside of the map, or to move it into the inventory of whomever is using the 'ID card'. Generally, it's not a good idea to 'adopt' ideas of any other programmer. You can draw inspiration from anyone's ideas, it's never good to simply take the idea for your own. 'I like how they do it, I want mine to be like that.' should never be uttered, it should be 'That's a good way of doing it, I wounder how I would/could do it.'. Anyway, the other way would be to make a 'ID Card' in your interface file and fill it out upon command, most likely using winclone() so to be able to hold more than one window open.
Thanks for replying NNAAAAHH. I appreciate your advice, I agree that one should not take others' idea, that is not my aim. I have taken a look at client.Topic() I found it interesting but not quite the core principle needed for this design.

winclone() on the other hand will be good mechanism for reading the cards. I appreciate your suggestion.

Moreover, I guess this is not actually a code problem more than designing issue, in which, I am hoping that by creating a good engine it would help expanding the game to manipulate more than 300 cards/objects. I have been thinking of a way and would like to hear your opinion I am not quite sure this works for BYOND (driven by java..!) the idea is to have two separate superclasses, one is the predefined obj parent, the other is card (which all other cards must be a child of). Then every obj will have a reference to a card, so that in-game I would not bother deleting the obj and creating the referenced card, and vice verse. This would help defining different verbs and procedures, however I am not quite sure what is the parent for 'card' should it be atom? can I even define a superclass there? This is more like a basic programming step than an idea I own.. I appreciate your support!
In response to Killua - yugioh
Developer Help isn't just to help programmers, it's for development in general. This applies mostly onto programming, as it presents the most issues and challenges[EDIT](not to down-play any other forms of development, it's just that programming is ALWAYS expanding, changing, and the skill required is limitless as is the work into it - more so than other fields, though it is probably the easiest to 'start learning')[END EDIT]. This post would easily fit into developer help.

As for wanting a 'parent' object, you could go about making a variable directly connected to the card and card information.

obj/hasID/var/IDCard/Info=new//assign the objext type you want the variable that links back to the ID Card.
IDCard
//parent_type=/obj/hasID/ //if you want to actually assign a parent type, which I doubt you meant.
var/obj/hasID/Obj
obj/hasID/Book
New()
..()
Info.Obj=src //upon creating a object that would have a 'ID Card', assign the ID card the object, and the object is already assigned the ID card, so no worries.

I would like to say, however, that the client.Topic() route would probably be the better one to take for this. A little html and some hrefs will REALLY make things easier.
obj/hasID/Book/verb/Look()
usr<<"This book appears to have a <a href=?src=\ref[src];action=ReadNote>note</a> attached."//Show some next with a nice little href to the 'card' you want to display.
client/Topic(href, href_list[])
switch(href_list["action"])//check for the action param to see what you're doing with the href
if("ReadNote")//If it's to read a note:
src<<browse("<somehtml>[src.note]</somehtml>","window=[src.name];size=[x]x[y]")//display the note in another window, including some html to make it look nice. You can include more hrefs inside this, so you can make a browse-able window, the second part after the comma is the window name, so it doesn't attempt to display in any default browser you may have and to give a unique window name so you can have more than one open at a time, and size=[x]x[y] is where you'll have to input the size of the window you wish to pop up. 100x100 is pretty small.
In response to NNAAAAHH
NNAAAAHH wrote:
As for wanting a 'parent' object, you could go about making a variable directly connected to the card and card information.

> obj/hasID/var/IDCard/Info=new//assign the objext type you want the variable that links back to the ID Card.
> IDCard
> //parent_type=/obj/hasID/ //if you want to actually assign a parent type, which I doubt you meant.
> var/obj/hasID/Obj
> obj/hasID/Book
> New()
> ..()
> Info.Obj=src //upon creating a object that would have a 'ID Card', assign the ID card the object, and the object is already assigned the ID card, so no worries.

I would like to say, however, that the client.Topic() route would probably be the better one to take for this. A little html and some hrefs will REALLY make things easier.
> obj/hasID/Book/verb/Look()
> usr<<"This book appears to have a <a href=?src=\ref[src];action=ReadNote>note</a> attached."//Show some next with a nice little href to the 'card' you want to display.
> client/Topic(href, href_list[])
> switch(href_list["action"])//check for the action param to see what you're doing with the href
> if("ReadNote")//If it's to read a note:
> src<<browse("<somehtml>[src.note]</somehtml>","window=[src.name];size=[x]x[y]")//display the note in another window, including some html to make it look nice. You can include more hrefs inside this, so you can make a browse-able window, the second part after the comma is the window name, so it doesn't attempt to display in any default browser you may have and to give a unique window name so you can have more than one open at a time, and size=[x]x[y] is where you'll have to input the size of the window you wish to pop up. 100x100 is pretty small.


Thanks a lot NNAAAAHH, the first part is really the structure I am looking for! I see your point in the second part (the easier one with href links) but the issue is that the cards will have different procedures and else, its more like another object itself rather than just info. I am sorry for bugging you with questions, but I wish to know whether its possible to give each card different procedures, I see the IDCard in your code, if I am not mistaken, like a blueprint (abstract).. so I have been thinking, if these different procedures should be defined inside the object, and then the 'card state of the object' can refer to the connected variable's procedures, I suppose that is the way to program it right? But what if some cards had unique verbs? I can define those in this blueprint can I?

obj/hasID/var/IDCard/CardState=new

IDCard
var/obj/hasID/Obj
verb/Use()
src.Obj.Use()
//now here, suppose each card have unique verbs taken from its object, would that work? :
src.verbs += typesof(/mob/Effect/ReadMinds/verb)

obj/hasID/Book
New()
..()
CardState.Obj=src
proc/Use()
//some unique effect for each object
verb/ReadBook

obj/Effect/ReadMinds
verb/ReadMinds()
// anything here


I bet there is a better way than this one, otherwise I assume I should define each card differently and then connect it to the actual object. What do you propose?
In response to Killua - yugioh
You can assign a list of verbs to a ID card and then assign the verb(s) to a mob upon whatever proc you so choose.
obj/hasID/Book/var/list/specialVerbs(/*list of verbs*/)//ie: list(new/mob/Special/verb/Random,new/mob/Special/verb/Sleep,ect)
IDCard/verb/GetSkill()
usr.verbs+=Obj.specialVerbs//Add the list of verbs you defined above into the list of verbs the usr has.

You really should read more into the guides and tutorials.

Not sure if you meant to ask if you could make a different use for each object, but I'll give an example on how you would go about doing that.

obj/hasID
proc/Use()
[default action]
Book
Use()
[action specific to the book]
//..()//call the default defined function of Use(), in this case it would be obj.hasID.Use(), you can exclude ..() from procs like these to ONLY have a special effect and not the default one.
Thanks a lot for your help! That was really helpful, thank you. I did not know that it was possible to contain verbs in lists, cool! That should solve the issue.

lists can contain pretty much anything


I love lists
For dynamic verbs, I prefer placing objs with verbs having set src in usr to the mob's contents against the verbs+=verb approach. Handling actions via click is good too.
In response to Jemai1
I was thinking more of spell tomes in the elder scrolls games.
I was thinking of using the mob's contents list as a binder and the cards are objs.

http://hunterxhunter.wikia.com/wiki/Greed_Island

Card
verb
Gain()

Spell_Card
verb
On(mob/target as mob)


The binder could also be something else. Then, holding the card will put it into your contents list to give you the verbs.

Or even better, your mob can just have Gain() and On() verbs and do the appropriate action based on the card you are holding.
In response to Jemai1
Jemai1 wrote:
I was thinking of using the mob's contents list as a binder and the cards are objs.

http://hunterxhunter.wikia.com/wiki/Greed_Island

> Card
> verb
> Gain()
>
> Spell_Card
> verb
> On(mob/target as mob)
>

The binder could also be something else. Then, holding the card will put it into your contents list to give you the verbs.

Or even better, your mob can just have Gain() and On() verbs and do the appropriate action based on the card you are holding.

Yes exactly, or the binder can be a second list inventory. Gain() and On() can go with the mob indeed, to be honest I never need extra verbs but I was just considering the case. The way I am planning to design this now is to define the Card vars and then connect it (NNAAAAHH's suggestion) and each object would provide its own card's vars. This should make it easy to simply del() the obj and create it's /obj/Card. Converting back (gain) would just create the old obj [unless its a spell].