Is this a good way to instantiate objects? New to C#, want to make sure I'm not retarded. Switching over from python

no
a class for every type of item, so the items can inherit those attributes without having to rewrite shit every time you make a new item.

class potion
class weapon
class offhand

like this it's easy you fucking retard

Use inheritence here. Also worth mentioning, learn to use composition - particularly when designing AI.

for example:
>creature has an AI module
>possible for creature to get confused
>when confused, the creature can only attack, move randomly, or do nothing

class Creature {
String name;
AI ai;
}

class ConfusedAI implements AI {
int duration;
AI ai;
public ConfusedAI(int duration, AI ai) {
...
}

public void Act(Creature super) { //..whatever other info
if(duration-- == 0) {
Print("The " + super.name + " is no longer confused");
super.ai = ai;
ai.Act(super);
return;
}
else {
//do whatever
}
}
}

Yea bro I get that, I understand it. Look, I'm not arguing with you boys. Using inheritance is obviously preferred when things are a little more complex. Here's what I have planned. Pic related.

Attached: whatthefuckamidoing.png (1297x435, 37K)

To expand upon this, I do not plan on adding any other additional functionality to the items. They will all do one thing with one int. It's just a shitty rpg to get my hands wet with C#
I will look into this though, looks juicy.

I encourage you to google the flyweight pattern and use two types of objects: ItemDef and Item. ItemDef contains static properties like the ones in this image, the Item itself contains properties unique to that particular item like the amount in stack/charges left. Each Item has a reference to an ItemDef

People are suggesting inheritance, but that comes with the restriction that if you have a Weapon subclass and a Consumable subclass, what if you want it to be both? Item behaviour is usually easy enough to model in one class

Reading about it right now. Looks like an awesome solution to this. Going to have to read a lot more to get a grasp though. Thanks for the suggestion user.

>OO
>Instantiating an item on the heap as an object

This has always been retarded. Why not make it a struct? Why not do it functional-style and just have a product type that outlines an item, and add it to an inventory list in a player data structure?

When OO is dead and gone I'll finally be happy.

>retard who's never programmed anything larger than fizzbuzz complaining about heap allocation

Attached: 0cbpdjii3pa11.png (645x729, 105K)

you are retarded

>Using inheritance is obviously preferred when things are a little more complex
enjoy your bad programming habits

>muh habits
If doing something easy accomplishes the same end task with no repercussions compared to doing it a more difficult way, what is the problem?

>inheritance
>difficult
have fun with you duplicated code then

>When OO is dead and gone I'll finally be happy
user, I'm a smug ML weenie but most functional languages box the shit out of everything when writing idiomatic code.

>he doesn't know about composition

composition has overhead in most OOP languages, it's better to use inheritance when you can

enjoy your stack overflows you unbelievable shit rag.

inheritance is garbage and was never a good idea.

it's a zero cost abstraction, if you can't make use of it in appropriate circumstances you're a brainlet

it's forcing something that naturally has a graph structure (which can also be zero cost) into an hierarchy. dumb dumb dumb. I bet even its inventor rags on it now.

it doesn't force anything. Some things naturally fit into the inheritance structure, so you can use inheritance. If it doesn't fit you can just not use it

If you are not going to use inheritance, I would throw all your items in a data file(json, yaml, what ever). And just read the file. Will make iterating on items quicker.

those cases are a minority and the reason we now have the "Liskov substitution principle"

There's lots of good use cases for inheritance, even in situations where it doesn't fit conceptually 100% because it's one of the most efficient comprimizes between speed/efficiency when it comes to polymorphism

i highly doubt you understand the .net runtime enough to be able to reason with how it implements inheritance. How do you think it affects the design? How do you think it will affect the performance when it comes to garbage collector generations. Is it easy to adapt to a multithreaded architecture?

A single parent class that represents all items of any kind what-so-ever that provides the common interface needed for creation and deletion of resources tied to an item.
Every item is instantiated through an external document provided by the class that defines features like type, associated visuals (if applicable), name, visibility status, and so on.
You can then add every instantiation of any item created to a common list or collection that you can iterate through when necessary.

inheritance has nothing to do with garbage collection or multithreading. It's a science, not an art, there's one most efficient way to implement single inheritance, things get more complicated when you do multi-inheritance but all it affects is how long it takes to call a virtual method. The weaknesses in inheritance come from it's strengths - it's code abstraction technique with fast runtime but requires to to bind things together in an exclusive "is a" relationship. So you make a decision about when to use it, like with every abstraction

