FreeGameDev Planet - Games

Also check out the development planet.

June 19, 2013

Frogatto

A response to Gaslamp Game’s “The Colors of Frogatto”

Quite a while back, the lead art dude over at Gaslamp Games did an article praising frogatto’s colors. Which … frankly, is just incredibly awesome. Appreciation from people whose work I admire is frankly one of the most flattering things that can happen to me. I’d been meaning to do a kickback on this for quite a while (I’ve had a half-finished draft of this post sitting around for almost a year and a half now), but never got around to it.

I figure that now is a good time, since we’ve recently done an overhaul of exactly the colors he talked about, in 1.3 (and especially since we now have something like 20+ different environment palettes where we used to have 4). Hopefully I can return the favor by getting some good discussion going, and telling what I know, for whatever it’s worth.

The state of the game as he reviewed it was the game as it appeared in 1.1 and earlier – as can be seen in these screenshots. The current look of the game can been seen in our current screenshots. I think the most striking bits were the overhaul to the seaside background and base palette.

Notice how much warmer the lighter colors are – the green and brown are pretty much the same shade of yellow at their lightest, while the stone’s gray takes on a noticeable brown tone at its highlights. On the other end, the green cools down even to the point of using a shade of blue while the stone goes toward a more neutral (and relatively cooler) gray.

The use of yellow as a (frequent) highlight color is because yellow is visually brighter than other colors – not in some touchy-feely “seems brighter” sense, but in a raw, colorimetric measurement of lumens. Our human color response is actually pretty unequal around the color wheel – it’s actually somewhat hard to use some colors like pink as a highlight, because once they go above a luminosity value (measured in L*a*b) of about 70, they start to lose their color identity, and just become a really pale grey. Green and yellow are bright choices; red and purple are a bit dark, some blues can be bright, but they collapse as you get towards indigo.

The use of a blue tone in the tree is particularly interesting. It’s actually lighter than the mid-dark green but is so much cooler that it fits with the shadowy parts of the leaves – and the blue reflects the ambient, bluer light of the sky rather than the direct yellow sunlight — the use of color in the tree tells us a lot, very subtly, about the lighting in the environment.

It’s interesting to hear the mental analysis behind this – this was actually meant to be reflected light in a classical shading-treatment of a sphere. From my perspective, the only mental analysis I was performing was “what direction is this surface facing?” That’s it – that’s the one and only thing determining how something gets shaded in frogatto. In regular drawings, one has to also consider changes in “what does that given direction point at?” when an object is in different places, but (without a real 3d simulation and some crazy shader stuff), that doesn’t apply to frogatto. In frogatto every object is shading like it’s hanging, all alone, in a sky/ground box.

Color can be used very subjectively. It doesn’t matter what exact color your color-picker displays, and it definitely doesn’t have to match the “naive” understanding of what color something is. What matters is how the color you use works in-context with the rest of the colors of the scene; Indeed, leaves can be blue.

This is probably the single most important idea, bar-none. Objects are not, by law, their “named” colors. Leaves can be blue because – in real life, under a blue sky, leaves which are facing at the right angle literally are blue. Not “I’m drawing them blue because of some artsy-fartsy personal interpretation” or some nonsense, but “you can point a colorimeter directly at them and it will read blue.”

This seriously flies in the face of human intuition – we’re tuned to think of all objects as being certain “named” colors. By intuition, grass is just always green, period. Water is always blue, wood is always brown – those just seem like immutable properties of physical materials. How can this be; if we can point a colorimeter (a scientific device which directly measures color) at a green leaf and have this machine read it as blue, how can our eyes mistake this and see it as green? The trick is that our brains are designed to speed visual-comprehension of the world by what basically amounts to “summarizing”. Our eyes take in all the input as it really is, but our brains auto-correct for the shifting of colors by changing lighting. They look at a leaf that’s got a blob of sunlight on a glossy edge, and say to us “well, under that sunlight, that’s really not yellow, it’s green”.

We’re hard-coded to react to how lighting changes so we can maintain continuity with what objects are what – our brains are finely tuned filters which ignore all the changes in the visual appearance of objects which are not changes to their basic, physical properties. This allowed our ancestors – all the way back to the very first mammals, to pick out the subtlest movements of living creatures against a backdrop of otherwise similar colors – to notice that one patch of color shifting was the movement of a creature, and not just the shifting of sunlight with the wind and the passing of clouds.

