Apr
11

“BEWARE PLANET EARTH!” IS NOW AVAILABLE ON STEAM!

Hi friends,

“Beware Planet Earth!” is now available on Steam!

Click here to visit the game’s page!

This « Steam Edition » includes exclusive Valve content: new martians, new levels and some new achievements to unlock!

The game is available for $9.99 / 7.99€ / £6.99.

We hope you’ll like the new levels, have fun! :D

Mar
05

“BEWARE PLANET EARTH!” DISTRIBUTED BY BANDAI NAMCO…AND EXCLUSIVE STEAM CONTENT!

Hey there!
Good news everyone!

…Indeed, we are excited to announce that “Beware Planet Earth!” will be distributed by BANDAI NAMCO GAMES Europe on Steam and iOS! This partnership will allow us to handle calmly the Steam and mobile/tablet releases.

Here’s the page dedicated to the game on BANDAI NAMCO’s website!

Bandai Namco logo

Other good news is the Steam version of “Beware Planet Earth!” will include a brand new DLC, exclusive to Steam and featuring Valve-themed challenges! You’ll have to fight off Martians from Half-Life, Portal and Team Fortress 2! #ICanDieHappyNow


contenu exclusif Steam
▲Here’s a peek into the Steam-exclusive content…yay!

… And here’s a screenshot!

That’s it! Needless to say, we are super über happy to be able to pay an official tribute to those three games we are fans of! :D
See you later!

Feb
12

D-DAY FOR THE FLYING FARM!

Hi,

The Flying Farm is now available on the GameHouse website!

Click here to visit the game’s page!

This « Platinum Edition » includes some bonus levels, an artworks gallery and a strategy guide, for $19,99. The standard edition of the game will soon be available on Gamehouse for $9,99.

The Platinum Edition will be available in a few months on our website, and there might be a discount. We’ll keep you posted, so stay tuned! ;)

Feb
07

2014: A TRANSITION FOR LIGHTMARE STUDIO

Hi there!

Today, we won’t be talking too much about “Beware Planet Earth!” and The Flying. Instead, here’s a short article about the studio itself; our dreams and how we envision the next few years.
2014 will be a watershed year for us and how well both these titles will perform commercially will have a strong impact on our next projects. In a perfect world in which dollars keep flowing from everywhere, here are our intentions…

Lighmare Logo

In the first two games, we’ve chosen a “mainstream/casual” approach, both gameplay-wise and art-wise. We now wish to move towards more mature and serious projects (which doesn’t necessarily implies overly dramatic tones or strong, charged narratives). Our goal is still to make fun, accessible and intuitive games.
We’d like to make games that would be tributes to our childhood games, or games like amazing games we enjoy playing now. This intention, as well as the thematics and art direction, will also be made clear in games in which the replay factor is key, in which the game play loop is cyclic by nature (e.g.Faster Than Light or Dungeon of the Endless, in which each game features a unique, procedurally generated combination of elements that provide a unique experience each time you play…)

The PC is, to us, the platform that suits this intention best, and it is also the one we feel most comfortable with, to communicate as well as develop. Even though the mobile ports of our titles are still under way, we do not quite have enough budget and time to steer fully towards this market, which still feels quite incertain and hard to understand to us.

Lighmare Logo

We also feel we did not quite take enough time to communicate about The Flying Farm; communication with players is one of the pillars around which Lightmare Studio, and we’d like to refocus those efforts.

What that means is: we’d like to involve the community earlier in the projects by showing and explaining them soon in the process. Communicating very early (from preproduction and on) is a risk, because it implies we’ll have to explain why a project’s orientation changes halfway through production or is canceled. Regardless of that, we are willing to take this risk because we believe having players’ feedback early in the project’s life will have a very positive impact upon the game’s content as well as the team’s morale! :)

