Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
Tags


Is there a listing of every single command in one place? Or a way to search all of them? Where would I look to find focus_object in the docs for example?

This doesn't cover everything, but Playscii's documentation folder includes docs auto-generated from its own source code, which can also be found online here:

http://vectorpoem.com/playscii/generated/pdoc_toc.html

However it looks like Camera isn't one of the classes I marked for doc generation for this process. If you're wondering about properties like Camera.focus_object, I would say get the project's code by cloning the repo (unless that's already what you did to get Playscii running, ie you're not running the Windows build) so you can search the code and see where all something is referenced. For example, it looks like Camera.focus_object is mainly used in Camera.update to set the camera's position. If you wanted to do custom logic, I'd say leave the camera's focus_object as None and have some other code elsewhere that drives its position every frame, eg from one of your object's update() functions.

Main question is: Do I need an instance? for the world, camera, etc., and many other things, and if so how? sorry for noob questions.

GameWorld and Camera are singletons that are intended to live firmly in the "engine" layer, you shouldn't need to subclass either. Though I'll admit now (7 years since I made some of these architectural decisions) that a Camera could arguably be something you create several classes of to drive different behaviors.

I am trying to use a Character to represent player objects instead so I can control multiple objects. Or should I use multiple Player objects?

There are probably several places in the game mode code that assume a single player character, I have no idea how difficult it would be to add support for multiple players.

How can I attach multiple separate types of hitbox to an actor?  I want to use hitboxes to represent ranges like detection, fields, or ranges for various actions, so a single actor might have several distinct hitboxes.

GameObjectAttachment was made for things like shadows and effects, so there's probably something about it that doesn't behave well if you try to make it collide with stuff. I would say just make a GameObject subclass, sync its position with the player's (or whatever it's attached to) every update, and then do your custom logic in its started_overlapping() function.

But yeah I would say your main source of truth is going to be the code, and the (hopefully adequate) comments I left in it when I wrote it. Secondary to that, the documentation (included and on the website, same docs) I wrote not too long after writing the code. And tertiarily, me in 2022 when my memory's faded a bit and my brain is occupied with other projects.

Good luck! You're not the first person to make a game with Playscii's game mode but you're probably before the 10th person or so. I apologize in advance for anything that's non-obvious, broken, poorly designed, or annoying for any other reason. :]

thanks for the great reply. i am just someone on my own journey. Playscii seems like such a brilliant tool, to me. I hope I could do it justice, in some way, and not let it down... 
It's quite difficult for me to think beyond the paradigm of a main loop, i find, but also quite liberating. The design is so unique.
It really inspires me to think in different ways, whatever they may be.

i think i'm understanding a bit more about the paradigm from looking at the source, but it's rather incomprehensible to me.
what if the player object was driving gameplay by moving through rooms, something like that?
then rooms become more like discretised game segments, whatever that may be, including cut-scenes, controller set-up, whatever...
the player moves from room (game-state) to room... but i still don't know what i'm looking at anywhere i admit.
I'm just going to comb through examples until I grasp it better.