adi64 / terminus Goto Github PK

Wagons that overlap are showing a mixed color

Create pseudo-random game world for every playthrough

• Volume controls
• Enable/Disable vibration on hit ??
• Enable/Disable gyroscope

• Add touch gesture "pinch-to-zoom" to enable the user to switch into the specific UI of the currently selected wagon
• Add the zoom out gesture
• Add check if wagon has a wagon specific UI

Maybe use a texture?

• Check if bullet supports OpenGL ES and Android/iOS
• Integate bullet into the project

• Create Dummy 3D Model
• Load and display 3D Models in the game world

The game crashes without an error message when loading a faulty .obj (in this case an obj without a single "o" line). The crash could also be caused by trying to load a model that is not available.

Expect behavior would be not loading any geometry for this object and displaying an error message.

Create the weapon wagon UI

• support zoom
• fire/shoot
• aim

similar to #4

• Check which file extension are supported
• Load the file for the background music
• Play file while being ingame
• Loop background music

ref #1

AFAIK bullet provides a collision shape optimized for heightmaps. Look into that and make things collide with the actual displayed terrain.

A more silent soundFX causes the other ones + background music to be played at the same level.

->Engine wagons sound disturbes backgroundmusic in general.

With great loading times come great responsibilities. These responsibilities include an awesome entertaining loading screen.

• create and use basic AI train layout
• AI can use weapons (aim to center of player train)
• AI can use repair
• AI alternates between using a weapon and repairing
• Play by the rules (i.e. use primaryAction() etc.)

• second track
• second train

We will need a timer eventually... the clock's ticking

• Animate and smoothen the change of position of the camera after flicking
• Fine tune values to distinguish flicking, pinching and the multiplier for other interactions
• Restrict gestures to certain areas/modes

improves #10

• randomize train layout (different layouts every game)
• use priority system to choose next interaction
• use priority system to find next target wagon to attack
• AI takes into account the length of the level/track
• Recognize difficult terrain and change priorities accordingly

Ground plane cover train. 2nd cart overlaps 1st and some more stuff.

needed for #13

Camera does not return the right matricies yet.

• support multiple wagons
• wagon positioning
• extended functionality?

• Check supported file extensions (performance?)
• Load SFX files (manager class?)
• Play SFX sounds at appropriate moments
• Adjust volume according to distance to camera

• create camera
• create scene
• setup camera to render scene

• implement AABB
• camera should be oriented on the local model axis/coordinates

• implement random generation for track using a spline
• parameterize the spline for arc length conformity

• Repair Wagon
• Model
• Wagon specific UI

• fog
• storm

We need to know the extent of a Geometry object in order to do collision detection and other things. As long as our models are more or less quboids, an axis-aligned bounding box / AABB will do the job.

• Use Arrow keys to switch wagons
• Use the touch swipe gesture to enable the user to switch between the selected wagon and its neighbor

In order to properly synchronize game state changes (i.e. deleting nodes), a queue of events should be implemented that will be processed before Scene::update(). This way, events can be safely scheduled asynchronically (e.g. deleting a node in response to a key press while rendering nodes).
This means that our game loop will essentially consist of

• process scheduled events
• update every node
• render every node

At the moment, needed geometry is only referenced while rendering. I think AbstractGraphicsObject should have members that list used geometry, materials and programs. I think of something along the lines of std::vector<std::string> m_usedPrograms (and m_usedGeometry and m_usedMaterials).

Also, while we're at it: I don't know how bad it really is, but referencing geometry etc. by string makes every render() call of every object cause about three hash-map lookups. If we really know all resources at compile-time, maybe enums make sense?

Using both QVector/QMatrix and glm::vec and glm::matrix all over the place wont work in the long run. Which one should we keep.

• Make a decision
• Create guidelines on usage of when to use glm or Qt Containers
• Adopt guidelines in existing code

ref #1 #4 #8

• Firing mechanic
• Reload
• Firing direction
• Collosion detection
• Damage calculation

This should be in Scene.

elapsedmilliseconds does not need to be passed around after this is added

• Create Terrain Class
• Create Ground Plane
• Place Tracks on Plane

Possibly as non functioning mockup overlay for Early Access Convention but preferably actually implemented

• Own train and enemy train status bar
• Aiming reticle if weaponwagon
• Primary Action Button
• Wagon Switch Buttons
• Force Bar
• Health Bar
• Map?

Camera should be able to be locked to a certain object (mostly AbstractWagonObjects) and follow its movements.
When locked to a wagon, camera center should be fixed a little above the center of wagon's top plane and movement should be limited so that the camera eye moves along the x axis of the wagon.