To link your feedback to the game content is something we truly want to make happen. We are currently thinking about which tools to choose or devise to give player feedback more importance.
This might take the form, for example, of alpha funding campaign, during which you could give us feedback and suggestions on our forum as soon as a game’s Alpha version. This could also take the form of a vote on an artistic or game play decision on our forum or Facebook. We’re also thinking about creating a newsletter because it is easy to miss important information on Facebook or Twitter.
We believe that with such tools, players would be able to actually involve themselves in the game’s development and this way, everybody would get something out of it. Speaking of which, if you have any suggestion regarding this very matter, we are listening! :)

Last but not least: this article is waaaay too serious and cruelly lacks in humor. We’d like to share the best video of a cat jumping we know, the cornerstone of good communication over the Internet :

Cheers, and see you very soon! :D

Dec
20

MORE DETAILS ABOUT THE FLYING FARM

Hi there!
This is time for us to show more of The Flying Farm!…and do dive in right away, what’s better than a piece of music from the game?


(the score is from Aurélien Piters again, our thanks to him!)

Now, about the story and gameplay…

As you already know, The Flying Farm is set in the same universe as “Beware Planet Earth!”. As such, you will find Barney, our cowardly rancher, locked as always in his outhouse. Running a ranch requires a lot of time and energy, and that is the reason why this genius gadgeteer as built a small flying robot called Marvin (aka MRV-42-Mk-1) to help him!

Jaquettes pirates

You get to man Marvin and give him orders! You’ll be able, through him, to interact with the various elements of the game: grow, water and harvest crops, fix broken machines, or feed and tend animals, as well as many other tasks.

You’ll also meet Heather. She escaped the hustle of the big city to work at Barney’s peaceful ranch, and she will give you lots of advice about new crops or how to take care of your animals.

But things will get complicated soon enough… after a couple of days, the team will find out that a baby starling has crash-landed in the backyard and seems to be far from home. Marvin will manage to decipher its complicated language, and him, Barney and Heather will decide to take him back…on the Moon!

Starling et Heather

The Flying Farm is a time management game: you will have a limited amount of time (3 to 5 minutes for example), to grow, harvest and cook various products required by Barney to run his ranch. You’ll have to give optimized orders to Marvin by setting waypoints so that he completes the order as fast as possible.

The amount of time given to you on each level is divided into two parts: one is “gold”, the rest “normal”. The more dedicated players may try to go for the challenge and try to finish all levels with gold awarded to unlock some achievements, whereas the normal time is longer and will allow most players to finish the levels while still offering some challenge.

A special “Casual Mode” is also available: this mode will allow you to complete all the levels of the Story Mode without a time limit. We noticed that some players (especially younger ones), were having fun just trying to complete the levels at their pace, while experimenting with recipes. And so we decided to implement this mode, so that everybody, even kids, can enjoy the game.

▲ Yes, you can grow tomatoes on the Moon!

But that’s not all! There is another challenge: the endless mode! In this mode, all products have a value (in dollars), and a certain amount of money will be required for you to earn at the end of each term (which typically lasts 1 or 2 minutes). You’ll have to choose carefully which products you prefer to cook or grow in order to reach the required amount of money, thus passing as many terms as possible!

Roaming the world and take the baby starling back to its parents won’t be an easy task, and you will have to travel through the skies, the ocean and even a volcano on your way to the Moon! You may see below a glimpse of the settings you’ll find in the game!

Jaquettes pirates
▲ Under the sea…under the sea…♪

The “beta test” phase is now over and the game is finished! Some of you gave us feedback on our forum, and we’ve taken it into account and added most of yours comments! We sincerely thank you again for your comments and support!
However, we can’t give any release date as of yet, because we’re still discussing things with various distributors to release The Flying Farm on PC and mobile phones in the best possible conditions! If everything’s good the game should be available by the first quarter of 2014, for the PC.

Here’s a gameplay video:

Merry christmas to all of you, and enjoy your holidays! :D

Oct
16

“10 SECONDS LEFT, MR. PINK RABBIT!” POST MORTEM

From August the 23rd to the 26th, the whole team gathered to take part in Ludum Dare #27 (Jam), a kind of friendly game creation mini-contest. The rule was to create a game within 72 hours, with the theme “10 Seconds”.
“10 seconds left, Mr. Pink Rabbit!” is what came out of this jam!

