millabasset/cambridge

The next open-source falling-block game engine!

cambridge's Issues

If a directory contains non-ASCII characters, it breaks saving.

This will be remedied by adding the current directory as an alternative save location.
This also will serve as a reminder to everyone that you should put Cambridge in a location that is not Program Files and that contains only ASCII characters.

Before reporting an issue, make sure you're not using LOVE 11.4!

LOVE 11.4 has proven to be exceptionally unstable with Cambridge, causing random freezes. Please check to make sure that your LOVE version is 11.3 before you submit a new issue here.

If you don't have LOVE 11.3, you can grab it here: https://github.com/love2d/love/releases/tag/11.3

Black box renders over frame.png instead of being a part of it

This means that you can't see the backdrops of custom frames.
A version of frame.png with the black box inherent has been attached. I cannot send my modified gamemode.lua due to Github's file type restrictions.

v0.3.1 progress

I'll be using this issue to track the features that I want to implement in the next beta / major version of the game. Intermediate betas may be released containing only some of these new features.

• Campaign.
• Mass bugfix of modes in main game and modpack.
• Overhaul highscore system.
• Finish more flexible BGM support. (Finished, but not uploaded to GitHub.)
• Allow mod makers to add their own next piece sounds.
• Color scheme select (for 7 piece rulesets) in the settings.

User suggested features:

• Extra unused buttons that mod makers can repurpose. (In addition, genericize the button system.)
• Add DAS to the menus, so people don't have to repeatedly tap.
• Randomizer test script.
• Separate menu bindings from in-game bindings.
• Refactor game over effect.

Anything else you want for the next version, just comment on this issue.

This post will always be edited to showcase finished features / new ones that I add later by request, but I will also comment whenever this post is changed.

Refactor gamemode / randomizer / ruleset interaction for piece sets that are not 7 in length.

The current engine requires piece sets that are not 7 in length to be labeled with numbers - you can't use your own custom labeling for these pieces. Furthermore, piece sets that are 7 in length are required to use the traditional piece names - "IJLOSTZ" - even if the pieces may not be those shapes.

The goal:

• Refactor how the default randomizer is picked if the mode's randomizer does not align with the number of pieces in the ruleset. This will allow the pieces to be labeled anything.
• Remove the clunky dependency on being required to specify a number of pieces in the randomizer and the ruleset, and make it "just work" without needing to specify that.

Change the big piece coordinate system.

Right now, big pieces emulate a 5x10 grid (halve both dimensions) instead of a 5x20 grid. The issue with changing to a 5x20 grid is that wallkick code would have to be changed to double kicks on the y-axis.

This is already accounted for in a basic sense, by halving the gravity applied to a big block. However, this still allows a big block to "climb" up a step that it has already fallen down by simply moving.

Instead, what I'm thinking of is to have the big blocks fall in half-steps, such that a block can have a half-step y-coordinate (like 2.5) - no possibility of floating point errors, as 0.5 is an exact floating point number. This principle could also be extended to the x-coordinate to allow TGM1-style "death block."

Bug: Cambridge locks up on macOS

Cambridge just locked up twice on me while playing a game of Survival A2. Both times it happened within two minutes. I get the "spinning beach ball", the game state freezes, and the only remedy is to force-quit love2d.

I am on macOS 12.1.

Is there a way to log debug output? If so, I would be happy to provide it as this issue seems reproducible.

Starting on Mac

> brew install love
> love --version
LOVE 11.3 (Mysterious Mysteries)
> git clone https://github.com/MillaBasset/cambridge
Cloning into 'cambridge'...
> cd cambridge 
> love .

Gets me into a key configurator, and it's not obvious how to get out of that into the game.

screen at https://www.tbray.org/tmp/love.jpg

smooth piece drop not off

with smooth piece drop set to off in settings
pieces still drop smoothly using Ti-ARS ruleset and HOLD in survival_a3

Discord functionality doesn't work on 32-bit Windows

