top of page

Fantasy Ball

Fantasy Ball is a breakout clone with a Forest-Fantasy theme to it. This was a trip down the nostalgia lane of childhood and was greatly inspired from other breakout clone games like Araknoid, DX-Ball and Grove Flowers.

Role

Generalist Programmer

Game Engine

Personal Phoenix Engine

Platform

PC (Windows)

Development Time

3 Months, 2020

Team Size

Solo Developer

Fantasy Ball - Phoenix Game Engine
Trailer
Fantasy Ball Trailer
Screenshots
Screenshots
What did I plan to accomplish?

A Forest Fantasy themed brick breaker game with a limited number (with at least 3) of levels that can be painted using a color key. For the game to feel fun and juicy, the plan was to adding is multiple different types of particle effects, power ups for the ball and the paddle with varying brick types.

What the game currently features?

  • Easily adding new levels using any simple image editing tool like paint and XML.

  • Randomized music, audio effects, powerups spawning and background images.

  • Local High Score System and UI.

  • Gameplay and UI debug visualizations.

What would I do to make it better?

  • Add more Juice to the game – more powerups, effect variations, more levels.

  • Balancing powerups spawn rate and scoring mechanisms.

  • In general more variation of everything the background, the music, etc.

Goals
2D Particle System
2D Particle System 

Part of the goals with this project was learning to drive the development of the personal Phoenix Game Engine along with the needs of the game. For the game to feel juicy and satisfying a 2D particle system was developed within the Phoenix Game Engine. Why an engine side system then? For reusability with any other 2D game developed using the engine to enhance the user experience with particles while reducing the development time needed to add in similar effects to the game.

Fantasy Ball | Particles | Phoenix Engine | Game | Breakout | DirectX 11 | C++

Fantasy Ball - Particles

2D Particle Emitter

2D Particle System

Particle 2D

Power-Ups

Augmented the game with easily modifiable powerups. The powerup can be added to the XML file and the powerup definitions loads all powerups in this XML file. For access via game code, powerup behavior can be defined in the powerup file along with its respective enumeration value. Data Driving allows fast testing of the parameters, addition of new parameters and the powerup definition file allows control and robustness to avoid the user from breaking the game with new power ups. 

Fantasy Ball | Particles | Phoenix Engine | Game | Breakout | DirectX 11 | C++

Power-Up Spawning in game

Power Ups C++

PowerUp Definition C++

PowerUps.xml

Power-Ups
Development Insights and Deep Learning

  • Data driving should have been done at the end and not right from the get-go as unexpected challenges arrive with it.

  • Data driving was a double-edged sword in this case and I learned that it can increase or decrease development time depending on the use case. It can be dangerous if the user is allowed excessive control to change parameters.

  • Poor Gameplay architecture from the get-go causes more issues when adding features in the long run. (Do not rush through this and put more thought into it)

  • Having assets and assets matching the need of the game are two separate things. Do not confuse them and make sure that you are getting desired results with them in early milestones.

  • Driving Engine functionality, as the game develops is different than developing engine systems in a vacuum.

  • Performance optimization can be done in simple ways and complex ways and often simpler and faster approach works out better.

  • Very easy to become a “Feature Creep” in simpler games as they are mostly driven by juice.

  • It's really hard to debug release only build bugs if you don't know where to look for.

Deep Learning 1.png

  • Do not Ignore Warnings generated by the compiler even the simplest ones. 

    • FIX: - Promote simple warnings like not all control path return a value to Errors and include them in your Engine Common and Game Common header files to avoid these kinds of errors in the future.

Development Insights and Deep Learning
Post Mortem
Post Mortem

What Went Well ?

  • Initial planning was inadequate, but the process got better with each milestone.

  • Keeping track of tasks, bugs, focusing on deliverables for every milestone.

  • Understanding how negotiations with a stakeholder works when milestone deliverable needs to be changed in the middle of a sprint.

What Went Wrong ?

  • Bucket tasks do not work well when planning for sprints. 

  • Actual work time was off by almost 50% of the hours proposed in initial plan.

  • Do not recreate tasks already present in the backlog.

  • A lot of unplanned tasks were created due to lack of granularity of tasks.

 What I Learned ?

  • Avoid creating bucket tasks as much as possible but if creating bucket tasks, list some sub tasks with estimates for those buckets.

  • Look patiently and thoroughly in the backlog before creating a new task.

  • Atomize the tasks as much as possible.

bottom of page