Tag Archive: Game Design

Last Friday we have finished our implementation for controller/gamepad support. This means that in the next big content update of Caromble!, you can choose your favourite input device out of the big three:

You can now control the paddle with gamepad, mouse or keyboard! More input devices are on their way...

We will do a beta of our first big content update next week on Steam Early Access, and if that won’t bring up any major issues, we will release shortly after. Get ready for Chapter 2, full of explosions, introducing the 1st special powerup (!), two skill levels and support for your favourite gamepad.

Controlling the paddle is the main type of interaction in the game, so this should feel as smooth as that actor in a hot spice commercial. Therefore, during the implementation of gamepad-support, we also tweaked the mouse and keyboard controls to make those better. The implementations of these three input devices are fundamentally different and I would like to use this blog post to explain these different methods and tell you how we achieved the best result for optimal control of your paddle.

In the following snippets we have a few parameters:

  • deltatimethe time between the current and the previous frame; to make the controls framerate-independent.
  • paddleSpeed: this parameter is necessary because of the way we set the paddle position in code. Each level has a left- and right-end position of the paddle. The movement of the paddle can be between these two extremes. A value [0, 1] describes the position of the paddle with 0 as the left-end and 1 as the right-end. If our input devices would work on this value directly, then the paddle speed would be depending on the distance between the two end-point. Instead, we want the speed to be described in terms of paddle-size, which is what you would expect. The value of paddleSpeed is calculated based on the distance of the end-points and the paddle-size and is thus used to make sure that we can control the paddle in terms of ‘move 0.2 * paddle-sizes to the left’, instead of ‘move 0.2 of the distance between the end-point positions of the paddle’.
  • movement: the result of the functions on the input data and is applied directly onto the paddle to map its position to [0, 1].
  • curSpeed: this variable keeps track of the speed of the paddle when using the keyboard or d-pad. We update curSpeed every frame, so it needs to be stored.

I like mouse control the mostThe mouse has the most straightforward implementation. We want the displacement of the mouse to be mapped linearly to the displacement of the paddle, resulting in its new position.  All that is applied to this displacement is a scaling factor. This gives a feeling of direct control. You have the freedom to move the paddle over large distances quickly or apply small displacements in a very precise manner. Here is the code:

float moveX = mouse.getDeltaPositionNormalized().x;
movement = (float) (-16.0 * paddleSpeed * moveX * deltatime);

