Data Dealer, an interesting project to fund!

The the last Kickstarter game project we featured was sadly not successful and with only 11 days to go it doesn't look too good for Data Dealer either. But this HTML5 and CC-by-SA licensed game project comes with a pretty cool idea and is quite playable already.



It centers around the idea that services like Facebook & Google really arn't in the business of bringing you a good service (aka "If you are not paying for it, you're not the customer; you're the product being sold") and makes a ironic game out of that.

Here is game-play trailer to give you an better idea:



Or try the current demo on their webpage.

Now of course as we have all recently learned (or at least got confirmation about), the reality is even more twisted than just the private business side of things. But over the revelations of the mass surveillance by the NSA & Co., we should still not forget that all those big internet companies arn't victims by far either.

P.S.: My best wishes go out to Mr. Snowden! You are a hero of our generation.

Read More

Games Course Alumni Postcards

We're pleased to feature some of  our recent Alumni postcards here.
So very proud of the success of our graduates :)

Read More

Unvanquished summer tournament

Given the often quite small online communities around FOSS games, one has to become creative on how to keep players and attract new ones. Regular tournaments are one of those good ideas, albeit one that is a lot of work organizing.
One of the games that is still struggling to attract a stable player base is Unvanquished, even though the game is based on Tremulous and thus quite well developed game-play wise.

Don't hide from the Aliens

However for those complaining about it being the "same old" just with fancy graphics, they have implemented an all new resource and base building system, which will be also used in the tournament! To quote them:

Your tactics may need to change to compensate for this, but you can always test out the new gameplay on our development server beforehand, as well as by attending and observing our weekly development games on Saturdays. An explanation of the differences between our gameplay and the classic Tremulous variety will be explained in a helpful guide that we will provide to you shortly. Most notably, camping is no longer a desirable tactic, and map control is the new focus.

They said "no more camping" !"§$%&/!!!

So where can you learn more about this tournament? Well follow the previous link ;) The event will begin in the middle of July, with the first matches held on the weekend of Friday, July 19th through Sunday, July 21st.But if you manage to pass those rounds, you will have to plan for some matches on the following weekend too.
Registration starts on the 1st of July and you will need at least 3 other people on your team. I would naturally suggest a FreeGamer team, however due to my current bad internet connection, it is sadly not possible for me to join. But I hope some of the matches will be recored so that we can cover them here on the blog too :)

Read More

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.

Read More

Porting SimBlob to the web

I first saw Emscripten a few years ago. It compiled C++ to
Javascript. My mind boggled! How cool! This year at
Game Developers Conference there was a talk showing that Emscripten
plus asm.js
could run C++ games in the browser with good performance. I was
amazed.

After publishing my article on hex grids, I decided I should do
something different for a little while. I remembered Emscripten looked
intriguing, and I should try it out. Could I make BlobCity, an OS/2-only game from 15 years ago, run in the browser?

TL;DR: Yes, try it out here!

Here's what I started with, a game that only runs in OS/2:

Porting to SDL

The first problem is that SimBlob (the simulation/game engine for
BlobCity) is written for multithreaded OS/2, using the Presentation
Manager graphical library. The game isn't cross-platform, and nobody
uses OS/2 anymore. Even I couldn't run my own game, even as a
reference for this port. To use Emscripten, I needed to make SimBlob
work with either SDL or OpenGL. I chose SDL as a better match.

I'm developing on a Mac with Homebrew, so I used brew install sdl to
get SDL. I went through a few examples from this tutorial, then used
the SDL docs as a reference.

I took inventory of the SimBlob modules. Only one third of the code
was independent of OS/2. Yuck. I was hoping that it'd be better than
that. That means I have 10,000 lines of code that I need to
port. Ugh. Do I really want to do this?

I decided it'd be ok to port just part of the game. After all, my main
goal was to play with Emscripten, not to make BlobCity run. I first
got the simulation code running, and output the map in ASCII. Then I
made some simple rendering code in SDL. After a bit of fighting with
SDL, I got things to work. The game simulation was
running successfully, and showed up in the minimap!

I started wondering how much work it would be to make the main map
display. I started digging into the code, cursing at my 15-year-ago
self for making it so convoluted and undocumented. I commented out
OS/2 specific code, or created extra typedefs and no-op functions to
make it compile. After I had it compiling, over the next week I either
ported OS/2-specific code to SDL, or I emulated parts of the OS/2 API
in SDL. Some notes:

