The latest Jerusalem Strategy Gaming Club session report is up. Games played: R-Eco, Shipyard.
Shipyard takes the four of us 3.5 hours.
Thứ Năm, 31 tháng 3, 2011
Thứ Ba, 29 tháng 3, 2011
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:
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
Bart K.
OpenGameArt.org
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!
- 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.
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
Bart K.
OpenGameArt.org
Thứ Hai, 28 tháng 3, 2011
Board Game Blog World Roundup
For a complete list of active board game blogs, see my left sidebar. The following blogs are active and new to me since my last roundup.
Board Game Info: The new BGI site has several feeds.
Board Game Reviews by Josh: Josh Edwards, Missouri. Reviews.
BoardGameGeek News: The defunct BoardGameNews moved to BGG. Eric now does news roundups.
The Opinionated Gamers: Meanwhile, most of the other BGN contributors moved here.
Eye of the Vortex: A team blog covering topic on various genres; currently mostly focused on Magic and RPG material, with some other stuff.
Father Geek: Cyrus Kirby (and others), Elgin, Minnesota. Games and fatherhood.
Ludology: Ryan Sturm and Geoff Engelstein, to oftime Dice Tower contributors covering geeky game topics in a new podcast.
Matt's Board Game Back Room: Matt Stevenson, Eugene, Oregon.
Meople's Magazine: Kai, Germany. Hoping to have more contributors.
Plankton Games Journal: Dave Dobson, Greensboro, NC. Game design.
Smartplay (Thinkfun): Charlotte. About play.
State of Play: Thomas McDonald, a professional game journalist and contributor to Games Magazine (among others). All types of games.
The Mystical Throne: Another site attempting to catalog games, organized by theme.
The Obsessive Compulsive Gamer: Toronto, ON. Playing through his game collection.
The Superfly Circus: Peter Ruth, Kentucky. Game reviews, interviews, and commentary.
Zwischenzug: Frank Feldmann, Dayton, OH. Family game blog.
Board Game Info: The new BGI site has several feeds.
Board Game Reviews by Josh: Josh Edwards, Missouri. Reviews.
BoardGameGeek News: The defunct BoardGameNews moved to BGG. Eric now does news roundups.
The Opinionated Gamers: Meanwhile, most of the other BGN contributors moved here.
Eye of the Vortex: A team blog covering topic on various genres; currently mostly focused on Magic and RPG material, with some other stuff.
Father Geek: Cyrus Kirby (and others), Elgin, Minnesota. Games and fatherhood.
Ludology: Ryan Sturm and Geoff Engelstein, to oftime Dice Tower contributors covering geeky game topics in a new podcast.
Matt's Board Game Back Room: Matt Stevenson, Eugene, Oregon.
Meople's Magazine: Kai, Germany. Hoping to have more contributors.
Plankton Games Journal: Dave Dobson, Greensboro, NC. Game design.
Smartplay (Thinkfun): Charlotte. About play.
State of Play: Thomas McDonald, a professional game journalist and contributor to Games Magazine (among others). All types of games.
The Mystical Throne: Another site attempting to catalog games, organized by theme.
The Obsessive Compulsive Gamer: Toronto, ON. Playing through his game collection.
The Superfly Circus: Peter Ruth, Kentucky. Game reviews, interviews, and commentary.
Zwischenzug: Frank Feldmann, Dayton, OH. Family game blog.
Divorced Again
I am now divorced for a second time. I have nothing bad to say about either woman with whom I shared a few fleeting years of my life. They were not "bad" people; nor do I think less of myself for having not sustained the marriages. I someday will find myself on the cusp of another marriage and I would not hesitate to send my prospective partner to talk to my exes.
Now I am in a ditch; divorced again. I have acquaintances, some few friends and family, but I am alone in a very real way; no daily companion with whom to dine, walk, and laugh, no warm body to share my bed, no woman to sit unfailingly by my side were I to take sick. My divorce, however much it is for the best, is still a tragedy.
Yet, even in a ditch, I have only to look up to see the stars, the moon, the blessed rain, and the wide, wild world. The world holds a great deal of love, life, laughter, and beauty. Someday, someone will sit with me under a blanket on the couch, our hands intertwined, as we each read to ourselves. Someone will wonder - she will know, that I am thinking of her every day and it will be the most important thing in the world to her; and perhaps, she will think of me, and it will be the most important thing in the world to me.
I love. I have loved. I will love. My heart is broken but beating strong. It bursts with a lifetime of love to give. I will give it.
Now I am in a ditch; divorced again. I have acquaintances, some few friends and family, but I am alone in a very real way; no daily companion with whom to dine, walk, and laugh, no warm body to share my bed, no woman to sit unfailingly by my side were I to take sick. My divorce, however much it is for the best, is still a tragedy.
Yet, even in a ditch, I have only to look up to see the stars, the moon, the blessed rain, and the wide, wild world. The world holds a great deal of love, life, laughter, and beauty. Someday, someone will sit with me under a blanket on the couch, our hands intertwined, as we each read to ourselves. Someone will wonder - she will know, that I am thinking of her every day and it will be the most important thing in the world to her; and perhaps, she will think of me, and it will be the most important thing in the world to me.
I love. I have loved. I will love. My heart is broken but beating strong. It bursts with a lifetime of love to give. I will give it.
Chủ Nhật, 27 tháng 3, 2011
Weekend Gaming
I spent shabbat at the house of my friend and fellow gamer David K and his wonderful, hospitable family. I've known David for 30 years; the first time I visited him at his house in Maalei Adumim was 25 years ago. I don't visit him often enough, so I see the kids in a kind of strobe: one in a teen and another is a little child - flash - now the older one is married, the former child is a teen, and there's another little child.
Even though I hadn't met the little children often, my reputation preceded me; they were expecting games. Here's what we played:
Before lunch we played half a game of The Settlers of Catan. I partnered with the littlest girl, and I let her make many of the decisions for the early parts of the game. As a result, though we weren't too far behind, we weren't winning either. Lunch came along and we had to leave the game alone until we could resume it later.
After lunch, the principles from Settlers had gone out to play, so David and I started a game of Homesteaders. It was only the third or fourth time for David; but even though I had played a few more times (maybe 10), the game still feels like a vast uncharted sea of possibilities. My respect for the game grows and grows. It's really a stunning achievement for a first time designer, and probably in my top ten games at this point.
Some of the principles from Settlers returned while we were halfway through Homesteader, so we left it set up and started a game of Bridgetown Races. (That left two games in progress, Settlers and Homesteaders, while we played a third.)
The problem with BR is the last third of the game, when there just isn't much to do. The mechanic where a particular flag is assigned to a particular bridge on your scoreboard means that you have to not only hope that the right flag colors appear but that they appear in the right places. There is only one "swap" action available for all players, so you can't do anything if the draw isn't right. So what do you do in the last one or two rounds? And the all or nothing scoring doesn't help.
I figured to solve the problem by assigning points to the flag colors equal to their movement rate, so the game could end with an immediate win, but otherwise you count the flag points. David said even early on in the game that the points should be reversed, i.e. the flags with less movement rate and thus harder to acquire should be worth more than the flags with a higher movement rate. And he is right. But more so, I think you should just toss out the whole bridge scoreboard, and simply count all flags you pick up; none of this tossing out and replacing nonsense.
The game just needs a good final follow-through. One of the kids won.
After BR, we returned to finish our game of Settlers, which I and little girl won barely by completing eight points and then spending three rounds trying to steal Longest Road, eventually successfully. After that, David and I returned to our game of Homesteaders, which I won 75 to 54. I played with a second round Gold Mine, rather than the usual Market or Farm start. I did pretty well until the last round or two when, for the first time, I couldn't buy the building that lets you also buy another building in the same turn, neither in round 9 or 10. I successfully bought some good buildings nonetheless, including the 10 point building in round 6 (for a gain of 20 points).
I retired to read a book, and David taught his kids and a neighboring kid how to play Tichu. After one of them left, I joined them. I think we only played one hand.
The rest of shabbat was sweet and mellow.
Even though I hadn't met the little children often, my reputation preceded me; they were expecting games. Here's what we played:
Before lunch we played half a game of The Settlers of Catan. I partnered with the littlest girl, and I let her make many of the decisions for the early parts of the game. As a result, though we weren't too far behind, we weren't winning either. Lunch came along and we had to leave the game alone until we could resume it later.
After lunch, the principles from Settlers had gone out to play, so David and I started a game of Homesteaders. It was only the third or fourth time for David; but even though I had played a few more times (maybe 10), the game still feels like a vast uncharted sea of possibilities. My respect for the game grows and grows. It's really a stunning achievement for a first time designer, and probably in my top ten games at this point.
Some of the principles from Settlers returned while we were halfway through Homesteader, so we left it set up and started a game of Bridgetown Races. (That left two games in progress, Settlers and Homesteaders, while we played a third.)
The problem with BR is the last third of the game, when there just isn't much to do. The mechanic where a particular flag is assigned to a particular bridge on your scoreboard means that you have to not only hope that the right flag colors appear but that they appear in the right places. There is only one "swap" action available for all players, so you can't do anything if the draw isn't right. So what do you do in the last one or two rounds? And the all or nothing scoring doesn't help.
I figured to solve the problem by assigning points to the flag colors equal to their movement rate, so the game could end with an immediate win, but otherwise you count the flag points. David said even early on in the game that the points should be reversed, i.e. the flags with less movement rate and thus harder to acquire should be worth more than the flags with a higher movement rate. And he is right. But more so, I think you should just toss out the whole bridge scoreboard, and simply count all flags you pick up; none of this tossing out and replacing nonsense.
The game just needs a good final follow-through. One of the kids won.
After BR, we returned to finish our game of Settlers, which I and little girl won barely by completing eight points and then spending three rounds trying to steal Longest Road, eventually successfully. After that, David and I returned to our game of Homesteaders, which I won 75 to 54. I played with a second round Gold Mine, rather than the usual Market or Farm start. I did pretty well until the last round or two when, for the first time, I couldn't buy the building that lets you also buy another building in the same turn, neither in round 9 or 10. I successfully bought some good buildings nonetheless, including the 10 point building in round 6 (for a gain of 20 points).
I retired to read a book, and David taught his kids and a neighboring kid how to play Tichu. After one of them left, I joined them. I think we only played one hand.
The rest of shabbat was sweet and mellow.
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.
Session Report, in which we begin to like Mu
The latest Jerusalem Strategy Gaming Club session report is up (actually, has been up since last week). Games played: Dominion, Princes of Florence, Mu.
We introduce a new player to Dominion and PoF, and we try again to like Mu, with some success.
We introduce a new player to Dominion and PoF, and we try again to like Mu, with some success.
Thứ Ba, 22 tháng 3, 2011
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.
Bart K.
OpenGameArt.org
P.S. Feel like working on a game this weekend (3/25-3/28)? Join Team OGA and in the 48-hour Reddit Game Jam!
----
* Now Square Enix
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.
Bart K.
OpenGameArt.org
P.S. Feel like working on a game this weekend (3/25-3/28)? Join Team OGA and in the 48-hour Reddit Game Jam!
----
* Now Square Enix
Dev-corner: Bart K. explains (and rants about) C/C++ pointers
C pointer syntax is an egregious design flaw. It's so bad, in fact, that it's solely responsible for multiple generations of programmers struggling with pointers, which frankly aren't that hard of a concept. I'm going to take some time today to explain pointers and, in the process, point out exactly what it is I can't stand about C/C++ pointer syntax. If you've never been able to wrap your head around pointers up until now, please give this a read, and hopefully you'll have a better understanding of them by the time you get to the end. I'll start with the basics (which you probably already know, but please bear with me).
Conceptually, a pointer is a variable that points to a location in memory, generally another variable. In C and C++, the actual data stored in a pointer is a memory address, which is just a number that signifies a particular location in memory. You can interact with a pointer in two ways. You can either look at the actual value of the pointer, which as I said is a memory address, or you can dereference the pointer (I'll explain this in a bit) and look at the value stored in the memory address that it's pointing to. A pointer can point to any type of variable. What's important to remember, though, is that pointers are their own type, distinct from the type of variable they're pointing to. A pointer to a character is not the same type as a character, which brings me to my first major beef with C/C++ pointer syntax. I'd like to introduce you to our recurring villain: the asterisk (*). The asterisk is a villain because he does two completely different things that both have to do with pointers, and he does them in a way that's very confusing. I'll address the first of these things now. Let's say you're declaring an integer.
Ha! If only.
A pointer is a type, the same way that character and integer are types. And yet, you don't declare them the same way as you declare other types. In fact, you can mix them in with declarations for different types, which is horribly inconsistent. C doesn't let you declare a mix of integers and characters on the same line -- so why can you declare a mix of integers and integer pointers on the same line?
Here's a better way to think of pointer declarations:
You either have to declare them one per line or declare them in a way that's conceptually misleading:
Now why on earth would I want to do that? Simple! When C looks at a pointer, it has no idea if the number contained in that pointer is a valid piece of allocated memory or just some random number that points off to Tux-only-knows-where. So what does C do? It just trusts you. It assumes, sometimes wrongly, that the number that's sitting inside that pointer is a valid memory address, and will happily write to that address if you tell it to, regardless of whether you've actually allocated memory there. Often times this will overwrite some of your code or another variable, and your program will continue humming happily along with no idea that it just made a huge mess of itself, only to mysteriously crash later on in a way that's very difficult to trace.
The thing about zero is the C knows it's not a valid address, so when you try to do something to memory address zero, your program will crash in an immediate, clean, and traceable way, which makes debugging a lot easier. If you're super hardcore and you're writing code on an embedded system where processor power is expensive, you can always remove the "= 0" bit later, although I wouldn't necessarily recommend it.
Another perfectly valid thing that you can do is just allocate the memory immediately when you declare the pointer instead of setting it to zero (or null, as they call it). In C, you'd do this with the malloc() function, and in C++, you'd use the 'new' operator. Here's how that looks:
Let's look at the C declaration again, this time in glorious technicolor!
A void pointer is useless on its own, since 'void' is a type that doesn't actually store anything. The intent, in this case, is that you cast the void pointer to whatever kind of pointer you're allocating, which brings us to the (int*) bit. If you're familiar with C and C++, you've probably already seen a cast, which is where you convert one type of variable to another. What we're doing in this case is telling it to change the void pointer that malloc() returned into an int pointer, so we can then set i equal to it. [edit: There are some good arguments in favor of omitting the cast, although my own C++ habits lead me to include it (not that one ought to be using malloc() in c++ anyway. See this stackoverflow link here: http://stackoverflow.com/questions/605845/do-i-cast-the-result-of-malloc (courtesy of )]
The last part, the sizeof(int) is telling malloc() how much memory to allocate. Since we want a pointer to an integer, we're allocating enough space to store an integer. Sizeof is a function that's built into C that returns the size in memory of the given type. Hence, sizeof(int) returns the size of an integer in bytes, which can vary depending on your system architecture.
So, to summarize, the above line of code creates an integer pointer, initializes an int-sized block of memory, and sets the new pointer to point to the memory address you just initialized. Ugh.
C++ is way simpler in this regard:
Hmm, now where'd that evil little bastard asterisk go? Ah, there he is! He's off dereferencing stuff!
So what does dereference mean, exactly? Well, remember how we when we initialized the pointer to zero, we were actually setting the address to zero, and not the contents of the address. One has to wonder at that point, how do we interact with the stuff contained within the address the pointer is pointing at? You dereference the pointer.
Dereferencing is an operator. An operator works essentially like a function, in that it takes a value and returns a different value. When you dereference an integer pointer, you get the integer that the pointer is pointing to in memory. When you dereference a character pointer, you get the character that the pointer is pointing to in memory. What's important to remember here is that when you dereference a pointer, it returns a different type than the pointer itself. This is because a pointer isn't the same type as the item that it points to -- a pointer to an integer is a pointer, not an integer.
So how do we actually dereference a pointer? We use... the asterisk! (dun dun DUNNNNN!)
This brings us to my other big problem with the asterisk. It does two completely different things. In one case, it signifies a type. In the other case, it's an operator. Let's look at this little piece of C++ code:
Now, some more explanation on why I like to write my pointer declarations the way I do ("int* i;" instead of "int *i;"). Look at this code here:
Instead, consider writing your code this way:
Finally, there's one last thing that you need to know about pointers: C and C++ don't care when pointers fall out of scope, which means that you need to explicitly get rid of them when you're finished with them. If you don't, the memory will never be de-allocated even once the pointer falls out of scope, so you won't know where it is to be able to de-allocate it or reference to it. This is what's called a memory leak, and it can cause your code to run slowly and eventually crash when it tries to allocate more memory than the machine has available. Delving deeply into memory allocation is beyond the scope of this blog entry, but here's a quick note about how to do it:
The other thing you'll notice here is that I say "i = 0;" after I deallocate the pointer in both cases. This is just so that C and C++ will know in the future that the pointer no longer points to a valid address. If (as is often the case) you're deallocating a pointer at the end of a function, it's generally okay to skip this step, since it's just going to fall out of scope anyway. However, if you want to be as safe and clean as possible, it doesn't hurt to just leave it in.
So there you have it. My pointers rant. I predict that there will be at least some comments below saying that you don't have to do it my way, and that it's shorter to mix your pointer and non-pointer declarations or that it's better to not initialize your pointers. If you're new to pointers, ignore those people. Once you've gained a solid understanding of them, you can start breaking the rules a little bit. What I've written here isn't necessary in terms of language syntax; it's simply a good set of habits for beginners to get into in order to keep their understanding of pointers as clear as possible and also ease debugging.
If you have questions, feel free to ask in the comments. If you see any real, actual errors in my code, please point them out.
Peace,
Bart K.
OpenGameArt.org
Conceptually, a pointer is a variable that points to a location in memory, generally another variable. In C and C++, the actual data stored in a pointer is a memory address, which is just a number that signifies a particular location in memory. You can interact with a pointer in two ways. You can either look at the actual value of the pointer, which as I said is a memory address, or you can dereference the pointer (I'll explain this in a bit) and look at the value stored in the memory address that it's pointing to. A pointer can point to any type of variable. What's important to remember, though, is that pointers are their own type, distinct from the type of variable they're pointing to. A pointer to a character is not the same type as a character, which brings me to my first major beef with C/C++ pointer syntax. I'd like to introduce you to our recurring villain: the asterisk (*). The asterisk is a villain because he does two completely different things that both have to do with pointers, and he does them in a way that's very confusing. I'll address the first of these things now. Let's say you're declaring an integer.
int i;Now you want to declare an integer pointer:
int *i;When you're declaring variables, the asterisk signifies that the variable is a pointer. Easy enough, right?
Ha! If only.
A pointer is a type, the same way that character and integer are types. And yet, you don't declare them the same way as you declare other types. In fact, you can mix them in with declarations for different types, which is horribly inconsistent. C doesn't let you declare a mix of integers and characters on the same line -- so why can you declare a mix of integers and integer pointers on the same line?
Here's a better way to think of pointer declarations:
int* i;Note that the space is now between the asterisk and the variable, so you're seeing "int*" instead of "int". This is conceptually a much better way to declare your pointers, because it stresses the fact that pointers are a distinct type. Unfortunately, here is where the evil asterisk rears his ugly head. Let's say now I want to declare two integers:
int a, b;Good so far. Now I'm going to declare two integer pointers:
int* a, b;Simple, right? No! The above code is wrong, even though it should be correct. What the above line of code actually does is declare 'a' as in int pointer and 'b' as a regular old integer, making it very difficult to treat pointers the way they ought to be treated -- as a separate type.
You either have to declare them one per line or declare them in a way that's conceptually misleading:
int *a, *b;The above code correctly declares two pointers but makes the evil asterisk appear to be in his other role, which I'll get to in a bit. First, one other important note about declaring pointers: Never leave them uninitialized. It's 2011 at the time of this post -- the overhead of initializing a pointer is utterly minuscule compared to the amount of time it will save you later on when it's time to debug your code. The real way to declare a pointer is like this:
int* i = 0;So, what am I doing here? Remember that a pointer is its own type, and it holds a memory address that points to a location in memory. When I set a pointer equal to something, I'm actually changing that memory address itself, not what's stored in the memory address. Hence, the above variable declaration is creating a pointer that points to memory address zero, which is invalid.
Now why on earth would I want to do that? Simple! When C looks at a pointer, it has no idea if the number contained in that pointer is a valid piece of allocated memory or just some random number that points off to Tux-only-knows-where. So what does C do? It just trusts you. It assumes, sometimes wrongly, that the number that's sitting inside that pointer is a valid memory address, and will happily write to that address if you tell it to, regardless of whether you've actually allocated memory there. Often times this will overwrite some of your code or another variable, and your program will continue humming happily along with no idea that it just made a huge mess of itself, only to mysteriously crash later on in a way that's very difficult to trace.
The thing about zero is the C knows it's not a valid address, so when you try to do something to memory address zero, your program will crash in an immediate, clean, and traceable way, which makes debugging a lot easier. If you're super hardcore and you're writing code on an embedded system where processor power is expensive, you can always remove the "= 0" bit later, although I wouldn't necessarily recommend it.
Another perfectly valid thing that you can do is just allocate the memory immediately when you declare the pointer instead of setting it to zero (or null, as they call it). In C, you'd do this with the malloc() function, and in C++, you'd use the 'new' operator. Here's how that looks:
/* In C: */Egad, what's all that craziness in the C version?
#include <stdlib.h>
int* i = (int*) malloc(sizeof(int));
/* In C++: */
int *i = new int;
Let's look at the C declaration again, this time in glorious technicolor!
#include <stdlib.h>First we'll take a look at malloc(). Malloc is actually a function that's declare in stdlib.h, which is why we included it. What malloc() does is allocates a block of memory and returns a void pointer to the allocated memory address.
int* i = (int*) malloc(sizeof(int));
A void pointer is useless on its own, since 'void' is a type that doesn't actually store anything. The intent, in this case, is that you cast the void pointer to whatever kind of pointer you're allocating, which brings us to the (int*) bit. If you're familiar with C and C++, you've probably already seen a cast, which is where you convert one type of variable to another. What we're doing in this case is telling it to change the void pointer that malloc() returned into an int pointer, so we can then set i equal to it. [edit: There are some good arguments in favor of omitting the cast, although my own C++ habits lead me to include it (not that one ought to be using malloc() in c++ anyway. See this stackoverflow link here: http://stackoverflow.com/questions/605845/do-i-cast-the-result-of-malloc (courtesy of )]
The last part, the sizeof(int) is telling malloc() how much memory to allocate. Since we want a pointer to an integer, we're allocating enough space to store an integer. Sizeof is a function that's built into C that returns the size in memory of the given type. Hence, sizeof(int) returns the size of an integer in bytes, which can vary depending on your system architecture.
So, to summarize, the above line of code creates an integer pointer, initializes an int-sized block of memory, and sets the new pointer to point to the memory address you just initialized. Ugh.
C++ is way simpler in this regard:
int *i = new int;When you say "new int" or "new char" or "new whatever" in C++, you're going through the same process as above, but in a much more readable way. The "new" operator looks at the type you gave it, initializes the memory for that type, and returns a pointer to it.
Hmm, now where'd that evil little bastard asterisk go? Ah, there he is! He's off dereferencing stuff!
So what does dereference mean, exactly? Well, remember how we when we initialized the pointer to zero, we were actually setting the address to zero, and not the contents of the address. One has to wonder at that point, how do we interact with the stuff contained within the address the pointer is pointing at? You dereference the pointer.
Dereferencing is an operator. An operator works essentially like a function, in that it takes a value and returns a different value. When you dereference an integer pointer, you get the integer that the pointer is pointing to in memory. When you dereference a character pointer, you get the character that the pointer is pointing to in memory. What's important to remember here is that when you dereference a pointer, it returns a different type than the pointer itself. This is because a pointer isn't the same type as the item that it points to -- a pointer to an integer is a pointer, not an integer.
So how do we actually dereference a pointer? We use... the asterisk! (dun dun DUNNNNN!)
This brings us to my other big problem with the asterisk. It does two completely different things. In one case, it signifies a type. In the other case, it's an operator. Let's look at this little piece of C++ code:
int* i = new int; // Here, I'm using * to signifyNotice that when I'm dereferencing i, I write (*i). The parentheses aren't strictly necessary, but they're another way to differentiate between using the asterisk to declare a pointer type and using it to dereference a pointer. In this case, the asterisk is an operator that operates on the pointer i and returns an integer variable that's located at the memory address i points to. I can then treat the result of that operation the same way I would treat any other integer.
// a type.
(*i) = 100; // Here I'm using * as the dereference
// operator. I'm setting the value of the
// memory address that i points to to 100.
cout << "This is a memory address: " << i << "\n";
cout << "This is the value of that memory address: " << (*i) << "\n";
Now, some more explanation on why I like to write my pointer declarations the way I do ("int* i;" instead of "int *i;"). Look at this code here:
int i = 0;These above two lines of code do the same thing, the only difference being that the first line also declares i as an integer before it sets it to zero. Now look at this code:
i = 0;
int *i = 0;Any reasonable person would assume (wrongly) that the two above lines of code do exactly the same thing, with the exception that the first line also declares i as a pointer. In actuality, the first line ("int *i = 0;") creates a pointer an initializes the address that the pointer points to to zero. The second line dereferences the pointer and sets the value stored at the address to zero. In any case, if you try running the above two lines of code in immediate succession, you'll get a null pointer error, because you've set the pointer to a null address.
*i = 0;
Instead, consider writing your code this way:
int* i = 0;Now, it's a lot more clear, despite the efforts of that thrice-damned asterisk, that the first line is initializing a pointer and the second line is dereferencing a pointer and setting the value of its address. (Note that running these two lines in immediate succession would still cause a null pointer error, for the same reason as above).
(*i) = 0;
Finally, there's one last thing that you need to know about pointers: C and C++ don't care when pointers fall out of scope, which means that you need to explicitly get rid of them when you're finished with them. If you don't, the memory will never be de-allocated even once the pointer falls out of scope, so you won't know where it is to be able to de-allocate it or reference to it. This is what's called a memory leak, and it can cause your code to run slowly and eventually crash when it tries to allocate more memory than the machine has available. Delving deeply into memory allocation is beyond the scope of this blog entry, but here's a quick note about how to do it:
/* In C: */The free() function is essentially the reverse of the malloc() function, in that it tells the computer you're no longer using the memory that the pointer points to. The computer then releases the memory back into the pool so that it can be allocated again. The C++ delete operator does the same thing. The only catch here is that if you're writing in C++, even though it's possible to use malloc() and free(), you can't mix malloc() with delete and new with free(), since internally they work in different ways. In C++, it's best practice to avoid malloc() and free altogether, and you should never delete a pointer allocated with malloc(), or free() a pointer allocated with new.
#include <stdlib.h>
free(i);
i = 0;
/* In C++: */
delete i;
i = 0;
The other thing you'll notice here is that I say "i = 0;" after I deallocate the pointer in both cases. This is just so that C and C++ will know in the future that the pointer no longer points to a valid address. If (as is often the case) you're deallocating a pointer at the end of a function, it's generally okay to skip this step, since it's just going to fall out of scope anyway. However, if you want to be as safe and clean as possible, it doesn't hurt to just leave it in.
So there you have it. My pointers rant. I predict that there will be at least some comments below saying that you don't have to do it my way, and that it's shorter to mix your pointer and non-pointer declarations or that it's better to not initialize your pointers. If you're new to pointers, ignore those people. Once you've gained a solid understanding of them, you can start breaking the rules a little bit. What I've written here isn't necessary in terms of language syntax; it's simply a good set of habits for beginners to get into in order to keep their understanding of pointers as clear as possible and also ease debugging.
If you have questions, feel free to ask in the comments. If you see any real, actual errors in my code, please point them out.
Peace,
Bart K.
OpenGameArt.org
Thứ Hai, 21 tháng 3, 2011
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 ;)
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.).
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).
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 :)
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!
But don't worry, there is a GIMP plug-in for that too!
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!
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!
Chủ Nhật, 20 tháng 3, 2011
The Rocky Horror Purim Show
One day a year, the Jews dress in costumes and gather together to act out a raucous participatory play.
A story is read: The Book of Esther; in Hebrew, it is Megillat Esther. The reading varies from the sedate and straight to the wild and humorous. Audience participation varies from the very sedate to the wild and humorous with sound and visual effects.
Unlike Rocky Horror, the participation is generally family friendly (little kids are usually present, and there is, after all, a required commandment to fulfill, namely to hear the story read). But similarities abound: even to the point of (otherwise religious) men coming to the event dressed as transvestites.
One prevalent custom performed in nearly every synagogue around the world is the custom of wearing costumes (like Halloween), originally masks. Participation in this custom is more uniform for children; nevertheless many adults also do this. Costumes are often associated with the Esther story, but can vary as wildly as Halloween costumes do.
Another prevalent custom performed by nearly every synagogue across the world is to "drown out Haman's name". Namely, when the name of Haman is read during the story (about 70 times), everyone present stamps his or her feet, boos, or whirls some kind of noisemaker (often a "gragger", which is a spinning, clacking noisemaker designed specifically for Purim). Since there is an obligation to hear every word read, the reader must finish reading the name before the noise starts, and must wait for the noise to end before continuing. Or must repeat the name and continue, if the noise actually drowned out the name. However, many people are not careful about this.
Yet another custom is for certain of the foreboding sentences to be read not in the traditional chanting tune used for The Book of Esther but in the tune used for the book of Lamentations.
Those are some of the most prevalent customs. However, many other acts of audience participation crop up into the reading, and these vary from place to place.
In synagogues I've been to:
In normal years, in most places, this all takes place while people are still fasting from the Fast of Esther (the fast is during the day, and the first reading occurs on that night). However, when Purim falls on Sunday, the fast is pushed back to Thursday. And in Jerusalem, Purim is celebrated a day later, but the fast is still on the same day, so there is always (at least) a day break between the two.
What is the fast for? Some think it is because of when Esther fasted in preparation for intruding on the king to make her request. Some think it is for the fast that Jews did before going to war. And some think it is in atonement for whatever we must have done to bring the calamity (that was ultimately overturned into a festivity) upon ourselves. And because, though Haman is defeated, his descendants live on today.
A story is read: The Book of Esther; in Hebrew, it is Megillat Esther. The reading varies from the sedate and straight to the wild and humorous. Audience participation varies from the very sedate to the wild and humorous with sound and visual effects.
Unlike Rocky Horror, the participation is generally family friendly (little kids are usually present, and there is, after all, a required commandment to fulfill, namely to hear the story read). But similarities abound: even to the point of (otherwise religious) men coming to the event dressed as transvestites.
One prevalent custom performed in nearly every synagogue around the world is the custom of wearing costumes (like Halloween), originally masks. Participation in this custom is more uniform for children; nevertheless many adults also do this. Costumes are often associated with the Esther story, but can vary as wildly as Halloween costumes do.
Another prevalent custom performed by nearly every synagogue across the world is to "drown out Haman's name". Namely, when the name of Haman is read during the story (about 70 times), everyone present stamps his or her feet, boos, or whirls some kind of noisemaker (often a "gragger", which is a spinning, clacking noisemaker designed specifically for Purim). Since there is an obligation to hear every word read, the reader must finish reading the name before the noise starts, and must wait for the noise to end before continuing. Or must repeat the name and continue, if the noise actually drowned out the name. However, many people are not careful about this.
Yet another custom is for certain of the foreboding sentences to be read not in the traditional chanting tune used for The Book of Esther but in the tune used for the book of Lamentations.
Those are some of the most prevalent customs. However, many other acts of audience participation crop up into the reading, and these vary from place to place.
In synagogues I've been to:
- When the word "runners" is read (runners delivered the messages to every kingdom), the audience stamps its feet like runners.
- People boo and make noise when Zeresh's name is mentioned (Haman's "evil" wife: it's only equal rights that we boo both of them, right?) and when the words "and the king imposed a tax" are read.
- When the words "and a great cry went out over Shushan", I let loose a bloodcurdling scream, something I learned from my friend David Elkins when I was in his synagogue.
- This year there were a few vuvuzela's in the audience for use as noisemakers.
- The reader uses a faux feminine voice when reading Esther's lines in the text, and a gruff voice when reading Haman's lines. Certain lines are spoken with dramatic raising of the voice or dramatic pauses.
In normal years, in most places, this all takes place while people are still fasting from the Fast of Esther (the fast is during the day, and the first reading occurs on that night). However, when Purim falls on Sunday, the fast is pushed back to Thursday. And in Jerusalem, Purim is celebrated a day later, but the fast is still on the same day, so there is always (at least) a day break between the two.
What is the fast for? Some think it is because of when Esther fasted in preparation for intruding on the king to make her request. Some think it is for the fast that Jews did before going to war. And some think it is in atonement for whatever we must have done to bring the calamity (that was ultimately overturned into a festivity) upon ourselves. And because, though Haman is defeated, his descendants live on today.
Thứ Bảy, 19 tháng 3, 2011
Weekend Gaming, Purim
At Nadine's house, I played Puerto Rico for the first time in (what feels like) a year. I had actually been hoping we might play it after lunch.
Puerto Rico is still my favorite game, but we just don't play it much at the group, as a) some of the players play it obsessively online already, and b) we received many new games last year.
I played with Nadine and her daughter Ginat. I was second player, and the only building substitutions were Small Wharf for Large Warehouse and Library for University, neither of which were bought.
Despite my not having played in a long time, I still wanted to try something a little different. So my second building purchase (after Small Market, duh) was Construction Hut; I hesitated between it and Hacienda, another building I don't play much. However, I could see my way to producing corn, indigo, and coffee by the first half of the game already, and I didn't think I needed to worry about more production. My coffee was in front of Ginat who also had coffee, Nadine was already working on sugar, and I didn't think I was going to go for Residence.
Well, it worked well. I bought Harbor. Together with a few coffee sales, and some judicious Captain-taking to ensure the boats were always filled with my goods, I was able to advance in both shipping and building. Final scores: 58 to Nadine's 51 to 45.
Purim
Tonight is Purim outside of Jerusalem. I will be joining my brother Ben for a seuda tomorrow (and expect to play something) and then I will return for Shushan Purim (celebrated in Jerusalem). As an avel (mourner), my partying is limited: people aren't supposed to send me shaloch manot, I can only send two, and I can't go to any parties, though I still have to do the seuda and other mitzvot.
However, for those not in mourning, I recommend the shpiel my synagogue is putting on, and in which I would be participating if I could:
Puerto Rico is still my favorite game, but we just don't play it much at the group, as a) some of the players play it obsessively online already, and b) we received many new games last year.
I played with Nadine and her daughter Ginat. I was second player, and the only building substitutions were Small Wharf for Large Warehouse and Library for University, neither of which were bought.
Despite my not having played in a long time, I still wanted to try something a little different. So my second building purchase (after Small Market, duh) was Construction Hut; I hesitated between it and Hacienda, another building I don't play much. However, I could see my way to producing corn, indigo, and coffee by the first half of the game already, and I didn't think I needed to worry about more production. My coffee was in front of Ginat who also had coffee, Nadine was already working on sugar, and I didn't think I was going to go for Residence.
Well, it worked well. I bought Harbor. Together with a few coffee sales, and some judicious Captain-taking to ensure the boats were always filled with my goods, I was able to advance in both shipping and building. Final scores: 58 to Nadine's 51 to 45.
Purim
Tonight is Purim outside of Jerusalem. I will be joining my brother Ben for a seuda tomorrow (and expect to play something) and then I will return for Shushan Purim (celebrated in Jerusalem). As an avel (mourner), my partying is limited: people aren't supposed to send me shaloch manot, I can only send two, and I can't go to any parties, though I still have to do the seuda and other mitzvot.
However, for those not in mourning, I recommend the shpiel my synagogue is putting on, and in which I would be participating if I could:
In celebration of Purim, Kehilat Mizmor LeDavid's Kosher Hams present the
new comedic musical revue: DEAD SEA DISCS - The Saga Continues!
Written by Allan Rabinowitz and Performed by the Kosher Hams
Join us following Shushan Purim Megilah reading!
Sunday, March 20
9:00 PM
The Masorati Auditorium
30 NIS
Masorati School, Beitar 8, Talpiot, enter by way of Giladi/Efrata Streets.
Tickets sold at the door, first come first served, costumes encouraged.
Further information: mizmorledavid@gmail.com, or 02-673-5338
Thứ Sáu, 18 tháng 3, 2011
Xonotic Player Interviews
Do you like Let's Plays (Commented gameplay videos)? I do. Antibody of Xonotic made something similar with pro Xonotic/Nexuiz players and sometimes developers: Interviews during playbacks.
Um, I hope you like YouTube..
Um, I hope you like YouTube..
Thứ Năm, 17 tháng 3, 2011
Fun Board Games to Enhance Students' Learning Experiences
The following is a guest post from Brian Jenkins
Playing board games is a great way for students to learn because children retain more information when they're having fun. Games get children motivated. Math and spelling won't induce boredom when they're integrated into fun games. By playing board games, children enhance their logic and reasoning skills, learn to solve problems, and gain skills in strategic thinking.
Kids also enhance their social skills while playing board games. They learn about following rules, taking turns, fairness, and how to graciously win and loose. Of course, gracious losing might kids some extra time to get the hang of!
Let's take a look at some of the best board games for young students:
Dino Math Tracks Place Value Game
This game has received the Oppenheim Toy Portfolio Gold Seal which is given to toys that enrich the lives of children. Players race around the game board with a pack of prehistoric pals. The game emphasizes the mathematical concept of place value and is a fun way for young students to learn addition and subtraction. The game includes multiple levels of play for children of different ages and abilities.
UPWORDS
UPWORDS is similar to Scrabble and exercises the same skills. However, it is easier to make words and score points because kids can stack onto existing words. Therefore, it's a better choice than Scrabble for younger kids. Also, the scoring system is simplified.
Primary Pups
This fun game integrates 1st through 3rd grade curricula. Players answer multiple choice questions from the following subject areas: Math, science, history, grammar, health, and geography. Students advance their puppies along the game board by correctly answering questions.
Flip 4
Flip 4 is designed for ages 8 to 12. It's a strategy game that teaches math and logical thinking and planning. Kids role the dice and then add, subtract, or multiply to land on board squares. Students try to strategically flip their opponents out of the game. The game received an Oppenheim Toy Portfolio Gold Award, a Dr. Toy Top 10 Game Award, and an iParenting Media Award.
Equate
This game is a mathematical version of Scrabble. Kids use tiles to make horizontal or vertical math equations. In addition to teaching kids how to add, subtract, multiply, and divide, the game requires kids to think strategically and creatively. Equate received a Parent's Choice Recommended Award, a Games Magazine Best Game award, and a Dr. Toy 100 Best Children's product award.
Word Pirates
It takes spelling and strategy skills to win this game. Kids try to be the fist player to reach the treasure by building a path of words and bridges. The game is designed for ages six and up and received a Creative Child Magazine Preferred Choice Award.
Have Kids Create Their Own Board Games
Besides playing with fun, educational games made by adults, let students have the opportunity to make their own games. Give them criteria to meet and allow them to use their creativity to develop a game. This is a great challenge for students!
Board games are a great way to break up the monotony of everyday classroom instruction. Fun and education is always a great combination!
Brian Jenkins writes feature articles, including pieces that offer career information for elementary school teachers, about a variety of different education and career topics for BrainTrack.com.
The opinions expressed in this post do not necessarily reflect the blog owner's.
Playing board games is a great way for students to learn because children retain more information when they're having fun. Games get children motivated. Math and spelling won't induce boredom when they're integrated into fun games. By playing board games, children enhance their logic and reasoning skills, learn to solve problems, and gain skills in strategic thinking.
Kids also enhance their social skills while playing board games. They learn about following rules, taking turns, fairness, and how to graciously win and loose. Of course, gracious losing might kids some extra time to get the hang of!
Let's take a look at some of the best board games for young students:
Dino Math Tracks Place Value Game
This game has received the Oppenheim Toy Portfolio Gold Seal which is given to toys that enrich the lives of children. Players race around the game board with a pack of prehistoric pals. The game emphasizes the mathematical concept of place value and is a fun way for young students to learn addition and subtraction. The game includes multiple levels of play for children of different ages and abilities.
UPWORDS
UPWORDS is similar to Scrabble and exercises the same skills. However, it is easier to make words and score points because kids can stack onto existing words. Therefore, it's a better choice than Scrabble for younger kids. Also, the scoring system is simplified.
Primary Pups
This fun game integrates 1st through 3rd grade curricula. Players answer multiple choice questions from the following subject areas: Math, science, history, grammar, health, and geography. Students advance their puppies along the game board by correctly answering questions.
Flip 4
Flip 4 is designed for ages 8 to 12. It's a strategy game that teaches math and logical thinking and planning. Kids role the dice and then add, subtract, or multiply to land on board squares. Students try to strategically flip their opponents out of the game. The game received an Oppenheim Toy Portfolio Gold Award, a Dr. Toy Top 10 Game Award, and an iParenting Media Award.
Equate
This game is a mathematical version of Scrabble. Kids use tiles to make horizontal or vertical math equations. In addition to teaching kids how to add, subtract, multiply, and divide, the game requires kids to think strategically and creatively. Equate received a Parent's Choice Recommended Award, a Games Magazine Best Game award, and a Dr. Toy 100 Best Children's product award.
Word Pirates
It takes spelling and strategy skills to win this game. Kids try to be the fist player to reach the treasure by building a path of words and bridges. The game is designed for ages six and up and received a Creative Child Magazine Preferred Choice Award.
Have Kids Create Their Own Board Games
Besides playing with fun, educational games made by adults, let students have the opportunity to make their own games. Give them criteria to meet and allow them to use their creativity to develop a game. This is a great challenge for students!
Board games are a great way to break up the monotony of everyday classroom instruction. Fun and education is always a great combination!
Brian Jenkins writes feature articles, including pieces that offer career information for elementary school teachers, about a variety of different education and career topics for BrainTrack.com.
The opinions expressed in this post do not necessarily reflect the blog owner's.
Session Report, in which I beat David in Magic, suprisingly
The latest Jerusalem Strategy Gaming Club session report is up. Games played: Boggle, Glory to Rome, Magic: The Gathering, Tribune, Bridge.
Sintel The Game mini-update
The Sintel The Game crew contacted me and asked me to take down the post due to a misunderstanding, will keep the couple of screenshots here though. ~Goat
Awesome.
Thứ Tư, 16 tháng 3, 2011
Red Eclipse 1.0
The Red Eclipse project, forked from the now-defunct Blood Frontier project, has made it's first release - Red Eclipse 1.0: Ides Edition. It has been continuous under heavy development, as was BF before it, but the RE team took their time over a release opting to "Get Things Right" first*. Thus, the '1.0' should be an accurate reflection; solid gameplay, stable game, and embodies the majority of the game design the developers first envisaged.
It claims to have both single- and multi-player modes. At time of writing, the website has no about page, no details on the game other than the very basics (genre, platforms, etc). I am told that, in the single player game, you lead a squad through a series of zombie-infested maps. Who doesn't love zombies?!
Gameplay is described as 'agile' so it's frantic and fast-paced with acrobatics and super powered weaponry.
Red Eclipse is based on the Cube 2: Sauerbraten engine, so comes with a very powerful built-in map editing and the stability and graphical capabilities of one of the most mature Free Software FPS engines.
EDIT - updated to a better trailer. If you want to see the previous trailer, go here, but it's naff so just watch the one below.
Also Red Eclipse has applied for a forum on FreeGameDev.net which is another boost for the community.
* Note that I am a big believer in 'release early, release often' but the Red Eclipse team had the activity levels and situation to be able to be successful by holding off, partly because Red Eclipse SVN was nearly always playable and partly because a lot of the work had been done in the guise of Sauerbraten and the play testing, tweaking, and feedback from Blood Frontier.
Thứ Ba, 15 tháng 3, 2011
Spaced Out - Vega Strike and Pioneer betas plus Multiplayer Simutrans and MotoGT
The recent blogging activity, spurred on by the growth in official Free Gamer blog authors, is a pleasure to see. When I started the blog back in 2006, I didn't think it'd ever be so popular, let alone last this long.
* Casual reference to remind readers that I am the original author and, should I ever be displeased, I will smite thee with banana flesh limbs.
^ Reference to IVAN; LIVAN or IVANX are better - see community site for variants.
Vega Strike ShadersThere's a new beta release for Vega Strike. Version 0.5.1 beta 1 (forum announcement) is a bigger point release than the 0.5.0->0.5.1 step implies. Improved planet shaders, lots of bug fixing, lots of general tidy up, video support (mainly for mods) and a lot more ships.
Coincidentally, one of the original Vega Strike authors is working on a project called OurBricks for online collaboration of 3D resources. Lots of the Vega Strike ships are already uploaded.
The ever impressive Pioneer Space Sim project, an Elite-inspired game, continues its activity with the release of Pioneer beta 9. Changelog includes rewritten combat AI, lots of HUD work, some even nicer planet terrain, trade ships, and more.
Also there's big news for Simutrans fans. There was a lull in releases after Simutrans 102.2.2 as the team worked on introducing multiplayer. After nearly a year, version 110.0.1 (and 110.0.0 before it) has arrived with the usual plethora of fixes and well as full multiplayer support.
Our final exciting release is for the fourth beta for MotoGT. Changes include new tracks, effects, joystick support, full championship mode, and more. A video:
Reddit Game Jam 06 (March 25 to 27)
All the screens I could find of RGJ 1-5 submissions
Reddit Game Jam 06 starts March 25 and ends two days later (22:00 UTC).
Anybody can participate. Those who can't code should get together with coders in a team. Team size this time is unlimited.FOSS is encouraged, not required. [full rules]
From the subreddit's sidebar:
A game jam is an event during which all participants create games according to a provided theme within a short amount of time (usually between two days to a week). The Reddit Game Jam hosts game jams as part of the wonderful Reddit community.
Anybody can participate, experienced or newbie, flash developer or C hacker.
The main goal of this game jam is to be a learning experience for everyone involved. There is nothing to win except for fame, comments and of course karma."
Thứ Hai, 14 tháng 3, 2011
Holy Crap! M.A.R.S. 0.7.0!
Grave-Itation Pit!
I don't like gravity shooters. In fact I don't like them so much I don't play them. They require more precision and skill than I want to give and are unforgiving.
It is ridiculous that I like one gravity shooter though. A ridiculous one. M.A.R.S.
So.. new version.. let my just copy-paste that changelog.. OH MY DOG THEY HAVE A VISUAL CHANGELOG!
- new music (by Obsidian Shell)
- new game mode (Grave-Itation Pit)
- improved AI (collect powerups, use specials, kick more butt)
- new planet gfx
- new ships
- new specials (Freezer, Fire Wall)
- gamepad support (tested with Xbox360 controller)
- more languages (total of 15)
Updates since the 0.7.0 release:
- M.A.R.S. has experimental OSX builds!
- M.A.R.S. is in need of Arabic, Hungarian and Italian translators!
The web needs more visual help requests!
Chủ Nhật, 13 tháng 3, 2011
My Game Closet
Or as Rachel calls it, the eyesore:
Some games not present (lent out to game club members) and some games behind the shelf (Go board, extra copies of It's Alive, etc). As I said, it's not many games; I keep it small by regularly trading away or selling games that didn't go over well in favor of new games.
Some games not present (lent out to game club members) and some games behind the shelf (Go board, extra copies of It's Alive, etc). As I said, it's not many games; I keep it small by regularly trading away or selling games that didn't go over well in favor of new games.
SDL job offer, open art funding opportunities, tiny java/Slick game competition...
SDL-makers Galaxy Gameworks are looking for a talented developer who would be interested in developing and maintaining SDL.
Pfunked might support artists starting their own funding campaigns for creating art for FLARE, as he did with Justin's. Here are some asset ideas.
Then there's the option to offer high-quality art for being 'funded into free' at OpenGameArt. The current target is $130 for this dwarf warrior.
I wish there were (more) open source projects at 8bitfunding, Kickstarter, Fundry and IndieGoGo. The only open source game dev projects I found are a flash game (successful), FAR Colony and an interactive fiction engine iphone port (successful). I'm sure not only full game projects could make use of these fundraising services but free content creators as well.
Then there's a game competition by the Slick java game engine. Check the image above for rules and prizes.
That's about all I can find and think of right now. Got anything to add? :)
PS: do you use flattr? Then share your data for great justice! If you're not using it yet but are sharing content on the web, then start using it already! :D
PPS: Wesnoth is still offering $200 for a swamp sound loop.
Pfunked might support artists starting their own funding campaigns for creating art for FLARE, as he did with Justin's. Here are some asset ideas.
Then there's the option to offer high-quality art for being 'funded into free' at OpenGameArt. The current target is $130 for this dwarf warrior.
I wish there were (more) open source projects at 8bitfunding, Kickstarter, Fundry and IndieGoGo. The only open source game dev projects I found are a flash game (successful), FAR Colony and an interactive fiction engine iphone port (successful). I'm sure not only full game projects could make use of these fundraising services but free content creators as well.
Slick contest - art by danc
Then there's a game competition by the Slick java game engine. Check the image above for rules and prizes.
That's about all I can find and think of right now. Got anything to add? :)
PS: do you use flattr? Then share your data for great justice! If you're not using it yet but are sharing content on the web, then start using it already! :D
PPS: Wesnoth is still offering $200 for a swamp sound loop.
News from 0 A.D.
Well I certainly didn't see this coming, but 0 A.D. has decided to switch their game-play concept and turn the game into a Diablo like hack and slash RPG (while keeping the historical accurateness of course). For the first teaser pic see below:
Ok bad phun, I admit...in reality they decided to turn it into a FPS game, which I really can't understand at all :( I mean, just look at these horrible screen-shots they are putting out as a 'proof of concept':
However, unrelated to these shocking news... check out this boring new alpha 4 RTS release, code named Deadalus. It features a boring new AI, and a bunch of other boring stuff (including boring additional celts stuff)... so don't bother with it until the new and shiny 0 A.D. RPG, errm FPS arrives ;)
Ok bad phun, I admit...in reality they decided to turn it into a FPS game, which I really can't understand at all :( I mean, just look at these horrible screen-shots they are putting out as a 'proof of concept':
However, unrelated to these shocking news... check out this boring new alpha 4 RTS release, code named Deadalus. It features a boring new AI, and a bunch of other boring stuff (including boring additional celts stuff)... so don't bother with it until the new and shiny 0 A.D. RPG, errm FPS arrives ;)
Thứ Bảy, 12 tháng 3, 2011
icculus @ Flourish! 2011: Gaming and Linux - also an interview!
icculus will be talking about gaming on Linux in Chicago April 2nd.
Ryan "Icculus" Gordon is a former Loki Software employee who is now responsible for icculus.org, which hosts many Loki Software projects as well as several new projects created by himself and others. Gordon's site hosts projects with the code from such commercial games as Duke Nukem 3D, Shadow Warrior, Quake III Arena and many other free and open source projects for multiple platforms.I can tell the Flourish! conference is a good one because it does not have "Free", "Libre" or "Open" in its title directly. ;)
Last year's conf was documented in videos and hopefully the same will happen with icculus' talk.
There is a recent interview [Czech version], in which icculus talks about himself, graphics programming, a better world and porting.
FPS release weekend?
As the self proclaimed FPS expert here on FreeGamer (who doesn't have a PC to play any FPS right now :( ), I have to keep you updated on the newest released and developments of course!
So what is the big news for this weekend? Well looks like the Cube2 engine powered Red Eclipse is finally getting an official release tomorrow :)
Head over to their IRC chat to not miss the release, which is expected for Sunday 13th of March, 2am GTM! Oh and they are also having a small donation drive to fund their new player-model which will be released as all art assets of the game under a FOSS compatible creative commons license (170 Australian $ still needed at this time) AFAIK.
A smaller release comes from the Alien Arena team today. Not much changes in version 7.51 in regards to gameplay or media, but under the hood the engine got some serious performance upgrade (full change log).
To my surprise it stayed really quiet after the Enemy Territory source release last year, with ioET never getting even seriously started, and no other interesting releases showing up :( The only exception was the Xreal renderer partially ported to ET, but development stalled and their website recently went down, with no further signs of development.
Now however someone else seems to have taken up the source code and released a updated developers version. Let's hope for the best and I am really looking forward to play an updated version of that multiplayer classic again!
So what is the big news for this weekend? Well looks like the Cube2 engine powered Red Eclipse is finally getting an official release tomorrow :)
Head over to their IRC chat to not miss the release, which is expected for Sunday 13th of March, 2am GTM! Oh and they are also having a small donation drive to fund their new player-model which will be released as all art assets of the game under a FOSS compatible creative commons license (170 Australian $ still needed at this time) AFAIK.
Alien Arena 7.51 released
A smaller release comes from the Alien Arena team today. Not much changes in version 7.51 in regards to gameplay or media, but under the hood the engine got some serious performance upgrade (full change log).
Enemy Territory Xreal development picked up again
To my surprise it stayed really quiet after the Enemy Territory source release last year, with ioET never getting even seriously started, and no other interesting releases showing up :( The only exception was the Xreal renderer partially ported to ET, but development stalled and their website recently went down, with no further signs of development.
Now however someone else seems to have taken up the source code and released a updated developers version. Let's hope for the best and I am really looking forward to play an updated version of that multiplayer classic again!
Thứ Sáu, 11 tháng 3, 2011
Ryzom now nearly free to play
In a bold (desperate?) move the guys behind the nearly completely FOSS but still commercial MMORPG Ryzom have decided to make their game free-to-play, but with some smaller limitations (which are supposed to make you buy a subscription at some later point of course ;) ).
We mentioned it before, but Ryzom also runs fine under Linux (as seen above), and check out their developers page, and art asset repository if you are thinking about contributing.
Personally I feel the game shows it's age a bit too much on the desktop platform, but a mobile version (lets say on Maemo and Android) could really shine and attract a lot of users. But now is your chance to try it out as long as you like ;)
We mentioned it before, but Ryzom also runs fine under Linux (as seen above), and check out their developers page, and art asset repository if you are thinking about contributing.
Personally I feel the game shows it's age a bit too much on the desktop platform, but a mobile version (lets say on Maemo and Android) could really shine and attract a lot of users. But now is your chance to try it out as long as you like ;)
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
Session Report, in which I win both Glory to Rome and Shipyard
The latest Jerusalem Strategy Gaming Club session report is up. Games played: Glory to Rome, Shipyard.
Yay me, I won both games.
I just reorganized my game closet; Rachel thinks it's an eyesore. I think it's a thing of beauty, except that it has so few games (about 75; naturally, everyone else thinks I have "so many" games).
Yay me, I won both games.
I just reorganized my game closet; Rachel thinks it's an eyesore. I think it's a thing of beauty, except that it has so few games (about 75; naturally, everyone else thinks I have "so many" games).
Thứ Năm, 10 tháng 3, 2011
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.Thanks to gustavo for the instructions!
mono GameModeFortress.exe
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.
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
Đăng ký:
Nhận xét (Atom)