Author Topic: PYTHON: pros and cons for rougelike development  (Read 614 times)

Krice

  • Troll
  • Chancellor
  • *****
  • Posts: 2231
    • View Profile
    • Email
Re: PYTHON: pros and cons for rougelike development
« Reply #15 on: February 19, 2019, 10:12:01 AM »
I remember trying C# and I was annoyed by the amount of stuff generated for "forms" app. I guess it's also possible to create a console application, but that's too simple. I wish it had something like an empty canvas app you could then add your own gui routines etc. Console application models of VS in any language are ridiculous, because in Windows the console is slower than first 8-bit computers were. Otherwise you could program ASCII roguelikes in C# for sure. I don't know what is the deal with Windows console anyway. How it was possible to make it that slow.

Vosvek

  • Acolyte
  • *
  • Posts: 24
    • View Profile
Re: PYTHON: pros and cons for rougelike development
« Reply #16 on: April 01, 2019, 07:27:21 AM »
I remember trying C# and I was annoyed by the amount of stuff generated for "forms" app. I guess it's also possible to create a console application, but that's too simple. I wish it had something like an empty canvas app you could then add your own gui routines etc. Console application models of VS in any language are ridiculous, because in Windows the console is slower than first 8-bit computers were. Otherwise you could program ASCII roguelikes in C# for sure. I don't know what is the deal with Windows console anyway. How it was possible to make it that slow.

I mean, WinForms apps aren't any more complicated than trying to open a Window in C/C++.  There are also C# bindings to SFML and SDL if you want an alternative.

You can speed up the Windows console by using a buffer, resetting the cursor position on render, and printing 'over' the old values (if using a double buffer, only when there's a difference). It's still slow, but it's at least viable.

I do quite like C#. In many ways, it's the Java that Java should have been. I especially like that the devs aren't afraid of adding breaking changes, something the C++ badly needed before it turned into a Goblin.

The big problem with higher level languages is that they actively encourage (or force) you to create a lot of garbage. Thankfully, most people have at least 2-4GB RAM... but still, it's disheartening to see a simple game use up 100-300MB of memory just because the language doesn't have classes/structs that land on the stack. Throwing around giant classes doesn't help either... but Roguelikes a usually simple anyway, so who cares about the cache.

-

This might sound strange, but why not commit to learning C? I've recently picked it up and have been slowly and carefully following K. N. King's C Programming: A Modern Approach (2nd ed.). The language isn't as scary as I'd first thought, even though I still have a lot to learn some two months later. The big benefit is that by learning C, you'll understand both C++ and assembly more intimately, which brings you as low down as you'll honestly ever need to be (unless you plan on becoming an electrical engineer sometime in the near future). On top of that, the more familiar you become with the language, the easier it becomes to hack things together like you can with Python... barring anything involving GUIs of course, and linking is a pain... though, I'm yet to work with GTK or CMake/Make.

Not to mention, prior to learning some C, I never really felt that attached to the machine. Things sort of just happened, and I spent more time engineering abstract problems than engineering data or actually implementing features. Could just be me though. :D
« Last Edit: April 01, 2019, 07:30:40 AM by Vosvek »
Signed. Dustman of the Mortuary.

Krice

  • Troll
  • Chancellor
  • *****
  • Posts: 2231
    • View Profile
    • Email
Re: PYTHON: pros and cons for rougelike development
« Reply #17 on: April 02, 2019, 06:41:55 AM »
This might sound strange, but why not commit to learning C?

If this was for me then I have programmed in C since 1995 and switched to C++ in 2005. I'm a grandmaster level C++ programmer now.

Vosvek

  • Acolyte
  • *
  • Posts: 24
    • View Profile
Re: PYTHON: pros and cons for rougelike development
« Reply #18 on: April 02, 2019, 07:23:31 AM »
This might sound strange, but why not commit to learning C?

If this was for me then I have programmed in C since 1995 and switched to C++ in 2005. I'm a grandmaster level C++ programmer now.

That section was more general, for anyone who's still trying to choose a language. I probably should have used a divider/horizontal rule. :D

I'm curious to know though, is there a reason you personally use C++ over C? It seems that even developers who praise C use C++ for one reason or another. :)
Signed. Dustman of the Mortuary.

Krice

  • Troll
  • Chancellor
  • *****
  • Posts: 2231
    • View Profile
    • Email
Re: PYTHON: pros and cons for rougelike development
« Reply #19 on: April 02, 2019, 08:53:24 AM »
I'm curious to know though, is there a reason you personally use C++ over C?

I like object-oriented programming style.

When you think about it, a C program is just a class. The program is the class, functions are member functions of it. But unlike in C++, you can only create one class. When you can create more than one class it's easier to organize the code.
« Last Edit: April 02, 2019, 11:36:58 AM by Krice »

Vosvek

  • Acolyte
  • *
  • Posts: 24
    • View Profile
Re: PYTHON: pros and cons for rougelike development
« Reply #20 on: April 03, 2019, 01:16:51 AM »
I like object-oriented programming style.

When you think about it, a C program is just a class. The program is the class, functions are member functions of it. But unlike in C++, you can only create one class. When you can create more than one class it's easier to organize the code.

That's fair. I like OOP as well, but I tend to spend more time trying to figure out class responsibilities and hitting walls with dependencies than being productive by programming anything of value (although composition over inheritance and the command pattern are working wonders). Do you ever find you have the same problem? :)

C programs as a Class is an interesting thought. And it makes sense really, classes are, after all, just a combination of struct schema, struct data, and functions under a namespace. Come to think of it, that thought might be the deeper subconscious reason for why I wanted to learn C in the first place. Having worked primarily with OOP, I feel as if I lack the understanding of what a class, and by extensions, a program, should be and function like.
Signed. Dustman of the Mortuary.

Krice

  • Troll
  • Chancellor
  • *****
  • Posts: 2231
    • View Profile
    • Email
Re: PYTHON: pros and cons for rougelike development
« Reply #21 on: April 03, 2019, 06:53:37 AM »
figure out class responsibilities and hitting walls with dependencies than being productive by programming anything of value (although composition over inheritance and the command pattern are working wonders). Do you ever find you have the same problem?

The real problem I had for a long time was programming too much like procedural style in C++. When you are programming in OOP inheritance is actually the first and most important way to implement things, not composition. Class should always have only one task,  although sometimes the task is complex. Writing good OO code is quite difficult, that's why programmers result in composition etc.

It's actually not that simple to say that C program is one class, because functional paradigm can work in procedural code as well. But often C programs have lots of global access to "member data" so it works a lot like class.

Vosvek

  • Acolyte
  • *
  • Posts: 24
    • View Profile
Re: PYTHON: pros and cons for rougelike development
« Reply #22 on: April 04, 2019, 02:51:30 AM »
The real problem I had for a long time was programming too much like procedural style in C++. When you are programming in OOP inheritance is actually the first and most important way to implement things, not composition. Class should always have only one task,  although sometimes the task is complex. Writing good OO code is quite difficult, that's why programmers result in composition etc.

It's actually not that simple to say that C program is one class, because functional paradigm can work in procedural code as well. But often C programs have lots of global access to "member data" so it works a lot like class.

Interesting. I have a big reply for you! I'm curious to know how you handle your OO. OO Is definitely difficult, and it doesn't help that gurus use a lot of pseudocode for both example and comparison. It probably doesn't help that the first language I learned was Java, meaning I missed out on a lot of the procedural stuff early on (I'm just now catching up), so my view on how to handle things is distorted by a modern view of OO. :D

