jiffyrob/treds-adventure-v2

Refactoring (and completion?) of a top-down game

treds-adventure-v2's Issues

Assets

I'll put which assets we need here. To start with:

We need some interior tiles:

• castle
• cave
• dungeon
• snow cave/igloo

We need some exterior tiles:

• cliffs
• cave entrances
• logs you can walk in
• thin/cracked ice
• etc

We need some buildings:

• elvish ruins (outpost, broken temples, platforms, etc. made of stone or of wood)
• dwarvish architecture (workshops, houses, etc. made of stone, wood, and metal. Steampunk)
• gnomish architecture (houses in trees, hobbit holes, etc. hewn into the forests)
• human architecture (some multiple story houses, and more varied buildings)
• tents

We need some characters:

• main character (NEED ASAP) (around 16x32 px)
• npcs (dwarves (around 16x20 px))
• gnomes I can use from NinjaAdventure pack

We need some monsters:

• tbd what we need

We need some items:

• I can probably pull my art from v1 for that.

Tools (and Weaponry)

Just thinking out loud on how to implement equipped items. I think the way to do it is to have a Tool class. A Tool would have:

• Animations that the Player class reads and renders
• What state the player should show when he "uses" it
• A callback to execute when the player uses it. This will:
  • push the usage state to the player
  • do whatever the tool does. It will have access to everything that a script does, and be able to start dialogs, affect sprite in front of the player, spawn new sprites, etc.

Some Tool subclasses would be:

• Sword (All variants that work normally would use this class)
• Bow (Same deal as the sword)
• Wand + Subclasses (For all magical wands found throughout the journey)
• Key (Does not have to be a literal key. All items that act like keys would use this class as well)
• Pickaxe
• etc.

Items

Just some planning stuff for items.
Here are the current types of items planned to be implemented:

• Health items affect player health in some way. These also include magic points, etc.
• Tool items change what the player currently has equipped.
• Event items are items that do nothing. NPCs or other scripted entities will give, take, or trade these to set off events and progress the story.

Bug Fixing

If anyone is playing the web version (or desktop I guess) and finds a bug in the game they can put it here. Currently:

• Using the cheese item fails because the player can't be poisoned
• Using the bug net item fails because there isn't a BugNet object in the tools library
• Quitting the game freezes the tab. Close the tab or disable quitting
• NPC interaction allegedly freezes the tab. I haven't been able to reproduce this though.
• When left alt is held, you cannot move up or down
• If you interact when a bush is picked up, the alt key can be let go of during interaction, and the bush can no longer be picked up (edit: Now you can pick the bush up)
• If you enter the windmill when a bush is picked up, it appears elsewhere and then cannot be picked up
• UI does not refresh properly after loading and saving - globals.player not being reset correctly? Probably best to keep the Player object constant at runtime and not make a new one on new map load.
• Day/Night cycle should not affect buildings

Music

As with Assets (Issue #1), I'll do the same with music.
We need:

• Human city day/night x2
• Gnomish village day/night (DONE)
• Dwarvish village day/night (day done)
• Plains day/night (one done)
• Overworld day/night (one done) (merge with plains?)
• Enchanted Forest day/night (day done)
• Winter day/night
• Desert day/night
• Mountains day/night
• Cave (no day/night in a cave)
• Victory jingle
• Loss jingle
• Doorway opened jingle
• and others

OpenGL shading?

This is an issue to debate the necessary-ness of implementing OpenGL GPU shaders in the game. This would allow for fast processing of effects to the screen and other surfaces. Some examples of what we could do would be:

• Dynamic shadows on all game objects
• GPU-accelerated day/night cycle
• GPU-accelerated camera scrolling
• Fancy particles and lighting system (yeah, dynamic shadows)
• GPU-accelerated limited-visibility in dark buildings, etc
• Interesting transition effects
• etc.
  Additionally, all of these would be rendered incredibly fast compared to doing it via vanilla pygame.
  Pretty much everything would be put in a separate package, probably bush.gl. This would have utilities for creating shaders and applying them to surfaces.
  Downsides:
• New dependency of the ModernGL library (I suppose we could use PyOpenGL, but ModernGL is a lot easier to use)
• OpenGL shading is a whole lot of work to implement
• In order to create all these effects we would have to learn GLSL, a language similar to C.
• Shaders don't debug nicely.
• The game might not work on (very) old hardware, depending on what versions we use
• There might be an issue of subtracting from the retro aesthetic of our game.

I'm kind of leaning toward yes, because bush was meant to be reusable, and not just specific to this game. If we decide not to use it now, we could still use it later.

At any rate, we should probably do this last, as most of the things listed above are either optimizations of current features or fancy eye-candy that leaves game play unchanged.

pygame.DirtySprite?

Pygame has a special kind of sprite called "dirty sprites" that when used with the "layered dirty" group allow some very handy features:

• Drawing with custom blend-modes
• Only drawing when an image has changed

The first portion may be useful for things like skies and shadows, and the second one would be good for performance. OpenGL displays cannot be update like this, but we would be updating to a seperate surface and converting anyway, in which case it would still be better because the screen surface only receives limited blits.

Downsides I can think of include:

• A bunch of changes to the code (maybe a good first issue?)
• Doesn't help performance much if the map is scrolling (we could scroll it with OpenGL too though...
• The Sky class is set to later remap colors directly instead of just darkening the surface. Cusom blendmodes won't be great for that.

Relevant docs:
https://pyga.me/docs/ref/display.html#pygame.display.update
https://pyga.me/docs/ref/sprite.html#pygame.sprite.DirtySprite
https://pyga.me/docs/ref/sprite.html#pygame.sprite.LayeredDirty

Player Art

This one gets its own issue cuz that's how important it is.
We need:

• Basic Walking Animations + Default clothing
• Arms:
  • Carrying something overhead (carrying a monster + new item sequence)
  • Pushing against something in front of player
  • Swinging a sword
  • Shooting a bow
  • Turning a key (Opt.)
• Legs:
  • In giant Lead Boots
  • In elf shoes
  • Underwater (shallows)
• Head:
  • In a helmet
  • In a balloon hat
  • French Beret and Mustache (Opt. Easter Egg)
• Torso:
  • In mail armor
• Gnome Mode:
  • Idle + Walking
  • Carrying something overhead

The ROADMAP

Figured it would be good to add a list of features to add, in no particular order:

• Enemies
• Melee Combat
• Range Combat
• Bombs & other explosions
• Item Menu & Item Usage
• Magical Items (how to do these...? I'm thinking do it scripting style.)
• Dungeons & Lucite
• Layers
• Pitfalls and fall walls
• OpenGL shading and optimization?
• pygame.DirtySprite optimization
• "Room Style" camera (thru OpenGL eventually)
• Boss fights
• Events and Story

Web Build

This issue was created for thoughts on the question of whether to make a web build using pygbag.

Pros:

• Can be made to run anywhere, including chromebooks and macs
• Distribution becomes very easy
• May not need to distribute painful windows and linux builds. We could target a single platform.
• Could be run on github pages with newest commit to 'release' branch automatically (maybe)

Cons:

• Would require changes to the code. For one thing, we'd need to be "async aware"
• Some parts of pygame may not work
• OpenGL shading will very likely not work.
• First load on browser can take a very long time depending on the game
• Desktop likely performs a lot better