Two of the most common color distortions happen in exterior environments – there is a shift towards blue or indigo on the shaded side of objects, which is caused by being lit only by blue light from the sky, and no light from the sun (in effect like being hit only by a blue spotlight). Likewise, the yellow highlights on the sunny side of objects are because the light of the sun is yellow (since the sky filters out the blue). This dichotomy of yellow sunlight and blue skylight is a phenomenon that happens quite strongly in the real-world, and was also a favorite of impressionist artists. I think the impressionist were really marked by being the first group of artists who (whether intentionally or not) realized that most physical objects are actually lit by some pretty exotic colors, and that exaggerating those subtle effects still looked good.

[Yes, I've spoken out about how I don't care for using small fixed palettes in pixel art. The upside of the practice is that it forces artists to be very conscious about their color choices, so from that perspective it promotes some artistic rigor and, on occasion, very creative use of color.]

You’ll probably find this fascinating, but the biggest advantage of pixel art to me is the exact opposite of what you suggest – pixel art allows me to be completely careless about colors until the very end.

“But wait!” you say, “How can you start drawing without picking your palette of colors?” If you’re used to basically any other kind of painting, period, you pick your colors up-front, because once they’re blended at all on the canvas, you can only apply overall photoshop-style color-adjustment filters. On a portrait, for example, your five colors of skintone smear into hundreds of indistinguishable colors which can’t be picked out and modified individually – you can modify bands of resulting colors, but the “sets of source-brushstrokes in a certain color” don’t correlate with the “sets of color selected by a photoshop filter”. You can still tweak the colors, but you lose all control over the initial ingredients.

In pixel art, because the pixels are always fully opaque, they don’t blend whilst I paint. I might blend by dithering, but the colors themselves don’t get mixed. Because of this, I can change colors “as though they had been this color from the beginning” at any time. Up to and including at the very end. Most importantly, this means that rather than picking one set of interesting color-interactions in my palette, doing a art piece with it, and only being able to do one iteration of color-experiment in the lifetime of that piece, I’m able to as many as I would like. All I have to do is hit a given color with a paintbucket click.

When I was a beginner, I used to get hung up about worrying which colors I should use, but instead, I’ve found that the only important thing to worry about is the luminosity of the colors (as measured in a color space like HSV or LAB). If I get those right – and those are the things that determine the “volume” or apparent-3d-shape of a drawing – then the piece is solid, and I can always fix the hues and saturation later. This means I can plow ahead on a piece even if I can’t figure out the colors for the life of me, because later on, I can always fix the problem.

So actually rather than being really conscious and careful about color choices, pixel-art allows me to be incredibly _careless_ about color choices, because I know I can trivially fix them later. It moves the colors from being the foundation, to being the window-dressing.

In general, warm hues bring things forward, cool hues set things back. (Sometimes I like to play with inverting this rule to make a scene look weird.)

People constantly keep teaching that, but – I’ll be a bit daring here, and say that I personally think this rule is completely bogus. I’ve done A/B testing on this and changing a sky to red doesn’t seem to change its depth-of-field at all. I think this is like many other misconceptions that highly competent people have – for example, virtually all chefs, world-class ones included, swear that searing meat seals in all the moisture, helping to make a nice, juicy steak. The best chefs in the world swear by this – and it’s utterly false. The problem is one of memetic fitness – it’s not a big deal if they’re completely wrong about this, because the food’s (or art, in our case) is still good. So there’s nothing driving them to correct this misconception.

I think there’s a good body of evidence in real life that this isn’t true; red skies are quite common, whether from sunsets, smog, or nighttime city lighting – and so are red landscapes, such as the deserts of Arizona, the dry grasslands of Australia, Asia, Africa, and America – and all of these within a picture recede; they’re immediately and unconsciously recognizable as backgrounds, and don’t cause people any confusion by “popping forward” and seeming to be in the foreground.