Because the input for the mouse is provided in pixels, we use getDeltaPositionNormalized() to normalize for the screen size. You want to have the same behaviour in a 1280 x 720 as on a 1920 x 1280 screen. This function also applies the mouseSensitivity setting that can be set by the player.The biggest advantage of the gamepad is that you can really 'hang' on the couch with it. I love hanging...The main difference of the analog stick on a gamepad with the mouse is that it has a limited range of positions. It can be tilted to the left and to the right in a continuous matter, which will produce an input value of [-1, 1]. How can we use that to control the paddle? If we would map this value directly to the position of the paddle between its left- and right-end, the resulting speed and behaviour of the paddle would differ per level (some levels are very wide, like a platformer game; #waitforcaromblechapter3). This is not what we want, so instead of using the analog stick value to set the paddle´s position, we will use it to set the paddle´s speed. Let’s imagine moving the paddle to the right. Keeping the analog stick at 0 will result in a speed of 0. When we put it completely to the right, corresponding to a value of 1, we want a speed of, let´s say, x, which is normalized as described before (dependent on the paddle-size and not the distance between the ends).  Now we can achieve all values between [0, 1] to give the paddle the speed we want, which also gives us a lot of control. Our first idea was to map [0, 1] linearly to [0, x], but as it turned out, it feels nicer if we apply an exponential mapping. So a value of 0.5 does not map to 0.5*x, but more like something as 0.25*x. This allows to have precise control of the paddle when you move the analog stick only a little.

There are still a few more things we have to take into account. Unfortunately, if you release the analog stick, it does not return 0 as its value. Sometimes it ‘sticks’ a little, which can even result in values around 0.2 when the analog stick isn’t touched. To fix this, we introduce a deadzone. We choose a deadzone of [-0.2, 0.2], which means that all values within this range are mapped to 0. In this context we want a value of 0.2 to correspond with 0 as well, so we remap [0.2, 1] -> [0, 1] and [-1, -0.2] to [-1, 0].

Even after introducing the deadzone, we were still not satisfied with the achieved precision when we wanted to move the paddle only a little. In a brick breaker game like Caromble!, this precision is crucial, so we have added something that we call precision mode. When the right shoulder button is hold down or the right trigger is pressed over halfway, we enter precision mode. In precision mode we scale the applied speed with a value of 0.35. Here is the code:

// amplitude is in the range of [-1, 1] 
float amplitude = actionList.getAction("AnalogStickHorizontal").getValue();
// precision mode if one of the right triggers is pressed
float precisionScaler = 1f;
if (actionList.hasAction("PaddleMoveFocus") || actionList.getAction("PaddleMoveFocusAxis").getValue() > 0.5)
	precisionScaler = 0.35f;

curSpeed = Math.signum(amplitude) * Math.pow(amplitude, 2.5) * 3 * paddleSpeed * precisionScaler;
movement = (float) (curSpeed * deltatime);

The introduction of an extra key for precise control works, somewhat to our surprise, great! When you need to move the paddle over a long distance you put the analog stick in its extreme. When you are close to your desired position you hold the precision button and you can place the paddle exactly where you want. Awesome stuff.
There are so many buttons on the keyboard that are not used with Caromble!. Maybe that's reason enough to find a prpose for the 'any' key
And then we have the keyboard; a bit old fashioned, but still a favourite to some players. This is a fundamentally different input device than the mouse and the analog stick. Where with the other two you have a whole range of input values, the keyboard provides… just two. One key to move to the left and one that moves your paddle to the right. It makes sense to map these keys to a certain paddle speed, but we would like to see the paddle move smoothly. More precise, we would like the speed of the paddle to be differentiable, meaning that it doesn’t ‘skip’ values. This is a property that the mouse and analog stick implementation also possess. We can achieve that by letting the two keys correspond to an acceleration of the paddle, which is applied until a maximum speed is reached. This means that the paddle starts moving slow, but while you hold down a key, its speed increases until a set maximum. As with the analog stick, we won’t increase the speed linearly, but exponentially. This provides more control when we hold the left or right key for a short time, which I use in a way I’d like to call ‘tap-tap-super-tap‘. This puts the paddle in the exact position I desire. When I release the keyboard key, the paddle decelerates until its speed is 0.
I mentioned the differentiability of the paddle-speed, but I lied a little there. When we switch from the left key on the keyboard to the right key, we want to move the other way immediately. At this moment we do not decelerate nicely, but set the speed to 0 and accelerate in the other direction.
Also, because we liked the precision mode so much in the gamepad implementation, we use the Left Alt key on the keyboard to enter precision mode. Here is the code:

float maxSpeed = paddleSpeed;
float acc = 20 * maxSpeed;
boolean hasMoved = false;
float factor = (float) Math.pow(Math.max(0, 1 - Math.abs(curSpeed) / maxSpeed), 2);
if (actionList.isDown(paddleLeft) && !actionList.isDown(paddleRight))
      if (curSpeed < 0) 
            curSpeed = 0; 
      curSpeed += factor * acc * deltatime; 
      hasMoved = true; 

if (actionList.isDown(paddleRight) && !actionList.isDown(paddleLeft)) 
     if (curSpeed > 0)
           curSpeed = 0;
      curSpeed -= factor * acc * deltatime;
      hasMoved = true;
float focusScaler = 1f;
if (actionList.hasAction("PaddleMoveFocus") || actionList.getAction("PaddleMoveFocusAxis").getValue() < -0.5))
      focusScaler = 0.5f;

curSpeed *= focusScaler;
if (!hasMoved)
      // decelerate to 0
      curSpeed *= Math.max(0, 1 - 20 * deltatime);

movement += (float) (curSpeed * deltatime);

Of these three input devices I personally like the mouse the most. I feel that it gives me the best control of the paddle. This opinion is not purely subjective; science supports it! Humans tend to find it easier to interact with position-control than with velocity-control. Furthermore, humans like velocity-control more than acceleration-control.

I hope this has blog given you some insight in how we approach the issue of paddle control in Caromble!. We are curious what you think of our gamepad implementation and hope you find it as smooth as James Bond. We have tested our code on these three gamepads, so we hope you have one of these three 😉