Here is the “postmortem” of our 3-day journey!

Mr. Pink Rabbit

What Went Neither Especially Right Nor Wrong But Is Worth Noting

- Everything goes fast, even emotions: it’s funny to see how we felt the same emotions as we would have during a “real” 6-9 months project (excitement, creative rush, discouragement, tension, sadness,, weariness, final exhilaration, pride, etc.) in the same order and at roughly the same moments of the development. It’s as if we were in a time bubble where everything goes real fast and all of a sudden — BOOM! The project is over, we can celebrate as if we had been working on it for the past year.

- Much in the same way, we feel we actually brought a project – however modest and narrow-scoped it might be - to fruition. That is pretty much, to me at least, the whole point of entering a Ludum Dare. As the organizers put it: LD is here to give us an excuse to hatch a game. And that feels good and gives a motivation boost for the “normal” projects.

- Working under a 72h constraint and an imposed theme was a first for all of us, and it was a pretty intense! Constraints are almost always great for creativity because it forces you to focus, keep motivated and think astutely about how you will create stuff.

- It is interesting to see that not everybody tackles the very concept of the LD jam with a common mind set. Partly that went wrong (see below), but mostly it’s just an “interesting fact”.

L'équipe qui pose devant l'écran titre du jeu, les mines fatiguées
▲ Sure, now that the game is done we’re smiling…but at what cost?

What Went Right

- Choosing a third party IDE over our in-house engine: this was actually decided long before we started the jam. There were two main reasons: first, it allowed me – Foug, to take part in the coding process. My meagre programming skills are limited to Game Maker: Studio with which I have a long-time experience. Secondly, our in-house engine, Black Hand, is powerful and reliable (we can import .swf animations as 2D skins for example), but it’s still under ongoing development as any in-house technology, and while some features would have been overkill for a 72 hour jam, some vital others could have been missing at a critical moment (I have no example to give and that’s part of the problem: we are simply unsure how and when we would have been limited, IF we had been limited).
So Game Maker: Studio (Pro and Standard version) was chosen. As we will see in “What went wrong”, it comes with its lot of flaws and incomprehensible limitations. But overall it was a good choice, if only for the dual-coder capacity.

- Living together in the same flat for the duration of the jam: this point does not seem to sound obvious to many jammers but to us it was important to regroup at a common place and work together with a common sleep and meal schedule. We deemed it to be important to limit the risks of having some of us oversleep at their place or be distracted by external factors and, in hindsight, it turned out to be a very good decision because we had an almost perfect synchronization.

- Keeping a good sleep/nap/break schedule: it might be because we’re getting old (we are all around 30 years old), but we felt right away that we wouldn’t be able to crunch-time our way through 72 hours straight. It would have been madness (and not even SPARTAAAA!!!1!11!) to even try. Because making games is also our job, we know how important it is to abide by the “fair and softly goes far in a day” saying. We managed to cram in a perfect 6-7h night’s sleep every day, with power naps here and there when nodding off. It allowed us to be almost 100% dedicated to work during waking hours. We even had time to watch the WCS finals :D We reckon approximately 50 full hours of work per person (minus a little less than one day for one of us that couldn’t be here on Saturday).

- Managing to keep a healthy lifestyle: “a healthy mind in a healthy body”; it goes with a good sleep schedule, but it is important to listen to your body and not overload it with junk food, energy drinks and caffeine. We did eat a lot of salty, fat and sweet food, but we didn’t go overboard as we would have during a purely non productive LAN party.

- There is no “i” in “team”: being a tightly knit team of developers (and friends!) gave us a edge in the production flow. Autonomy is key, too.

- Recording the sound effects by mouth, as well as the vocal music, was a ton of fun and gave surprisingly decent results. Writing the game’s page with fake reviews on our website was fun too :)

- In spite of the sporadic tensions and fights now and then, we feel that, overall, our bonds as a team and as friends have been strengthened.

Fab pose au milieu des pizzas
▲ “PIZZA TIME!”

What Went Wrong

- A clash of visions: while having dinner by the end of the second day, we started discussing how we felt about the project. It turned out we didn’t have a common vision of what it should have been (although it may sound paradoxical because we were perfectly aware of the design goals, the limitations and of all tasks to do).

Some of us had regrets that we didn’t spend more time finding a more original concept or clever interpretation of the theme, even if it meant delivering a half-baked game, while others wanted to kick off as soon as possible and deliver the best possible game in 72h. However, because we tackled the problem relatively early we could start singing on the same song sheet and the last day was exhilarating partly because of that. If we ever enter another jam, the vision will be agreed upon beforehand so I guess you have to learn it somewhere :)

- Debriefing too soon: this conversation around dinner of the 2nd day was also something of an unofficial debriefing. The problem with this kind of unofficial meetings is that you can’t anticipate or prevent them from happening. But what can go wrong with a short conversation?

Well, the problem is, we sounded like the jam was already over and we were judging a finished game when, in fact, we were closer to alpha than master. So basically some of us were a bit disappointed by how the game turned out and we had a fight over personality clashes. Might not be such a bad thing but the atmosphere was uselessly awkward for the rest of the day because of that. Again, it allowed us to make proper adjustment and be on the best possible tracks for the last day of the jam.

- Perforce and Game Maker: Studio don’t mix well! We had quite a hard time merging the resources, especially the first two days when both coders had to work on the same things. Game Maker: Studio has a huge flaw when you don’t work with its embedded source control options (which we couldn’t use because only one of us had a Pro license): whenever you save or launch the project, for some reason, GMS opens and writes ALL the files in the project, even if it doesn’t change anything. Should even one single file be read-only, you’d screw up the project file immediately.

So everybody working on the repo needs to checkout ALL the files at any given time. The problem? Well, because Perforce sees files checked out, it will systematically ask you to resolve merges before checking in even if you didn’t bring any changes to the files others were working on. It was not such a big deal by the end of the project when little changed at each check-in, but it was horrible to maintain the first two days!

 

L'équipe, concentrée
▲ “‘kay guys, try to look busy, I’m taking a picture!”
Jul
19

“BEWARE PLANET EARTH!” PATCH 1.2.5

Hi!

If you have experienced a problem due to the previous patch (1.2.4), you can now fix it and run the game with the patch 1.2.5!

You can download this patch here!

Menu

All the details about this update can be found on our forum.

Have a nice game, everybody! :D

Jul
12

“BEWARE PLANET EARTH!” PATCH 1.2.4

Hi there!

A new patch is now available for “Beware Planet Earth!”: it fixes a few bugs and add some optimizations to the game.

You can download this patch here!

Menu

All the details about this update can be found on our forum.

Have a nice game, everybody! :D

Jun
18

A REPORT ON THE STUDIO AND OUR PROJECTS…

Hi everybody!

It’s almost been one year since we shipped “Beware Planet Earth!” for the PC, and, recently, there’s been an increasing number of people asking us what we are up to, and what will be our next projects. Now seems a good time to give a report about the last year, and to look forward the future!

“Beware planet Earth!”, 12 months after…

In a few days, we’ll celebrate “Beware Planet Earth!”‘s first anniversary. We brought the game to 12 digital marketplaces, both to PC and MAC. Le game was also made available through 3 independent game bundles. Distribution through Steam looks bleak: the game is far from making it to Top 100, it is clearly identified as a “casual game” by Steam users and has little to no chance to be Greenlit.

Beware Planet Earth

 
This first project taught us a lot, especially about publishing and distributing a PC game as well as managing the communication aspect through social networks and specialized websites.

First, good news: press feedback was, overall, quite positive, and player feedback was VERY good. It’s been an excellent surprise to us because we couldn’t really know how the game would be received. It was available from our very own website, as well as other distribution website, and through indie bundles (in which its individual price was low), which is the bulk of the sales. All of these amount to around 20,000 copies sold, which is a somewhat modest success but still quite a good beginning and on which we can base our future efforts to develop new games, which in turn will hopefully be more widely distributed.

In spite of this, the other side of the coin is that “Beware Planet Earth!” can’t be regarded, as of today, as a profitable product. This could definitely change in the future (especially with the iOS version), but to us it is more of a good callback card to introduce the studio to partners and gamers. Unlike what one may think, it is still a significant benefit, if only for what it taught us.

Our primary mistake was to underestimate the time, effort and money needed for marketing and communication: making a great game is around 50% of the whole project, and getting the game known requires a tough investment, especially if the studio has a low marketing budget, and nobody who is fully dedicated to communication in the team.

And yet, our work on “Beware Planet Earth!” is not over: the game is still being patched to fix the remaining issues that we know about through player feedback, it will also be available in 6 additional languages, and will be distributed through new channels as well as other indie bundles later in 2013.

Beware Planet Earth on Ipad

 
The iOS version (for tablets) is also almost ready to be launched: there are still some optimizations and ergonomic tweaks to make to fit the platform, and the pacing of levels has been redefined in order to make the experience more pleasant on tablets. We are currently looking for a publisher for this version; the mobile market is widely unknown to us and we are not eager to take a risk of releasing the game to the AppStore on our own. We could, but working with a publisher on the distribution process will teach us a lot and spare us a lot of trial and error.

“So, what’s next?”

Well to put it clearly, transitioning from “Beware Planet Earth!” to the rest was no simple task. The upcoming projects were to be greatly affected by the first game’s performance, and because we like to do things the “easy” way… we went for several possibilities at the same time! :D

The first project we’ve been working on for some months is a “Beware Planet Earth!” spin-off named…”The Flying Farm”! You may have already noticed that the blog’s been updated accordingly!

“The Flying Farm” will take place in the same universe as “Beware Planet Earth!” and will bring new characters and locations! It’s not a tower defense game, it’s a time management game. We’ll be back soon and show more about it, and let you have a glimpse at the development process now and then, just as we did for “Beware Planet Earth!”.

We went for this project for two reasons. First, there is an artistic as well as an economic balance: we wanted to expand “Beware Planet Earth!”‘s universe and add depth to it. At the same time, creating a new game from existing material is “simpler”, not only from an artistic standpoint, but also because it requires less new development tools.

The Flying Farm

 
The second reason is about long-term strategy: “The Flying Farm” will prevent us from leaving “Beware Planet Earth!” to gather dust in one of the dark recesses of the net, because both game will strengthen each other up as we will communicate about them. We believe that people who liked “Beware Planet Earth!” will enjoy playing “The Flying Farm” :)

Last but not least: although we’re still being independently funded for this project and will retain intellectual property and creative content, we are planning to let the game’s commercialization be handled by a publisher or a digital distribution channel. We learned our lesson as to the distribution and communication of “Beware Planet Earth!”, we wouldn’t like to make the same mistakes with “The Flying Farm” now, would we?

…but that’s not all!
Martians, robots, farms and talking outhouses may be good, but we’d actually like to make something a little more… “mature”. We have several possible projects in mind, and we’ve begun working on one of those. Unfortunately we can’t tell much about it for the time being, because we still don’t know whether or not we’ll be able to afford its development, but we’d like to share a little bit with you…

 
And…that pretty much wraps it up!
See you very soon for more about “The Flying Farm”!

May
24

ABOUT “BLACK HAND”, OUR IN-HOUSE ENGINE…

Since the release of “Beware Planet Earth!”, I’ve been asked several times a bunch of questions about the libraries, environments and the languages I used for the engine and the game. And so I decided to write a “short” article to explain all that.
First, the language with which both the engine and “Beware Planet Earth !” were written is C++. The reasons? First, C++ is a native language and can be easily ported to almost all platforms. It’s also a language that allows for a lot of control on various things; the memory management in particular. It offers better performance than JAVA, while offering better portability than C#, for example.
Of course, some of you might say “hey C# can be ported everywhere; there’s Mono, it’s great!”, and yes, it may be; but here you get the problem of depending on a middleware – which you can go without if you change languages. This can make your development impossible or at least very hard, should the middleware’s developer stop supporting it.