• OS/2 has a vector graphics object called "PS" in my code. It handles
  text, line drawing, rectangles, etc. If I were porting directly to
  Canvas or SVG or Flash, I would have equivalent vector graphics
  available. SDL has only a subset of this functionality in SDL_gfx and SDL_ttf, and Emscripten has only a small subset of that, so I decided not to port that code.
  


• OS/2 has multiple overlapping windows, each with an event
  handler. SDL has none of this. At first I decided to comment out the
  code, and hard-code the main map and minimap. As the week went on,
  and I wanted the toolbar, status bar, and tabbed information pane, I
  ported the display code to SDL and emulated multiple windows with
  their own event loops.
  


• The multiple layers in my code made porting easier in some ways. The
  Window hierarchy had a subclass that only dealt with bitmaps, so I
  could port that to SDL, and the Glyph hierarchy didn't deal with
  OS/2 at all. Most of the game graphics are rendered to an
  platform-independent bitmap.
  


• Without the vector graphics and text rendering, I couldn't generate
  the procedural graphics at run time. The code generated these and
  saved them to files, so I was able to reuse those files. I can't
  regenerate them but at least I can use them.
  


• The OS/2 blitting code used multiple approaches, WinDrawBitmap,
  GpiDrawBits, DIVE. I also used heuristics to choose blitting on
  the fly (each frame) based on the size of the dirty rectangles. This
  extra layer made it easier to plug in SDL as a rendering target.
  


• I had wrappers around OS/2 low-level data types: colors, sizes,
  points, rectangles, damage regions, mutexes, event semaphores. I
  reimplemented these to not use OS/2. Since I wasn't going to use
  threads this time, mutexes and related constructs became no-ops.
  


• I also found a bug that's been there for over 15 years. If more than
  one builder tries to do a job, the first one does it and the second
  one undoes it. In a typical game you have only one builder working
  at a time, so this bug escaped my detection until now.
  

Over the period of a week, I continued to either port OS/2 specific
code or emulate OS/2 APIs, and I ended up getting almost all of the
code running. The only thing I didn't tackle was the OS/2 menubar.

Getting a little bit drawing on the screen encouraged me to work on more.

Here's a screenshot of the SDL version – looks the same as the OS/2
version except for the menus!

Using Emscripten

Setting up emscripten: I installed llvm and clang through homebrew
(brew install llvm --using-clang). Note that clang on the Mac isn't
enough. It doesn't have the right version number, and it doesn't
include the rest of LLVM. And using the Homebrew regular install
(brew install llvm) isn't enough. I needed to install both through
Homebrew.

I used the Emscripten FAQ and the #emscripten IRC channel on
irc.mozilla.org as references. I also read through some of the
Emscripten code when I needed to understand what was going on.

The first thing the Emscripten limitations page says is that it
"CANNOT compile Code that is multithreaded and uses shared state. JS
has threads - web workers - but they cannot share state, instead they
pass messages." SimBlob is very much multithreaded. Yikes!

Other notes:

• OS/2 is multithreaded. This was one of the reasons I was using OS/2
  instead of Windows 3. For SimBlob, I had multiple main loops running
  simultaneously, communicating with event semaphores, shared state, and
  lock-free data structures. To make this work with Emscripten, I had
  to switch to a single threaded model. I had to merge all the main
  loops together into a single SDL event loop. It wasn't as bad as I
  had feared. Although I could've used threads with SDL, Javascript is
  event-based, and Emscripten wouldn't work if I left the game
  multithreaded. Emscripten needs the standard SDL event loop changed to this.
  


• SimBlob uses an 8-bit palette. I got this ported to SDL, but I had
  some trouble making it work in Emscripten. I decided it'd be easier
  to switch to 32-bit color. Since the game graphics draw to my own
  bitmap structures, I used the palette there, and expanded the
  palette when copying it over to the SDL surface.
  


• There's an Emscripten open issue that recommends disabling
  "copy on lock" to make palettes work. I had tried this out, but
  didn't need this anymore once I switched to 32-bit color. But I saw
  no harm in keeping it disabled. As far as I can tell, if you disable
  it, it will not copy the browser canvas back to your internal SDL
  surface. I don't need that copy.
  


• The binary includes SDL, so it's relatively large. Use -O2 to
  shrink it. I also needed -O2 to make the simulation code run
  acceptably fast.
  


• SDL's event.type is Uint8 in the SDL docs, but Emscripten needs
  more than 8 bits. I ended up using an int instead, but keep this
  in mind when porting your code.
  