The left one is so old! It was also very sticky, but we don't know why...

Besides these three described main means of control, we are also working on a fourth input method: Intel RealSense. We will address this in a future blog post, but we can’t tell you when or if we will actually support this in Caromble! . The Steam controller is on our wish list as well. Hopefully we can get our hands on one soon!

As we have already mentioned many times, we work on Caromble! only on Fridays and every spare hour in the evening and weekends. Mostly, we write these blogs about our part-time struggles of making Caromble!, but this time, I want to take a moment to talk about my other occupation. Not that of being a boyfriend, but my ‘real’ job at Motek Medical.

Motek Medical creates products for rehabilitation. They combine motion platforms, instrumented treadmills and motion capture systems with a virtual environment to provide motivating and engaging training exercises and precise assessments for rehabilitation:

I am primarily a C++ developer here, but lately I am also working on rehab applications (so called ‘serious’ or ‘health’ games) for patients, doing game design and implementation.

Making a health game is very different from making a game for entertainment. For Caromble! I make design choices using my gut feeling and my own experiences of the games I love. It has to become a game that I too could enjoy. When designing a game for a specific patient group, the approach is very different. More than in any other game, the player is the main focus in a health game and the desired outcome is different. The game should be motivating, challenging and captivating for the targeted patient, not only to entertain, but with the goal of improving her (let’s assume she is female) capabilities. A game designed for this purpose, could very well be a game that I wouldn’t like to play or look at. For me, this takes me a bit out of my comfort zone, where as a gamer I think to know which are ‘good’ game design choices and which are not; knowledge which I can use in the game design choices of e.g. Caromble!. In health games these ‘rules’ I have learned simply do not apply.

When designing a health game, the main question is: “Who is the audience?”, and to go a bit deeper, also: “What is the (clinical) goal of the health game? “, “What is the patient capable of (cognitive, physically and visually)?” In an ideal world, a health game is designed for one person, so you can make specific design choices for that person, taking into account her capabilities and interests. Unfortunately, this is often not the case. A health game has to be designed for a whole patient group, for example stroke patients. The problem is, that one stroke patient is very different from another; one can still move her arm, a second can move it only a little and third can’t move it at all. Or one has an easily overloaded cognition, while another can handle a lot of different cognitive signals easily. Besides these variations there are also the subjective preferences that patients can have about visuals, gameplay and sound. Making a game that is suited for a whole patient group is according to me, the biggest and most interesting challenge.

Before we start prototyping a new health game for a specific illness or physical/psychological problem, we sit around with therapists and patients to get to know the intended audience. With the retrieved insight we start prototyping both gameplay and visuals. We playtest the prototypes ourselves and with patients and with those new insights we often have to go back to the drawing board. It still amazes me how difficult it can be to fully let my own assumptions of a ‘good’ game go and think ‘with’ and ‘for’ the patient, about what is desired for her.

Once we have a suitable prototype for the project, we still have the challenge of making the game such that it is challenging and captivating for the whole range of patients. A scalable difficulty is one of the most important aspects to achieve this in my opinion. There are two ways to do this:

  1. Incorporate many settings that the therapist can adjust, such that the game can be tailored to the specific patient.
  2. Design the game in such a way that it uses adaptive difficulty.

I think the best solution is to use a combination of these two. Expose some settings to the therapist, but not too many or the game will be difficult/unclear to use. Also, find a way to let the game decide itself whether it should change its difficulty and if so, think of a good way to do this. Probably many games that I have played use some form of adaptive difficulty, but two examples that come to mind are FIFA Football and Mario Kart. FIFA did this in the worst way possible: after a few games I lost, the game suggested something like: “shall we set the difficulty to a more suitable level for you?” Well thank you very much EA, for pointing out that I’m a loser. Mario Kart on the other hand, gives losing players a higher probability of better powerups, improving their chances of winning. I think that these methods are not the best way to do this, but to hide this mechanic from the player, instead of what FIFA did, seems like a good choice.

Today, my colleague Coen and I went playtesting our current project Bloonies with a patient. The goal of the application is to train dual tasking: stroke patients can have difficulty with walking when executing a cognitive task. During this extra task they can slow down or even stop walking. The goal of Bloonies is to train this dual tasking. I have been reading some game design books (currently ‘A Book of Lenses’, love it!), but none of these books could give me the insight that I got from seeing this patient playing Bloonies and hearing his thoughts about it. Making health games requires a whole different kind of game design, one that I grow more fond of every day. I will share a video of Bloonies on this blog once it is finished and perhaps explain something about the way we achieved scalable difficulty in that project.

Thinking about the concept of adaptive difficulty, it makes me wonder if such a thing would be suitable for Caromble!. We are now too far in the development to incorporate such a thing, but it is an interesting thought experiment. I think that the difficulty in Caromble! is linked to two situations:

  1. Losing the ball; a higher difficulty makes the player lose the ball quicker and more often.
  2. Taking more time to complete a level; either to destroy all blocks or to solve a puzzle.

If we would incorporate an adaptive difficulty, we could influence both of these situations. Losing a ball can have multiple causes, but I think the main ones are a ball speed that is too high and blocks close to the paddle where the ball bounces off. If the player loses the ball too often or too quickly, the game could decrease the ball speed and destroy nearby blocks. A solution for a level that takes too long is to destroy some of the blocks after too much time has passed or to provide a hint system for the puzzles that offers these if too much time has passed. I think it is not smart to try and implement this into Caromble! now. These kind of features have to be incorporated early on in the development of  a game; otherwise it can introduce balancing difficulties in terms of gameplay.

Also, the process of thinking with the patient, what I am learning through experience at Motek Medical, made me think of how this approach would work on Caromble!. Who exactly is our audience? In my opinion it are retro and indie gamers and perhaps (hopefully), some casual gamers can appreciate it (read: love it to the fullest) as well. Would the game be very different if we carried out an extensive study on the preferences and desires of these gamers? I think it can be very interesting to try this approach on a future entertainment game we make: to let go of our current assumptions and learn from the potential players.

Caromble! is a game that at least we enjoy playing a lot and we can only hope that many players feel the same. Since Caromble! is the first full game we create, I believe that is enough.


Like a Boss


Most people will interpret this as Homer Simpson’s catchphrase, but that’s actually spelled as “Do’h”. For me, and perhaps most Breakout fans, the story of Arkanoid comes to mind. Arkanoid’s almost unbelievable story goes like this: Vaus is the space vessel that escaped the ill-fated mothership named Arkanoid – hence, the name of the game. That vessel acts as the game’s focal character: the paddle. After some rounds of brick breaking awesomeness the player reaches the final round where the goal is to demolish the ‘dimension-controlling fort’ which is named… “DOH”.

This illustrates that a Breakout game can have a story to add to the overall experience. In an earlier post we promised to put in boss fights. We didn’t initially plan this – in fact, we rejected boss fights earlier in the development process because we didn’t see how it would fit into Caromble! – but as art, gameplay and story developed, the boss fights seemed to find its way back onto our agenda and seemed to fit right in. Storywise the paddle is our so-called protagonist, the lead character whom the player can identify with. Opposed to that we have the boss as antagonist, the character that (literally) creates obstacles that the protagonist must overcome. Throughout all aspects of the game the idea of protagonist versus antagonist is a nice contrast to elaborate on.

Caromble! is almost gameplay complete now. The boss fight is one of the latest gameplay features that we are still experimenting with. Despite the fact that we rejected boss fights earlier in the development process we are really excited that we put this element back into the game. Finally we arrived at the point that we can proudly say “THIS is Caromble!”.

P.S. For those wondering what Arkanoid’s “DOH” means. If my Google skills are okay it’s an acronym for ‘Dominator of Hours’. I guess this knowledge will score you some nice points in your next video game themed pub quiz!

Since I was a kid, I loved to create something huge with Lego blocks and then… destroy it. Or make a huge card house with my grandfather, like 7 stories high, and then… make it collapse. I’m not unique in this. Many people seem to like destruction, witnessing  the several popular scientific television shows in which objects are blown to pieces or dropped from a crane.

I think that besides seeing things collapsing, people find it even more satisfying  to be the cause of some kind of destruction. Whenever I see a structure of domino stones, my fingers itch and I want to be the one to tip over the first stone. I think we love to be the first part in a causal chain. I’m not  sure why we love it so much, but perhaps it creates a feeling that makes us extra aware of being alive. I experience a similar feeling when travelling by bus. Whenever I need to press the stop button, I also want to see the stop sign lighting up because of MY button press; “Yeah, I did that!”. Perhaps instead of “I think therefore I am”, the statement “I cause therefore I am” suits us better.

