as3sfxr-b: evil (flash) sound machine

as3sfxr-b

[Flash version]
[Code]

Before was: as3sfxr
Before before was: sfxr

read more...

OpenDungeons: Huge Progress

OpenDungeons finally released version 0.4.7 of their Dungeon-Keeper like game, now with a new UI, better team colors, and many more animations. Very exciting to see the project develop! Download the new release here

The Peragro Tempus project also kindly enabled DAMN asset managing for the OpenDungeon's media repo, which could really help with getting artists to contribute in the future (go to the DAMN link, then browse, and you should see the OD assets).

read more...

Blender Game Engine Air race

We recently featured another air race kind of game, but this on has much more eye-candy:

BGE_Airrace ocean demo

And believe it or not, but it is made with Blender3d 2.49b's game engine (update to 2.5/2.6 planned at some point)! Another video with a nice terrain you can find here (beware crappy sound). And an in-game track editor is under development too!

You can have a look at the development of it and download some old versions of the .blend over at the Blender artists thread. But don't expect visuals like above, as the awesome Blender artist Martinsh just recently started to overhaul the graphics like that.

So where is the catch? Well licensing is a bit unclear... in a recent BlenderNation news posts the main developer stated: "This air-race related project is a non-commercial open -source freeware and source .blend file will be released for common good", but I am not sure in how far this will extend to the new art assets, and a clearer commitment to a Creative Commons license and an actual release of the source .blend would make me feel more confident about the licensing status ;)
But hey... at least I assume it was completely done with FOSS software (e.g. Blender3D)!

read more...

PyWeek 12 is upon us! - Also: Python Game Book wiki and Spielend Programmieren

Take this for not doing your own "thing, number" logo! ;)

PyWeek 12 is a game challenge/competition. It goes for a week. It starts on 2011-04-03.

It's kind of open source: code needs to be visible, FSF license list is recommended, open source license appears not to be required though. See rules for rules.

Screens of PyWeek11's entries

Here's the initiator's blog (+feed) - in case you're the stalker type. I know I am. :)

PGB and SP banners/logos

Horst, a Wien-based friend of FOSS hosts the Python Game Book wiki and Spielend Programmieren ("Programming by Playing") which is a wiki used for his courses teaching kids to make games using open source tools and libraries. There might be a guest post by him on this blog sooner or later.

Some cool kids on his YT channel.. I hope you like das German.

PSA for psychodelic PyGame Hirnschoner

read more...

ManicDigger & ArdorCraft - Open Source Minecraft-likes

Manic building on a ManicDigger server

ManicDigger started as a third-party client for Minecraft Classic. According to the FAQ only Windows is supported but if you have Mono, you can do the following:

Get nightly binary (.zip: warning, it is a .rar), unpack.
mono GameModeFortress.exe

Thanks to gustavo for the instructions!

Must.. build.. house..

Unfortunately ManicDigger has the "most commonly used textures (grass and dirt) are ugly"-feature (just like Cube2/Sauerbraten for example).

ArdorCraft

ArdorCraft runs in Java (Ardor3d) and I got it running with its webstart file. I'm not entirely sure, but it seems that development halted four months ago.

ArdorCraft Dev [mute]

Even more ArdorCraft screens

By the way, Notch (Minecraft lead dev) just posted his first (technical) article about terrain generation. How is this open source related? Weeell.... not that much, except for the following scrap of text (from here):

Once sales start dying and a minimum time has passed, I will release the game source code as some kind of open source. I'm not very happy with the draconian nature of (L)GPL, nor do I believe the other licenses have much merit other than to boost the egos of the original authors, so I might just possibly release it all as public domain.

So it's future open source, right? :D

read more...

Besiege - 3D RTS (Java/Ardor 3D)

Besiege

Besiege is a space based real time strategy game where you conquer planets to let them produce new ships (and eventually research new technologies for you). Somewhat inspired by Eufloria and Galcon.

The description resembles Qonk.

The project did one thing that I think is very, very right: BIG SCREENSHOT ON FRONT PAGE.

The ardor3d game runs on Linux this way:

java -Djava.library.path=native -cp lib/*:Besiege.jar net.playbesiege.Besiege

Besiege 1.0 Beta gameplay with sound

read more...

Dev-corner: Primer to texture creation

So you got this shiny 25 megapixel camera from your grandma last Xmas, and are getting bored making photos of your cat with it? Put it too a good use and make some environmental pictures and upload them to the burning well!
Wait, you don't have a rich grandma?... well take some photos from the website above (all public domain) and convert them to some nice textures to use in games ;)

And of course FOSS is to the rescue and provides you with all the tools you need:

Most importantly THE GIMP of course! Which is the premier open-source image manipulation software, that doesn't need to hide behind other commercial programs starting with Photo and ending with Shop (the other major FOSS contenders being Krita and MyPaint both in that order aiming more at digital paining then image manipulation. Oh and check out Alchemy for a funny sketching app.).

Creating a seamless texture

So what you will normally want to do is take a picture that shows a relatively flat surface with an interesting pattern and not too strong shadows (a cloudy day with a lot of diffuse lightning is best is you want to take photos yourself).

Based on this you take a small part and try to make it seamless, e.g. make the edges fit to each other so that it can be tiled endlessly on a 3D surface in a game.

The guys at OpenClonk have a pretty nice tutorial about the manual process.
However nowadays there are also some smart algorithms available as GIMP plug-ins that try to do the job for you (with better or worse results, but it is for sure a lot faster). Here is an example with a short tutorial of what I did in less then 5 minutes with the perhaps most advanced of these plug-ins: Resynthesizer. Another, which looks good too but I have not tried is Texturize. However the latter does not remove your ex-girlfriend from your favorite holiday shots, so 1:0 for Resynthesizer :)

Making a normal map for your texture

So your are working on the next super MMORPGFPS super Counterstrike killer with next-next-next-gen graphics? Well then your texture (don't go for anything lower that 10,240 x 10,240 for your toilet door textures!) needs a normal map of course!

Gimp normal map plug-in

But don't worry, there is a GIMP plug-in for that too!

So there you have it... start making some texture packs and upload them to OpenGameArt!

read more...

Dev-corner: Making unlicensed fan games -- why your time is better spent elsewhere

If you're reading this blog, you're probably like me in that you feel that current copyright law vastly overreaches in favor of the "content industry" and at the expense of culture as a whole. You may or may not also enjoy playing unlicensed fan-made games -- games that make use of IP from other games without the original owner's permission.

Today I'm going to talk about a little game company named Squaresoft(*). I liked Squaresoft -- a lot. I never cared for the company Squaresoft all that much one way or the other, but I loved their games (as you may have figured out from my previous blog entries). Chrono Trigger, in particular, is a game that frequently shows up in the ubiquitous "Top 10 video games of all time" lists and polls that gaming magazines like to do from time to time -- and it's also one of my personal favorites.

Among Chrono Trigger fans, the Chrono Trigger franchise is generally considered to have been treated very poorly by Squaresoft (now Square Enix). After a dissatisfying sequel, the only attention Chrono Trigger has received at all has been in the form of multiple re-releases, none of which have changed or added very much to the game.

Arguably, when a company can release the same thing over and over with minimal modification and keep selling it to people, it's become part of popular culture and the copyright ought to have expired, seeing as how the stated intent of copyright is to encourage innovation and progress as opposed to cultural stagnation. If you look at the original intent of copyright as stated in the U.S. Consitution (To promote the Progress of Science and useful Arts, by securing for limited Times to Authors and Inventors the exclusive Right to their respective Writings and Discoveries), fan games actually look like a fairly good idea. If copyright is leading to cultural stagnation (remakes of remakes of remakes), maybe it's time to take culture into our own hands and follow the intent of copyright, rather than the letter of copyright, which exists in its present form entirely because of the lobbying efforts of the content industry [author's note: the intent of this blog entry is not to advocate violating copyright law -- there are other ways to fight bad laws. Please read to the end for the full context of this article before reaching any conclusions about what I'm writing here. Thanks!].

So yeah, I have nothing against fan games. Given that Chrono Trigger has received precisely zero attention from Square in recent years, I would have loved to have played Chrono Resurrection or Crimson Echoes, both of which looked very promising. If Square had purchased those games from the developers and sold them, I would have happily paid for them. Instead, Square hit them (and their fans, indirectly) with legal threats, shutting both projects down (a week before conclusion, in the latter case). By the letter of the law, this is entirely their right.

Now I don't know about anyone else, but this really cheezes me off. Square has taken something that I like and turned it into a cheap cash cow, and I'd really like to stick it to them, which is why I'm advocating against spending time making more fan games. Allow me to explain.

Fan games, like it or not, do these big fan-hating companies a favor by creating buzz about their games. Chrono Trigger is 12 years old now. I think maybe it's time that, instead of talking about it and spending our time adding to the Chrono Trigger mythos, we ought to relegate it to the black hole of dead copyrights. That's right, I think we ought to move on and stop doing Square a favor by spending time and effort promoting their games only to be slapped in the face for it. Instead, take that massive effort that you wanted to pour into a Chrono Trigger fan sequel (or whatever other game you want to make a fan sequel of) and use it instead to take the buzz away from big, fan-hating companies by either making something original or expanding on some content that's already available in the Creative Commons (like the many different Wesnoth campaigns).

Wouldn't it be nice to have some open franchises that people can expand on without fear of being sued? This is something that I think the Creative Commons needs more of, and there's nothing stopping us from doing it.

read more...

Tiny game: Stop the Zombies!

I'm so proud of saving more than killing...

I discovered a tiny and minimal Java/Processing game through future superstar game designer William: Stop the Zombies!

Launch nuke circles. Save human pixels. Kill zombie pixels. Or just kill everything.

The code is under a "Do whatever you want with it" license as far as I'm concerned, as it says in the code, it was based on someone else's code already.

It should be noted that that code will no longer compile due to changes in the Processing environment over the years.

read more...

Dev-corner: 48-hour Reddit Game Jam Postmortem

Last weekend, I had the distinct pleasure of "leading" a large (20+) team of dedicated artists, coders, and writers in the creation of a wonderful (if a bit rough around the edges) 2D platform game called Last Escape. I put "leading" in quotes, because my position was more of organizer and first-among-equals (save for a couple of executive vetoes, mostly to save time and keep things moving). It was an amazing experience, and I'm very proud to have been a part of it. It was also highly educational, so I'm going to try and take stock of what we did right and what we did wrong, and write about it here, in hopes that it helps other teams develop games later on.



First off, a little more about the project. Last Escape was ambitious from the outset. Before the project began, we decided that we were going to work with C++ instead of Flash or JavaScript. This decision was of a practical nature; the two coders who had committed the largest amount of time to the project ahead of time (myself and FLARE creator Clint Bellanger) were the most comfortable with game development on C++.

The art in Last Escape is a combination of digital painting and pixel art. This effect is a bit jarring, but given the 48-hour time constraint, we had to make full use of all the artistic talent that was available to us. By and large, the vast majority of the art in the game is brand new, although we used existing assets where we could.

The basic premise behind Last Escape is that you're a person who has made a forced landing on an alien world due to your space ship being out of energy. The object of the game is to collect enough energy to power your ship, and, in the process, you run into some interesting alien ruins as well as some giant insects.

We started out by planning certain things beforehand. Since we didn't know what the prompt would be, we were somewhat limited in the planning we were able to do, but we did create a rough road map and timeline in advance to give us some indication of where we should aim. You can see these on the OGA forums. While we eventually fell a bit behind schedule on certain milestones, these documents were absolutely essential to keeping everyone motivated and on track, and I would not recommend undertaking a team based game design project without them, no matter how small.

When the contest theme was announced (it turned out to be "Energy"), we got the group together and immediately started brainstorming. I set the time limit on brainstorming for game ideas to 45 minutes, and we created a google document and began typing up a list of ideas as they came up. I attempted to steer the ideas in various directions to get a wide variety of suggestions, because I noticed that the discussion tended to get hung up on whatever game genre we were talking about at the time. We had to deliberately move things from puzzles to action to strategy, etc, and this is one place where I put on my "leader" hat in order to make that happen.

Following the brainstorming session, we put things to a vote. We went through a two-step voting process -- the first step was to ask for an approval vote, and just have everyone list all the ideas they liked. We used this to narrow the choices down to five. After that, we had a second vote and everyone picked their favorite. As an aside, it's interesting to note that in the craziness of brainstorming, I accidentally copied an idea from the main #opengameart IRC channel into the list, and that was the idea that was chosen. We discovered later on that the person who's idea we used was submitting their own entry into the game jam, so we ended up with two games that had a very similar premise. Fortunately, Xiphias3 (the originator of the idea) was cool with this, and said that we didn't have to mention it. We did anyway. :)

After the voting was finished, we put together a brief todo list and started frantically coding and doing art. This is where the real learning kicked in, and, knowing what I know now, there are some things I would probably handle differently.

First off, probably the biggest issue I ran into personally were merge conflicts. We hosted our project on GitHub and gave a number of people commit access. This was all well and good, but we were poorly organized (IRC can be a double-edged sword, since at any given time you have no way of knowing who is paying attention). Consequently, there were several situations where more than one person ended up working independently on the same feature or bugfix. I personally spent at least five hours cleaning up merge problems brought about by pieces of perfectly reasonable code interacting in unexpected ways.

As such, I would strongly advise anyone working on a large, rapid team project such as this one to have a web-based task tracking program ready to go at the outset. Google Docs proved inadequate for this.

Another related thing that I learned is that when you're managing a team of 20 people, the director doesn't really have time to code. This made things difficult for me, because I had already budgeted most of my time for coding, but as the project lead, people looked to me to know what was going on. On a large team, people generally need to be broken into smaller groups and given tasks; as such, you need someone whose job it is to know exactly who is doing what at any given time, and that's one area where I would make an effort to improve on if I were to ever undertake something like this again. Real task tracking software -- something simple with a quick and easy learning curve -- would have been very helpful for this.

One place where I would consider myself fairly successful is keeping a large group of people with differing interests and talents moving and motivated through a stressful project. Here's the advice I would give to anyone needing to do this:

• First off, have a leader. You need someone with veto power in order to keep things moving in a good direction.
• As the leader, understand that it's not "your" project -- it's everyone's. This means that it's not your job to tell people what the direction of the project is; rather, your job is to facilitate the team finding a direction and keep things from getting sidetracked.
• Democracy rules. The main direction of your project is often best decided on by brainstorming and then a vote. This gives everyone a chance to make their case and have their idea judged by the entire team, and not just the leader.
• Large groups of people can tend to get sidetracked very easily in discussions. As such, it is very important that you limit discussion time in advance and make sure that you designate a time by which brainstorming is over, and a time shortly thereafter when you have to reach a final decision. If you don't set up these times in advance, people who are trying to make their case may assume that you want to silence them. Plus, it's not particularly fair to people if they're not aware when their time to speak is going to be over. To avoid putting yourself in the position of even appearing partial, it's best to set time limits in advance.
• If possible, keep votes in the open. When I took a vote, I asked everyone to send me a private message with their vote (because it was easiest to keep track of), but also vote publicly, and then verify my count.
• Remember, your project depends on your team. People will come and go, as is natural with any project, but people will be a lot more likely to leave if they feel that their input has no chance of being heard. This is to some extent reiterating what was said above, but I cannot stress enough that leading is about facilitating and not ruling with an iron fist!

Another thing that I think we did well (with certain caveats) was the selection and use of tools. If you're developing a game, even "from scratch" as we were, there are a lot of tools out there that you can and should use to make things easier. Here are my thoughts:

• Where possible, be tool-agnostic. Not everyone is comfortable in the same software. Some people may prefer to use closed-source tools, and it's important to accommodate these folks if you want to keep your dev team happy.
  
• You should not be format-agnostic. You need to decide in advance what formats are acceptable for your media files. Stick to well implemented open standards, and make sure people understand that they are responsible for providing their files in these formats. This means that media editors that can't output to these formats are essentially out, unless the people using them have a quick and clean way of converting both to and from their proprietary formats. The rest of the team should not be burdened with these conversions.
  
• Version control is an absolute must. As much as I complained about merge conflicts, things are a lot worse if you're sharing a code base without version control. I recommend using a system with web-based tools that as many people as possible are comfortable with. Most coders prefer Git, and by and large GitHub turned out to be a good choice for us (with one major caveat that I'll get into below).
  
• Tiled (the Qt-based FOSS tile map editor) was absolutely excellent for putting tile maps together quickly. I strongly recommend it to any project considering making a 2D tile-based game.
• Try to avoid reinventing the wheel when possible when writing your code. You may have specific requirements that no existing game engine meets, but there are plenty of frameworks you can build your engine on that provide things like easy, cross-platform graphics, sound, and I/O. We used SFML to great effect, but there are plenty of other good choices.

I mentioned above that we had a major caveat with Git; namely, version control is complicated. I don't have any good solution for this. Artists don't always think like coders, and a lot of version control systems require a certain level of comfort at the command line. This is particularly true of Git, which can work with several different protocols, some of which have issues when going through web proxies and the like. We also had confusion about how to generate public keys for connecting to GitHub.

While it may not be possible to avoid these sorts of issues completely, I would strongly recommend setting up your team with version control before you start coding.

Another issue we ran into with Git is that it tried to merge Tiled's XML map files. It did surprisingly well at this in most cases, but machine-generated XML isn't always the best thing for code merges, since it often needs to be in a very specific format. I'm guessing there's some way of turning this off for certain filetypes and forcing the merge to be resolved manually, as you would with a binary file.

Finally, some thoughts on coding. On one hand, you're trying to develop code quickly. On the other hand, you need to make your code easy to expand. Generally, you have two types of people -- the ones who want to code as quickly as possible due to the time limit, and the ones who want to code as cleanly as possible, time limits be damned. You need to be prepared to listen to both these sorts of people. Sometimes going off half-cocked can end up wasting a lot of your precious hours because you end up having to replace code or work around nasty hacks. On the other hand, when someone wants to take a while to do something the "right" way, you need to take stock of how long it will actually take them to finish what they're trying to do. If they can't do it within the allotted time, there's not much of a point, and they may as well have been working on something else.

What's important is that you be practical and strike a balance between the two. Your code needs to be at least somewhat maintainable and readable, or else you'll run into roadblocks long before your time is up.

So there you have it. No doubt some other folks from Team OGA will read this -- if you do, please chime in in the comments, and I'll try to work your thoughts into this post. As always, if anyone has any comments or questions, please feel free to post them. I tend to reply to almost everything. :)

A final, encouraging note: Last Escape has taken on a life of its own, and the project is continuing. You can follow our work (and download the latest version) on GitHub, although for the moment you'll need to compile it yourself. Here's the link:

https://github.com/lendrick/Last-Escape

read more...