So where, then, does Depth-of-field come from in a 2D drawing? By my reckoning, it seems to come more from the luminosity gamuts of the different parts. And the emphasis there is on “gamut” – not how bright/dark something is, but how far it changes from light-to-dark, and how frequently and sharply. Foregrounds use a full gamut of brightness, whereas backgrounds, even with a clear sky, have some hazing simply because plain air itself is slightly opaque. If you’ve ever looked at distant mountains, you know what I’m talking about. It’s especially the lack of dark blacks in the backgrounds that I think “pushes them back,” visually.

And how does this relate to Dredmor? Well, Dredmor is filled with pixel art. This art does indeed have colors in it, and I apply the above concepts to greater or lesser degrees, depending on the particular application.

There is not as much depth and exuberance as Frogatto, I must admit. The reasons for this are indeed My Problem and have something to do with the setting of Dungeons of Dredmor (a series of underground rooms), the format of Dredmor’s maps (randomly generated therefore somewhat generic by-necessity),

If you don’t mind my thoughts … I actually think it’s got more to do with the variety of tile types than anything else. I’ve found that no matter what you do, even when you (as you have quite nicely) vary an individual tile type with deformation and decay, having a single tile type for each “kind” of terrain just isn’t enough for a game environment. If you look at many of the classic snes games lauded for visual richness (including chrono trigger and SD3), many of them had 3-5 tile types in any given area. They didn’t just have “grass”, and “dirt”, and then call a scene done; they had multiple varieties of grass, and 2-3 different kinds of dirt, et cetera, on top of individual variations within each type. Just having some tattered rugs and such, having scattered straw, some large pavers mixed in with the regular tiles, and maybe even some patches of bare earth, all of which could be placed “randomly” (with some simple rules, like rugs are always a rectangle, etc), and I think you would really take your terrain to the next level – without changing the style at all, and without reworking any existing art.

by Jetrel at June 19, 2013 10:26 PM

Stellar Forces

New Graphics

It's been a while since I posted anything (again).  I've been working on adding lots of new scenery to Stellar Forces, as I think it makes a big difference to how the game is perceived.



I'm slowly adding more and more items, so I can add different ones to each map and so each map doesn't look exactly the same.

by noreply@blogger.com (Steve) at June 19, 2013 01:24 PM

June 17, 2013

FreeGamer

DevCorner: Underapprechiated game engines

In my never ending search for a FOSS game engine that is usable for game modding with out having to reinvent the wheel (nor requiring to be a C++ code master) & having decent tools for content creation (because I am spoiled and think that is a minimum requirement for a game engine) I have become quite disillusioned lately. That is because *spoiler alert* sadly there is none so far... but a few are close luckily.

The usual contenders for 3D action games are your mixed assortment of idTech based engines, most notably ioQuake3. There are a few upcoming contenders like Unvanquished's Daemon engine (which is a mix of ET:Wolf, ioQuake3 and Xreal) and a yet to emerge idTech4 based champion (my uninformed guess is that it will be dhewm3). But all of them lack a decent game-play scripting function.
On the other side of the idTech spectrum, there is the idTech1 based granddaddy DarkPlaces, which while having advanced to an quite impressive feature set, suffers a quite a bit from its nut-bolted & mostly undocumented client side add-on on the already a bit arcane script language QuakeC.

Interestingly the idTech2 based engines get little attention though. I have highlighted a few nice game projects based in it in the past, but it is probably due to the fact that each project is hacking on their own engine fork, that none has gained prominence as a game engine on it's own. But feature wise the engines behind AlienArena, Overdose and Warsow are probably the most advanced.
The last one of these, has been probably the most overlooked, with the game itself not exactly open-source friendly and the engine being developed more or less behind closed doors. It seems however that this has changed now, although given recent project news it is unclear what made them change their approach. But an all new version of it is now on Github with the main developer mentioning a few really nice changes here. Let's hope it isn't just a "source-drop" of a dying project, as after digging into it a bit (the documentation is really fragmented and lacking) I have to say that it includes a few really awesome features not commonly seen in other FOSS engines:
Besides being really performant, it is fully scriptable and has some quite unique multiplayer features like awards, friendlists and persistent game statistics. It also seems to make good process in having easy to edit GLSL shaders, which I have realized is a much rarer feature than I originally thought. Last but not least it has a really modern looking and fully scriptable menu and HUD.

Ah and before I move on to non-idTech based engines I should mention Engoo for those looking for a modernized software rendering engine based on idTech1 (there was some controversy over it, so I am trying to show some support for its further development here).

