Arkanoid Mini Game
156 views
Skip to first unread message
Grigory Filatov
Sep 21, 2025, 11:32:19 AM9/21/25
to Harbour Minigui
Hi there,
Continue good news.
I've discovered the Arkanoid game implementation which provided by HMG user Edward with the following description:
I had an idea to build an vintage game from the 80s called Arkanoid, using HMG.
I've attached the game code along with the necessary graphic files.
Due to lack of time, I focused only on the basic functionality, such as knocking
down bricks with a ball or counting points. There are no extra features, such as
falling surprises, changing the width of the paddle, the ability to shoot to bricks.
I hope you like it and the program code will be useful for you in other projects.
Good luck - not only in coding but also in getting the best score in the game.
I've attached the game code along with the necessary graphic files.
Due to lack of time, I focused only on the basic functionality, such as knocking
down bricks with a ball or counting points. There are no extra features, such as
falling surprises, changing the width of the paddle, the ability to shoot to bricks.
I hope you like it and the program code will be useful for you in other projects.
Good luck - not only in coding but also in getting the best score in the game.
Many thanks to Edward for his efforts.
I've adapted this source code to MiniGUI syntax with small additions (external font management).
You can see the result in the picture below.
Your feedback is very welcome.
Best regards,
Grigory
Marcos Jarrin
Sep 22, 2025, 12:17:20 AM9/22/25
to Harbour Minigui
Hello
Grigory,
It's interesting to see that game development is possible with HMG/MiniGUI. I have a few questions:
How complex can games built with MiniGUI become?
Would it be efficient to create a game engine using MiniGUI?
I'd be interested in reviewing sample code if available.
For context, most major game engines (Unreal Engine in C++, Unity in C#)
Thanks for any insights.
Best regards,
Marcos Jarrin
Grigory,
It's interesting to see that game development is possible with HMG/MiniGUI. I have a few questions:
How complex can games built with MiniGUI become?
Would it be efficient to create a game engine using MiniGUI?
I'd be interested in reviewing sample code if available.
For context, most major game engines (Unreal Engine in C++, Unity in C#)
Thanks for any insights.
Best regards,
Marcos Jarrin
Grigory Filatov
Sep 22, 2025, 4:07:44 AM9/22/25
to Harbour Minigui
Hello Marcos,
Would it be efficient to create a game engine using MiniGUI?
Thank you very much for your kind feedback.
My answers to your questions are below.
How complex can games built with MiniGUI become?
Pros:
* 2D games are feasible, especially simpler ones: sprite drawing (images), basic animation (via timers or loops), handling input (mouse, keyboard) are all possible. The sample set includes (for example) a Minesweeper game. ([Группы Google][2])
* You get existing UI widgets and windows, so overlay menus, dialogs, simple in-game UI is mostly “free” if used appropriately.
* Portability (on supported platforms), ease of building rapid prototypes if you are comfortable with Harbour/xBase.
Limitations / Bottlenecks:
* Performance: because it’s not built for fast graphics (like a game engine does), performance will likely degrade with:
1. Many sprites / many independent moving objects: redrawing large portions of the screen frequently (especially with transparency, or many overlapping bitmaps) will be slower.
2. High frame rates: getting 60 fps with many moving parts + collision detection etc. might be tough.
3. Hardware acceleration: I think MiniGUI and HMG Extended do not provide advanced GPU hardware acceleration out of the box for things like shaders, full-blown 3D, etc. It’s much more software / basic GDI/Win32 / basic graphics context based.
* Limited 3D: you’d be reinventing a lot or embedding another library if you wanted 3D or advanced effects.
* Memory / resource constraints: depending on platform, image sizes, sprites etc will eat into memory, and garbage / object overhead from using higher level abstractions (Harbour) may add overhead.
* Tooling / ecosystem: fewer game-oriented libraries, maybe fewer community resources for physics, audio, particle systems etc built for HMG. So you'd need to build those pieces yourself or integrate external libs.
Conclusion: you can build 2D games of moderate complexity; think of platformers, puzzle games, arcade style, or simple side-scrollers. Big open world, high FPS action, 3D, or very high-resolution sprite-rich games will be challenging, probably inefficient or awkward.
---
* 2D games are feasible, especially simpler ones: sprite drawing (images), basic animation (via timers or loops), handling input (mouse, keyboard) are all possible. The sample set includes (for example) a Minesweeper game. ([Группы Google][2])
* You get existing UI widgets and windows, so overlay menus, dialogs, simple in-game UI is mostly “free” if used appropriately.
* Portability (on supported platforms), ease of building rapid prototypes if you are comfortable with Harbour/xBase.
Limitations / Bottlenecks:
* Performance: because it’s not built for fast graphics (like a game engine does), performance will likely degrade with:
1. Many sprites / many independent moving objects: redrawing large portions of the screen frequently (especially with transparency, or many overlapping bitmaps) will be slower.
2. High frame rates: getting 60 fps with many moving parts + collision detection etc. might be tough.
3. Hardware acceleration: I think MiniGUI and HMG Extended do not provide advanced GPU hardware acceleration out of the box for things like shaders, full-blown 3D, etc. It’s much more software / basic GDI/Win32 / basic graphics context based.
* Limited 3D: you’d be reinventing a lot or embedding another library if you wanted 3D or advanced effects.
* Memory / resource constraints: depending on platform, image sizes, sprites etc will eat into memory, and garbage / object overhead from using higher level abstractions (Harbour) may add overhead.
* Tooling / ecosystem: fewer game-oriented libraries, maybe fewer community resources for physics, audio, particle systems etc built for HMG. So you'd need to build those pieces yourself or integrate external libs.
Conclusion: you can build 2D games of moderate complexity; think of platformers, puzzle games, arcade style, or simple side-scrollers. Big open world, high FPS action, 3D, or very high-resolution sprite-rich games will be challenging, probably inefficient or awkward.
---
Would it be efficient to create a game engine using MiniGUI?
It depends what you mean by “game engine” and how performance critical a target you have. Here are considerations:
Efficiency trade-offs:
* If you build a lightweight 2D engine (sprite management, basic collision, tiled maps, simple sound) in HMG Extended, you *can* make it reasonably efficient, especially if you are careful about minimizing redraws, perhaps using dirty-rects (only redraw parts changed), optimizing image loading, caching, etc.
* If you need high performance, frequent redraws, many simultaneous moving objects, complex physics, etc., it might be more effective to use a graphics/game library built for speed (SDL, SFML, etc.), possibly embedding or calling those from Harbour. Or possibly combine HMG for the UI part but embed a faster engine for the game core.
* Another dimension is ease vs performance. HMG gives you many conveniences (windows, controls, menus, etc.), so for a game with lots of menus, dialogs, configuration screens, it’s nice. But when it comes to the rendering loop, updating, etc., you may hit limitations.
* Also consider cross-platform requirement: MiniGUI / HMG Extended is more suited to certain OS environments, so if you want mobile, consoles etc, it doesn’t fit as well.
So building a “game engine” in MiniGUI is possible, but you'd probably aim for something simpler / moderate, not AAA. Good for hobby, educational, or specific types of games.
---
Suggestions / Best Practices if You Build a Game Engine with HMG Extended
1. Layering: separate engine core (update, physics, sprite handling) from UI. Use HMG for UI (menus, dialogs), but core game loop perhaps more “bare metal” where possible.
2. Graphics optimizations: see if you can use off-screen buffers, caching bitmaps, etc.
3. Efficient input handling: rather than polling too often, use event hooks where possible.
4. Use timers carefully: many small timers might be less efficient than a single master loop.
5. Memory management: reuse sprites, images etc., avoid leaks.
6. Limiting resource size: image size, number of objects etc.
---
Existing Sample: Tetris in HMG Extended
One useful real sample is “Tetris game”, contributed by Claudio Soto, in the HMG Extended samples. It’s included in version 20.06 of HMG Extended, and now it's available in the PRO release.
This shows that simple arcade-style games are already being done. You can examine how it uses:
* Game loop / timers
* Drawing blocks (images or rectangles)
* Handling user input (keyboard)
* Simple collision / boundary logic
Examining how Tetris is implemented gives a working reference for structuring the game: dividing responsibilities, optimizing redraws, etc.
---
Thank you again for your attentiom.
Efficiency trade-offs:
* If you build a lightweight 2D engine (sprite management, basic collision, tiled maps, simple sound) in HMG Extended, you *can* make it reasonably efficient, especially if you are careful about minimizing redraws, perhaps using dirty-rects (only redraw parts changed), optimizing image loading, caching, etc.
* If you need high performance, frequent redraws, many simultaneous moving objects, complex physics, etc., it might be more effective to use a graphics/game library built for speed (SDL, SFML, etc.), possibly embedding or calling those from Harbour. Or possibly combine HMG for the UI part but embed a faster engine for the game core.
* Another dimension is ease vs performance. HMG gives you many conveniences (windows, controls, menus, etc.), so for a game with lots of menus, dialogs, configuration screens, it’s nice. But when it comes to the rendering loop, updating, etc., you may hit limitations.
* Also consider cross-platform requirement: MiniGUI / HMG Extended is more suited to certain OS environments, so if you want mobile, consoles etc, it doesn’t fit as well.
So building a “game engine” in MiniGUI is possible, but you'd probably aim for something simpler / moderate, not AAA. Good for hobby, educational, or specific types of games.
---
Suggestions / Best Practices if You Build a Game Engine with HMG Extended
1. Layering: separate engine core (update, physics, sprite handling) from UI. Use HMG for UI (menus, dialogs), but core game loop perhaps more “bare metal” where possible.
2. Graphics optimizations: see if you can use off-screen buffers, caching bitmaps, etc.
3. Efficient input handling: rather than polling too often, use event hooks where possible.
4. Use timers carefully: many small timers might be less efficient than a single master loop.
5. Memory management: reuse sprites, images etc., avoid leaks.
6. Limiting resource size: image size, number of objects etc.
---
Existing Sample: Tetris in HMG Extended
One useful real sample is “Tetris game”, contributed by Claudio Soto, in the HMG Extended samples. It’s included in version 20.06 of HMG Extended, and now it's available in the PRO release.
This shows that simple arcade-style games are already being done. You can examine how it uses:
* Game loop / timers
* Drawing blocks (images or rectangles)
* Handling user input (keyboard)
* Simple collision / boundary logic
Examining how Tetris is implemented gives a working reference for structuring the game: dividing responsibilities, optimizing redraws, etc.
---
Thank you again for your attentiom.
Best regards,
Grigory
понедельник, 22 сентября 2025 г. в 06:17:20 UTC+2, marcos...@gmail.com:
Grigory Filatov
Apr 12, 2026, 5:43:25 AM (12 days ago) Apr 12
to Harbour Minigui
Hi All,
I've prepared the updated version of the Arkanoid game for the upcoming MiniGUI PRO build 26.04.
/*
* Harbour MiniGUI Extended Edition - Arkanoid Mini Game
*
* This application demonstrates a classic Arkanoid-style arcade game implemented
* using the HMG Extended framework. It showcases dynamic control creation,
* collision detection logic, frame-rate independent movement, and resource
* embedding (fonts).
*
* Features:
* - Embedded TTF font extraction and private registration.
* - Delta-time based movement for consistent FPS.
* - Keyboard input handling (arrows, space, ESC, R).
* - Collision detection (walls, paddle, bricks).
* - Level progression with increasing difficulty.
* - High score save/load via file.
* - System WAV sounds.
*
* Requirements: paddle.png, ball.png (place in EXE folder).
*
* Authors: Edward (original), G. Filatov (HMG Extended adaptation)
*
* License: Public Domain
*/
* Harbour MiniGUI Extended Edition - Arkanoid Mini Game
*
* This application demonstrates a classic Arkanoid-style arcade game implemented
* using the HMG Extended framework. It showcases dynamic control creation,
* collision detection logic, frame-rate independent movement, and resource
* embedding (fonts).
*
* Features:
* - Embedded TTF font extraction and private registration.
* - Delta-time based movement for consistent FPS.
* - Keyboard input handling (arrows, space, ESC, R).
* - Collision detection (walls, paddle, bricks).
* - Level progression with increasing difficulty.
* - High score save/load via file.
* - System WAV sounds.
*
* Requirements: paddle.png, ball.png (place in EXE folder).
*
* Authors: Edward (original), G. Filatov (HMG Extended adaptation)
*
* License: Public Domain
*/
Here is a structured technical analysis of Harbour MiniGUI Arkanoid implementation, focusing on architecture, runtime behavior, and maintainability.
---
✅ Advantages
1. Clear Procedural Game Architecture
The code follows a classic game loop + state variables model:
* Central loop: GameLoop()
* State: global STATIC variables (nBallX, nLives, aBricks, etc.)
* Event hooks: ON INIT, ON KEY, timers
Why this works well:
* Predictable control flow (important in real-time systems)
* Easy to trace execution
* Suitable for HMG, which is not inherently game-oriented
👉 This is a pragmatic adaptation of game engine patterns into a GUI framework.
---
2. Frame-Rate Independent Movement (Delta Time)
LOCAL nFactor := nDelta / Arkanoid.tmrGame.INTERVAL
This is one of the strongest design choices.
Benefits:
* Movement scales with real elapsed time
* Prevents:
* Fast machines → overly fast gameplay
* Slow machines → sluggish gameplay
👉 This is a professional-grade technique rarely seen in small demos.
---
3. Dynamic UI Control Creation
Bricks are generated dynamically:
@ nROW, nCol TEXTBOX &( cName ) ...
Advantages:
* No hardcoded UI layout
* Easy to:
* Change grid size
* Add new levels
* aBricks acts as a logical model layer
👉 Good separation between:
* visual controls (TEXTBOX)
* game state (array metadata)
---
4. Clean Collision Abstractions
You modularized collision logic:
* HandleWallCollisions()
* HandlePaddleCollision()
* HandleBrickCollisions()
* RectOverlap()
Benefits:
* Improves readability
* Encourages reuse
* Easier debugging of physics issues
👉 The use of AABB (Axis-Aligned Bounding Box) is correct and efficient.
---
5. Resource Management (Font Embedding)
pragma __binarystreaminclude "SHOWG.TTF"
Strengths:
* Eliminates external dependency
* Uses:
* AddFontResourceEx
* Private font registration
👉 This is advanced Windows API integration—very solid.
---
6. Robust Input Handling Strategy
Two approaches combined:
* Event-based: ON KEY ESCAPE
* Polling: GetKeyState()
Why this is good:
* Polling ensures low-latency movement
* Event system handles discrete actions
👉 Hybrid input model = responsive gameplay.
---
7. State Persistence (High Score)
MemoRead / hb_MemoWrit
Pros:
* Simple and effective
* No dependency on databases
* Works cross-session
---
8. Defensive Programming
Examples:
IF ! hb_vfExists( "paddle.png" )
Benefits:
* Prevents runtime crashes
* Provides user feedback
---
9. UI Feedback & Polish
* Message overlay system
* Color cycling timer
* Sound effects
* Level progression messaging
👉 These significantly improve user experience without heavy complexity.
---
⚖️ Overall Assessment
Strength Profile
This code excels in:
* Practical engineering within HMG constraints
* Real-time loop design
* UI-driven game implementation
* Resource embedding
---
🧠 Key Insight
This is not just a demo—it’s a well-crafted adaptation of game programming concepts into a business GUI framework.
However, it sits in a middle ground:
* More advanced than typical HMG apps
* Less structured than a true game engine
---
---
✅ Advantages
1. Clear Procedural Game Architecture
The code follows a classic game loop + state variables model:
* Central loop: GameLoop()
* State: global STATIC variables (nBallX, nLives, aBricks, etc.)
* Event hooks: ON INIT, ON KEY, timers
Why this works well:
* Predictable control flow (important in real-time systems)
* Easy to trace execution
* Suitable for HMG, which is not inherently game-oriented
👉 This is a pragmatic adaptation of game engine patterns into a GUI framework.
---
2. Frame-Rate Independent Movement (Delta Time)
LOCAL nFactor := nDelta / Arkanoid.tmrGame.INTERVAL
This is one of the strongest design choices.
Benefits:
* Movement scales with real elapsed time
* Prevents:
* Fast machines → overly fast gameplay
* Slow machines → sluggish gameplay
👉 This is a professional-grade technique rarely seen in small demos.
---
3. Dynamic UI Control Creation
Bricks are generated dynamically:
@ nROW, nCol TEXTBOX &( cName ) ...
Advantages:
* No hardcoded UI layout
* Easy to:
* Change grid size
* Add new levels
* aBricks acts as a logical model layer
👉 Good separation between:
* visual controls (TEXTBOX)
* game state (array metadata)
---
4. Clean Collision Abstractions
You modularized collision logic:
* HandleWallCollisions()
* HandlePaddleCollision()
* HandleBrickCollisions()
* RectOverlap()
Benefits:
* Improves readability
* Encourages reuse
* Easier debugging of physics issues
👉 The use of AABB (Axis-Aligned Bounding Box) is correct and efficient.
---
5. Resource Management (Font Embedding)
pragma __binarystreaminclude "SHOWG.TTF"
Strengths:
* Eliminates external dependency
* Uses:
* AddFontResourceEx
* Private font registration
👉 This is advanced Windows API integration—very solid.
---
6. Robust Input Handling Strategy
Two approaches combined:
* Event-based: ON KEY ESCAPE
* Polling: GetKeyState()
Why this is good:
* Polling ensures low-latency movement
* Event system handles discrete actions
👉 Hybrid input model = responsive gameplay.
---
7. State Persistence (High Score)
MemoRead / hb_MemoWrit
Pros:
* Simple and effective
* No dependency on databases
* Works cross-session
---
8. Defensive Programming
Examples:
IF ! hb_vfExists( "paddle.png" )
Benefits:
* Prevents runtime crashes
* Provides user feedback
---
9. UI Feedback & Polish
* Message overlay system
* Color cycling timer
* Sound effects
* Level progression messaging
👉 These significantly improve user experience without heavy complexity.
---
⚖️ Overall Assessment
Strength Profile
This code excels in:
* Practical engineering within HMG constraints
* Real-time loop design
* UI-driven game implementation
* Resource embedding
---
🧠 Key Insight
This is not just a demo—it’s a well-crafted adaptation of game programming concepts into a business GUI framework.
However, it sits in a middle ground:
* More advanced than typical HMG apps
* Less structured than a true game engine
---
Hope this is useful for everybody.
Regards,
Grigory
понедельник, 22 сентября 2025 г. в 10:07:44 UTC+2, Grigory Filatov:
Grigory Filatov
Apr 13, 2026, 11:49:58 AM (11 days ago) Apr 13
to Harbour Minigui
Sorry, I forgot to add a game screenshot.
Best regards,
Grigory
воскресенье, 12 апреля 2026 г. в 11:43:25 UTC+2, Grigory Filatov:
Reply all
Reply to author
Forward
0 new messages