You are not logged in. Please login or register.
AudioGames.net Forum → Developers room → Python audiogame frameworks
99% sure Dart is just exceptions. I used to like exceptions. Then Rust finally got the ? operator and I realized that hey, knowing what can fail without having to write 3 or 4 lines each time is pretty great.
@26, here here. Knowing what can fail instead of "Oh I have this block of code and its made of about 50 lines and any of it can fail" is awesome.
@24
This was from the tutorial code.
You're right: I don't think Rust is for me either. It looks very nice, but I prefer something a little higher level, thank you very much. 
Meh, Rust is plenty high level. The problem with Rust is that it forces you to think about things as composition, and you can't take shortcuts. It's a complicated language though, yes, and if you're not used to functional paradigms and think primarily in OOP you'll have difficulties.
In practice thinking about lifetimes is needed even in Python. Rust just makes it in your face and annoying. But it's probably the second-furthest language from a newbie language I can think of, beat only by C++. Just with more of a "omfg learning this sucks" and less of a "omfg 2 months of work and it won't stop crashing and I have to start over".
@29
I'd love to have the inclination to sit down and learn it, since I hear so much good stuff about it. I'm just a bit of a dinosaur in some regards - I love learning new stuff, but struggle to cram that much stuff into my brain.
Also, I'm finding I can achieve everything I currently want to do with Dart or Python, so it's hard to get up the enthusiasm.
Yeah, Python/dart do everything you want which is a big part of why I'm saying it's not for you. But I'm trying to push the frontiers forward at the moment and in ways which require being faster than that, C/C++ need no further explanation, and GO is a special hellish snowflake, so it's definitely for me. Plus it's been my full-time job for months.
@31
You know, with all the teasers you keep coming out with, I'm very fascinated to see what you're going to come up with!!
@32
I mean there's no blog but the repo is here. Unfortunately all the clever github org names I could come up with were taken so we get the super boring straightforward one instead. I spent a little time on it because at this point Synthizer is a chore that mostly I'm developing for others, being as it does everything I want it to for myself at the moment (and, obviously, when that's not true I just add stuff). Obviously it's supposed to be an MMO engine, but at the moment it's just some tile-based physics stuff, though tile-based physics stuff is much more of the project than it seems.
Plan is to take this as far as "you can walk around and shoot a gun or something", then go mostly closed source and turn it into some sort of fantasy RPG. Think Alter Aeon but with consistent lore. And hopefully by then I'll be in the position to throw a little money at it too. Not much, but in blind people hiring other blind people for art land not much should go pretty far, and frankly you can run a social media campaign that'll get it in front of 50000 people for like $500 (not all blind of course), hit hackernews, etc. And since no one including even Swamp markets--well, I think 100 concurrent players * might* be reasonable.
Or this all falls down and ends in tears, or I get hit by a bus, or get bored, or whatever. Who knows. But no one else is trying to my knowledge.
I was going to do this as a bunch of C libs and slowly build up to it, but that's too slow and if I do maybe we'll see something in 2025 or something, so I skipped over all that and went straight to Rust and if someone wants to use one of these from Python they can write a C binding if they want. The compressed tile grid might be useful.
@33, no need to write a C binding to it, just use pyo3.
@34
Yes, and then leave out everyone who happens to not be using Python.
@35, nope. All you do is write the algorithm/code/whatever in Rust, expose it to C via cxx, cbindgen, etc., then use pyo3 to interface with Python. No need to go into C land just to interface with Python.
Shrug, if someone wants to bind my stuff to Python they can do whatever I guess. But there's no need to go into C no matter how you do this: you can either use cython or cffi.
@33: STW has something like an average of 40-50 players, has maintained that for a long time, and hasn't seen a substantive update in a year (although admins can script stuff so there are probably items, quests and maps added and such). Again no marketing, no social media literally at all from what I know except that Sam tweets once every few months. I'm pretty sure lots of it comes from the admins being able to script things and multilingual players. I think if you really market to people outside audiogames.net, you could probably get more than 100 concurrent if you have a team of people who can act professional administrating and improving it.
@37, then you don't need to drop into C. But all you have to do is write your API and then use pyo3 to bind it to Python. Its insanely easy. It works perfectly along with your Rust project so you don't need to use Cython/CFFI.
@38
I would like to do better than 100 but at the same time it's called not counting our chickens before they hatch and all. Plus an FPS-viewpoint fantasy rpg seems like the sort of thing that's--I wouldn't call it niche, but it's not the kind of thing someone who barely knows the computer can pick up. We'll see what happens.
It doesn't help that I effectively can't do it for free--free and professional quality don't mix. It's only coincidental that very low cost and professional quality specifically in blindness land do, otherwise it wouldn't be possible at all.
@39
Yes, sure, fine. But then you're maintaining a Python binding in Rust that's probably tied at least to some extent to the internal details, *and* a C API that's also tied to some extent to the internal details, and then every time you want to refactor an internal detail you have to maintain both. It is much easier to maintain only one public auxiliary interface that everything that's not Rust hooks into, not only from the perspective of code refactors and the like but also from the perspective of testing and baking changes. But again: that's not going to be on me, it's going to be on someone else, and these components are primarily for the project, so shrug.
I'm not arguing that the library is bad though. I'm just looking at this from a larger perspective in which "that's a cool library" doesn't actually solve the large problem, but instead solves a small subset of the large problem while still requiring a solution to the large problem.
@33
Nice, thank you for the link.
If you close source, will it be possible to rent / buy instances from you if people wish to run their own MOOs? Or is this going to be owned and administrated as you as a kind of BDFL?
I don't plan to yank the public repo, I plan to depend on the public repo from Cargo. And it's Boost licensed so even if I did yank it, it's not like I can stop everyone who already had a copy from going to town.
But I'm not going to go hand out the unique parts to whatever game I make because that's how we end up with FPS clone-of-a-clone 5000. Avoiding this thing where we end up with 10 kind of okay games instead of one good one because everyone who doesn't really know how to code or do game design just ran with it is half my reason for not just putting it all up on GitHub. Even if I wanted to rent you something I couldn't rent you something useful anyway. I'm not building moo but graphical or something like that where you can just grab some building tools and make whatever--it's a whole other discussion but "I'm building world of warcraft" assumptions get built into something like that all the way down to networking. But I'm hoping that at least some of the parts I put out will be useful enough to others, because at the moment it seems to me that there's maybe 5 people who have a chance to pull this off, and I don't mind competition if someone manages to compete. That compressed tile grid could be used in a factorio clone or something like wayfar, at least once it's finished and bug free.
So, yeah, I guess BDFL in the sense that if you send me patches I might say "not interested but thanks" or something but also this is tiny enough that you could just fork if you don't like me.
Hi all.
Ok, so i've come to the conclusion.
I am now using pygame, the sound.py file linked in the guide for now, the sound_pool that amerikranian linked to in the guide and sound_positioning that amerikranian linked to.
I am also using the timer class he provided.
I will write a sound player that uses synthizer at a later point in my project, but i just wanted to make sure if it's fine that i use them, or will some one kill me if they find out I use them? lol
edit: and i am also using the speech function provided also. basicly every thing?
What you use is solely up to you. I would encourage you to consider looking at synthizer in not too distant future, if I remember correctly my pool does not support caching. Also there is nothing wrong with using Cytolk
@45 thanx for that.
All i want for now, is just to listen to the sounds, and check if they play when they need to. I want to use cytolk, but I would like my project to be cross platform... as far as i know, tolk does not run on platforms other than windows right?
@46, nope, but that's easily resolvable. Use this little code snippet as your tts module (you'll have to alter it to fit cytolk though, sorry):
# Tts functions, used for cross platform compatibility.
import platform
if platform.system()=="Windows":
import Tolk
elif platform.system()=="Linux":
import speechd
elif platform.system()=="Darwin":
from AppKit import *
tts = None
def initialize():
global tts
if platform.system()=="Windows":
Tolk.load()
elif platform.system()=="Linux":
tts = speechd.SSIPClient("")
elif platform.system()=="Darwin":
tts = NSSpeechSynthesizer.alloc().initWithVoice_(None)
def say(text: str, interrupt: bool):
if platform.system()=="Windows":
if interrupt:
Tolk.output(text, True)
else:
Tolk.output(text)
elif platform.system()=="Linux":
if interrupt:
tts.cancel()
tts.speak(text)
elif platform.system()=="Darwin":
if interrupt:
tts.stopSpeaking()
tts.startSpeakingString_(text)
def deinit():
if platform.system()=="Windows":
Tolk.unload()
elif platform.system()=="Linux":
tts.close()
elif platform.system()=="Darwin":
tts.release()This might need updating, particularly with the M1 macs. It might also not be exactly correct -- I pulled it from some old code and that code is proven to work. But if you have any problems, feel free to ask and I shall try to answer them. This should hopefully get you universal TTS across Windows, Mac and Linux (but not BSD). I may consider rewriting this in Rust as a Python module and just upload that to Pypy. Hmmm...
@47 thanx a lot.
I will deffinately give this a shot.
Just a question: when using this script, do i need to install any thing else for it to work?
for example the line that says import speechd, that is on linux if i am not mistaken. do I need to install speechd? or will python do that on linux for me?
And the same goes for mack.
@47:
One minor little tweak. Before speaking to Tolk and interrupting, it's better to call tolk.silence(), or it might not get spoken, because reasons. You may also need to change it to be from cytolk import tolk, if you plan to use cytolk. Nicely done either way.
@48:
Nope, they ship with the stdlib for that platform. For example, AppKit is apple-specific.
@49, I didn't know that. Like I said, this code is fairly old and hasn't been worked on in years, but its proven to work, so I thought I'd throw it out there. And like I said, I might just rewrite it in Rust and make a Python module that way.
AudioGames.net Forum → Developers room → Python audiogame frameworks
Generated in 0.024 seconds (50% PHP - 50% DB) with 9 queries