-
Welcome to B4X forum!
B4X is a set of simple and powerful cross platform RAD tools:
- B4A (free) - Android development
- B4J (free) - Desktop and Server development
- B4i - iOS development
- B4R (free) - Arduino, ESP8266 and ESP32 development
Games [Project] Kingdom Crisis (KZ Engine)
- Thread starter wonder
- Start date
- Similar Threads Similar Threads
Probably once I have an Input/Output Game Flow System in place, I'll be focusing solely on Game Design, so (almost) no more coding. 
My next step is to create .game files as the primary input to the engine.
The structure I envision is as follows:
This is just a sketch, the structure will probably be much simpler than this (maybe in a small SQLite db).
So, again, a GAME may contain many WORLDS, each world has it's own Textures and Sounds.
A WORLD my contain many MAPS, each map has it's own rules, but borrows the (some/all) textures and sounds from it's parent world.
A MAP can contain many SECTORS, sectors can be, for example, bonus or secret areas, underground levels, etc.
When changing worlds, if some of the textures from the previous map can be reused, they won't be disposed. Only new textures will be loaded. The same goes for sound.
My next step is to create .game files as the primary input to the engine.
The structure I envision is as follows:
B4X:
MySuperCool.game
----------------------------------------
+ Intro Screen[separate file .intro]
------------------------------------
- Texture List
- Sound List
- Asset Files
- Interactive Objects
+ Game Worlds[separate files .world]
------------------------------------
- Texture List
- Sound List
+ Maps[separate files .map]
--------------------------------
- Asset Files (level design, characters, blocks, bombs, coins...)
- Physics (rules, gravity values, etc)
- Sectors
- Micro-Scripts
+ In-Game Menus[separate files .menu]
--------------------------------
- Similar to .intro
+ End Screen[separate files .end]
------------------------------------
- Similar to .intro
----------------------------------------This is just a sketch, the structure will probably be much simpler than this (maybe in a small SQLite db).
So, again, a GAME may contain many WORLDS, each world has it's own Textures and Sounds.
A WORLD my contain many MAPS, each map has it's own rules, but borrows the (some/all) textures and sounds from it's parent world.
A MAP can contain many SECTORS, sectors can be, for example, bonus or secret areas, underground levels, etc.
When changing worlds, if some of the textures from the previous map can be reused, they won't be disposed. Only new textures will be loaded. The same goes for sound.
Last edited:
Wonder you may have a look at this one:
https://play.google.com/store/apps/details?id=com.vorun.yaya
Looks nice but yours looks better. you really should release it and let people create levels and share with the world.
https://play.google.com/store/apps/details?id=com.vorun.yaya
Looks nice but yours looks better. you really should release it and let people create levels and share with the world.
Thank you for your kind words!! It really motivates me to hear such a thing!
I just had a look at it, while the stem concept is the same (Mario Maker), I believe mine is more organic as I'm putting a lot of personal effort into it, every bit of code has been carefully written by hand.
The first release will be (if not, almost) freeware, probably something like 3 or 4 worlds, each holding 2 or 3 maps to explore. It may or not include the level designer.
I want it to be a test product, presented as a final one. This way, if it suffers severely bad reviews, I can always pull it off the store.
The current graphics aren't final, as some of them are (probably) copyrighted. Once I get into the game design stage, I'll try drawing some of the stuff myself.
So yeah, I'm writing code for it almost every day. Even when I'm working on side-project, it's usually a "beta-test" for new code to be implemented in the main project.
I gave-up saying that it will be released soon, as I have no idea when it will be possible. I still have some obstacles to climb, physics to tweak and user interface to redesign...
Contrary to my previous project, I've learned from previous mistakes, the code is object-oriented, scalable, expandable, highly readable and maintainable, so all I can say is... I'm on the right path.
Last edited:
What's new?
- Heavily working on this project, I should be able to dedicate at least 32+ hours of coding next week...
Meanwhile, I got myself an empty Patreon page:
https://www.patreon.com/preview/12ce1fcd50d3416b947da03a9dec8957
- Heavily working on this project, I should be able to dedicate at least 32+ hours of coding next week...
Meanwhile, I got myself an empty Patreon page:
https://www.patreon.com/preview/12ce1fcd50d3416b947da03a9dec8957
my 50cts : lot of work for that slow motion but perhaps not have to be displayed all the time because I feel the game play ... slowed ....
The first one made me think "WOW nice game", the second "OK really nice", the third "Well, I have already seen it", imagine after the 20th ;-)
The first one made me think "WOW nice game", the second "OK really nice", the third "Well, I have already seen it", imagine after the 20th ;-)
True, true, true...
It's just a proof of concept for now. I will eventually create a set of conditions (AI) for the engine to decide when it's "cool" to utilize slow-motion.
Big boss defeatedTrue, true, true...
It's just a proof of concept for now. I will eventually create a set of conditions (AI) for the engine to decide when it's "cool" to utilize slow-motion.
Yes, it's still alive (and kicking)!
Currently working on:
- Scripting support for interactive menus
- Better physical gamepad support (managing multiple gamepads)
Ideas to be implemented (maybe):
- JRPG style boss-battles
Stuff I don't wanna do but I really have to:
- Create the Game Design Document
- Document the in-game scripting metalanguage
- Document the slideshow subsystem
- START.DOING.SOME.LEVEL.DESIGN!
Currently working on:
- Scripting support for interactive menus
- Better physical gamepad support (managing multiple gamepads)
Ideas to be implemented (maybe):
- JRPG style boss-battles
Stuff I don't wanna do but I really have to:
- Create the Game Design Document
- Document the in-game scripting metalanguage
- Document the slideshow subsystem
- START.DOING.SOME.LEVEL.DESIGN!
Last edited:
