Tagged: Weekly News Toggle Comment Threads | Keyboard Shortcuts

  • xuv 17:43 on 2016-10-25 Permalink | Reply
    Tags: , , , Weekly News   

    Polymorph weekly news #9 

    Tuning Scores chair physics

    No news is good news. Polymorph is alive and kicking. The train is on its tracks. The ball is rolling.

    It’s already almost a week since I’ve chatted with @frankiezafe and @louise about the advancements of their project. You might have also noted that they don’t post much either on this blog. As François says it, it’s because the progress they make is not that big of  step to share, or does not produce some visuals that would look good on the blog. Back a couple weeks, when features where being added almost every day, things were exciting. Now, the real work of polishing and improving what has been initiated is actually happening and that just does not seem as exciting to share. Although it’s exciting for the team to see it growing.

    A second meeting with Contredanse was much more productive and finally we started talking about gameplay. Baptiste and Florence could put their hands on the mouse and feel what a player could feel. Discussion ensued on object movements and reactions in the virtual world. The manipulation of the camera created interesting problems and awkwardness that needs to be addressed. And a common set of objects has been defined and should be limited to a stone, a stick, a chair, a cup and a chain for now. @louise is iterating on the appearance of those and playing around with their physics properties.

    François is deep into physics programming. He also took a big decision regarding all the tools he is building. Instead of trying to produce some independent Ogre libraries, he will concentrate on making it all work in the Polymorph Engine (PE). As a reminder, the PE is a bundle, a package of great open source libraries to make video games. The choice to release work as a bundle instead as independent modules is mainly a practical one. It will take less time to code. The modules are also very much interdependent for now. So making them detachable from the PE would require extra work that the team does not have at the moment. Maybe in the future. But again, making a full featured game engine on top of Ogre was always one of the goal of Polymorph. The ability to break this apart is then for later.

    Where is PEEL you might ask? On hold for now. Tuning Scores is the priority since the prototype needs to be delivered by December. All eyes are on this goal now. And challenges remain, such as multiple mouses input for example. Anyway, all progress on Tuning Score is good for PEEL. So no worries, François will be back on it for Christmas.

    See you next time.

    PS: All screenshots by @louise

    Tuning Scores chair

  • xuv 22:12 on 2016-09-30 Permalink | Reply
    Tags: , Kimai, , Weekly News   

    Polymorph weekly news #8 

    Bullet schema

    This will take only 5 minutes.

    This is what @frankiezafe and I told each other when starting our weekly meeting about the Polymorph.

    Time, whether it’s a good way to evaluate a human activity or not, is always going to be used as a reference. How much time did you spend on this? How long will it take to release a first video game? How much more time do you need to finish implementing Bullet? Do you have 5 minutes to share this article with your friends or read this weekly news? (which by now you have figured out is not even weekly).

    With computers it seems, we’re all quickly loosing track of time. Whatever the machine is doing to us, it is sucking it at an incredible pace. And EVERYONE in the business knows it. Let me quote a discussion between Ton Roosendaal and Bart Veldhuizen about development time:

    Our meeting, with the excuse of this post, took almost 2 hours. Of course we talked about other things than Polymorph. Of course this always happens between us two. But in an open structure like Polymorph, on an open source project like PEEL or the Polymorph Engine, how do you track the amount of work being done?

    Well, it’s not really a little secret, but within Polymorph, participants are encouraged to log the hours they spend on each project using Kimai. It’s certainly not the best way, but it’s not a bad way either. It’s also mostly a tool for oneself to figure out how much time we’ve spend on something. And believe it or not but @frankiezafe has already spend 350 hours developing the Polymorph Engine. Not bad if you ask me. This is over the course of the last 3 months, full time, or close.

    The Polymorph Engine is not finished yet, of course. But François is happy the way it advances. It will help build games faster in the future, as the most common operations for building a game will be immediately available, without hiding the complex process underneath it.

    For the technical minded in the audience, François is still working on adding Bullet to Ogre. The illustration of this artcile is from Bullet’s documentation, which François has praised as the best documentation he’s seen so far. Bullet (a physics engine) will be useful for both PEEL and for Tuning Scores. In PEEL, it will help to avoid collisions and discard impossible moves in the puzzle, while in Tuning Scores, the whole game play is based on the physical properties of the objects in the virtual world.

    This news took me 53 minutes to write. I better close now. I still have to post it on Twitter, Facebook and Diaspora*. You’d be so kind to give us a minute too and share it with your friends.


    • frankiezafe 19:44 on 2016-10-01 Permalink | Reply

      a programmer’s day lasts around 30 minutes, from 9am to 8pm for the rest of the world…

      • xuv 20:49 on 2016-10-02 Permalink | Reply

        Nope, it’s the other way around. A programmer’s day lasts 2 weeks for the rest of the world.
        Because if a programmer tells you that he can do something in a day, come back in 2 weeks for actual delivery.

  • xuv 00:01 on 2016-09-24 Permalink | Reply
    Tags: , , F/LAT, KDEnlive, , , , Weekly News   

    Polymorph weekly news #7 


    Welcome @louise! As a new member, she just joined the Polymorph team and this post will be presenting her to you and hopefully tell you more about her role and interest in the Polymorph project.

    I did not know Louise Baduel before having a conversation with her a couple hours ago. All I knew is that @frankiezafe had met her during the Blender workshop he gave at iMAL a few months ago and that he had offered her to work on the video game project he is working on for the company Contredanse.

    So Louise is a choreographer, dancer and videographer living in Brussels. She co-founded the dance collective System Failure and is interested in studying and understanding the relation between sound and performance. She also does video editing and wanted to start manipulating 3D objects and create them. That’s why she decided to come to a Blender class. She admitted having downloaded Blender 6 years ago, but needed a little push to get up to speed with the technology. And apparently, François’s classes were very helpful in that sense. So helpful that Louise agreed to join the Polymorph team and jump full time in Blender on a Linux system.

    Louise told me she had been quite interested in libre and open source software for a while. She is fed up with Apple’s logic. “I need to get out of this, she said. But working with video has been a show stopper for me as it is not as easy to do with Linux.” Now that she’s been working with Blender and Linux intensively for the past two weeks, she said she was ready to try video editing with Blender. She also tried KDEnlive last week but found it to be missing some features compared to FinalCut. But she likes this new approach to making things and will definitely experiment more now with this fully open source toolbox.

    At the same time she arrived at Polymorph, she also discovered F/LAT. She said she appreciate the feeling there and that everybody is happy to be helping each other when there is a problem or a question around open source software. “There is always someone available to answer a question” she said, and that helps her learn a lot every day.

    As you may have seen from @louise posts on this website, she is working on “Tuning Scores”, the code name for now for the video game being developed with professional dancers in mind. Tuning Scores is actually a series of techniques for dancers, put together by Lisa Nelson, to develop spontaneous compositions. And Polymorph is commissioned by Contredanse to port this into the virtual world of an interactive application, or so called, video game.

    There is many challenges in a project like this. It will be a game for two players. And there will have a palette of 3D objects to play with. The objects will be kept simple but the rules governing their behavior will be complex. Special attention will be given to the sound each object makes. The point here is not to be literal but to create a sensation. Dancers work with their feelings and need to feel the space they are in. The virtual world needs to be rich enough to invite the participants to interact with it and with each other. How will a dancer perceive the presence of another dancer in the game? How will they communicate? How can a dancer perform according to the rules of “Tuning Scores”? The players need to be able to repeat a set of actions s·he just made or play it backwards, freeze or sustain it. And overall what would be the purpose of this tool?

    Definitely there is a demand from Contredanse to get the word out about the “Tuning Scores” practice and the work of Lisa Nelson. This is one of the reason to come up with a project like this, but where could this head up to? Since sound is involved and reactive to the players actions, it could be a way to create or compose music. It could also be an application to put 2 dancers distant from each other physically and have them interact in the same room. It could also possibly be an instrument for live performance.

    All these questions will hopefully find an answer in the coming months, but they are certainly driving Louise research right now, with the help of the rest of the Polymorph team. This is a unique project and possibly the first of its kind. So keep an eye on this website for regular posts in this matter. And don’t worry, @frankie hasn’t left the development of PEEL. It’s advancing. Bullet is now integrated. But I’ll ask all about it when I’ll chat with Francois next week.

    In the meantime, stay tuned, and share responsibly.

  • xuv 22:00 on 2016-09-09 Permalink | Reply
    Tags: , , , Weekly News   

    Polymorph weekly news #6 


    If you’re following this series of weekly news, you’ve noticed there hasn’t been any for the past few weeks. I apologize for this. It does not mean Polymorph was on hold or that I lost contact with the team, but I just did not have much time to write a post and do the regular interviews of the different participants. But this week, I’m back on track and was invited to participate in the dev meeting with @frankiezafe, @balt and Olm. So let’s summarize this 3 hours meeting in a couple points that hopefully will invite you to dig further and come to the next one. Because, since Polymorph is actually an open source game development platform, you are all welcome to join, anytime you want.

    Out of the many things that have been developed around Ogre for the past few weeks, the last notable one is an addon to handle game controllers. François has finished and tested it with Olm and Balthazar. They’ve even tried to plug in multiple mouse controllers in one machine to see how that would work. But although this could be possible on a Linux machine, it’s not as easy as it sounds. While the idea of creating a game for multiple users on the same computer, each with his/her own mouse, is appealing, the complexity and the limitation in terms of OS choice don’t make it a priority for Polymorph at this time. If a project comes up that requires it, further research will be done in that direction. As for now, the Ogre addon for game controllers works. It’s not going to be an official addon as the Ogre community requires that unit tests must be written for it in order to make it into the official list.  But since it’s open source and the code available here, if someone wants to jump on it and do it, you’re more than welcome.

    The conversation went on about PEEL’s gameplay and especially how the player moves around and manipulates objects. As you can see in the video below, things run smoothly. But an interesting conversation happened between Olm, Balthazar and Francois on how to improve things and make it even smoother.

    François then introduced his plan on how to configure each levels using XML files. Basically, each level is fully described by a tree of options and parameters, which makes it a fast and convenient way to create new levels. Discussion went around the structure of the XML, where to add and define sound parameters and so on. Which then evolved in a whole conversation on how to best use the sound engine (aka Pure-Data) that is now fully part of the Polymorph Engine. Pure-Data, for those who don’t know, is the open source equivalent of Max/MSP. A very powerful realtime sound synthesizer, making the Polymorph Engine a musical instrument in itself.

    As for PEEL, being a minimalist game in  terms of 3D objects and environment, the sound will be crucial to give a sense of space and set the overall mood of the game. We’re taking about spacial sound and realtime sound effects, of course, done with the help of Daniel Perez Hajdu.

    Regarding the development of Polymorph Engine, many questions are still open. What about the compilation on Android? Lacking tools and access to proper Android hardware, Francois has not managed to compile it for this platform yet. There is also big questions hanging in the air regarding shadows. Francois has not figured out how all that works. It might be not so important for PEEL, but the next project will require it.

    And since we are already talking about the next project, @louise will be joining Polymorph next week to start working on the Contredanse application. She will be doing research on the gameplay and work on the integration of the 3D elements in the game engine. While @frankiezafe will be in charge of integrating Bullet (the physics engine) and finding all the help in can get from the Ogre community to get the shadows working.

    So stay tuned, come visit us and pass on the information around you, that’s also a way to show support to this project. And see you next week.

  • xuv 23:19 on 2016-08-12 Permalink | Reply
    Tags: compositing, , , Weekly News   

    Polymorph weekly news #5 

    As soon as we started video-chatting, @frankiezafe showed me this graph, which could possibly be represented by the equation f(x) = sin(10*x)*exp(-x)+1.

    Learning curve

    That, he said, is the plot of my feelings of satisfaction and achievement with Ogre over time. It’s going from “super awesome” to “total discouragement” and back again, although as you can see the curve is slowly flattening and staying on the upper side of things. François is used to a learning curve when he gets interested in a new technology. And certainly, with open source software, you sometimes have to put extra work at the start to get yourself going. But he said he never hit such walls as with Ogre and at the same time felt so empowered as he was overcoming the difficulties. Definitely he said, at the end of the conversation, Ogre will be a tool he’ll be using for a lot of things from now on. “It’s so powerful”.

    So what has been cooking at Polymorph for the past week?

    Well, François is still completing his Exemple 2.0 which gathers in a neat fashion all the stuff he’s been learning so far. A kind of a reference project and a test bed for compilation. He also started developing PEEL using Ogre. At first he thought he was going to do some mesh generation on-the-fly in the engine itself, since the elements of PEEL have such simple geometries. But that did not work as expected in Ogre. The complexity necessary to generate meshes is far more demanding in Ogre than in Openframeworks for example. It’s not impossible, but somehow it’s an overkill and François wanted to get going with the game. So he opted for a quick modeling session in Blender using armatures and exported for Ogre.

    And that brought a new challenge: shadows. Shadows in Ogre 2.0 are not activated by a simple switch (like in 1.9). They are now a complex set of parameters and passes that need to be taken care off in Ogre Compositor. This, although pushing back a little in terms of easiness, gives enormous power to the developer and game designer on how, what and when he wants shadows to be handled in the game. So it requires that you know what you’re doing. It requires understanding the whole rendering process and the multiple passes Ogre goes through to render a frame. There is also need to take into account the multiple versions of OpenGL, GLES and other shading languages found on the different platforms the game might be running.

    Again, the Ogre Compositor is complex but extremely powerful. Possibly more powerful than the node editor of Blender, he says. Each node in itself can have its series of own sub-processes and passes, etc. A true compositing system optimized for realtime rendering. A game like Memory of a Broken Dimension, which François is a huge fan of, would make sense to be developed using Ogre and its compositor.

    We then discussed on the advantages of open source over proprietary software. Even if open source software can be hard sometimes, you know so much afterwards that the journey is worth it. François has been using Unity3D for a while and although it’s supposed to be a fast and easy application to develop games. He enjoys Ogre better now, because at least, he knows how things are working. The problem with proprietary software is that there is this layer that is supposed to make things easier by hiding all the complexity, but it’s actually hiding its internal mechanism, which, as a user, you can not act upon, or even slightly understand or master. With libre/open source software, it’s totally the opposite, you have all the blocks you need. Sure, you have to know how they work. But then the possibilities are endless.

    Conversation drifted to capitalism, DIY, and mass market. Ho, by the way, François is looking into posting PEEL on Steam. If you have any experience with that, he’d be happy to talk to you.

    • frankiezafe 10:20 on 2016-08-13 Permalink | Reply

      Excellent that you wrote the statisfaction curve of #libre! But it’s a pity it ends up around 1… I prefer this function: sin(10*(x-2.2))*exp(-(x-2.2))%2B(1*exp(x-2)).
      After a good amount of time, you get back to feeling of the beginning, and even more 🙂

      • xuv 18:38 on 2016-08-13 Permalink | Reply

        Indeed. Your graph is better. Though that’s not what you showed me during our chat 😉
        And I’m not 100% about the exponential satisfaction when you’ve mastered the tool. 😉

  • xuv 20:00 on 2016-08-05 Permalink | Reply
    Tags: , , , Weekly News   

    Polymorph weekly news #4 

    OGRE Render Window_658

    Fourth week already and half way? Let’s see.

    So back to interviewing @frankiezafe, our project leader and main motor behind the Polymorph Engine (haha, I’m so funny). So Frankie and I had a little chat, which was supposed to last one hour but ended up taking two. Although this post won’t be as long, I promise. But I was keen to know how projects were going from his point of view.

    As you may have seen from his last posts, there is now what is called an Empty example for Ogre 2.0 running. It’s not that empty because it has a camera, lights and objects floating in empty space, but you get the idea. It’s a basic demo to start working from. It’s also a great tool to check that things compile in all platforms. So far, François has it running on Linux. It should run on Windows and other platform are coming. By the way, if you are interested, please have a go at it and send feedback. There is now documentation and code on the repository. And while it’s not yet a complete Empty example, it should get you started. And we’re excited to read what you think of it.

    So François is now step by step going deeper in the Ogre3d documentation. His experience with Openframeworks proved very valuable here. Because he already knows how the GPU (graphic card) is handling images, as he says it:

    You throw a bag of numbers at it in the correct format and it spits out an image.

    Although handling Ogre is a lot more different than Openframeworks. If Openframeworks is an excellent introduction to C++ and a very flexible tool, Ogre is way more complex and structured. It requires a good understanding of high level C++ concepts and related software design patterns, which makes Ogre a powerful tool indeed, but harder to learn. I could sense that this was kind of a hard step for François, but it also came with its moments of joy, when he shared with me the code that defines the camera movement.

        if ( mouse_right_dragged ) {
            Real rspeed = 0.005f;
            Vector2 diff = mouse_right_current - mouse_right_pick;
            Quaternion qo = cam->getOrientation();
            Quaternion qx( Radian( -diff.y * draw_event.timeSinceLastFrame * rspeed ), Vector3( 1,0,0 ) );
            Quaternion qy( Radian( -diff.x * draw_event.timeSinceLastFrame * rspeed ), Vector3( 0,1,0 ) );
            cam->setOrientation( qo * qx * qy );

    These little things in Ogre make it so much easier, said François.

    His work from this week focused on code to generate mesh, materials and texture on-the-fly, meaning things are not preloaded from files at startup, but generated by the engine itself when the game runs. François is taking inspiration from Mad Max tutorials, but “cleaning up” the code, as he says it, and creating basic classes from it. Making it then reusable code for following projects. It may not look like it, but all this is necessary for the development of PEEL, the first game of Polymorph.

    PEEL should come out at the end of August, hence my introductory mention of “half way”. Polymorph exists since 4 weeks and should deliver an alpha verison of its first game in 4 weeks. There is many steps until then, but Pieter and François are making progress. And Daniel Perez has agreed to make a Pure-Data patch for spatialized sound. So stay tuned and see you next week.


    • frankiezafe 10:26 on 2016-08-09 Permalink | Reply

      Much better version of the camera controls, thanks to qknight (https://github.com/qknight/ogre-examples)

      Real rspeed = 0.005f;
      Vector2 diff = mouse_right_current – mouse_right_pick;
      cam->yaw( Radian( -diff.x * draw_event.timeSinceLastFrame * rspeed ) );
      cam->pitch( Radian( -diff.y * draw_event.timeSinceLastFrame * rspeed ) );

      Already in example.2.0

  • xuv 22:39 on 2016-07-29 Permalink | Reply
    Tags: , open source, , Unity3D, Unreal Engine, Weekly News   

    Polymorph weekly news #3 

    Going for the third week now, I scheduled an appointment with @balt, the second developer of Polymorph Engine.

    I never met Balthazar and so this was more an introduction meeting and a discussion to get to know each other. The other reason is Balthazar has tasks to do on the Polymorph Engine but he has not found the time yet to get to it, so it was pointless to talk about what he had achieved so far. Nonetheless we did talk about it and what he sees in Polymorph and that’s equally interesting.

    So Balthazar de Tonnac is a developer and system administrator from Brussels. He has worked with artists helping them integrate open source tools in their workflow. He also has knowledge in Blender, Unreal Engine and Unity3D. One of his previous work was to develop a visualizer for atk.io. ATK! is an audiovisual duo, composed of Ofer Smilansky and Isjtar, known for doing live performances using light and music in relation to architecture. Balthazar created an interactive application for ATK! using the Unreal Engine. This permits them to visualize their set up and show what it could look like to their clients. Using the Untity3D engine, Balthazar is now working on a VR application to help companies visualize the installation of heavy industrial equipment in their final environment.

    All this experience with proprietary solutions is very useful for Polymorph and it’s also the reason why he wants to invest time and energy into it. As Balthazar says it, there is an incredible amount of resources and tools already available in the free/libre and open source world regarding the development of games and interactive applications. But where proprietary still beats everyone is that there is no packaged solution yet. Ogre3D is a very powerful engine but it’s very complex to start using it. There is an enormous amount of code that needs to be rewritten every time someone wants to start a project and this should not be the case.

    Also, we need something that can compile for all platforms and from whatever platform you’re working on. And to achieve that, a lot of configuration needs to be done. Ogre is not easy and one needs to dig into its documentation first, which is also a little scattered all over the place. But it’s a very promising tool and, as we can see, @frankiezafe and Pieter have achieved a big step this week (check previous posts by François).

    Balthazar believes that Polymorph is working on an incredible and very ambitious project. Something that the open source community needs and that in the long term could be really successful, but it also requires a great amount of resources. He sees the Polymorph Engine as an open source alternative to Unreal Engine or Unity3D. But for that, so much work needs to be done in terms of ease of access and more intuitive interfaces. The problem with Ogre is that, whatever you want to achieve, you have to do it with code. There is no preview window, no icon that tells you where your camera or your lights are. You have to write it, compile it and then see it running. Which makes game creation very tedious. Balthazar is hoping that with Polymorph Engine, those aspects could be solved, one day.

    For now, though, building PEEL, the first open source game project from Polymorph, is the real goal and the best strategy according to him. It allows the team to see what’s working and what needs to be improved. And once Polymorph has something to show, than the bigger goals can be put on the table. But as Balthazar says it: “All we need now is a very good Makefile”.

  • xuv 20:36 on 2016-07-22 Permalink | Reply
    Tags: , , , , Weekly News   

    Polymorph weekly news #2 


    Just like last friday, here’s a little recap of what happened inside Polymorph during the week. For this episode, I interviewed Pieter Heremans, one of the core developer working on the Polymorph engine. I first met Pieter when he was part of Lab[au], but you probably also know him for his involvement in HSBXL, F/LAT and many more projects involving hacking and open source technologies.

    During our discussion to prepare this post, I was curious of why they had chosen to go for Ogre 2.0 and how Pieter was seeing the development of the engine.

    There is 4 concurrent versions of Ogre (1.9, 1.10, 2.0 and 2.1), but the dev team decided to go for the 2.0 as it’s right now reaching a stable state and also works on mobile platforms. This page from Ogre team helped make the decision. The “problem” though is that most of the examples and documentation available online are for versions 1.x, so one of Pieter’s task is to fill that gap, meaning, porting or creating new examples and providing good documentation to compile Ogre 2.0.

    Last week Pieter had managed to compile it on Linux (Debian to be precise) and Android. This week, compilation worked on Windows 10. If you care to see how he did it, check out his report in the related issue on Bitbucket. When I left the conversation with him, he was going to have a try at MacOSX, although that could maybe more problematic. It’s worth noting also that although the compilation for Android was successful, meaning software was running and debug messages were flowing smoothly, the violet (violent?) color displayed on the screen could mean problems with the graphics engine. If Ogre uses OpenGL on Linux and Windows, it needs to use OpenGLES on Android, and there might still be some bugs or things to solve in that corner.

    I then asked if Pieter was contributing back to the Ogre development and where or how he was making the documentation. So far, he has only done little changes to Ogre’s code to be able to compile, but does not exclude pushing back his findings later on. As for documentation, he uses a viva voce approach at first with the help of the issue tracker. His plan is to tell @frankiezafe how to compile Ogre with its verbal instructions and see where François might have trouble or where he might be missing some packages. Then they would write a more structured documentation together explaining the process.

    I also asked him about the analogy between Openframeworks and the Polymorph Engine. And here Pieter is a little more skeptical. Openframeworks is a very immediate tool that allows to start coding and get a quick result. Ogre has a more managed approach and is responsible of doing the scene draw itself. It’s also bigger, more complex and uses a different way to get things rolling. So, apart from C++ knowledge, the transition between Openframeworks and Polymorph Engine will not be an easy one. There is a whole lot of different things to take into account. But, where the analogy works, is that Polymorph Engine will be a bundle of Ogre with other useful libraries, proposed as a package. Right now, compiling Ogre means compiling it from libraries installed on your system, while compiling the Polymorph Engine would be working from a folder where everything is put together.

    One of the addition of the Polymorph Engine that Pieter is looking forward to is the the use of libPD (Pure-Data) inside the game engine. Apart from the fact that it would permit all sound manipulations that Pure-Data already proposes, which is very exiting in itself, Pieter hopes to be executing PD patches directly inside Ogre. As he puts it, this would open collaboration between game designers and sound engineers, allowing to integrate their work directly in the game making process, without needing to recode the patches. We could also imagine PD patches becoming a form of scripting language for Ogre itself.

    Next week, @frankiezafe is back from his Blender teaching at iMAL, and the whole Polymorph dev team will be working together on implementing the first game, still known as PEEL, in the Polymorph Engine. This will be an important week. So stay tuned.

    • frankiezafe 19:10 on 2016-07-25 Permalink | Reply

      About the “putting everything in a folder”, it’s working fine > one or 2 flags in cmake and the job is done. I’ll a video to show how easy it is 🙂

      • xuv 19:35 on 2016-07-25 Permalink | Reply

        Looking forward to the video. The “putting everything in a folder” was more about a question of distribution of the Polymorph Engine, rather than building the PE. When you say, it’s easy, do you refer to this documentation: https://bitbucket.org/frankiezafe/polymorph-engine/wiki/ogre.0.2-setup
        Another way of phrasing the question is: Is Polymorph Engine going to be a distribution in itself or a set of docs to build it?

  • xuv 20:38 on 2016-07-15 Permalink | Reply
    Tags: , , , , , Weekly News   

    Polymorph weekly news #1 

    This is the first post of what we hope to be a series, where we try to summarize and explain what happened at Polymorph during the past week. For this one, I interviewed @frankiezafe and asked him about the development of the different projects at Polymorph.


    Peel is the code name for the first game developped inside Polymorph. François was working on this project since a while and started with a first concept, which gave it its name. As portrayed in this video, the idea was to solve a puzzle, to find your way through a labyrinth by peeling a 3D sculpture. This concept came after a workshop François gave about Three.js.

    If you’ve followed some posts from this week, the concept is evolving into something completely new and different. The name is kept, but the principles have evolved into a different game, one where the player has to assemble different 3D pieces in order to solve a puzzle.


    Since this is going to be the first game published by Polymoph, Francois is looking for something more interesting in terms of gameplay than just a little project that you would discard after 2 minutes. The goal behind PEEL is to test the workflow and the tools, but not only. The purpose of Polymorph is to also test new gameplays and new approaches in game design, this is why PEEL had to evolve in something more challenging, more interesting.

    The inner workings of the game are now more complicated and hard to put into words. So Francois is laying his ideas into schemas and graphics, both as a way to express them but also possibly ease the work of programming it afterwards.


    Let’s see how that evolves over the next weeks.

    Polymorph Engine

    What we call the Polymorph Engine is an assembly of different tools, with at its core, the open source 3D engine called Ogre. Every monday, the dev team of Polymorph meets to discuss the tasks and needs to achieve compilation and running examples of Ogre on all the operating systems possible.


    Taking OpenFrameworks as an example, the Polymorph Engine would be Ogre and some other components nicely packaged so that a game developer could easily start working on projects without having to recompile Ogre each time. The same way you just clone an empty example from OpenFrameworks to start working on your next digital art project, with Polymorph Engine, you would copy the basic default empty example and start coding and testing your project from there. This means that the compilation of Ogre would only be done once, most certainly just after downloading the latest version of the Polymorph Engine. Then just the example you are working on would be compiled each time some code is changed.

    So far, Francois had achieved compilation of Ogre 1.9 on Linux and even published a tutorial for those who would like to try it also. But the dev team of Polymorph has decided to use Ogre 2.0 for the Polymorph Engine and this is much much less documented than the previous versions of Ogre. Work needs to be done in that sense, to document and ease that process.

    During the past week, Peter has managed to compile Ogre 2.0 for Android and Debian and also compiled the first examples that come with it (aka. the Purple Screen of Joy aka “Yes, it’s working”). @balt has also managed to compile Ogre 2.0 for Linux Mint and has investigated into build farm software to automate compilation on different platforms.

    Plans for next week

    By the end of next week, we expect to have Polymorph Engine working as it should (Ogre + an empty example to be copied) for Linux. The whole Polymorph team working exclusively on Linux machines, this is priority in terms of platform so that game designers can start implementing their ideas.

    Compilation of Polymorph Engine will also be tested on Windows 10.0.

    And François will take some time off from game development because he will teach Blender for the whole week at the summer workshops of iMAL. Don’t hesitate to join him if you’re interested, there might be some seat left.

    Thank you

    If you found this post interesting or want to follow Polymorph’s activities, don’t hesitate to subscribe to our RSS feed or our Twitter account. Don’t hesitate to leave us comments, ask us questions and, of course, forward this to those who might be interested.

Compose new post
Next post/Next comment
Previous post/Previous comment
Show/Hide comments
Go to top
Go to login
Show/Hide help
shift + esc