Arkanoid Mini Game
89 views
Skip to first unread message
Grigory Filatov
Sep 21, 2025, 11:32:19 AMSep 21
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 AMSep 22
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 AMSep 22
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:
Reply all
Reply to author
Forward
0 new messages