Currently, the Discord RPC DLL in the repository is 64-bit, so that won't work on 32-bit Windows. Discord does support 32-bit Windows currently (I even checked what sort of app Discord really is, it's actually 32-bit). So we have to add a 32-bit DLL for 32-bit Windows, then package that with 32-bit releases. We could keep the existing 64-bit DLL as-is though, since there isn't a way to detect whether LOVE is running on 32-bit or 64-bit, and just assume when the game is run from a cloned copy of the repo it's on 64-bit.

Alternatively, we can just drop 32-bit support.

manual lock is not implemented correctly for ARS

i noticed this by trying your clone for the carnival of death. Classic ARS and Ti ARS isn't implemented correctly.

if down direction is manual lock, Cambridge only lock the piece at the first frame you press down. In TAP and Ti, if you hold down during ARE, it will allow you to make "instant spawn lock". Furthermore, you must release down direction to be able to manual lock again, preventing multiple unintended instant spawn lock.

If this behavior is the one expected by cambridge, you can just close this issue :).

Cambridge Development Progress Thread

This thread will be used as a place to track new features in development as well as allow players to suggest features they want to see in the game.

Next milestone: v0.4

Current to-dos:

• Highscore system overhaul.
• Tie the highscore system into the replay system (to make replays more informative.)
• Mode/ruleset folder support.
• Fix issue #41 by separating menu keybinds from game keybinds.
• Check the modes in the main game and modpack for gameplay / UI bugs.

User suggested features:

• Add extra buttons that mod makers can repurpose. (Additionally, genericize the button system.)

Create a "partial piece" class, for use in next queues.

The current structure of the next queue stores only basic information about a piece: the shape, skin, and orientation. This is sufficient for most contexts, but for some wackier mode ideas it might be more useful to have a class that stores most of the information about a piece, except information that would only be useful for an active piece, such as position, gravity, etc. This "partial piece" would then be passed as an initializer to the full, active piece when it is time for it to spawn. This would allow things like piece offsets etc. to be changed in the next queue, among other things.

Suggestion: Optionally disable status bar during gameplay

The status bar in the top left of the game window seems incredibly distracting. Probably I would start to subconsciously ignore it by playing more. However, would it be possible to move it to the top right, perhaps aligned with the section times column? This would keep that information out of sight, therefore avoiding this issue for new players, and possibly veterans, too?

Allow both keyboard and joystick input at the same time

After #8, we now have joystick support, but you'd have to reconfigure input every time you wanted to switch between keyboard and joystick.

Can we have support for both at the same time?

Input is broken

Firstly, to investigate the bugs with input, be sure to delete your existing configuration. An existing one from a previous, working version might work fine, so you need to start fresh from no configuration.