Caromble! is in its essence a breakout game. A game in which the player moves a paddle, aims and bounces the ball, hoping to destroy some blocks. Somehow it so much more interesting if one of these blocks was supporting a big structure that is now collapsing. “Yeah, I caused that… again!”. That specific feeling, that is the added value of incorporating a physics engine into Caromble! in my opinion. The core gameplay may not always be very different from an ‘ordinary’ breakout game, but the fact that the player can be the first step in a causal chain that leads to destruction, explosions and chaos , makes the experience so much more satisfying. Here is an awesome video from OK Go that demonstrates this idea through a Rube Goldberg machine. And how satisfying does this look (we use the Java port of BulletJBullet, for our physics)?

The interesting thing of incorporating a physics engine in your game, is choosing when and how to intervene in the physics simulation. Without intervention (moving, creating or destroying objects in the simulated world) there is no gameplay. In Caromble! the single action a player can perform (besides using power-ups) is moving the paddle. With the paddle, the player can influence the most important object in our  game; the ball. The ball is a peculiar object. It takes part in the physics simulation, but it is not totally governed by it. If that would be so, friction of the floor with the ball (which both are not zero) would eventually result in a ball at rest (zero velocity). That would be quite a boring game. That is why the ball is governed by more rules than those of the physics simulation: OUR rules.

For example, each level has a desired ball speed. Whenever the ball speed deviates from it, we make sure it quickly converges to the desired one. Also, we handle all ball collisions ourselves. The collision detection is done by the physics engine, but based on the ingoing direction and the normal of the object at the collision, we determine the outgoing direction of the ball ourselves. One of the reasons we do this, is to ensure that  there is some minimum bouncing angle. Whenever the ball bounces almost horizontally between two opposite side walls, we don’t want it to take forever before  it approaches our paddle again.

Finding the balance between simulation and intervention is quite the challenge. Sometimes, mostly after heated discussions, we decide to add a new intervention rule to our physics simulation for the sake of gameplay. How far should you go with this? Well, we think that you should aim for a certain level of control for the player, such that whenever he/she loses a ball, it should have been possible to prevent this using skill. However, the simulation should add a factor of unpredictability and surprise. You know that once you hit that one block, that structure will collapse, but how exactly, that should be somewhat of a surprise. We aim to get this balance right and I think we are on the right track. As long as Caromble! will make some of you players experience the feeling that I got when tipping over a Lego structure, I am very satisfied.

Meaning of Life

Up to this point the background story has been our neglected child. She has become a wild beast. But now we are walking her back from the forest and we begin to tame her.

I hear you ask: “Why does Caromble! need a background story?”. The answer is quite simple and binary. Concerning stories there are 10 types of gamers. Those who ignore the story, just play, and find that beating the game is its own reward. And those who want an explanation for what they are doing.

But that’s game design theory speaking. The real reason is that we love stories! Every Friday we come up with tons of new game ideas, backing them up with a story as we sing their theme songs describing new fantasy worlds. Games in general are about doing stuff we can’t do in the real world.

Caromble! will be about good vs. bad alien ‘viruses’ in an earth-like environment. That leaves us with more than enough ingredients to write a wonderful background story to reward our players looking for meaning in their games and lives.

Color Coding

About time to post some concept art, that’s still waiting to see the light of the internet. Some time ago we decided on the chapters we will have in the final version. These have to look consistent with each other, but also distinguished as different themes. Add to that that the gameplay itself uses colors too (the common red explosives for example), and you have quite a complex setup to plan.

Since the gameplay also evolved organically, it dawned on me pretty late that each part should have a clear color code. Here is the setup I sketched out:

The bumpers are blue, and the borders, that the player can’t destroy are yellow for example… this might not need to be explained to the player – but tell him subconsciously what he can do in the game.

Here you can see how it works in the game so far:

The strong colors of these elements make it hard to get all the rest work well with the subtle colors I wanted. But gameplay goes first. I’m actually thinking to try black for the “indestructible” border – might be more consistent with the black outlines in the artworks, and allow yellow to be used for other parts, like highlighting important structures.

After that then I approachd an overview of the level art – with more muted colors. And specific shapes for the different chapters. For now we’re going only for the factory and the commercial area. … and now comes the hard part to get all this nearly like it into the game.

