Pyra Is C++ and Python mainly used?


LWFlouisa

Still Fresh
Joined
May 6, 2018
Messages
15
Age
35
I'm more used to developing in Ruby and HTML, although I'm currently working with Shoes GUI. Gitlab currently wiped all my gits I had stored there, so buh bye Terminal Shooter.

Although luckily I still have the prototype for Doomed Warrior, another 7DRL I did.

I've heard Python is similar to Ruby, although Crystal seems closer to it to me.

I can learn Python, it just might be slower.

In referencing to developing for Pyra specifically. Or should I try Pandora first?
 
I code mainly in python these days. I don't know Ruby especially, or Crystal, but python is normally installed by default in most distros these days so just works on linux (although you may still need to install python3 manually, I don't know).

As for which platform you target, it really doesn't matter for a high level language like these. Code for what you've got.

I'm slightly surprised you could lose git repos. Didn't you keep your original local copy for everything?
 
For a long time, I had the bad habit of having to constantly reinstall the OS. Going to try to find one other flash drive I got, see if its on there. But most of my stuff is at Github rather than Gitlab. Trying to install this decentralized Git options, but no luck.

It seems like everything I try to install with NPM doesn't work. Maybe it's a Trsiquel thing?

I mean it might be easy enough to rebuild, concept is simple enough: you fight another spaceship in a turn based grid, similar to tactical games like Final Fantasy tactics. You have three options: Regular Attack, Combo, and Repair Spaceship. Random difficulty mode, with impossible mode comparable to fighting ten spaceships in one enemy. Player represented by the letter P, and enemy is the letter E.

I did a lot of coding practices I'm not sure is correct: whether player is a class in itself, or a subclass of creature. I always assumed Player and Enemy were separate classes.

It's basically just a space shooter that fights more like FF Tactics than Space Invaders.

It's not really obvious from the screenshot, but I have this weird bug where the map shape seems to switch every time I load the dungeon. So I'm basically have to rebuild both from the ground up.
 

Attachments

  • Screenshot from 2018-05-06 13:52:06.png
    Screenshot from 2018-05-06 13:52:06.png
    101.9 KB · Views: 420
Last edited:
Ah, right. I mainly partition my home directory separately, so I can always blat the OS partitions without touching my home if I need to. That does mean I've still got a little cruft from my original install, but only stuff that's so small I've never got round to clearing it out.

Yeah, laying out OO classes can be a bit of a dark art. You could always start out with a superclass of creature, and delete it if it turns out there's very little stuff in that superclass. That's the point in having a superclass at the end of the day, whether you can reduce duplication by putting common methods and data in there. In a lot of 2D games I suspect there isn't much but in your case you might share movement methods and location data, and you could put a render method in that depends on an overridden data item defining which ascii character to use for each. In a game a la space invaders, your movement and the aliens movement doesn't share much since you can only go left and right under joystick influence, while the aliens go left and right and down under timer control, but if the only difference is the control method then maybe it's worth sharing methods, and getting a rock solid well tested superclass to base things on.
 
Ah, right. I mainly partition my home directory separately, so I can always blat the OS partitions without touching my home if I need to. That does mean I've still got a little cruft from my original install, but only stuff that's so small I've never got round to clearing it out.

Yeah, laying out OO classes can be a bit of a dark art. You could always start out with a superclass of creature, and delete it if it turns out there's very little stuff in that superclass. That's the point in having a superclass at the end of the day, whether you can reduce duplication by putting common methods and data in there. In a lot of 2D games I suspect there isn't much but in your case you might share movement methods and location data, and you could put a render method in that depends on an overridden data item defining which ascii character to use for each. In a game a la space invaders, your movement and the aliens movement doesn't share much since you can only go left and right under joystick influence, while the aliens go left and right and down under timer control, but if the only difference is the control method then maybe it's worth sharing methods, and getting a rock solid well tested superclass to base things on.

Yea I'm still having to learn how GUI commands work though. All I've managed so far is a word processor and a Cryptography/Steganography index.

But wanting to integrate QR code based cryptography in a game sometime later.

I'm actually more of a fiction writer/designer type, but having to learn coding largely by necessity.
 
Yes, a slow language might miss the next vsync and cut your framerate in half if you need to do a lot, so I guess you could call that lagging. In terms of crashes, only a badly implemented language will crash more than any other. You could argue that one language's crash reports are easier to understand than another, but to a large extent it's down to user preference. In a high level language such as python though, you'll have to go some way to get a core dump, while something more low level like C++ gives you the flexibility to omit to delete something and cause a memory leak, or to corrupt the stack, or do a few other things that are hard to debug which is why good coding standards are more essential there.

Personally, I tend to prototype things in Python. In a few cases I've intended to go on any recode things in C/C++ buy in practice I've always found the CPython interpreter fast enough for me. I've not coded a game that renders graphics though, so my definition of 'fast enough' is just that I don't get bored waiting for it to do anything.
 
Yes, a slow language might miss the next vsync and cut your framerate in half if you need to do a lot, so I guess you could call that lagging. In terms of crashes, only a badly implemented language will crash more than any other. You could argue that one language's crash reports are easier to understand than another, but to a large extent it's down to user preference. In a high level language such as python though, you'll have to go some way to get a core dump, while something more low level like C++ gives you the flexibility to omit to delete something and cause a memory leak, or to corrupt the stack, or do a few other things that are hard to debug which is why good coding standards are more essential there.

Personally, I tend to prototype things in Python. In a few cases I've intended to go on any recode things in C/C++ buy in practice I've always found the CPython interpreter fast enough for me. I've not coded a game that renders graphics though, so my definition of 'fast enough' is just that I don't get bored waiting for it to do anything.

Ah OK, that explains a bit. I've never coded with graphics. Or at least sprites. Even my GUIs are for cryptography and not so much games.
 
Back
Top