If there is overlap of game and menu controls, those controls don't work in-game, but do work in the menu. So, currently, you must map all menu inputs separately from game inputs, or game inputs won't work. Also, it appears inputs "accumulate" if you reconfigure (not sure if that's intended, because it would allow configuring both keyboard and joystick). This might be "acceptable" on keyboard, but isn't on game controllers, especially those with only a dpad and no other directional inputs, where you're effectively required to have both game and menu directions on the only dpad.

This is a personal preference, but I don't like having to have menu decide/back on entirely separate inputs from game inputs, I want to be able to have decide/back on rotation inputs, emulating the setup typical on game systems. But keeping them separate is good, as it allows users to set "Xbox" or "Nintendo" layout decide/back. Allowing that would require a new input, one specifically for exiting a game, so menu decide/back do nothing in-game, or alternatively having menu-back only exit a game while paused. But menu-back should exit the game at the game over screen, with no need to pause first.

And, if the input accumulation is desired behavior, there must be a way to fully reset all input configuration in-game in a guaranteed, unremappable way (say, a function key brings up a "reset input" confirmation screen), and guards against reconfiguring previously set device inputs (if the user accidentally mapped menu-decide and menu-back to the same key in separate configurations, they're screwed).

Replay saving is a potential CPU hog and replay file names are not representative.

As with current replay saving system, it's hard to understand what exactly the replay is, just looking at a file name, and also, it has a big O notation of O(n²). (N being the amount of any files in replays folder)
e.g. having 1000 files will lead to 1 million concatenations and comparisons.
Old and potentially slow code:

local replay_files = love.filesystem.getDirectoryItems("replays")
-- Select replay filename that doesn't collide with an existing one
local replay_number = 0
local collision = true
while collision do
	collision = false
	replay_number = replay_number + 1
	for key, file in pairs(replay_files) do
		if file == replay_number..".crp" then
			collision = true
			break
		end
	end
end
love.filesystem.write("replays/"..replay_number..".crp", binser.serialize(replay))

New and optimized code:

local init_name = string.format("replays/%s.crp", os.date("%Y-%m-%d_%H-%M-%S"))
local replay_name = init_name
local replay_number = 0
--This will get stopped when there's no file with the same name.
while true do
	if love.filesystem.getInfo(replay_name, "file") then
		replay_number = replay_number + 1
		replay_name = string.format("%s (%d)", init_name, replay_number)
	else
		break
	end
end
love.filesystem.write(replay_name, binser.serialize(replay))

Optionally you can use this for even more file name clarity
string.format("replays/%s - %s - %s.crp", self.name, self.ruleset.name, os.date("%Y-%m-%d_%H-%M-%S"))
instead of just a date
string.format("replays/%s.crp", os.date("%Y-%m-%d_%H-%M-%S"))

Bug: Piece visibility dependent on background image

I noticed that sometimes the next piece is hard to distinguish if it blends into the background. This is particularly obvious with the T-piece in ARS and the standard background of the 5xx section, but there are probably other combinations where this issue appears. Could you perhaps display the next piece on a black rectangle, similar to how TAP does it?

Cambridge Crashes just as I start playing in PAIRS rule

Error

tetris/modes/gamemode.lua:517: attempt to index a nil value

Traceback

tetris/modes/gamemode.lua:517: in function 'drawNextQueue'
scene/game.lua:59: in function 'render'
main.lua:121: in function 'draw'
[C]: in function 'xpcall'

Widescreen and HD Resolution Support

A simple request. One of the biggest problems with NullpoMino was the resolution being 640x480.
I'd love to see support for 16:9 resolutions. The graphics don't need to be amazing or anything.
I think full-screen would benefit from this as well.

I would recommend the base resolution for 16:9 be set to 640x360 so that it can integer scale to 720p, 1080p, 1440p, and 2160p.

Find better, copyright-compliant backgrounds/music

Eventually we want to get to a state where all assets in the latest snapshot of the Cambridge repository are ones we are legally allowed/licensed to use. (If anyone ever raises a DMCA stink about the fact that the files are still around in the Git commit history, we can then cut the tree off at that revision and then leave them to deal with all the straggling forks.)

Also, some of the backgrounds are just plain ugly and I want to replace them anyway.

Double mapping does not work as intended.

When a player tries to bind the same button to two different keys, it will silently unbind the first keybind that the button was originally bound to.

Planning to fix by explicitly disallowing double maps.

Buffer lock inputs do not work as expected.

As pointed out by members of The Absolute PLUS Discord server, buffer lock inputs locks a piece if down is pressed AT ANY POINT during ARE. The correct behavior is to simply lift safelock when down has been RELEASED, and not handle any special cases. This is a simple fix, but I need to put this here to remember to fix it.

survival_a3 missing levelstop chime

as is customary in tgm3 shirase, texmaster sudden ti, shiromino g3_terror

this is potentially not an issue

Can't bind sticks nor L2/R2

Controller: DualShock 4

It's impossible to bind L2/R2 or stick directions. For example, when you press L2/R2 one time, all keys, or a big part of them (depending on how much time you press the button), get binded:

Migrate the random generator from Lua's to Love2D's.

Title should be self-explanatory. This would entail changing all math.random calls to love.math.random calls, but no extra steps would need to occur, making this migration easy. The reason I'm doing this is because math.random does not support retrieving the seed, making replays impossible. As a bonus, love.math.random does not need to be seeded upon starting the game, as it comes pre-seeded, although this is a negligible detail.