• I had considered implementing the OS/2 menus on the HTML side, and
  then using Javascript to send those events back to the C++ code. To
  do this, you need to export some of the C++ code using "C" linkage,
  and then listing those functions in the command line flags, -s LINKABLE=1 -s EXPORTED_FUNCTIONS "['main', '_invoke_command']" You
  can then import the function into the Javascript side with
  invoke_command = Module.cwrap('invoke_command', 'void', ['number']) although for reasons I don't yet understand I was able to call _invoke_command directly without the wrapper. I added buttons for each of the OS/2 commands, and had those buttons call into the C++ code.
  


• I also used these flags: --jcache -s ASM_JS=1 -s WARN_ON_UNDEFINED_SYMBOLS=1
  


• I wanted the game to start with the window size I used back in 1997,
  but a large window makes the game more fun to play. I added resize
  support to the SDL version, then added a "Zoom" button to resize in
  the browser. You can call Browser.setCanvasSize(width, height) to
  do this. I experimented with full screen but haven't gotten that working.
  


• It was awesome to see the game running in the browser, but even more
  awesome to see it running on my phone! Emscripten needs
  Float64Array which is supported in iOS 6 but not iOS 5. The game
  also runs on Android 4.1; I haven't tried it on older versions of
  Android. It runs very slowly but it runs.
  
  
  
  


• Once I saw it running on the phone, I decided to add touch event
  support. I trapped touchstart, touchmove, and touchend and
  redirected them to SDL mouse down/move/up. This makes it feel much
  nicer on iOS. It didn't seem to help as much on Android.
  


• I had to switch drawing byte order when using the putpixel() code
  from SDL's docs. I filed a bug, but the workaround is easy. It's one
  of the few places where I have #ifdef EMSCRIPTEN in my code.
  


• SDL_GetKeyState() wasn't supported; I worked around it by tracking down/up events myself.
  


• Shift, control, alt modifiers didn't show up in Emscripten. SDL
  event.key.keysym.mod always contained 0. I filed a bug, and
  inolen on irc gave me a branch with a fix.
  

The process of getting Emscripten to compile the game to HTML5 was
surprisingly easy. The OS/2 to SDL port took most of my time; after
that, emscriptening (is that a word?) took only a few tweaks.

Thoughts

Try it out here!

I'm still amazed Emscripten is possible. Javascript doesn't
support pointer arithmetic, unsafe casts, unsafe unions, etc., and yet
it all works! I dug into how it works and I was amazed even
more. I'm also quite impressed by how fast asm.js is. In some
microbenchmarks, I found that C++ code compiled to Javascript ran
faster than equivalent Java code.

I've not been able to run BlobCity for 15 years. Although I could have
ported SimBlob to SDL, it was Emscripten that motivated me to do
it. This was a fun project. I love being able to run the game in the
browser. I don't plan to do anything more with SimBlob/BlobCity but I
will probably use Emscripten for a future game project.

Read More

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

Video: Lost Sky Gameplay: Tactical jRPG on Linux [PyGame] 

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

Read More

Origin Story

SimBlob. This is the project that got me interested in tile games, hex maps,
pathfinding, road drawing, economic simulation, AI, and procedural map
generation. Those of you who have been following me for a long time
know that these are topics I'm especially fond of. This project was a
huge influence on me and my game programming site. It ended 15 summers ago.

SimBlob was the simulation game engine / project that I was going to
use for a building game called BlobCity, but I also wanted to use it for other games. As typical for people who work on a game engine
first, I didn't finish. But that's ok. I was writing the game in order
to learn and experiment, not learning and experimenting in order to write
a game.

More screenshots from 1995-1998

Playing the game