Ok, that covered, what are some maybe under appreciated non-idTech 3D engines?
First of all I should probably mention the well known ones for the sake of completeness: Cube2, Ogre3D and the new big player Torque3D. All of which are IMHO still failing to provide a good platform for easy game creation (mainly due, following the same order: in-fexibility & lack of scripting; huge mess of independent parts & bad toolchain; lack of Linux port & buggy and overly complicated toolchain).

One of the shining but lesser known examples of trying to improve the status quo is the jMoneky3 engine. Even though it is still a bit bare-bone (e.g. lacking game frameworks) the nicely integrated SDK and the great new node based GLSL shader editor keeps on attracting my attention. Similary the BlenderGameEngine sure has a few great advantages due to its tight integration. Sadly it seems to be the unliked stepchild of the Blender3D project though, which some quite serious limitations and awesome additions like the candy branch never reaching the the main release.

Then there are the still very much alive big names of the past: Irrlicht and Crystal Space. I am not exactly sure why those never quite reached the required mass to become the engines of choice, but I guess the license mess around Irrklang (and other non free but more or less required addons) and the CS Yo Frankie disaster might have to do with it. But at least Crystal Space was accepted as a hosting organization for this year's GSoC again, so they must be doing something right.

Last but not least, I would like to give a mention to a relatively new contender: Octaforge, which has supplied a steady stream of updated betas lately. The interesting things about Octaforge is that it takes all the good things from Cube2 and combines it with a much updated renderer (Tesseract) and full lua script support. But sadly it isn't quite there yet, and the move to a scripting language required the removal of all the nice game-code that it inherited from Cube2.

As closing remarks I have to admit that this article was rather lopsided towards FPS game engines (and more general purpose ones). Of course there are many great other game engines in the FOSS sphere that focus on RTS or (MMO)RPG games etc. I do however feel that many of the grievances voiced here probably apply there too, but maybe it isn't quite as frustrating there as in the FPS genre.
But if you have some better insights into those type of engines feel free to comment below!

tl;dr: the author (as an old school modder) is frustrated that after all these years there still isn't an FOSS FPS engine that can be modded as comfortably as the Half-Life2 engine or UDK. Don't miss the new qfusion stuff though.

by noreply@blogger.com (Julius) at June 17, 2013 09:25 PM

Hedgewars

Ongoing situation with mobile port

This is an official Call for Help on the Hedgewars mobile ports.

First of all let me say that *all* the code is still fully available and compilable; in other words, it should be still working fine and dandy on any mobile phone. The Android version currently in the repository is *much* more advanced and feature complete than current alpha on the GooglePlay store, it even has networking play! iOS has received a unified input manager from the Android port and a lot of merging steps have already been done.

We just need someone to look after the code, apply latest library updates and unify the interface module.

Currently it takes a lot of effort to maintain three separate architecture targets and most of the devs are focusing more on the desktop version; in order to develop for mobile a lot of the interface has to be rewritten, as well as input method, and, at least until a few months ago, the supporting libraries were not as mature as today.

Although most of the engine is fairly portable, Hedgewars has a completely separate 'frontend' module which is based on Qt/C++ but is implemented in native Uikit/Objc and Android/Java. This is nice because native development offers a more consistent look'n'feel, but it is a maintenance nightmare, as you have to backport your changes three times. There were some attempt to unify this situation in the past and proposals to have a single codebase to be used everywhere but we could never find a complete replacement.

The binary builds used to be provided by me for iOS and by Xeli and then Medo42 for Android but all of us have found themselves too busy with IRL projects. So if you read this and are interested in mobile development, GUI and game design, jump in, we will really appreciate your effort and you will make countless people happy of playing our game!

by Koda at June 17, 2013 12:38 PM

June 16, 2013

FAR Colony

Alpha 6 [0.6.0] (Late) Dev Status: Hydrosphere

The design of the hydrosphere is just finished this Saturday night. I'll begin to implement it this Sunday.
After that I will need to implement the Seasonal data + Clouds Cover and Albedo, and this step will be completed.

After that I will begin the final step of the FUG, the regions (including the Fractal Terrains link, the resources and the biosphere).

