AngryCube

A game where you use a catapult to destroy fortifications.

AngryCube_cut1.mp4

Gameplay

• The player controls the shooting angle and tension (shooting force). Ammo is limited

• The goal is to destroy all the bricks in a fortification

• The game currently consists of 5 levels with increasing difficulty

---

How to run the game

1. Download AngryCubeGame.rar from Releases
2. Extract AngryCubeGame.rar
3. Run AngryCube.exe

---

Project overview

The game is built with C++, OpenGL, and ImGui.

The project is structured into two main parts: the Engine and the Game.

• Engine provides core functionality:
  • Rendering
  • Movement
  • Physics
  • Collision
  • Base class for all objects in a game
  • Mechanism for attaching objects to other objects
  • Level manager
  • Base class for level saving
  • Destruction
  • Some common UI widgets
  • Clock and timer utilities
  • Debugging functionality (logger, UI)
  • Some interfaces and base classes intended to be inherited in a game
• Game adds functionality on top of engine:
  • Saving and loading specific game levels
  • All game objects (cubes, bricks, catapult, etc.)
  • Core gameplay (shooting, projectile-brick interactions, menu loading, etc.)
  • Game-specific UI (catapult controls, win/lose menus)
  • Level transitions and win/lose logic

Simulation

The game simulates several real-world behaviors:

• Physics (gravity, friction forces)
• Object interaction (collision + physics, sometimes rough approximation)
• Catapult arm rotation (uses parameters of ropes, arm and projectile)
• Projectile velocity at the moment of release

AngryCube_cut3.mp4

AngryCube_cut4.mp4

The catapult is modeled after a mangonel (which uses twisted ropes to store energy). Though the visual representation lacks defining features of a mangonel, the underlying formulas are based on a rope-driven mechanism.

Things that can be improved

• GameObject should not contain all the components by default. Components should be added to objects only when needed, making them more modular
• Components can be stored in a container within the GameObject and updated by calling GameObjectComponent::Update() on each component in the GameObject::Update() method. This way, components will work automatically without requiring code to be written inside the object itself
• The UI should probably be made with a library focused on UI, not on debugging. Alternatively, the current UI should be more extensively customized and configured
• More levels can be made
• Creating all the constructors, operators, and destructors for each class is quite tiresome. This approach should be reconsidered
• Brick destruction can be made truly physics-based (now brick destruction is based on projectile-brick mass ratio)
• Momentum and impulse physics simulation can be implemented