C++

 
Indeed, the primary goal of our in-house engine is to last long, and for it to do so, we have rely as little as possible on external resources. When those become essential, it is vital that they are limited to independant modules, or even encapsulated. If we depend on a tool such as Mono, it is the whole engine (and the game with it), that will be tied to an external technology, and we take the risk of being forced to rewrite it entirely, should a big problem arise (for example in another language).
That being said, there’s a moment when relying on external software becomes nigh inevitable. In Black Hand (Lightmare’s in-house engine), three modules depend on external libraries: sound, graphics and scripts. When we chose to implement them, we have made it bearing in mind the possibility of porting the engine to various platforms.

For the graphics part…well, I’ll start by saying the exact opposite I’ve been saying so far! The first library which was implemented for the display engine was DirectX. “Yeah, talk about portability!” So, why on earth would I choose that, of all libraries? Primarily because it is quick to use and set up. We’re working on PC and starting with DirectX was a good “temporary” solution.

DirectX

 
Indeed, DirectX is more than a mere display library; it also features various handy side routines. For example, it allows us to load various graphic file types to implement the texturing system, and spares us the use of multiple graphic file loading libraries.
This in turn allowed us to postpone the final choice as to what would be the unique file type we would be using for graphics. For example, while we were developing “Beware Planet Earth!”, we seamlessly went through two different graphic file types using this system. In the early stages of development, we also used the text font loader embedded in DirectX. Then, later in the development, those features were generalized in order not to rely on DirectX anymore, and being able to use other display libraries.
When the time for various ports of the display system arrived, we “simply” had to rewrite some of the display routines in OpenGL for Mac, OpenGL ES for iOS as well as some more in specific OpenGL for Windows, in order to be able to switch between OpenGL and DirectX on PC.
We’re pondering whether going with or without DirectX in the future, but we haven’t made up our mind yet. The reason is that this part of the code, as small as it is, requires specific maintenance. On the other hand, the one reason that prevented from dropping DirectX sooner is that it offers more powerful on (very) old graphic cards, which is still the average hardware our target audience is using.

As for the sound engine, we went for OpenAL pretty soon, because it’s a portable library, quite powerful regarding our needs, and it is free, which is not the worst part, especially considering the price of commercial use audio libraries!

OpenAL and AngelScript

 
Last but not least, for the script part of the game, we chose AngelScript after long researches. Initially, the game was meant to run a lot more script than it did eventually. The script code was to amount to up to 60-70% of the total game code (the enginz’s code is native and not taken into account here). The initial criteria of choice were based on this, but eventually, only the interface and levels’ introductions were scripted this way. Our criteria for this were:

  • the language had to be compiled/precompiled for good performance
  • it had to have strong typing to make debugging easy while preventing “dumb” mistakes…
  • …and ideally it had to be object oriented for the code reading/writing simplicity – which is admittedly a matter of personal taste.
  • and lastly the library had to be portable, and there had to be an active community that would use and maintain it.

Eventually, all those criteria were satisfied by AngelScript, its creator being incredibly reactive and easy to contact, and the community being quite impressive as well. Performance was never an issue with AngelScript because no functionality vital to performance was implemented using it. On the other hand, the language being object oriented and close to C++, its complex syntax didn’t allow for much intervention from the “non programmers” in the team. It’s one of the few negative points we’ll be working on during the upcoming projects, but we will still be using AngelScript in the medium term.

Now concerning the IDE (Integrated Development Environment), we used Microsoft Visual Studio 2008 for the PC and xCode 4 for Mac/iOS. The versions themselves were limited to what would be compatible with our target platforms (Windows 2000 was initially planned, then dropped).

I hope that this article has made Lightmare’s technological choices a bit clearer; please don’t hesitate to comment or ask questions about the article itself or other technical aspects!