by JF Baconnet (noreply@blogger.com) at June 16, 2013 02:50 AM

Battle for Wesnoth

Wesnoth 1.11.4: Development Release

Wesnoth 1.11.4 has been released. This is the fourth release of the 1.11.x development series. It includes huge, groundbreaking changes. Please have a look this forum thread to get a rough idea about those big changes (including why it is called 1.11.4 and not 1.11.3). We offer two versions of changelogs: a rather nice to read players changelog that only includes changes every player will probably notice and the (rather) complete changelog with (almost) all the details, which is likely to cause a serious headache...
At the moment the Windows and OpenPandora packages are ready. You can find them at the download page. Once the others (e.g. the Mac OSX package) are done you can find them at the download page, too. Please keep in mind that it is a development release which might include quite many bugs. If you find one, please report it to help us fix it in following releases.
UPDATE (2013-06-09): The Mac OS X build is now available.

-- Delivered by Feed43 service

June 16, 2013 12:56 AM

Wesnoth 1.11.2: Development Release

Wesnoth 1.11.2 has been released. This is the third release of the 1.11.x development series. It includes huge, groundbreaking changes. Please have a look this forum thread to get a rough idea about those big changes. We offer two versions of changelogs: a rather nice to read players changelog that only includes changes every player will probably notice and the (rather) complete changelog with (almost) all the details, which is likely to cause a serious headache...
At the moment the Windows, Mac OS X and OpenPandora packages are ready. You can find them at the download page. Once the others are done you can find them at the download page, too. Please keep in mind that it is a development release which might include quite many bugs. If you find one, please report it to help us fix it in following releases.

-- Delivered by Feed43 service

June 16, 2013 12:56 AM

Wesnoth 1.10.6: Maintenance Release

Wesnoth 1.10.6 has been released. This is a bugfix release for the stable 1.10 series. For information about further changes in this release, please visit this forum thread.
We offer two versions of changelogs: a rather nice to read players changelog that only includes changes every player will probably notice (and often feels empty because devs tend to forget to add their stuff there) and the (rather) complete changelog with (almost) all the details, which might make your head spin due to the technical terms used every now and then...
At the moment the Windows, Mac OS X and OpenPandora packages are ready. You can find them at the download page. Once the others are done you can find them at the download page, too. If you find a bug, please report it to help us fix them in following releases.

-- Delivered by Feed43 service

June 16, 2013 12:56 AM

Wesnoth 1.11.1: Development Release

Wesnoth 1.11.1 has been released. This is the second release of the 1.11.x development series. It includes huge, groundbreaking changes. Please have a look this forum thread to get a rough idea about those big changes. We offer two versions of changelogs: a rather nice to read players changelog that only includes changes every player will probably notice and the (rather) complete changelog with (almost) all the details, which is likely to cause a serious headache...
At the moment the Windows, Mac OS X and OpenPandora packages are ready. You can find them at the download page. Once the others are done you can find them at the download page, too. Please keep in mind that it is a development release which might include quite many bugs. If you find one, please report it to help us fix it in following releases.

-- Delivered by Feed43 service

June 16, 2013 12:56 AM

Wesnoth 1.10.5: Maintenance Release

Wesnoth 1.10.5 has been released. This is a bugfix release for the stable 1.10 series. For information about further changes in this release, please visit this forum thread.
We offer two versions of changelogs: a rather nice to read players changelog that only includes changes every player will probably notice (and often feels empty because devs tend to forget to add their stuff there) and the (rather) complete changelog with (almost) all the details, which might make your head spin due to the technical terms used every now and then...
At the moment the Windows, Mac OS X and OpenPandora packages are ready. You can find them at the download page. Once the others are done you can find them at the download page, too. If you find a bug, please report it to help us fix them in following releases.

-- Delivered by Feed43 service

June 16, 2013 12:56 AM

Wesnoth 1.11.0: Development Release

Wesnoth 1.11.0 has been released. This is the first release of the brand new 1.11.x development series. It includes huge, groundbreaking changes. Please have a look this forum thread to get a rough idea about those big changes. We offer two versions of changelogs: a rather nice to read players changelog that only includes changes every player will probably notice and the (rather) complete changelog with (almost) all the details, which is likely to cause a serious headache...
At the moment the Windows, Mac OS X and OpenPandora packages are ready. You can find them at the download page. Once the others are done you can find them at the download page, too. Please keep in mind that it is a development release which might include quite many bugs. If you find one, please report it to help us fix it in following releases.