Paddle Version 2.0

After we picked the red style from the last post, it was time to come up the paddle design. Here are some possible versions.

We currently have a dummy of version K in the game. Some research also went into how paddles look and behave in other breakout games. I was really surprised to learn that most paddles nowadays don’t use proper reflection. But that makes them way more controllable. The worst problem is really when the player hits the ball and it still goes out – that feels unfair.

Concept: The Alien!

So in our push to get a new demo together we’re also adjusting some gameplay. For one we want to give the player a clear goal what to aim for in a level.

Our idea is to add an alien artifact, that crashed in each level. The player is basically the alien rescue team. Here are some ideas for how the design could look.

It has a clear contrast to the world, to be easily spottable. It also gives us an excuse to make the goodies easily spottable. Red looks nice – so we’ll run witht hat, but we might have to use more colors for different goodies.

Tinkering under the Hood

The last update is a while ago, but there has been nice progress. Most importantly the programmers have been very busy with the editor, as we planned after our Indigo-reviews. We have now a working tool to build levels without working only in abstract text files. There are bugs left to fix for sure, but new levels will pop up here soon.

On the art side there have been mostly changes to the existing assets. Lot’s of boring resizing. But it was necessary, since the whole setup in the demo didn’t quite work. The steps will be always in multiples of four – its easier, and more logical. (Interestingly – after figuring this out with lots of number crunching, I learned that four is a recurring number in “Scaling Laws In Biology And Other Complex Systems“.)

Object Resizing

Object Resizing

Some gameplay tweaks are in already and just need tweaking and extending. For example the spin idea mentioned in earlier posts.

New Gameplay mechanic: Spin ball

A new gameplay mechanic: the spin ball.

And some features we’re planning still, if we get around to it. One of them is to let the people in the game run away from the ball. Should make it a bit more livelier, relatable… and fun! Who doesn’t like chasing little scared humans with a wrecking ball?

Gameplay Crowd

Gameplay Addition: Crowd

Indigo Roundup Part 2

frontpage Ardor3D

BTW: We're featured on the Ardor3D frontpage (the engine we use).

The other week the Caromble team met up to exchange the experiences from the Indie-event and think about where to go next. So now is the perfect time now to reassess before committing to a more final direction in development: Our prototype is far enough to judge the players reactions, but still early enough to change direction if necessary. And we had a lot of input.

The main things we want to figure out now is how to move on commercially: We all agree that we would love to make some money out of it. Maybe early investments (not just after we’re done), so we can put it in the development.

We also want to try some more gameplay tweaks – we have the chance now to still test around. The main mechanic is too simple, we should at least allow more interaction for better players.

Taking aside the problems that result from presenting a prototype (missing content and features, lack of consistent quality, not much guiding of the player), here are the points we agreed on from the feedback.

    The good:

  • It is already a lot of fun, so the basic idea can stay. In my experience early prototypes are often more of a drag (because of the mentioned shortcomings) – Caromble is a positive exception.
  • It ran really stable. After some trouble setting it up, I don’t think we ever had a crash or performance problems.
  • The art style can stay. Also the decision of the scenario with the cities got really positive reactions.
  • The music worked well.
Indigo - yet another pic

Indigo - yet another picture

indigo logo.

Since that is the last roundup: A thanks goes again to the game garden for letting us show our game at thier event.

    The bad:

  • The art is too inconsistent. The idea with making it comic-style is not getting across enough. Funnily it seems I put too much work into it. All the assets I rushed for the event got the most positive feedback. I could write a whole article about the state of confusion and dilemma that puts me in – but I spare you.
  • The sounds: There was not enough variation. They were not convincing enough. But we knew it, since it was a bit rushed but still there is much work ahead for us.
  • Several things caused confusion, that we ourselves didn’t even see anymore: The pink blobs that fly to the player. We should remove them or make them useful. We have to add walls to the level, to make clear what the ball reflects from.
  • The slogan has to change – heh I liked the joking “yet another breakout” – but some people took it seriously. So we’ll have to come up with something more positive. No ideas yet.

So the plan: Fix the problems, add a deeper layer of gameplay and get the level editor going. Then we can test around more, and create a playable version with more levels. Once that all works, we can show it to publishers or even publish it as beta on the website.