next »

[seu]

Hi all,

 I started toying around with a concept while I wait for the launch of my current game, and came up with something that might be interesting, but I wanted to hear some feedback.



 'Demondrian' (working title) is a match-1 logic abstract puzzle game where levels are solved by aggregating smaller pieces into bigger ones, until only one is left. Imagine bejewelled with an abstract theme and rules its turned on its head.

 You play by removing tiles with no matching neighbors (with same color or size). After removed, tiles above fall to fill the empty spaces and a new one appears on top. When 2x2 tiles of matching color and size form a square, they are replaced by a bigger one, until only one big tile covering the whole board is left.

 Demondrian is currently in concept stage, but there is already a working prototype for the basic mechanic, as you can see in the video. I'm interested in hearing feedback about the core concept while I work on secondary mechanics to make it more interesting.

 The art style (and name) are inspired by Piet Mondrian's most iconic paintings.

 Current prototype gameplay video:



 Screenshots (cannot see them in the preview, but they should be there...):


http://perroelectrico.com/demondrian/demondrian_proto_20160118_1.png

http://perroelectrico.com/demondrian/demondrian_proto_20160118_2.png

http://perroelectrico.com/demondrian/demondrian_proto_20160118_3.png

PS: I read somewhere about the 'workshop' subforum for posting concept or ideas, but could not find it. Sorry if this should go somewhere else.

[voltaicore]

If you need an audio engineer or audio producer be sure to message me so we can work something out for Demondrian

[seu]

If you need an audio engineer or audio producer be sure to message me so we can work something out for Demondrian

Hey, thanks! Right now, I'm at the point where I need to figure out gameplay mechanics and will probably just use some beeps and boops from Flip for a while.

[Zorg]

I like the idea, it looks interesting!

Random impressions:
- You could spawn more white blocks to match Mondrian's art.
- I'm missing blue - some special block?
- Rectangles would be cool. But maybe it would be too complicated?
- Please delete the white outlines. Mondrian's lines are black.
- Add an indicator for the next block. An outline or an arrow for example.
- In screenshot 2, what would happen if the black block was white? Two big white blocks?
- In the video at 0:27, why are the two adjacent black blocks shaking? I think i understood why the big yellow block was shaking if you click the red block. Those situations are the same, aren't they?
- You should show the four block pieces at the final position before merging them to one big block.
- Are you, as the developer, able to solve every painting?
- Isn't it a match-4?

I'd like to play the prototype.

[seu]

Thanks for the comments! I'll answer below.

I like the idea, it looks interesting!

Random impressions:
- You could spawn more white blocks to match Mondrian's art.
- I'm missing blue - some special block?
- Rectangles would be cool. But maybe it would be too complicated?
- Please delete the white outlines. Mondrian's lines are black.
- Add an indicator for the next block. An outline or an arrow for example.
- In screenshot 2, what would happen if the black block was white? Two big white blocks?
- In the video at 0:27, why are the two adjacent black blocks shaking? I think i understood why the big yellow block was shaking if you click the red block. Those situations are the same, aren't they?
- You should show the four block pieces at the final position before merging them to one big block.
- Are you, as the developer, able to solve every painting?
- Isn't it a match-4?

I'd like to play the prototype.

- I would say it's inspired by Mondrian, but will not necessarily look all the time like his compositions. That would for example prevent me from using a different number of colors (which is a way to regulate difficulty).

- Rectangles: maybe, but I want to keep for now the 2x2 matching in place as the main board 'complexity reduction' technique.

- The next blocks incoming are the ones on the top, is that what you mean?

- In screenshot 2: no, it would just be 2 1x1 whites. But then you remove the big white, the two on top fall and match the two in the bottom, becoming a big white.

- Blocks shaking indicate the current obstruction for the move. The possible obstructions are those that would not allow a proper falling into place of new pieces, like:
-- a bigger block on top
-- a block that is not correctly aligned with the one you chose (this happens only with 2x2 and bigger blocks). Imagining if you turn to the right screenshot 2, you cannot remove the yellow 2x2 because the white is not aligned.
 or when you have others of the same color as neighbors. But... pieces that are not really aligned (again, with 2x2 and bigger) don't count as neighbors, as it would make playing impossible.
 So yes: they shake because they are the obstruction for your move. I thought that showing it in that way (and adding some sound) might make it clear why you cannot make a move in particular.

