snorridev / thoth Goto Github PK

Background layer -- should be adapted to be an image
Midground layer -- no texture blending, platformer blocks
Entity layer -- normal entities drawn here
Foreground layer -- sprites for ambient effects (ignore for now)

Screen should scroll both horizontally and vertically with the player.

Reduce to only sling and papyrus consumable. Add mana "gas" cost for each word.

Player has base stats:

• Strength - damage
• Defense - health
• Intelligence - mana cap
• Attention - mana regen rate

Make GUI interface for editing spells simpler and have it come up when you cast a papyrus.

World should move with you horizontally. It should probably not move with you vertically.

This actually is low priority. We can keep the centered movement system the same for now.

In other words, players with more health should have more hearts displayed.

It's unclear how to resolve ambiguity around prepositional phrases. The best way would probably be too remove prepositional phrases modifying nouns because their utility is questionable anyway.

Right now, the whole World is saved, which is expensive.

Potentially, we can completely remove auto-save.

Doors should be upright. Two door blocks should now suffice.

Reproduction: Open jar file, play tutorial. Close the game. Reopen the jar file and open tutorial again, character cannot move.

Played on Mac 10.10.5 in build 0.8.5

We have a partially implemented entropy mechanic.

The idea is to allow some kind of decision-based scaling. Players can transition on a spectrum between Order and Chaos (the value on this axis being called entropy). The affect of some spells scales with the player's entropy value.

See SpellEvent for more details.

I've decided to simplify spellcasting a bit. Now, each item implements an onCast method, which takes a CastEvent. This allows information about cast position, etc. to be passed in from the context.

Note that sy (it/mouse) will always refer to the dynamic (i.e. runtime) mouse position, whereas the second person object now refers to either the object that the spell was cast on or a blank entity at the initial cast position.

One immediate consequence of this is that Open will be refactored to be intransitive. It will always use the second person object as the position for opening. This makes its behavior more intuitive. Just write wpi on a sling or target a papyrus with wpi on a door and it should work as intended.

Since using Open is the first step in the tutorial, it lets us start with a non-compositional spell, and then introduce a compositional spell in stage 2.

Right now, the underlying data is updated but not the UI. This is fine for most practical purposes and should be treated as a very low priority issue.

We need physics in this game like so stuff can fall and shit

EDIT(lambdaviking): This entails adding velocity (momentum) to entities and gravity.

This is a good idea because it lets the logger keep track of where the calls are coming from (will log the function name).

This refactoring would be a high level change to the interface or underlying data representation.

Some possible changes would be to:

• Replace trinary rules with binary branching structure.
• Choose whether to execute or evaluate based on something in SpellEvent.

When they break, things drop.

Order spells

• Vortex
• Lazer weapon
• Invincibility
• Flood of order: parting the Red Sea (modify deep water, the same as force push)
• Plague of order

Chaos spells

• Lightning storm
• Time walk
• Melee weapon
• Spawn living unit
• Plague of chaos
• Flood of chaos makes lava

Other spells

• Reanimation
• Darkness/light
• Shield/ward spell
• Landmine/trap

TODO: change how name unlocks work
Sandstorm spell should throw units?
Other dichotomies like create/destroy?

For example, the constructor of signature

public Tile(String substring);

should be made into a factory function.

We should create an AIMode.BUDDY for NPCs that walk near the player.

In this mode, players should walk towards the player until they are within getAttackRange().

See the other AIModes as an example for creating a new one.

What we are looking for

We are looking for someone to create animations for the following characters:

• Prince Setna Main character of the game. Existing concept art and placeholder animation.
• Thoth Egyptian god of wisdom, and namesake of the game. Existing unanimated concept art.
• Apophis Snake embodying pure evil in Egyptian mythology. No existing concept art or animations.
• Ghost Boss An ancient ghost sorcerer who is a main villain in the story. Existing unanimated concept art.
• Society of Set Boss An enemy sorcerer who uses fire and explosions, against whom the main character has to fight. No existing concept art or animations.
• Anubis Egyptian jackal god of mummification. No existing concept art or animations.
• Egyptian Axeman Soldier Melee enemy type. No existing concept art or animations.
• Egyptian Slinger Soldier Ranged enemy type. No existing concept art or animations.
• Imhotep Major secondary character. No existing concept art or animations.
• Egyptian Civilian NPC A generic Egyptian character. No existing concept art or animations.
• Crocodile A melee enemy. Existing unanimated concept art.
• Mummy Common enemy type. We currently have a placeholder animation but want a replacement.

Total contract is $300. We may give you another contract after you complete these characters. If you take on this contract, we expect you to complete the whole thing unless we come to an alternative agreement beforehand.

More info about The Book of Thoth

https://github.com/SnorriDev/SpokenWord/blob/master/README.md

Further specification

Our characters are drawn in Egyptian sideways walking perspective.

For example, check out this concept art for the god Thoth.

Here is another development screenshot.

Human units should be approximately 40 pixels wide by 80 pixels tall. Gods, bosses, and monsters should be slightly larger than this.

