Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

324 Neutral

About j-jorge

  • Rank

Personal Information

  • Role
  • Interests
  1. On the 6th of January, 2014, I joined IsCool Entertainment as a game developer on the recently released mobile game named Bazoo. It was a long time ago and the project went through a lot of phases. Let me tell you its story… [All illustrations courtesy of IsCool Entertainment.] The genesis The story of Bazoo begins near 2013, when the mobile market was overwhelmed by match 3 games following the successful Candy Crush Saga released the year before. One producer at IsCool rightfully saw in this trend the perfect conditions to create a game out of his younger memories. The man had a lot of fun playing puzzle games with his friends in high school and he wanted to bring back this feeling to today’s players. This was quite a good idea since puzzle game is a popular genre today and the gameplay of some past successful puzzles are not exploited today on mobile. Also, multiplayer mobile gaming is a really hot subject, so it is a match! At its core, the launch of this project can be expressed in few words: let’s do a real-time PvP mobile puzzle game! At the time, the company’s expertise was into developing and publishing its own games mostly for Facebook with some attempts on the mobile market. Some of these games were played asynchronously in multiplayer. In a way, almost everything in the pitch of Bazoo was new for us. Also, most match 3 games worked on the saga mode, and real time PvP gaming was quite new and still had to prove itself in a business point of view. In order to tackle these problems down, we had to remove some constraints from the initial pitch, starting with the most obscure areas: goodbye real-time, goodbye PvP, our first try on mobile gaming will be a saga-like puzzle game. A long way to go. Two thirds of the idea are already out. It was for sure quite far from the initial project’s pitch, hopefully it was a game seemingly reasonable according to our expertise in game development. Actually, I think it is important to emphasize how compromising from the very beginning put us on a path to the game we actually wanted to make. First encounter When I entered the company, the project was already six months in the making. There was a lot of questions about it. Its name has been changed at least once to become Bazoo Block, and its assets were repurposed from another project. The game was quite fun and incredibly beautiful but the team was not exactly thrilled by the product. Actually the subject of online PvP gaming was still present in their minds. The gameplay at the time was mostly a mix of Baku Baku Animals and Puzzle Fighter, plus some nice features of our own. In short, the player had to survive a fight against a computer-controlled opponent where both characters would receive a sequence of blocks from a launcher to assemble and destroy. Depending on the destructions, a varying quantity of extra blocks would fall in the opponent’s game board, making it harder to clear and eventually filling it completely. The game ended when one player could not receive any new block from the launcher. Chained destructions (a.k.a. combos) were rewarded by an increase in the intensity of the resulting attack. The first reader to send me a complete list of things in this capture that have been removed from the initial release of Bazoo wins a t-shirt. As you can see, the core gameplay was very similar to what we have today. From Baku Baku Animals specifically, there was the animals and the foods: four types of animals would destroy their associated food. From Puzzle Fighter there was the super blocks and the patterns of the attacks: grouping similar foods in a rectangular shape would increase their strength in the attacks and the blocks resulting from the attacks would fall in various specific patterns more or less difficult to clean up. On top of this we added some power ups and variations in the gameplay. The game followed the saga models of this time: the player evolved on a map where he would have to solve puzzles of various difficulties in order to access more puzzles. There were levels where he had to fight against an AI and other levels with a single game board and played in a time attack mode where he had to destroy a specified amount of a given food in the alloted time. One of the map on which the player evolved. As the player progressed on the map, its XP gauge was filled. Then every once in a while, when the gauge was full, one of the animals received a level-up, thus making stronger the attacks resulting from the blocks it would destroy. Holiday time Then the summer came and half the staff left in vacations. The project slowed down so… Hey, it’s a good time for R&D! What if we connect two devices over the network and make each one to appear as the opponent of the other? Let’s try and see… And there we had our first real-time online PvP mobile game :) In a few days we went from a classic saga puzzle game to a unique PvP puzzle game. This prototype was a life changer and thus brought a lot of questions. What was the future of the saga mode? Should we throw it, or keep it as an alternate game mode? What if the player has no network? Then went a period of approximately four months during which we maintained the saga in the game until we finally accepted to trash it so we could focus on the game we actually wanted to make. We are in September 2014 and we have a puzzle game that can be played against other players over the network. Ready for the release? Well, not quite… Are we there yet? Let’s get it straight: at least eighty percents of your game is not related to the gameplay. As you may have deduced from the release date of Bazoo and the above paragraphs, we were quite far (like two and a half years) from having a decent game. Here are the subjects we had to work on once the core gameplay was satisfying. Server code First of all, the game now being online, we need a server and thus more developers. From now on consider that each feature will have a server part and a client part. Twice the work and more human synchronization! Tutorial Introducing the game to the players is maybe one of the most difficult parts in the development. When you write a software, everything seems so obvious… Then you run some user tests and all you see is people entering the application with no idea of what to do next, struggling to launch a game during several long minutes. Seriously, do we really have to explain that the rabbit eats the carrots and that the dog eats the bones? No joke. Yes, we must explain it. As a player who skips most tutorials it was quite difficult for me to accept that, but actually several user tests have shown us that we cannot expect a random player to understand the game during its first experience. Every effort put into making it easier for the player to grasp the game is a good move. So we have added a tutorial in the game, where the player had to perform some fixed moves to see the matching in action. After these actions we would let the player finish the fight against an AI. It was better than no tutorial at all but not enough. The main problem was that the player had to understand the game almost immediately during its first launch. Also he could lose this first fight, so we had to force him to do it again. Finally, for the players who understood the game, this unskippable tutorial was frustrating. Eventually we replaced this tutorial with a slideshow explaining the basics of the game. This is the first thing you see when you install the game today. We also force the player to try some fights against an AI before entering the arena and contrary to the previous version of the tutorial he can do it at his own pace. Notifications It is well known on the mobile market that your game cannot have good retention metrics without notifications to bring back your app in the player’s interest, for better and for worse. We initially opted for a tool named Parse to handle our notifications. The service was backed up by Facebook so it seemed quite solid aaaaand it has been discontinued one year later. This, kids, is how you see yourself trashing your perfectly good code. We then went with Firebase for the notifications, let’s hope this one will last. Analytics Once the players are in your game you will want to gather metrics so you can adjust the game both to offer them a better experience and to optimize your revenues. For example, we need to track how long the players wait before finding an opponent and arrange the matchmaking to offer them someone at their level in a short time. Typical analytics tools consist into sending an event via their SDK on the specific actions you want to track as they occur in the game. We initially went with Upsight which eventually upgraded its version and money plan in a way that would not fit our needs anymore. Thus we changed for a brand new tool named Omniata, aaaaaand it was discontinued four months after we added it. We then went with Firebase for the client and a home-made tool for the server. And this, kids, is how you write three times your analytics code. More game We tried several variations in the gameplay before finding something satisfying. There was a time when the player could use some defense and attack items during the game. It was a cool feature that no one ever used. Players were so focused on the combos that they would go to the end of the game without launching a single power up. We also added a minor change in the way the blocks are controlled such that they can stick to the walls when they are rotated, thus allowing some moves that could not be done before. Some power ups the player could use during the fight. Customization There is a huge focus on the customization of the player’s avatar in Bazoo. It is a feature initially implemented with a simple collection of outfits, then it has evolved to become what it is today: an awesome catalog of items that can be individually assigned to various parts of the character. Look at this! Isn’t it awesome? Rankings Since Bazoo is a pure competitive game it could not exist without the ladders. We have added the world-wide ranking by assigning an Elo-like score to each player and the leagues were added soon after. The first implementation was quite overcomplicated with its groups of various sizes and its skins in the prize pool. We had to simplify the whole thing to make it appealing and it resulted in what you can see in the game today. Community What is an online multiplayer game if the players cannot interact before and after they met? Certainly not a game I would like to play. So we added the messages on the versus screens, then we introduced the buddies (i.e. last opponents and Facebook friends) and the chat. On the game modes we had also implemented a matchmaking for players on the same WiFi but unfortunately it was a feature that was almost not used, so we trashed it. Finally the clans where added, allowing the players to team together. Adding the clans in the game was quite an adventure. Another nice feature is found in the Battles, allowing the players to fight with their friends or to organize competitions with other players. The first implementation allowed the players to enter multiple battles at once but there was nothing to win but pride. This was a nice feature, maybe a bit overcomplicated again. So we cleaned it up. For the second version, which you can use in the game today, the player can enter only one battle at once and there is a prize for the top ranked players at the end of the battle. Streaming Bazoo being an highly competitive game it was important for us to provide a way for the players to stream their fights and to be able to watch the fights of others. The first streaming feature was done with the mobile SDK provided by Twitch. Aaaaaand it was removed four months after its integration, when Twitch stopped supporting it (I see some kind of pattern here…). Today’s players can stream with ReplayKit on iOS and with any streaming app on Android. On top of the screen was a drop down chat with the spectators on Twitch. We also provide in-game features to watch games so one can study the skills of others and improve his owns, and also because it is fun to watch. The first one is a replay feature allowing the players to watch their last fights and the last fight of other players. The second one is a live streaming feature, enabled for everyone. Every fight can be watched by the other players, in which case the spectators are able to send cheers to the fighters to show their support. Social Allowing the player to identify with its Facebook account has several advantages both for the player and the developer. First of all it is certainly the easiest way to link the player’s account on several devices. It is also typically associated with an exclusive bonus in the game and provides a way to offer extra resources to the player’s friends via a gifting mechanism, a thing we have added quite soon in the project. On the developer’s side it is a powerful tool for virality. We already had a plugin named EziSocial to handle Facebook in the saga version. It was a good tool for an initial integration but when we needed up-to-date Facebook services we had to change for something more complete. Thus we went with the Facebook plugin of Cocos2D-X. Again we had issues to keep track of the most recent Facebook API so we finally wrote our own C++ bridge to the official Android and iOS Facebook SDKs. Apple’s Game Center and Google Play Games were also added to allow the player to use his account on several devices. Support Being able to keep a dialog and to answer efficiently to the issues encountered by the players is a key point in keeping your community happy. We use Helpshift for this, which provides an nice interface for the user to access a lot of documentation and a great chat interface with our team. We never had to replace it so I guess it is quite a solid tool. Kudos to them! UI By looking at the above captures you may be wondering if they all come from the same game as they are so different from each other. Finding a great UI was a surprising long process. There was the funny one in the saga, then the pirate theme, then another pirate theme, then the flat one, and the modern one. One game, five homes. There was also a landscape version of the game for a short time, developed for the tablets and for the Apple TV (yep, we also added support for the Apple TV before dropping it). The landscape mode was very pleasant to use, unfortunately it made the development in no small way harder since every screen had to be composed and tested for both layouts. We thus had to abandon it and go with the portrait version only. The landscape version made the fights incredibly more intense but was unusable on a smartphone. The key to success Creating a game is a lot of work, creating a good game is an order of magnitude harder, and creating a successful game is even harderer. As you may have read before there is no recipe for success in this industry, that is why studios appear and disappear quite frequently. This is a market where a success is a surprise even for the game’s creator and where the ten top grossing titles take literally all the money. So how does one can make a living in developing video games? Even if there is no recipe for a success there are some keys toward making a great game: do a game you like, keep an eye your metrics, watch the tendencies on the stores and take care of the design to be as good as the bests. Gameplay is important, also are the graphics, also is marketing, and so on. Even if you don’t end with the game of the year, you may still get a nice and working product, commercially speaking. Then there is trial and error. Some developers try several games at once and trash the ones that do not work, others invest on a single game and polish it until it becomes good. As you may have deduced from this article, we are of the “other” kind, pushing as far as possible the projects in which we believe the most, fixing on the way all the inefficient parts we encounter. Will it work? Maybe there is no market for this game, maybe it will explode. There is no way to tell but we are very proud of the product we have created. In my opinion the team did a very good job with Bazoo. Going from the initial saga mode to this awesome online PvP puzzle game was done efficiently by compromising among fast and incomplete integrations, trashing the stuff that did not work, hopefully without having spent too much time on it, and refining the stuff that did work, once its usefulness was backed up by good metrics and user tests. I would for sure do it again! I hope that this view on the developer’s side was worth reading.
  2. j-jorge

    Straining Coasters

    I have just released an update with some nice features! There is now a tutorial to explain how to use the plungers and the cannon and to tell what to do with the balloons, the birds and the zeppelins. A clever hint is displayed on the navigation buttons to tell where are the next levels to be completed. Notifications are sent to try to bring the player back in the game if he does not play for a long time. It is a difficult part to tune as they must be sent frequently to stimulate the player but no too frequently to avoid flooding. Interstitial ads appear less frequently. As usual you can install the beta with HockeyApp or using the Play Store.
  3. j-jorge

    Straining Coasters

    I have released a new version today with the following changes:   - The level endings use a cleaner presentation and displays the score threshold for each medal so the player knows how far he is from winning a medal. - Buttons have been redrawn for a more uniform style in the application. - All fonts have been replaced with nicer ones. - Beating the boss is not required to access the next serial but it is to access the bonus levels. - The cursor is now hidden.   Now I'm going to work on making easier to shoot with the cannon and to design some very short tutorial levels. Please test the game and give me your feeling! :)   The link to download the game is still the same. You can also find it on the Play Store.
  4. j-jorge

    Straining Coasters

    Hi,   A few years ago I wrote a game with a friend during a small game jam. We rapidly extended the concept into a small PC game and finally I decided to port it on mobile under the name Straining Coasters. Compared to the PC version, this one has been totally redone visually and redesigned for mobile devices.   The game consists into riding roller coasters armed with a plunger gun to grab the balloons scattered along the tracks. A lot of obstacles will be on your path but hopefully you are also equipped with a huge cannon that will destroy them and create impressive chain reactions. This is a game that demands good reflexes.   On the technical part, the game was done with an engine we wrote for our other games at the time (named the Bear Engine, written in C++ and initially created for Plee the Bear). Of course I had to optimize it for mobile devices and port it to Android.   There is still a lot of things to do before releasing the final game. I'm thinking about adding some power up to make some levels easier, plugging in social networks, handling the player's account on several devices or also adding rewarded videos. In the meantime I would need your feedback, so click the following link to make your opinion!   >> Install the game on your device <<
  5. You can download the previous version, with all the problems mentioned above, on SourceForge.net.
  6. Dear game developers, I am quite happy because I have recently finished the drawing of the last sprite I wanted to add to Plee the Bear. It was this beautiful pink flower : To create this beautiful flower, I started from a 50% gray layer in GIMP in which I quickly drew the volumes using a black or white paintbrush. Then I added tint areas for each part of the drawing (petals and pistil) that I combined with the volumes by applying a "soft light" mode to the latter. In a second 50% gray layer combined in "soft light" mode, I drew the edges of the petals with a white paintbrush in order to emphasis them. Finally I applied a yellow airbrush in "addition" mode to contrast the whole thing. Neat, isn't it? This work is a partial result of the ongoing fundraising campaign for the game. The finalization of this task has a special meaning; it means that I can now begin the clean up process: I remove the old sprites, I edit the levels to adjust their structure and the decorations, then I will be able to package the game and to share it. About the graphics, apart this new flower and the fresh decorations you can see on the first screen shot, I ave also reworked the animations of the player walking, running and slapping: In terms of game play, the main character is now more easily controlled, especially because his speed has been greatly reduced. Also, the first levels are more simple, less intricate, but still have as many secret places. See for example the structure of the very first level (the player is under the little red arrow): In the previous releases of the game we had several problems with the inclined grounds: either the player couldn't climb, or was sliding on it, or climbing backwards, or he was running without moving…. At the time we met these problems, we found a workaround by using some magic numbers and half-assed computation of the forces. It was a bit shameful… Well, good news everyone!, all this crap has been removed! The smelly tricks are over, now the reaction of the ground follows the laws of physics and this is the main character who adjusts his force according to the angle of the ground on which he is. Another constraint of the slopes used in the previous release of the game was that they had to be necessarily straight. Well, as a side effect of the integration of the work done on Andy's Super Great Park, you will have in the next release some beautiful slopes whose surfaces are defined by a Bézier curve. As a result, the behavior of the main character when he goes from one ground to another is smoother and it is visually really nicer! Aside of this I have also worked on the documentation of the engine of the game and I have started a series of simple examples targeted to guide the user into taking the tools in hand. The approach is completely different of what I did before. While I wanted to write complete and precise technical documentations before, emphasizing the level editor, character editor and animation editors, I decided to tackle the problem in a different way by writing short programs to show that the engine is easy to use even without the additional tools. Thus the new developer is now accompanied in the documentation into creating his first window, displaying a rectangle, then a sprite, a text with a true type font, reading the keyboard, the mouse and the joystick, playing a music and some sounds, playing an animation, apply a fragment shader and more coming soon. For the developers already at ease in the development and who want to start immediately in the game, I have also created a project wizard for Linux distributions which downloads the engine, creates a tree structure with the minimal content for a project, then compiles and runs it. The archive of the wizard is also available out of git Here it is! I hope I will be able to provide a build of the game the next time  
  7. @MikeS I process the shapes from the front to the back while keeping a list L of rectangles representing the parts of the screen not yet covered by an opaque shape. When a new shape is considered, I search the rectangles in L intersecting the shape then, for each of them:   - I create for a new shape with the part contained in the rectangle, - I remove the rectangle from L, subtract the opaque rectangle of the shape to obtain zero to four new rectangles representing the non covered parts, and I insert these new rectangles in L.   There is no quadtree but… hem… it seems perfect for L. I don't know why I did not used them, I should have thought about it :/ Also, the way I split the non covered parts, as shown by the fifth picture, has a tendency to produce vertical stripes that lead to visual artifacts. I should be easy to produce more regular rectangles.
  8. @phil_t Before implementing this solution I did implement a solution based on the depth test but it was not convincing. It saved the computation of the fragments' color but it still cost the depth test. Nevertheless I have never tried a two passes rendering as you describe.   @x4000 It is indeed an old style blitting procedure. At the time of the article there was still the possibility of changing the back end, thus I wanted a rendering solution that would still work with another tool. Now the rendering is done using OpenGL and a better ordering of the materials should indeed improve the procedure. Right now there is no optimization of the textures' content nor do we minimize the texture switches. So thanks for the hints :)   @cdoty I have never seen worst result with this procedure than with the previous one even if, as you have noticed, the new procedure increases the number of vertices. My first reflex was to limit the size of the sub textures but actually it made no difference. Maybe a combination with the improvement proposed by x4000 would lead to different results on this subject.
  9. For this kind of problem I use claw::multi_type_map : For example : typedef claw::meta::type_list_maker<A*, B*>::result my_type_list; claw::multi_type_map<int, my_type_list> my_multi_map; my_multi_map.set<0>( myA ); my_multi_map.set<1>( myB ); Then I use a visitor to explore the map. With this solution, A and B do not need to share a common base class, nor to have any virtual stuff. There is also no dynamic_cast.
  10. Hello, I would like to share a tool I have developped when working on Plee the Bear and Andy's Super Great Park. This is a sprite packing software that works on Gimp images and produces PNG sprite sheets. The software is Pack My Sprites. It is written in C++ and relies upon Gimp and Xcfinfo to build the sprite sheets. The source code is available under the terms of the GNU GPL version 3. Only the source code is available now, there is no binaries yet. Right now it is mostly for Linux users since Xcftools is not available for Windows yet. As soon as I manage to build Xcftools for Windows I should be able to provide an installer for this system too.   From the website:   Are you intersted by this kind of tools? Would you be interested by a Windows version or a package for a given Linux distribution?
  11. j-jorge

    New C++ tweener library

    Hi, I would like to present a module of libclaw called claw::tween, whose goal is to bring tweeners to the C++ in a clear, efficient and extensible implementation. Long story short, this module allows to interpolate the intermediate values between two given values in a time interval. This practice is well used in animation and is widely popular in the context of ActionScript/Flash games and websites. Here is an example video taken from Plee the Bear showing an animation made with the tweener module of libclaw. When the rabbit is hurt is this video, the movement of his various parts is the result of several tweeners. Those tweeners compute the position and the angle of each part. This module is inspired from the ActionScript library named tweener and from its C++ port named cpptweener. Claw::tween is different from these implementation on several criteria: Interpolation is done on the value of a given variable or using an user-provided callback function,The interpolated values are computed using a predefined easing function or any user-provided function respecting the contract,Several tweeners can easily be executed simultaneously or in a row,The library has a modern C++ design. Libclaw is available under the LGPL license. To try it by yourself, just download libclaw from its project page on SourceForge.net. There is also a documentation of the tweener module with various code examples.
  12. j-jorge

    On Graphics, Windows, and C++

    We use OpenGL through the SDL for Plee the Bear and it works great, even if we had to do some algorithmic to speed up the rendering. But I cannot say if it is better than an other library. The main things I like in OpenGL for 2D are that it is easy to scale, rotate or flip sprites. Also, transparency is straightforward and we can easily change the aspect of a sprite by changing the intensity of the color components. The only other library we have quickly considered was SDL_gfx which looked a bit more complicated but we did not go deep inside.
  13. j-jorge

    C++ class design questions

    Quote:Original post by simpler Thank you j-jorge for great replies! There's just one thing I didn't grab. Quote:I had something like onPlayerCollision() in my game but I ended by removing it because it is just one special case of the various types of collisions. Eventually all classes check the instance of the colliding items when necessary in an onCollision(Object& o) function. What should have the onCollision(Object &o) function? Isn't all collisions going to be between player-object? Or do you mean that Enemies should check detection as well? Please explain a bit more how your onCollision() function would work if you will [smile] I would say it depends of your game. For example, if your hero can throw things, like a fireball, then you can have a collision between an enemy and a fireball. In our game we check the type of the colliding item with a dynamic_cast when necessary, which may not be the best solution. Quote:edit: Should I inherit Player from Object? Don't feel like that, just asking. I should say yes. The player lives in the world like any other object, has physic properties, an update procedure and can be rendered. So why not.
  14. j-jorge

    C++ class design questions

    Hi, Quote:1.) Should I use a single std::list<Object*>ObjectList or one list for all different types of Objects? Having one list for each type of Object is not a good design. You will have to update your level class each time you create a new object class. Instead, do a level class that works with any descendant of Object so you will write the level class once for all. Nevertheless, a example of separation I do in my game is to handle the objects in a different way according to their behavior (not their type). For example, in my game I have separate lists for objects according to their lifespan. Instances that never move and whose life is as long as the level are in a list (grounds, walls, etc.), instances that can disappear at any time are in a different list (monsters, power-up, etc.) Quote:2.) A Platform doesn't need any more member variables than an Object, but should I still make a new class called Platform to make things clearer? Yes, do it. The reader of your code will then know that the instance behaves like a Platform and you will prepare the place for the Platform-only features you have not thought about yet :) Quote:3.) For the collision detection, should each different object have a onPlayerCollision(Player *player) function which handles what to do with the player? Or should the Player class check what it collided with and find out by if statements what to do? I had something like onPlayerCollision() in my game but I ended by removing it because it is just one special case of the various types of collisions. Eventually all classes check the instance of the colliding items when necessary in an onCollision(Object& o) function. By the way, do not make all your virtual functions pure virtual. The virtual keyword is enough for polymorphism and you will want to make them empty functions the day you will create classes that do not have work to do in those functions. Use pure virtual functions only if the base class expects the subclasses to do something. And even then, you will be able to implement the function as empty.
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!