- Not sure what you mean with the four block pieces. Is it about showing then after they fall and match, and then animating their disappearance and appearance of the big? If so, yes, I still need to implement that, but it's right now tricky because of how I implemented some things.

- If I pay enough attention, I'm able to solve most puzzles, but I'll not know for sure if all are solvable until I implement a solver program that checks them.

- match-4: yes, you could say so. In a match-3 game, you remove 3 pieces at a time, whereas here you remove only 1, therefore my classification. But maybe you are right and it might make the concept easier to explain as a match-4. I'll think about that.

[Zorg]

- The next blocks incoming are the ones on the top, is that what you mean?

I meant you should additionally highlight the first block in the row of these blocks, imo.

- [...] or when you have others of the same color as neighbors

That's the point. The rule was not clear to me, that it's impossible to remove blocks with corresponding neighbors. It was obvious that shaking means that the move is not possible.

- Not sure what you mean with the four block pieces.

I mean the small blocks should fall and merge afterwards, not be falling and merging at the same time. I guess we are talking about the same and you just have not implemented it, yet. Sorry for my bad english.

[seu]

- Not sure what you mean with the four block pieces.

I mean the small blocks should fall and merge afterwards, not be falling and merging at the same time. I guess we are talking about the same and you just have not implemented it, yet. Sorry for my bad english.

You probably mean this:





(just implemented!)

I changed it so that now every independent action (remove a piece, make others fall, add a new, compact, compact again, etc.) happens one after the other. Of course you cannot see all that in the short video, but it's there.

[seu]

I've just uploaded the current prototype / demo:

http://perroelectrico.com/demondrian/demo/

The undo does not work properly yet, and reset will turn the board into a new random state (not reset to the current puzzle starting state).

I'm interested in your opinions!

[seu]

Some concept work for the game UI...

I don't want to make to totally *based* on Mondrian's (or De Stijl) style, just inspired, but the temptation to divide the screen and interface like that is too strong. Anyway, just a first rough concept.

I also changed a bit the look of the board.

[Zorg]

Nice! Did not have the time to test it, yet. I'll play it later this evening or (more likely) tomorrow.

[seu]

Programming until late last night, I implemented a very primitive editor.





This should also show how the pieces 'compact' on different levels from smaller to bigger, one after the other.

I wonder if I release the editor, and allow players to share their boards, how long will it be until someone draws a penis...

[seu]

It uses a very rudimentary DFS search, so it's sloooow.
I need to implement a handful of heuristics to cut down search time...





I'm considering implementing also a different approach, where I start from the final stage and work back to an initial one, which would make for a generator instead of a solver. I'll write more details as I improve it.

[seu]

I'm considering splitting the game into two main modes, one abstract/deterministic (the current one), and a more fun/mainstream oriented 'arcade' mode, somehow targeting the typical Bejeweled public.

For the second mode, one of the mechanics that I want to implement is a "match-all". These pieces should come semi-randomly and match any other neighboring piece with the same size. They are on one hand useful for compacting, but annoying because the cannot be (easily) removed and block also neighboring ones.





One thing I have to consider is what happens after they are compacted. In this video, it "grows" so now it's again a bigger match-all. But they could just disappear as well. I guess it will take a long time to figure out which one is better.





This video shows both mechanics, but in this case, when the compacting is done, the bigger piece is red and not a 'match-all' (the other option I mentioned).

[Zorg]

Hey, i finally found some time to play it. I'm sorry it took so long.

I like the game! It seems pretty complete in the prototype already. The match all/none looks like a nice addition (i prefer the match all --> matched color principle in the last video). I would definitely use blue for one of these blocks. Blue for match all and maybe gray for match none?

You could simply add two checkboxes, if the player wants these blocks or prefers to play the basic version.

What else do you want to add to the game? Mechanically it does not need more, in my eyes.

Edit: I just visited you website (the logo is awesome). You should totally add some kind of overview for your games to the blog (Flip, Demondrian, Tune).

