Skip to main content

On Sale: GamesAssetsToolsTabletopComics
Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines
(+1)

Interesting idea. I like the idea of changing winning conditions each level, adds a lot of depth and versatility. The art is good, the music gets repetitive quite fast. The puzzles have are a nice challenge. It might have been easier in 3D to see the dices other faces without having to press space, but this way works as well. Good job.

Well, recording music is a lot tougher than generating it with software, since you have to create and remember the song, and make sure to play it perfectly on tempo to make sure it loops well. In my local build, the song looped better into itself, which is weird.

 I do agree with the repetitiveness, and I would surely like to put more time into these game jam songs to either have a more interesting underlying melody, or create a 8-bar variation to chain.

I'd like to experiment with 3d games, since they can give out more information with perspective, but limiting myself to a HTML canvas and not using any APIs or engine does limit the possibilities a lot. It makes for a challenging jam though! 

Thanks for the criticism!

I didn't see it was a js game, certainly makes 3D harder that way. And i could see how recording music might take longer than generating it, but i guess that way you can get more feeling into it. The repetitiveness of the song is nothing uncommon for jam games, especially in songs with a strong melody.
Anyways, good job for finishing the jam with additional limitations to make it more challenging, lol. Was this by intention or because you don't have practice with other tools?

Honestly it's a bit of both. I have yet to learn Unity, which I plan to learn through my classes over the next year. Right now, I find it kinda overwhelming.

On my previous jams, I used Pixi.js, which is a 2d graphics rendering API, but it wasn't really suited to make a tile-based game. For this jam I decided to experiment with the HTML canvas, which had a lot of limitations and wasn't great to work with, but was sufficient to make a tile-based game.

For the moment, I prefer to make games without an engine since programming is definitely my favorite part of gamedev, and doing it that way allows for everything to be at the same place. I know C# and made multiple SFML or console games in the past, but I am not too familiar with making a downloadable build and I thought it would be simpler to have a html game you can imbed in the page

(+1)

Thats fair. As a software developer, programming is the part i enjoy most, after planning and designing the systems of course. My first game was in school in c++ with a very simple drawing library. Was fun as well, and definitely learned a lot about solving challenges i wouldn't have had in an engine. 

But once it comes to bigger games or more complex concepts its easier to rely on Unity (or any other engine) to do the heavy lifting of matrix manipulation, rendering, collisions and other performance critical functions, so the developer can focus on the systems that make the game what it is. There can still lots of programming involved, as much as you want, but it's easier to direct it at the challenges of your game. 

But in the end, everyone can make games the way they want and it's quite cool to see so many approaches to how people make games. There is no right way (tho some might be easier to walk lol)