The reason I'm going through this code is that I'm porting it to run
on modern systems; the next blog post will describe that process. (I'm not planning to work on it beyond the port.) Once
I got it running, I spent some time playing the game. The UI feels
clunky today but it followed the standard "paint program" paradigm
that I saw in games like Pinball Construction Set and SimCity.

I only had 8-bit graphics back then, so I used lots of dithering. The
dithering on ground textures looks terrible to me today, but it
probably looked ok on fuzzy CRTs. Some of the placeholder art is
terrible, but I'm quite happy with roads and walls. There are some
neat patterns you can make. Putting them together in a triangle or
hexagon forms some nicely curved shapes, not because these shapes were
specifically implemented, but because the way I made the individual
tiles, these shapes came out automatically:

I spent way too much time on simulation, both water and economic. A
lot of this stuff just isn't visible to the player. A simpler version
would've worked just as well. I also tuned the difficulty for
myself. Since I knew how the simulation algorithms worked, I knew what
to look for and could play the game reasonably, but I think the
simulation might be too difficult to understand for anyone who hasn't
understood the code.

Looking through the code

I've not looked at this code for a very long time. I've learned a lot
since then. Some aspects of my coding and design style are different
now. But other aspects are still the same, which tells me I have so
much more yet to learn.

There's plenty of extra complexity that never paid off:

• There are two separate class hierarchies for windowing:
  
  
  
  • Window works with OS/2 windows. The main map, minimap, toolbar,
    statusbar, and menus are all using this level.
    
  
  
  • Glyph is another window hierarchy, independent of OS/2
    windows. The design was inspired by the InterViews GUI toolkit,
    which had quite an impact on my impressionable yound mind. The
    buttons, statusbar items, tabbed information area, and a few other
    things fit into this hierarchy.
    
  
  
  
  
  


• There are multiple event processing systems. There's the OS/2 native
  one, WndProc, then one for my Window hierarchy, and another one
  for my Glyph hierarchy.
  


• The widget libraries include things I never used, like state cycling
  buttons and radio buttons.
  


• The layout manager was complete overkill, but something I wanted to
  experiment with. I had vertical layouts, horizontal layouts,
  overlapping layouts, and toggleable panels. It supported centering,
  stretching, and spacers. The original idea was that SimBlob was a
  simulation game engine that would support multiple games, and
  therefore would need an easy way to build UIs. In practice, I only
  ever partially wrote one game, and I could have manually placed the
  elements.
  

My main goal with the project was to learn things by trying things
out. It's a good thing my main goal wasn't to finish a game. I learned
a lot from all of these experiments, but I didn't finish the game.

I'm reasonably happy with the way the code looks. The main thing I
don't like is that the modules don't cleanly map onto files. This was
fine back when I was working on it, since I had the mapping in my
head, but when I try to navigate the code now, it takes more
effort. It's a good thing there are code navigation tools available.

Algorithms - environmental

I spent a huge amount of time playing with procedural map generation:
fractal terrain, mountains and valleys, ridges and canyons, soil
erosion, continental uplift, water erosion, volcanos, floods, forests,
river channels. I followed the standard model of: try something out,
run it, see if I like it. This was a huge time sink. At the very
least I should have automated some of the testing. When I work on map
projects today, I try to avoid this time sink by instead working
backwards, building maps based on the game's requirements instead of
trying to make a realistic simulation.

Programming the map generator and environment simulator led me to
learn a lot about geology, hydrology, and other fun subjects.

The environment simulation was largely about water. Water flows
downhill from springs. There are seasonal floods and droughts. Water
moistens the soil (which affects farms and trees). It evaporates. It
is absorbed by plants. It destroys towns. Flowing water picks up
sediment and deposits it in other places, creating erosion
patterns. Add simulation of energy and momentum, and I got some really
interesting patterns. For example, water picks up sediment on the
straight parts of a river then deposits it on the inner bank of a
curve, creating meandering rivers and oxbow lakes.

For gameplay, I wanted a continually changing surface. In SimBlob,
continental uplift followed by soil erosion happens not only during
map generation but also while the game is being played. Soil erosion
rates vary by area; it's higher on mountains and near towns and lower
in deserts and on river banks.

Vegetation was modeled in two ways: plants and trees. Plants are
entirely based on elevation. Low elevation gets plants; high elevation
does not. Trees are much more interesting. Trees would grow over
time, and older trees would spread seeds to nearby tiles. Seeds
sprouted if the soil was moist. Fires spread across the landscape,
damaging forests.

Volcanos would spread lava, which flowed downhill and then hardened
into new land. Lava also set fire to any nearby trees. Volcanos are
part of the map generator but can also be triggered in the game by the
player.

Algorithms - economic

Writing the economic system led me to learn about economic geography,
including location theory, central place theory, and economic rent. The model is: Farms generate food; Houses generate labor;
and Markets bring them together. Farms need to be near water and
roads. Houses want to be near other houses, but also like
water. Markets need to be near roads but away from other
markets. Markets and houses are more valuable near the city
center. The first economic system automatically built roads where
transportation was needed; it generated neat fractal-like patterns. My
later economic system required the player to build roads, as I was
moving away from pure simulation and towards having a playable game.

The simulation was based on a resource flow model. Resources flow from
sources to sinks along roads. Food flows from the market to houses. If
there's excess food, blobs move into houses; if there's a lack of
food, blobs move out of houses. Labor flows from houses to farms, and
houses to markets to farms. The more laborthere is, the more food is
produced.

The intended effect was for land near the town center to be more
valuable to markets than to farms. At a medium radius from the center,
houses are more valuable than farms, and there are just a few
markets. On the outskirts of town are the farms. As the town grows,
tiles near the center would switch from farms to houses to
markets. It's a nice simple model that leads to pleasant towns.

The job system for builders was rather bad. Each builder blob would
accept up to 6 nearby jobs, but this greedy algorithm wouldn't
consider cases where another builder was better suited for the
job. The code is messy. It worked fine for a single builder but worked
poorly when there were multiple builders. If I were approaching it
today, I'd look at algorithms for the Assignment Problem.

The original implementation of firefighter blobs used an influence map
to "follow the heat". I was a big fan of influence maps. However, it
didn't work that well, because after a fire was put out, it took too
long to propagate. Also, all firefighters would end up going to the
same place (I hear this is a problem in some other games too). I
changed it to an algorithm that divides the map into regions, and
chooses regions based on the number of fires and firefighters already
there. That worked much better.

I have a lot more notes written up here.

If you want to try out the game, I've made it run in a web browser.

Conclusions

Working on SimBlob was great for me. I learned a lot about science,
economics, simulation, and programming. I learned that finishing a
game wasn't as interesting to me as understanding a topic and writing
about it. So that's my site's "origin story": SimBlob is the project
that led to the original game programming topics covered on my site.

Read More

Xonotic 0.7 released

After an agonizingly long wait, I am happy to report that a new official release of the premier FOSS arena FPS Xonotic is available to the masses.

Here is a nice (but slightly older) game-play video for those not having played Xonotic yet:



Changes are quite extensive compared to the last official release... most notably an extensive update the the CTF mode, some neat additional features for competitive gaming and an assortment of great new maps.

New maps in Xonotic 0.7

On the technical side of things, the engine DarkPlaces got quite a few performance improvements (mainly due to the fact that the creator now works at Valve software and thus has direct access to Nvidia's and AMD's graphics hardware divisions) and that an all new script compiler is now in use. That it runs on SDL 2.0 might also increase it's usability a lot for some.
There are also finally an animation bending feature for the player-models and creation of new characters has never been easier now that the iqm format is used.

You can comment on this release over at the Xonotic forum release announcement thread (or of course here in our comment section).

Also check out these two still under heavy development mods for xonotic:

• Overkill is a mod that attempts to combine the best of minsta gameplay and TDM/CTF. It also has some nice vector shaded new weapons and player models.
• DotC is an DOTA like but in 1st person view type of mod.

Last but not least, the awesome all new level editor for quake based games, Trenchbroom is making great advances and should soon allow easy mapping for Xonotic out of the box.

P.S.: If you have a really fast Android device, you can also try to run Xonotic on it via this newly fixed DarkPlaces port. Just don't expect to be able to compete online with touchscreen input :p

Read More

DevCorner: Liberate some great Blender game art!

UPDATE: First set of files has been released (license CC0) and on my advise he added some stretch goals:

• 600$ > 3 game ready Enemies! (models, sfx, animations, effects)

• 650$ > Dynamic optimized lighting system! (rich dynamic lighting with low resource usage )

• 750$ > 4 new weapons!(model, texture, sound)

• 850$ > Triple the amount of the actual props! (interactive objects,explosibles, new walls, doors windows etc.)

• 900$ > New player model (model, textures)

Currently it is standing at 530$ and there are 22 days to go, so chances are we will see some more nice stuff out of this.
------------
Way too many closed-source game projects never see the light of the day, and their code and assets are forever lost. Now at least one developer thought he could at least make a few bucks by liberating this content under the CC0 license:





There is some seriously nice stuff in that pack, and the 500 US $ he is asking for on his indigogo page is a bargain for it.

At the time of writing this, 200$ have been already pledged, so with your contribution it should be easy going to reach the goal. Update: 515$ contributed, thanks to everyone! Maybe the guy should think about strechgoals ;)

But I sure wish more developers of failed projects would release their assets like this.

Read More

Hedgewars 0.9.19 released

Everyone's favorite clone of worm-warfare, Hedgewars recently got a rather big new release as one of the developers pointed out to us by email.

One of the new level themes for Hedgewars 0.9.19

The changes are quite extensive, so instead of failing to summarize them here, check out the above linked quite extensive original release announcement.

You can also have a look at this fan-made trailer if you enjoy cheezy stuff ;)

Read More