Edit2: At one point i arrived at this situation.

A move will always be possible but always useless. It would be good to detect those automatically somehow and end the game.

[seu]

Hey, i finally found some time to play it. I'm sorry it took so long.

I like the game! It seems pretty complete in the prototype already. The match all/none looks like a nice addition (i prefer the match all --> matched color principle in the last video). I would definitely use blue for one of these blocks. Blue for match all and maybe gray for match none?

I actually wanted to make some fancy shaders that alternate between colors, but I'm leaving those details for later. Now I want to focus more on gameplay.

You could simply add two checkboxes, if the player wants these blocks or prefers to play the basic version.

What else do you want to add to the game? Mechanically it does not need more, in my eyes.

Even though the basic features are there, they might need to change when I start doing puzzle and progression design. One thing is showing ransom puzzles in a prototype, but when you later try to make coherent progression to engage players as a full game, things can start falling apart.

I will add some bars between pieces that prevent them from falling, and I have in mind a couple different ways they might work. For example, they could prevent pieces falling in one direction but not in other. They might be removed by compacting others around them, or fall in one direction but not in the other... there are lots of ways to implement something like that.

Another (half implemented) feature is that instead of bringing a new piece type with each move, the removed one is sent to the top. Of course it will be impossible to reach only one piece in the end, but it could contain 4 different colors and always 1/4 of the pieces are of each color.

For the more "arcade" mode UNDO will be disabled, new pieces will be random, and the match-all, none and bars (and other things) should appear depending on some kind of internal counter. For example, if you compact more than one block in a move you gain points that accumulate to make one of those appear. If you make a lot of moves without compacting, the bars might appear (as a kind of punishment). And so on.
But also that would require careful dropping of new types if I want to prevent locking the player. All this will require a lot of fine tuning.

And then... again, puzzle design and progression: players should be introduced to features slowly, so there should be a track of specially crafted puzzles where I practically force you into solving them in one way so you learn some trick. This is something I could not do in Flip because the mechanic did not lend itself to that (so I added a tutorial) but it should be that with this game.

Edit: I just visited you website (the logo is awesome). You should totally add some kind of overview for your games to the blog (Flip, Demondrian, Tune).

Edit2: At one point i arrived at this situation.
A move will always be possible but always useless. It would be good to detect those automatically somehow and end the game.

Those are hard to detect, because I need to lookup several moves ahead, or attempt to solve the board after every move, which is too costly in processor time. But having an UNDO button means that you will not be blocked, just will not solve each puzzle optimally maybe.

[seu]

I've been dealing with a lot of internal stuff in Demondrian, so between that and press & bugfixing for Flip I had almost nothing to show in the past weeks. I had to re-implement how the state is shared between the internal board representation and the objects on screen, and it turned not to be that easy.

But I made this prototype of an intro animation (with the logo for Perro Electrico) using the same animation or appearing pieces in Demondrian, and adding some sound.





Which makes me wonder how would it work to have a level based on a bitmap. Have to think about the possibilities.
(which is not the same as a "highly pixelated" version of an image turned into a puzzle, something I'm going to implement soon)

[bluilisht]

cant play the demo somehow, stuck at 100%

anyway, have you play clickr? Kinda different, but you can try it to get some inspirations maybe.
Here is the demo http://clickr.kr/flash/ but you might want to try the full version with additional mechanic http://store.steampowered.com/app/45500/ 

[seu]

cant play the demo somehow, stuck at 100%

anyway, have you play clickr? Kinda different, but you can try it to get some inspirations maybe.
Here is the demo http://clickr.kr/flash/ but you might want to try the full version with additional mechanic http://store.steampowered.com/app/45500/ 

Yeah, for some people the demo does not work. I cannot manage to get consistent results from the Unity WebGL player, I don't know how some people manage to publish way more complex stuff with it.

I did not know this clickr, but I see why you find the similarities.

[Cranktrain]

This looks really great, I love the Mondrian style of the game, it looks really clean.

[seu]

This looks really great, I love the Mondrian style of the game, it looks really clean.

Thanks! Unfortunately I had almost no time to work on it lately, but I hope to have something new (and prettier!) to show soon.