i am 100% sure i saw a thread you made yesterday but i can't find it in the archive or anything
am i going insane

you don't know what you are talking about at all. have a look at the book "writing high performance .net code" and understand the optimizations present in a runtime like .net or java. it's not C++. this is all searx could find me fillumina.wordpress.com/2012/06/09/performance-comparison-between-inheritance-and-composition-in-java/. But it clearly shows in a runtime like this that inheritance is not necessarily faster. of course do you own testing so you can be sure to be right rather than spouting off some poorly reasoned garbage..

Use inheritance you nigger
This is the exact use case for it

>I can use an "if" statement to identify the "item.type" and then do whatever
Yeah, but you made item.type a string. Do you really want to run a fuckton of string comparisons? This is the kind of mistake people made fun of Yandere Dev for. Don't be Yandere Dev. Virtual methods aren't a zero cost abstraction, but they are a hell of a lot cheaper than what you're suggesting.

as far as I can tell that's a bad test, because the downside of composition is you have to do two memory allocations to create the object and the component, but it's not timing the creation, only how long it takes to run (and the component wins because it's not a virtual method). Regardless of that, there is still one perfect way to implement single inheritance, and it's probably the most efficient way to do runtime polymorphism, so inheritance has value even if it's not the right solution to every problem

If this were C++, I would say it would be natural to be smart about where you allocate memory. In C#, while it is possible to use structs to stack allocate objects, there are some caveats...

docs.microsoft.com/en-us/dotnet/standard/design-guidelines/choosing-between-class-and-struct

In Data Oriented Design, it would make sense that small objects get put on the stack, and large objects (including containers of many small objects) are put on the heap. In certain object oriented languages, this style of design is sadly impossible.

On Windows you get at least 1 MiB of stack memory per process (8 on Linux), which is plenty if you know what the fuck you're doing.

>it looks so filthy and disgusting
welcome to OOP

>you generally want to define your items with an external rather than through code
You mean with a db or xml-file or something like that?

Your constructor shouldn't have so many arguments. The item type "hp" or "potion" should be represented as a subclass of Item, not signified by a string.

itt:
babbys first programmer wants to make """"a game"""" using only his IQ of 78 and fizzbuzz-level python skills

>xml
That's gross. It's 2018, use json.

This user is right but gets a lot of shit from retards who are stuck in the trap of dated '00s mistakes.

Functional, structured, data driven programming is the way you want to handle hundreds of "items" in a game.
All your items should just be JSON.

>his main method has a capital C
:nauseated_face:

Will probably end up doing this.

I don't really want to make this game at all. I just thought it would be a decent way to get started with C#. What the fuck did you do to learn faggot, make a cock sucking simulation?

Not him, but perhaps making this game might make you think about how to become a better programmer in the first place.

Consider your item.type value. You store it as a string, which would suggest that it is something whose primary purpose is to be displayed, or compared against user input. However you also note that you want to use this particular value as a determiner of which item effect to use. This might make sense from an ease of programming point of view, but from the computer's point of view, it's a bit slow, especially if you're basically switching on a string.

Now, you might make this faster if you had, say, a hash table with string keys and function values, but at this point, you're already storing a function pointer for every item. It might make better sense instead to store a function pointer in every object to a "use" function. If you were using pure C, this is exactly what you would do. If you are using literally any object oriented language, you would say, "this is what inheritance is for in the first place."

It is important to think not only about how you, as a programmer, are organizing your code to make your own job easier, but also how the data is being stored and processed by the machine to make its job easier.

I gotcha. Thanks for putting it this way. I'm going to do this all a different way.

Class inheritance is the C# way. The entire language and ecosystem are designed around classes and inheritance. If you're going to use C#, you've already decided that you're programming in an object oriented fashion.

I'd be tempted to use enums instead of strings. Also automatic properties might be better, and then I think you can ditch the constructor, rely on the default constructor, and object initialisation syntax.

var ilesserHealPot = new Item{ Type="potion, SubType="hp", name="Op is a nigger monkey", Value=3, Cost=15};

also use fucking properties
If I were your coworker or lead eningeer I would have..
youtube.com/watch?v=e5_LyAn2ciI

Good thing this was my first day using C# then