-- Delivered by Feed43 service

June 16, 2013 12:56 AM

Wesnoth 1.10.4: Maintenance Release

Wesnoth 1.10.4 has been released. This is a bugfix release for the stable 1.10 series. For information about further changes in this release, please visit this forum thread.
We offer two versions of changelogs: a rather nice to read players changelog that only includes changes every player will probably notice (and often feels empty because devs tend to forget to add their stuff there) and the (rather) complete changelog with (almost) all the details, which might make your head spin due to the technical terms used every now and then...
At the moment the Windows, Mac OS X and OpenPandora packages are ready. You can find them at the download page. Once the others are done you can find them at the download page, too. If you find a bug, please report it to help us fix them in following releases.

-- Delivered by Feed43 service

June 16, 2013 12:56 AM

June 15, 2013

Xonotic

Don’t Stand on the Respawn!

Shortly before the release of 0.7 community member Lady*D released her latest movie. It’s called “Don’t Stand on the Respawn” and it features some of our CTS community’s fastest players.

Don't Stand on the Respawn

Don’t Stand on the Respawn

You can watch the video online here or you can download the high quality version here.

Featured in the video are the following players:

  • Lady*D
  • Nimbuz
  • bunny
  • eThaD
  • entou_

I don’t know about you, but I think this is absolutely mesmerizing! I hope you enjoy it as much as I did. Thank you Lady*D for creating such top-notch stuff.

Join the discussion of the movie here.

by Antibody at June 15, 2013 09:19 PM

0 A.D.

0 A.D. Development Report #12

Wildfire Games, the international group of volunteers developing 0 A.D., are happy to present this week’s 0 A.D. development report.

If you want to find out more about the development of this open-source, cross-platform real-time strategy game or if you are interested in game development in general, it might provide an interesting read.

If you want to be part of this project, we urge you to post your application in our forums. We are currently looking for Gameplay, AI, Sound and Graphics Programmers along with Animators and 3D & texture artists. You prefer to do something else than programming or drawing? Luckily for your portfolio we are also looking for a Sound Lead, Video Editors, a Documentation Manager and Scenario Designers. Still no luck? Head to our forums and join our active community!

!!! We are in need of (skilled) programmers. If you are one, redirect yourself to this thread. Your contributions are crucial !!!

On Performance

Performance has been a major bottleneck for quite some time. We know the problems, and we are committed to resolve them. Last two months we’ve seen an influx of new contributors who are keen to help us fix the lag. sbte committed some patches (sim interpolation optimization) and a couple of memory leaks have been fixed (Markus). Kuranes has also been working on optimization and his work seems very promising. He added VBO support to minimap entity rendering (1,5 ms/frame to 0,8 ms/frame, which may seem trivial but every millisecond counts!). But this is just the tip of the iceberg, his many other optimizations are WIP or being reviewed by us, but when they are committed to the game the increase in performance will be noticeable! Last but not least we have Redfox, a retired 0 A.D. programmer who became active again. Currently he is working on font rendering, but like Kuranes, he is dedicated to implement major code optimizations, and he has the know-how. Their work will make 0 A.D. the enjoyable and fluid experience, you always wanted it to be!

Screenshot of the Month
Posted Image

Team News

Peter a.k.a. alpha123 has joined the programming team. Peter has contributed quite a few patches to the game and has been a valuable contributor in design discussions.

Programming, Art & Sound

Our new project lead, Mythos_Ruler has been busy as well. So busy in fact that I’m reluctant to write down all the things he has been working on last two months. The major new feature is the blacksmith. Although the models are placeholders for now, in the near future you’ll be able to upgrade your units in this new building. He also added new technologies, a new Spartan hero (Brasidas), rebalancing and tweaking the stats of almost every unit ingame, a new map, normal and specular map for desert terrain … we could go on and on, but we insist you check out our next alpha release.

historic_bruno committed a lot of patches and bug fixes. I’ll mention just a couple of them: updating Valgrind headers and fixing some memory leaks (patches by Markus), updating Boost Library to 1.53.0 and improving SDL 2.0 support among many other. He also added a game speed option to the match setup.