...but I care about learning how to produce good code! So,

On inheritance:
How do you handle scenarios where some creatures have different capabilities to other creatures (i.e. a bird can fly, but a cat cannot)?

How do you handle scenarios where creature's capabilities change during runtime (for example, a cat gains the ability to fly)?

Do you:
  • Use inheritance (i.e. have a LandCreature and FlyingCreature class; create a new FlyingCreature instance with our cat's data, which was previously a LandCreature)
  • Use component-based design (pluggable "FlyComponent" class that extends an IComponent interface; creatures have a Vector/List of IComponents)
  • Use composition (creatures having a public IFly interface we can use to swap functionality in and out; that cat would have a CantFly object that implements IFly. To make it fly, we can replace IFly with some kind of Fly object implementation. Like function pointers in C, but OO with interfaces. Though function pointers would work just fine.)
  • Use data-driven design (there is no cat or bird, or LandCreature or FlyingCreature; they're all just a creature but with different data. Every creature can technically fly, but the data has to be in the correct state to allow that to happen; data is more or less just PODS)
  • Handle it differently?

On single responsibility/tasks:
Say your game has shops (NPCs that sell items), containers (chests that store items), and regular characters that have inventories. How would you go about organising those classes (or class/class hierarchies)? Would you have one Inventory class, acting a bit like a generic List/Vector, or would you have different implementations for each of these scenarios since they technically have different responsibilities (i.e. ShopInventory, ContainerInventory, and CharacterInventory have no relation, despite their similar names)?

On that same note, do you still use something like the command pattern that connects different classes via a common function? For example, when a player purchases an item from a store, that item needs to move from the shop's inventory to the player's inventory (assuming their different implementations)...

Alternatively, if a character equips an item, that item needs to move from the player's inventory to their equipment (is the inventory or equipment class responsible for handling this interaction? Does this interaction go into a separate class? Would the inventory and equipment be implemented inside the character class, so there is no generic inventory or equipment?).
« Last Edit: April 04, 2019, 03:03:43 AM by Vosvek »
Signed. Dustman of the Mortuary.

Krice

  • Troll
  • Chancellor
  • *****
  • Posts: 2231
    • View Profile
    • Email
Re: PYTHON: pros and cons for rougelike development
« Reply #23 on: April 04, 2019, 06:29:54 AM »
I think 'composition' is a funny term, because it's just a member variable. Inheritance is often a better solution, because with it you can build from simple to complex and don't need to repeat the code as with components (if they are used in similar way in multiple classes). In that inventory example I would use a generic list class for items (with basic routines that all containers would use), then inherit different type of containers if needed. For creatures I'm using data-driven style with a split to dumb, intelligent and player creature types. I think that's the way to go in that situation, because each new type of class has all features those types of creatures have. In theory you could make inheritance trees for creature types like birds, lizards, mammals, etc. even to the actual creature type. But if you have like 200 creature types it would generate a lot of classes to maintain.