jakubg1 / opensmce Goto Github PK
View Code? Open in Web Editor NEWGame engine which allows creating a broad range of marble popper games.
License: MIT License
Game engine which allows creating a broad range of marble popper games.
License: MIT License
Seeing the Speed Shot beam gives me these ideas:
Option 1 is to have it always be extended
Option 2 is to have it abruptly cut (like in vanilla 1/AR).
Option 3 is to have it be squished depending on how close the nearest sphere is (Zuma/Luxor 2).
This would be primarily used for sound positioning to make sounds more pleasant.
Should be self-explainable.
Any game could have a set of Lua scripts that would be assigned per game instead of per engine. This could enable extra flexibility for value configuration.
Example:
Take this from <game>/config.json
:
"sphereBehaviour":{
"collisionSpeed":-200
}
Instead, this could be an equivalent function in, let's say, <game>/scripts/sphereBehaviour.lua
:
function collisionSpeed(comboLv, chainLv)
return comboLv * -200
end
UI could be scripted in a similar way. However, this would need to have the game event system reevaluated and most of UI system functions should be provided in order to make game UI script files as simple as possible.
This would also allow to configure some tough formulas that are hard to be represented in JSON, such as functions whether a given match should spawn a coin or a powerup.
This feature will be implemented late, probably during the process of writing an engine documentation or even later.
Maybe there could be a json file (with some code in the program that makes it work) that determines/grabs:
Having certain levels (or whole game) to have a permanent speed shot is a thing under consideration. It will be nice to have it at some point.
Instead of just an amount of destroyed spheres, some other types can be used too, i.e. score.
Comment from @xregexx on SM Discord server:
also, time elapsed, gems collected, spheres/vises spawned, appropriate-colored spheres destroyed. and something more specific like "make X combo/chain T times", "destroy X spheres at once with this particular powerup T times", "keep the spheres enough far from danger zone for enough long time" and so on
also, winConditions stacking
This affects ResourceManager, WidgetManager, EventManager, ColorManager and RuntimeManager.
Sphere colors are hardcoded right now. The preferred indexing is as follows:
A given sphere should have at least the following parameters:
Additionally, when implementing remember to look at the sphere counting algorithm (Session.lua:46, Session.lua:82).
In short, such class would be a graphical representation of a Sphere and should include such features as idle particle or shadow.
It should be used by SphereGroup, Sphere, ShotSphere and Shooter.
This would simplify drawing code and remove all inconsistencies.
It is reported that it happens on speeds 900 and higher.
Each map would contain objects, previously defined by the user. The objects can be common (like the OG pyramid or sphere reflectors) or be special to just one map. Each object would be then placed on a position, and could be given a path to move on.
Objects could also interact with shot spheres, for example applying a gravity field, bouncing it, changing a color or destroying it.
New objects could be spawned and existing could be deleted. Objects may spawn more objects, particles or powerups on certain circumstances.
Sphere modifiers would alter newly spawned spheres.
Example in level file:
-> Replace this:
"colors": [1,2,3,4],
"colorStreak": 0.5333333333333333
-> to this:
"sphere_generation": {
"colors": [1, 2, 3, 4],
"color_streak": 0.5333333333333333,
"modifiers": [
{
"modifier": "stone",
"chance": 0.05
},
{
"modifier": "double",
"chance": 0.15
}
]
}
The modifiers
field can be omitted if no modifiers are provided.
The modifiers would be stored in config/sphere_modifiers/<name>.json
files, similarly to powerup generators.
Example modifier data:
config/sphere_modifiers/stone.json
:
{
"replace_with": [
{
"color": -5
}
]
}
config/sphere_modifiers/double.json
:
{
"replace_with": [
{
"color": 11,
"conditions": [
{
"condition": "color",
"color": 1
}
]
},
{
"color": 12,
"conditions": [
{
"condition": "color",
"color": 2
}
]
},
[...]
]
}
Description:
chance
chance to have a given modifier applied. One sphere can get modified multiple times.replace_with
. It contains a list of items - each item can have conditions. When an item is chosen, the iteration stops and the effect is applied. Currently the only effect is a color change, but the format may change in the future.When the pyramid is breached and the level is failed, sometimes the shooter still works. That shouldn't be the case.
Much like spheres generated on the board, each level should also have its shooter generator. Generators may change during the level if for example the danger flag is active.
Example types of generators:
For a puzzle level, there would be a sequence generator as well as a sphere limit for shooters.
Generators should have parameters.
Allow to create, based on some criteria such as position or color, an instance of a class that would contain a list of spheres with which you can do varius stuff, such as change their color or destroy them.
This would be useful for most powerups which mess with spheres. Currently, all that stuff is in Session.lua which isn't the best place to store all these functions.
When a sound that loops is playing and a player quits to main menu, the sound can still be heard.
The current config.json file is a huge 37 KB file which is still growing. Soon, it might be hard to make any changes, and although, there is an editor planned, it's still a pretty long way until we actually start making it. Until then, it would be nice to split all these different tables to different files, in order to maintain readability.
When multiple looping sound events of the same file are active and one of it is stopped, all instances are stopped.
The solution is to make the sound play function return a handler and use it to stop that particular instance.
This does not require taking an action in most cases, but this would be visible in tight spaces.
Because of how the current angle determination algorithm works, the spheres are "looking" at the warp destination when before a warp node and at the warp node when past the warp destination.
If you shot a sphere onto any sphere train already on the board, and pause and exit the game right after the shot sphere hits the train, you would crash the game upon trying to load a level state in such a way.
In ShotSphere.lua
, in serialize()
function, you can find this piece of code:
hitSphere = {
pathID = 1,
chainID = 2,
groupID = 1,
sphereID = 8
}, -- TODO: add an indexation function in Sphere.lua to resolve this problem
This is a placeholder, and should certainly not be there. Replacing this with a proper working indexation code should resolve this issue.
Instead of map sprites having a background
flag, and path nodes having a hidden
flag, there could be layers starting at 1, which would tell in which order spheres and map sprites should be rendered.
Example for current games:
background
set to true would fall to layer 1.hidden
flag set, because...background
flag set to false). This includes pyramids and path masks.hidden
flag set to false).Implications:
Similarly to spheres, powerups should also be defined.
A given powerup entry should hold the following:
The entry index should be an internal powerup name, like it occurs in main.lua header.
Example effects:
An almost full list of what the engine needs to do in order to consider Luxor 1 support fully finished:
When a Collectible is on the board and the player exits to main menu and reenters the game, the Collectible particles are still there and will not despawn.
The default main module file states that:
-- This is a default module file for OpenSMCE games.
-- You can override any, or all of the methods below.
However, this is only partially true. You can't make a module which replaces only one of the functions, you have to make a module which replaces all of the functions. This is because the default functions are ignored at all when anything is found in the game module.
Solution: Always load the default module first and then replace them with functions from the game module.
Ditch a list of levels, move their data to levels itself (name and music), and instead make a new data structure in level data. For example, it would contain:
Also, levels could be assigned their widget IDs so they would provide user interaction.
If possible, integrate the engine with Discord, for it to say
<Game Name>
<Level xx-xx>
Possibly add also life count, progress or score.
[Suggested by Ignatius]
Most notably add WidgetManager and EventManager.
This is to maintain the convention.
Since commit 7dd7857 there is now a more optimized version of the sphere drawing routine. I want to optimize it further.
image
field of each sphere definition object in config.json
)Map.lua
)Difficulties are stored in runtime.json
in a particular game's main directory, however they are not used.
Change the type from integer to string.
Difficulties alter some values. Consider implementing them similarly to Luxor 2's system. Example from difficulty.gvf (one of the difficulties):
{
Directory = "adventure"
StartStage = 1
FinalStage = 14
StartingLives = 4
CoinsForLife = 30
MinCollapseCount = 3
SpeedScale = 0.50
StageStepSpeedScale = 0.019
ScoreScale = 1.0
Timescale = 1.0
TimescaleWarmup = 1.5
LivesBonus = 50000i64
PerfectBonus = 10000i64
Downgrade
{
LossDelay = 1
Reductions = 5
MidSpeed = -5.0
MinSpeed = -0.2
SpawnStreak = 20
}
}
If one implements such values like here (preferably in the main game config file), there's no need to do it separately in that case.
When one exits the game during the level progress. This applies to:
Additionally:
For now two things. Disable RPC, and add an option to go back to the boot screen when you exit a Game.
Things that will be needed to make it work:
curl https://api.github.com/repos/jakubg1/OpenSMCE/tags
executed in Command Prompt will result in a list of versions being displayed.name
field in order to obtain the latest released version.The functionality is not there in Beta 2.0.1, however the button is. This should be fixed as quickly as possible in order not to mislead the people.
A powerup generator would be a JSON file containing spawnable powerups and corresponding chances and spawn conditions.
config.json
vanilla_generator.json
{
"entries":[
{"type":"powerup","name":"wild","weight":1000},
{"type":"powerup","name":"fireball","weight":500},
{"type":"powerup","name":"lightning","weight":500},
{"type":"powerup","name":"stop","weight":1000},
{"type":"powerup","name":"slow","weight":1000},
{"type":"powerup","name":"reverse","weight":1000},
{"type":"powerup","name":"speedshot","weight":1000},
{"type":"powerup_generator","generator":"vanilla_generator_colorbomb.json","weight":500}
],
"fallback":[
{"type":"powerup_generator","generator":"vanilla_gem.json"}
]
}
vanilla_generator_colorbomb.json
{
"entries":[
{"type":"powerup","name":"colorbomb_1","conditions":[{"type":"color_present","color":1}]},
{"type":"powerup","name":"colorbomb_2","conditions":[{"type":"color_present","color":2}]},
{"type":"powerup","name":"colorbomb_3","conditions":[{"type":"color_present","color":3}]},
{"type":"powerup","name":"colorbomb_4","conditions":[{"type":"color_present","color":4}]},
{"type":"powerup","name":"colorbomb_5","conditions":[{"type":"color_present","color":5}]},
{"type":"powerup","name":"colorbomb_6","conditions":[{"type":"color_present","color":6}]},
{"type":"powerup","name":"colorbomb_7","conditions":[{"type":"color_present","color":7}]}
]
}
First, upon generator data usage, all powerups that do not meet the conditions (if specified) should be removed from the list. Then, from the remaining entries, pick one. When no entries are left, use fallback generator if specified. Else, don't spawn anything.
weight
is omitted, it defaults to 1
.conditions
are omitted, no checks are performed.color_present
- check if a given color
exists on the board.level_number
- check if the current level is a number that equals/is in range of number
.Take a look at the code and rename the variables accordingly.
Classes known to have their settings named settings
:
Classes known to have their settings named config
:
TL;DR: Rename settings
to config
in Shooter.lua and Scorpion.lua.
If a sphere is shot before the first sphere in a chain, the chain moves a seemingly random number of pixels (forward or backward). This should not occur.
Tested with newly spawned chains in vertical arrangement. Does not happen in some cases.
I need to change it soon.
Replace them temporarily with hardcoded values, and think how should management look in the future.
Right now, the UI is actually scriptable but it's a made-up custom script syntax. Because there is already some Lua module stuff going on, I think it's time to make UI scriptable also via Lua. This has actually quite a few benefits:
This has of course a disadvantage - Lua knowledge would be slightly more mandatory for altering such code. This is especially important if one would want to create a custom UI for their game.
Furthermore, I don't plan any direct Lua scripting support in an upcoming game editor yet.
I don't exactly know how to replicate this bug, but I had a somewhat incomplete data folder so I re-extracted Luxor 1's mjz files. (later on I realized that QuickBMS somehow did not extract the main files, which is a non-OpenSMCE problem).
They turned out mostly the same, but re-doing the conversion process caused the program to not extract all the files.
img: https://cdn.discordapp.com/attachments/455322611178668032/735763257935003690/unknown.png
In case of a crash, you have still a chance to save your progress (this doesn't work yet, see #20). However, when an engine is stuck in an infinite loop, or there is a power outage, you can do nothing.
An autosave with a configurable delay would be a nice touch that could save some hassle.
This includes for now:
This is for naming consistency sake.
Boot screen pulls incorrect constant global version value, showing 1.0.0 even in beta 1.0.1. Easy fix by changing main.lua.
When one loses a level and exits the game before the Foul message pops up, the game can be loaded and played normally. This makes people be able to cheat, which shouldn't be the case.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.