Leper also had a productive period. He cleaned up code, and reviewed and committed many functionality patches, that were written by contributors like Josh and KareemErgawy among others.

stwf has kept working on the Soundmanager. Memory leaks have been removed, code has been cleaned up and multiple song playlists are now used by civs that have multiple tracks defined.

Wraiitii committed a few fixes and improvements related to water. More importantly, he is completely reworking the water code: adding support for different water heights (e.g. lake vs. sea), optimizing foam and shore waves … On top of that, ships received a sinking animation! Never has loosing your fleet been more pleasant to watch.

Enrique has been working on shields, unit props and buildings for our next civilization: the Ptolemaic Egyptians! He is also designing, modeling and texturing the new blacksmiths.

Omri Lahav has been working on some new material for the Mauryans. He has just invited two new guest musicians (didgeridoo and celtic harp) to capture their performance. How many freeware, open-source projects have a live recorded soundtrack? We are sure you will hear the difference.

Yves is working hard on upgrading Spidermonkey. The first benchmarks are a bit disappointing, but Yves won’t give up. This is not a simple task, but in the end performance and functionality will benefit greatly from the upgrade.

alpha123 and quantumstate reworked the armor system. Damage = Attack – Armour was changed to: Damage = Attack * 0.9^Armour (in case your unit has a 10% armor bonus). This change was necessary as techs now have the same effect on each unit. So a 10% armour tech will decrease damage by 10% for every unit.

We also want to thank all our contributors that are committing patches with new features and fixes. Not all of them make it into the report, but we are grateful. We can’t do it without you guys and gals!

This month special kudos to sanderd17 who is giving archers range bonuses based on map height and Micket who modeled a Hippo and an Oryx (and a WIP tiger).

See you next month with the latest development news!

by plumo at June 15, 2013 03:37 PM

SuperTuxKart

"Next gen tracks" sneak preview


Hello my name is Jean-Manuel Clemençon (aka samuncle)
I'm the lead graphics artist.
I have been a contributor for a while but this is my first post.

Graphics is an important aspect in our game and since the last version I worked hard to improve graphics.
I made a new track that shows what I'm planning for the future of supertuxkart and two major improvements.

Old (new) mine

I cleaned up the mesh but the most visible improvement is the new lighting system with several lightmaps (and some dynamic lights). It's also more interactive with a Minecart that can knock the player if he forgot to check the traffic light.






Lighthouse

Lighthouse is a next gen track with around 70 000 poly (the average for a track is 20 000). It's the first track that uses our new vegetation shader for grass animation.

The track has also several animated objects like floating buoys in the sea and a dynamic skybox.

Zen Garden

When I made Zen garden in 2010 supertuxkart didn't support lightmaps. So I added some lights and a sunset. Caves are less empty with little blue fireflies.

 I'm not saying any more, you can discover by yourself ;)

by noreply@blogger.com (samuncle) at June 15, 2013 02:10 AM

June 14, 2013

Unknown Horizons

Animation and color overlays

Heya! Time for a short preview of some under-construction features developed with a not yet released version of our engine: FIFE added support for two techniques that allow changing how graphics are d...

June 14, 2013 07:52 PM

June 13, 2013

FreeGamer

Lost Sky Tactical J-RPG [PyGame]

Lost Sky is a PyGame-based Tactical J-RPG that runs on Linux, OS X and Windows.

To play on a system that has mercurial and pygame installed, run:

hg clone https://bitbucket.org/featheredmelody/lost-sky-project-public
cd lost-sky-project-public/Story\ of\ a\ Lost\ Sky/
chmod +x srpg.py
./srpg.py

Lost Sky screenshots


Story of a Lost Sky is a Turn Based Strategy RPG with gameplay that is similar to Fire Emblem. Units are placed on a tile map and each side takes turns moving and attacking. Outside the battle map, the player is able to customize their characters and equip new spells and traits.
This project was discovered by seeing a link banner on Valyria Tear's blog. Yay networking!

Code License: New BSD
Content License: Various: PD, CC-BY 3.0, CC-Sampling+ (non-free), Unknown

by noreply@blogger.com (Iwan Gabovitch) at June 13, 2013 03:11 PM