Application

We are looking for one animator to fill the above contract. If you are applying to work with us, please fill out this brief survey.

Thank you for your interest in The Book of Thoth!

Should be more intuitive for new users. Example changes:

• "Click here to type spell.."
• Add headers to dictionary table.

Sometimes a unit starts moving very fast with no cooldown on its projectiles. I'm pretty sure this is caused by a duplication of the references to the object in the world's EntityGroup, which means there might be a problem in add/delete/recalculate methods.

Feel free to either work from existing animations or start from scratch depending on what's easier.

https://github.com/SnorriDev/thoth/tree/master/textures/animations/setna

Animation is currently being displayed at a frame rate of 8 (ew). Target is >24.

Make a GamePanel for easy editing of levels.

A somewhat open-ended issue. Basically, the spellcasting mechanics and the syntax of the spell language can be more clearly conveyed to the user by adding features like drag and drop, etc.

Use this issue to brainstorm ideas for an improved interface which can eventually be integrated.

Right now, it can only modify the default tile layer.

Given the new AIMode system, we should be able to supply the shooting logic for the ballista directly from snorri.ai.

Masking techniques were used in the old game to blend a continuous surface between bordering tile regions. This is probably no longer relevant, so it should be removed from the code base.

Logic for different Animations in Entity can be encapsulated in a (possibly transient) AnimationManager. This would then be accessed through a protected method entity.getAnimationManager().

The AnimationManager could register different Animations for an Entity using either string or enum constants (probably choose one; don't support both). Then, the animation for the object could be set using getAnimationManager().setAnimation(key) where key is a String or AnimationKey enum.

A rough sketch of the exposed interface for the AnimationManager would be:

• registerAnimation(AnimationKey key, String animationPath) - Load an animation into the manager.
• setAnimation(AnimationKey key) - Set the selected animation in the manager.
• getAnimation() - Get the selected animation in the manager.

As part of this refactoring, we should consider switching our Animation class to something built-in like https://docs.oracle.com/javafx/2/api/javafx/animation/Animation.html. This might be more work than it is worth.

Can't do anything if an unbound key is pressed.

Content in BackgroundLayer images should be tiled in display after the original image ends. This shouldn't be too hard.

The ImageViewer in the Java graphics API automatically handles transformations on a 2D rendered scene.

This might be useful for scaling and stuff.

Observed that the player can walk off the map and disappear. Not sure why this is happening.

When this happens, the update method (and presumably also the render method) stop being called on the entity. This probably means they are no longer registered in the QuadTree.

Add small clause syntactic constructions to allow for queuing commands onto other objects, etc.

Having this as a feature of the syntax would interest some interesting gameplay possibilities. For example, creating a land mind by enchanting a spell onto an urn on the floor.

At least two new playable maps:

• Valley of Kings
• Fountain level, etc.

Interface improvements:

• All tiles should blend together properly
• Fix hieroglyphic display glitch
• Replace useless tiles with good ones
• New dictionary interface in the Spell Editor

Graphics improvements:

• Make some new NPC sprites
• Make animations for units
• Simplify all units so animating is easy

Gameplay improvements:

• Chaos and order dichotomy

Old flying meant phasing through blocks. This is no longer an option.

For example, SpellResult.SUCCESS, SpellResult.ERROR, SpellResult.EVAL_TO_TRUE, SpellResult.EVAL_TO_FALSE.

These enums can have an eval() method which returns the old true or false value.

This is not a must have, but it might be useful for having more informative UI responses after executed spells.

Different entities should have different AI modes which can be specified in YAML.

We should have modes like SNIPER, PATROL, PATHFINDER, etc.

This should be parametric in terms of screen coordinates.

The old movement logic deals with moving along diagonal walls, etc.

We should get rid of this now that we have ported the game to a side scroller. The logic is unnecessarily expensive and also complicates the movement interface.

See Entity.moveNicely.

Looking good. Is there a way to build this without Eclipse?

There are a couple changes to the grammar which could potentially be introduced, although whether or not they would be good or bad is not immediately obvious. These features are:

Adverbs like "not" and "greatly"
Locative prepositions like "around" which execute a spell over a region (at a list of points)

This layer type can be used to easily display and integrate art.

Cuts down on world creation time.

We have a complicated hierarchy of abstract classes extending Entity.

It might make sense to convert these to interfaces or something.

This would let us have animated pieces of the map, which could be interesting for building worlds.

In redesigning the tutorial, the simplifications to the semantics of Open (#60) are particularly relevant.

We no longer need the three different enums of TileTypes. Should instead unify all of them into one enum UnifiedTileType which implements TileType.

We can keep the interface here more or less the same; some API methods might need to be replaced. It might make sense to have a sub-enum TileType.LayerProperties, but I'm not yet convinced that this would actually be a good thing.

See Player.java. Some input checking can apparently be moved to a new Event.

Refer to Player.java.

Would really minimize load times

Create a constructor for animations that specifies the frame rate.