Temple of The Roguelike Forums
Development => Programming => Topic started by: Skeletor on January 28, 2019, 03:39:35 AM
-
I am aware some people here love Python, others such as Krice don't like it.
I just would like to form an idea about it and welcome any input. In particular, what makes you like it in the context of roguelike development.
-
I think languages aren't "bad" in that sense if you can work with them, but I think languages often fail in game/regular program development, because they don't have a dedicated IDE. I think most game programmers are simple, they don't want to spend time in complex building schemes, at least I don't want. I want the project to compile and run when I hit one key. If python can't do that, it's not for me.
-
I feel like Python encourages sloppy programming. And to be honest, I mistype too often to be cool with a language where you don't explicitly declare your variables.
-
I didn't know any programming when I started with Python. But I found it easy to get into, and so far it's been able to do what I want, so I haven't regretted my choice. The official documentation is clear and thorough, and there are tools available for many specialized tasks, often in the form of modules. For example pygame, libtcodpy or ncurses can provide you with a framework for quickly getting an @ moving on screen. I don't know how the documentation on libtcodpy is, but there's at least one tutorial (http://rogueliketutorials.com/libtcod/1) that's supposed to be good.
In the context of (underground) Roguelike development, Python is adequate for many kind of projects. It can be quick'n'dirty enough that you can cough up a prototype for an idea in a day or two. But it can also be used for much larger projects. On computers, Python is quite portable, and it's easy to make binaries for at least the three major OSes. However, Python is not the thing if you want to develop for Android or iOS.
One objective weakness of the language is in terms of pure computational speed, but that probably won't matter much for many Roguelikes. But bottlenecks might come instead with stuff like AI if you have a lot of actors walking around and observing each other.
To mention it, Python is the closest thing to a "real" programming language I know at all. And while I don't know if Python encourages sloppy programming, I know I "get along" with my own, so you may have to take my advice with a grain of salt ;) I've thought about trying a game engine, but maybe for a different kind of project than my current clunky masterpiece. I imagine you get some more freedom with Python. Of course, you get even more if you drop down to deeper-level languages like C/C++. It would depend on your needs, tastes and way of thinking what fits best. I do sometimes feel the urge to learn at least a bit of C, if only to get a clearer grasp of the fundamentals. But I also wouldn't mind the possibility of merging C code with the Python scripts to speed up calculations here and there (those AI bottlenecks).
As always,
Minotauros
-
I mistype too often to be cool with a language where you don't explicitly declare your variables.
That's actually a very good point! ::)
As always,
Minotauros
-
@Minotsur, great reply thank you; what are the reason for the bottleneck effect you are referring to? do you know any roguelikes which would be not working good enough if they were written in python for this reason you mention?
@Krice: so python doesn't have a good user friendly IDE? what are some languages which have that in your opinion?
@wire_hall_medic: can you elaborate? not sure if I understand
-
@Krice: so python doesn't have a good user friendly IDE? what are some languages which have that in your opinion?
C++ always had the best ones. Even in ancient times we had Turbo C++, then later obviously Visual Studio. Code::Blocks is also quite ok, even it is a open source project.
-
@Minotsur, great reply thank you; what are the reason for the bottleneck effect you are referring to? do you know any roguelikes which would be not working good enough if they were written in python for this reason you mention?
It can for instance arise with nested loops (loops of loops). I mentioned AI, because if you have a lot of actors moving at the same time, you risk doing a lot of calculations between each turn. For instance, my game sometimes has forests of semi-intelligent plants, which would mimic critter AI to do stuff like seed spitting at passers-by. But just adding all the plants to the game's list of actors caused the application to start to lag, so I had to build in some shortcuts to let the plants not be actors as such, but still able to do their thing.
Map generation can also be a CPU sink, especially if your code is a bit clunky, like searching through a lot of empty space multiple times, failing and retrying from scratch a lot, etc. At least, that occurs as loading before levels. In my game, it takes a few seconds now and then to generate a new chunk of the world map. I've looked into process threading as a way to avoid visible lag, by letting the game dynamically generate surrounding areas in the background, simultaneously as the player is playing.
Regarding other games this applies to, I can't with authority name any in particular. But I would imagine stuff like Dwarf Fortress, with a lot of moving parts and dwarfs minding their business. In any case, a fairly complex AI is still a lot less CPU-heavy than real time 3D rendering and such. If Python won't allow you to brute force your way through any grotesque mass of data, you can at least strive for good design in the first place. Ie. make the game's rules in a way that makes sense to you as the game master; instead of having a zillion things testing for a zillion conditions, focus on the interesting things/conditions that will actually occur 8)
As always,
Minotauros
-
Thank you - this is really helpful.
-
I had a great experience with language Pharo that has IDE (it seems to be a core feature) but was so difficult to grasp that I quit after couple of minutes. Some languages and tools are like that, they require too much "smartness" and in the end it doesn't help writing code and programs in any way. Although I think I'm going to try Smalltalk if I can find some way to code it (Pharo is based on Smalltalk), because the syntax of Smalltalk is not that bad and it is a pure object-oriented language.
I think this is one of the reasons why some languages are more popular, because they require the least amount of work to set up and start writing programs.
-
(continuing rambling) Trying to find compiler/ide for other than C++ seems to be quite difficult in fact. Maybe that's actually the reason why C++ is so popular? I've tried to expand my programming knowledge by trying out different languages, but for Windows particular it's so hard to find anything that you can just download and start programming. Stuff coming from linux/open source is usually a nightmare to install or use and the only useful options are commercial which are often very expensive. I find this whole situation a bit ironic in this age of science.
-
Visual Studio 2017 for C#, its free.
-
I currently do the vast majority of my programming in Java - I plan to release a project here on the Early Dev forum in the near future which I've written entirely in Java.
Now, I haven't really had much experience with different sorts of IDEs, but I primarily use Eclipse for Java, and I find it meets my needs exceptionally well.
I am also in the process of learning other languages - Python and C among them - and while I tend to use Notepad++ for anything I do in C, there is actually an IDE available for Python called PyCharm. I have limited experience with it at this point, but it appears to have at least the same fundamental features for Python that Eclipse has for Java, although I'm still navigating the differences.
As far as languages themselves go, I'm not at all comfortable with Python yet - I, too, dislike the lack of explicit declaration of variables that was mentioned by a previous poster, and I also don't really like the inflated importance of formatting - in Java, it's a convenience, but in Python, it's an absolute necessity, and some of the habits I've gotten into with Java don't really align well with what Python demands. I'm much more interested in C - it shares many similarities with Java, and while you can make mistakes that simply aren't possible in Java, you also have that same margin of increased capability.
Maybe I will eventually come around to Python, but for now, I'm not a huge fan.
-
Visual Studio 2017 for C#, its free.
That's obvious, because it's also a C++ IDE and I have it. C# is not that interesting, but maybe I should give it another try.
-
C# is very similar to Java.
Unity uses C# and has a rogue-ish tutorial in the learning section.
-
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 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
-
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.
-
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. :)
-
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.
-
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.
-
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.
-
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?).
-
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.
-
Any language can produce "sloppy code" as long as programmer do that. For example, the Python libtcod example is somewhat messy, be careful - but it works.
The Python is a good language. Flexible, has lots of libraries, including tcod, there is the fine IDE - the PyCharm is a great one and it's also free, unless you want to debug web applications.
-
Any language can produce "sloppy code" as long as programmer do that.
Wish it was that simple, but some languages are considerably slower, because they have a complicated way to handle memory management, container structures etc. whatever the reason. I think a great way to measure the usefulness of a language would be simply create a roguelike in it. If it is possible and the game runs fast even in older computers then it has passed the test. And it seems that those people who say this and that language is better don't often show it by creating useful games and programs. It's all just a sweet theory.
-
@wire_hall_medic: can you elaborate? not sure if I understand
Sure. If I accidentally misspell a variable in Python, I have just created a new variable. And it's not a syntax error, so I don't get an easy error message most of the time.
Additionally, as an interpreted language, Python won't catch problems until runtime. So if I'm on something complex, I either have to test EVERYTHING in isolation, or get to it normally. If I tweak a map generator, I don't want to load the splash screen and start a new game before being told I forgot a colon. I'd rather just hit the compile button.
Java is like my car; suitable for most tasks. Python is a golf cart; nice for super short trips, because I don't have to turn on the engine, or fasten a seatbelt, or those other little things. C++ is a bulldozer; a little unwieldy, but sometimes nothing but raw power will suffice.
-
[...] Python is the closest thing to a "real" programming language I know at all.
Python is a real language. C, C++, C#, Java, Ruby, GML, BASIC; hell, even TI Basic is a real language.
HTML is not. No jumps.
Javascript is, but a tomato is technically a fruit (I'm just letting my prejudice show. Yes, Javascript is a real language. But it's the Frankenstein's Monster of programming languages. I'd rather use assembly.).