The walkthrough video for our latest release is now online at our youtube channel. In the video, I commentate about current content and the content we have yet to produce. I also give an explanation about our design philosophy and the motivations behind many of our major features.
The Windows package of our latest release is now available at Project Download page. The file is named allacrost_win_dev20150628.zip. Enjoy!
Today we're glad to announce our first release of 2015. This is a development release, meaning it is a stable snapshot of the game's current state of development. You can download these files from our new project page over at BitBucket (the files for this release have the text "dev20150628" in the filename). We have provided a release file for OS X and Linux (source). The Windows distribution is not available yet due to some technical issues, but it will eventually be on the download page in a few days. I'm also in the process of recording a walk-through video for this release along with commentary, which you can also expect in the near future. I'll make announcement posts accordingly when these items become available.
This is a pretty significant turning point for this project. It's been nearly four years since the last time this project saw a release and it feels great to turn things around. And notice we called this the "first release" of this year. We fully expect to follow up with at least one, possibly two more releases in the coming months. Much of the work that has been accomplished in the past several months had the aim of improving the process of developing maps, scripting events, and managing game data. With the bulk of this work now complete, future development efforts are going to be focused on developing game content and fixing many of the rough edges found throughout the game.
We hope you enjoy this release, whether you play it yourself or watch the walk-through video when its available, and look forward to what's coming next.
You may have heard of the latest scandals and tribulations with the site sourceforge.net, which has been a reliable service for our project since our earliest days. This news greatly upset me and caused grave concern about using their services. It's a shame, but it is clear that this hosting service has long since lost their way and can no longer be a trusted partner for us. As such, we are in the progress of migrating all of our code and release files to a new home and will eventually shut the doors on our sourceforge project page indefinitely.
After doing some research, we've decided to move to BitBucket.org for hosting of both our code repository and release files, including past releases. Additionally, the site supports a free issue tracker that we're going to experiment with. We'll likely retire our old issue tracker as a result. This tracker was used well for a few years, but it hasn't been maintained due to time constraints and most of the issues reported there are so old they are no longer relevant. Finally, as a part of this move we'll be migrating the code to new version control software. Subversion has served us well over the years, but has fallen out of favor and many hosting services do not support it (including BitBucket). We've decided to transition to Mercurial, which is similar to the popular Git, but is easier to learn and has a superior user interface. This ease of use was the critical factor in our decision, as we don't want to alienate those who aren't already experienced git users from being able to contribute to this project.
The new project page for Allacrost on BitBucket can be found here: https://bitbucket.org/allacrost/allacrost . It currently is very minimalistic and the code hasn't been uploaded here yet. By the time the next release is available though, this page should be complete and fully functional.
These moving pains have unfortunately caused some delay in publishing our development release by a couple weeks, as we need to complete this migration prior to uploading the release files. The release should still become available sometime this month and we're very, very close to having it ready. I'll also be uploading a complete play through of the release to our youtube channel once it's ready, so that those without the inclination or time to download, install, and play through the game themselves can still see what's new and get a sense of the state of the game. All of these developments should happen by the end of this month.
Progress has been slowing down quite a lot over the past month. There's a simple reason for this. For the past six months, I've pretty much been working solo on Allacrost. Yes, there have been small contributions by a couple of others along the way, but 99% of the progress made since the Fall of last year was due directly to my own efforts. My time has become more scarce over the past few weeks, which explains why this progress came to a grinding halt. This is a temporary situation though, and I expect to be back on track in a couple weeks.
The lack of contributors was certainly not due to my lack of trying. I've attempted to find others to help out at communities we've been successful at pulling from before, but for some reason this project doesn't seem to attract the talented and dedicated people that it used to. I'm not completely certain why this is, given that we are in a better position than we ever have been to start really producing playable content. But I speculate that lack of interest may be due to the following.
Most popular open source projects these days are hosted on sites like Github or BitBucket while we are still on Sourceforge. Some have told me that simply moving to these platforms will make our project more attractive. It's something we're certainly considering for the future, but right now I'd rather our efforts be focused on making the game, not fumbling around with updating our platform and processes.
When Allacrost was birthed, gaming in Linux was barely worth mentioning. Today, distributors like Steam and GOG provide native Linux ports. Not to mention the number of games produced in general feels like it has really climbed over the years. It's hard to be noticed among so many other fine projects (not that I'm complaining, as a Linux gamer myself I love how the platform has grown).
Allacrost is now over a decade old. That's a really long time, and I can imagine people being deterred simply because they don't want to contribute to something that's taking so long to complete. I can't say I blame people who think that, and it's unfortunate. People also tend to like to join a project early, when they can influence the direction and style of the game more easily. The only solution is to pump out releases so we can show the world we're still around and kicking.
To put it simply, we (I) am desperate for additional help. Its a real struggle to work solo on such an enormous project. Truthfully, there isn't much that remains in the way of completing the development release I had planned back in February. But it's a lot of little things including some programming, map scripting, artwork production, and map design. It feels a little overwhelming for just myself to wear so many hats and do all of this alone. But, I will do so alone if I must. But if you'd like to help, please have a look at the Contribute page and find out how you can.
With any luck, the next news post will be an announcement of the next development release. Look for that sometime in May or June.
With the editor redesign complete, focus is shifting back to working on creating the content needed to complete this release. The new editor is immediately being put to work to create new maps, and it's new capabilities are greatly expediting the map creation process. Here's a couple screenshots showing what is to be our largest and most complex map ever created. A link to an album containing more screenshots follows. This map is still very much incomplete and is only in the drafting stages, but it is the best visible progress that this release has seen in a long time.
I'd like to make a development release happen soon, ideally by the end of the month. The editor needs to be made available to more than just those with the time and interest to download and compile the code, particularly since we are still hoping to find a game designer who will focus on creation of maps and other game content. It will also serve as further proof that this project is alive and well again, even with our limited team. Below is a visual that illustrates just how large of a gap there has been since the last time that development on Allacrost was (briefly) active. Steam continues to pick up, and I feel increasingly confident that we can make an official release happen by July.
Over the past several weeks I've been working hard to make some major improvements to our map editor. Tonight, I'm happy to be able to share the results of that effort and demonstrate what our new editor can do for us.
The impetus for this work was that our old editor, while fully functional, was cumbersome and tedious to use. Our upcoming release includes one map that is larger and more complex than anything we have published in any of our past releases, and we found ourselves discouraged when we made attempts to create this map in the past. I look at this work as a long-term investment in this project that will pay off down the road as the map creation process will now be easier, faster, and more enjoyable.
For this release, the work on the editor is now considered complete. The major focus for the next month will be to use this tool to create the additional maps that we still need and to write the corresponding map scripts. A development snapshot release will be coming in the near future.
The culture of our development team has been a positive factor that has helped nurture the growth of this project. I always wanted this project to feel like a collaboration between real people, not just screen names. In the early years, I made an effort to call everyone on the project by their first name. I can’t do this anymore due to the sheer size and volatility of the team. In fact, I completely forgot that I used to do this until I started reading through some old forum threads when researching our history to write this series of posts.
Another important aspect to our team’s culture is ownership. I have never wanted anyone to feel that they are working on “Roots’ game”, but rather that they are working on their game. I wanted people to have ownership on this project, and to that end I encourage others to share their ideas for features, quests, and so on. If people feel like they can guide the destiny of this project and not just be a brick-layer for its predetermined path, they are a lot more invested and excited about the work that they are doing. Giving people a feeling of ownership hasn’t been easy, and some people on the team were flat out uninterested in design and simply wanted to make art, write code, or otherwise exercise their talents and abilities.
One of the biggest challenges with a free project like Allacrost is finding talented and motivated individuals willing to contribute their time. We do not pay a salary or promise any sort of financial reimbursement to our team. How can we attract volunteers, especially when there are comparable projects to ours that are for-profit? My answer to this question was simple: make sure that people are enjoying the work they do. If people are unhappy or frustrated with the project, they will leave. This policy is still in effect today and all new contributors read about it when joining the team . But it’s not perfect, and some great people certainly have left this project in the past due to feelings that prevented them from enjoying working with us. While we can’t make everyone completely happy on this project, but we sure as hell try.
After our initial team had finished our first series of design discussions and we had a better idea of what we were building, we began our first efforts to seek out additional help. They were wildly successful. Despite not having an experienced team or anything to show for this project, a lot of people were attracted to the type of game we were building and the ideas we presented and wanted to be a part of it. Our recruitment process was very formal in the early days and was almost like applying for a real job. There was a questionnaire that we required every applicant to fill out, then we would share their answers privately amongst the team and discuss the applicant. If no one objected to hiring them and they seemed like they would fit in, we welcomed them aboard.
One of the goals of this formal hiring process was to weed out people that lacked the qualities that we felt they needed to be successful. This could be any combination of experience, attitude, motivation, or other factors. It worked out well for the most part and the majority of the people we brought on the team met or exceeded our expectations. It wasn’t a perfect system though, and we did have some members that were not useful, or even downright damaging to the project. We hired one programmer and one artist in September 2004 and neither of them ended up working out. Here are their stories.
The artist we hired was producing great work that was very promising, despite his extremely young age. When another artist created an improved version of his work, he took it personally and got very offended that someone else would touch his art. Despite reminding him that this is a collaborative effort and that he should have read about this in his welcoming e-mail, he refused to accept the situation and promptly left the project. It was a shame as he was very talented, but not mature enough to work on a collaborative project like ours. It remains the only time we had an incident like that with a team member.
The programmer we hired immediately started making all kinds of destructive changes to the code as soon as he was given access to our code repository. He was scolded for making so many changes to our code policies and structures without first consulting other programmers to get their approval. As a result of this, we began being more careful about granting people commit access to the repository. He was tasked with developing the battle system for the game, which didn’t yet exist at that point. He repeatedly promised and failed to deliver anything for months. Eventually, the team dismissed him and he ultimately was just a hindrance to our progress.
The positive culture of this project was one of the reasons for its early prosperity and its continued survival throughout the years. We were extremely lucky to find so many talented and dedicated people in the first year of this project’s history. These early successes still influence the project today.
 - Allacrost Team Policies
Coming up next:
The first objectives for development of Allacrost were to do basic operations such as draw things to the screen and play sound and music files. I didn’t know it at the time, but I was writing a game engine from scratch. I wouldn’t even know what a “game engine” was until months down the road when we already had a primitive one in active use. The fact that Allacrost was built using a custom game engine is, in my mind, one of the most catastrophic errors that this team made in the early days. Designing and writing an engine from scratch, even for a moderately complex 2D game, requires an enormous amount of time and effort to do. Our engine is pretty nice and solid now after being worked on for so many years, but in the beginning it was pretty awful because we had no experience or idea about how a good engine design should function. A project like Allacrost should have used an existing engine from the beginning. We would be much, much further along in the game right now had we done so. The only positive benefit I feel we got out of it is that we gained a lot more software development experience than we would have otherwise. Of all of the time this team spent writing code for the first three years of this project, I’d estimate that we spent around 75-80% of it working on the engine.
One of the first steps that we needed to take to build the game engine was to select which software libraries we would use. In the very beginning, our technological goals for the game were pretty limited and we decided to use SDL  for pretty much everything. Within a couple months, however, we found ourselves disappointed when we realized the limitations of SDL, especially in terms of graphics. Although we were only making a 2D game, we wanted to harness the power that a 3D graphics library could afford us for making special effects and other nice touches. I began learning OpenGL and after a few days of study, felt that it would be a much better idea to find a graphics programmer  with the sort of experience necessary to write us a 2D graphics engine. I think that was the correct call to make, as with my limited experience and knowledge, anything I made would have been much worse.
Selecting the correct libraries to use is a very important step in creating a custom game engine. We carefully selecting each library that we chose to use, but we didn’t do enough research and ran into several problems. In the early days, we experienced a lot of grief resulting from some of our library selections. One of the first instances of this pain was with our audio engine. We switched back and forth between using SDL_Mixer (an extension of the SDL library) and OpenAL  a total of four times. Thankfully, the audio engine is relatively straightforward and didn’t take much more than a day or two to rewrite and test each time. We initially used SDL_Mixer because it was easy. We then switched to OpenAL because we wanted to use some of its more advanced features. There were some technical difficulties with that library (on Linux, at least) that eventually lead us to drop it and move back to SDL_Mixer for better reliability. We gave OpenAL another shot later and went back to the drawing board with a new engine design. We’ve had no problems with it since. It was frustrating and a poor use of our time. I’m not sure we could have avoided that hiccup though, as sometimes its hard to know whether or not a library works as good as it claims to on every supported platform. We would run into this issue with other libraries in the future. Below is one of the early UML designs I created while developing the first iteration of our audio engine. The UML of the same engine today is significantly more complex.
Needless to say, we reached the end of the summer of 2004 without much to show for it. We had the birthings of a pretty basic 2D engine, but not much in terms of game logic. There was still much, much more that remained to be done than what we had already accomplished. Reality began to set in for our team with regard to how difficult this project was going to be to pull off, and that it was going to take us much longer than we had hoped. Morale was still high and we were collectively learning and getting better every day. But by the end of August, we always felt like we were behind from where we should be. And that feeling still lingers around today.
Coming up next:
Its been a little over two months sinc this project's most recent revival. So far, I've been the only one actively working on it, although others are still around and participating in design discussions. We've agreed that we need to start growing the team again and will be looking to fill a few empty seats. With that in mind and the end of the year approaching, here's a status update on where we are and what we need to see our next release happening.
Our Roadmap has been recently updated and organized to reflect the current state of our progress toward the next release. As you can see on this page, a large number of the tasks for the next release are already completed. The remaining work that needs to be completed include creating map files, artwork, and sound files. I expect that we'll be able to procure some of the media content that we still need from sources like OpenGameArt. There's a forum thread for discussing the roadmap and direction of this project if you are interested in the details.
The primary focus right now is map creation. We still have two small maps and one huge map to complete. Map creation has, thus far, been much more difficult than it should be. The maps that we already have completed for this release and past releases were difficult to produce, largely because our map editor tool was cumbersome and difficult to use. Our sister project Valyria Tear made a great number of improvements in their map editor and map design process in their recent Episode 1 release, so we decided to follow their example. I've spent the last six weeks on a major redesign of our editor. Our editor code hasn't gotten the amount of attention and love that it needs over the history of this project because it was never a high enough priority until now. Once we have a first draft of completed for each of our maps, we'll make a development release available for others to try out and give us feedback on. Getting to this point is our most immediate goal right now and will mark the completion of a huge milestone.
Its difficult to say when we will get to this point. It depends on how soon we can get the help that we need, and how much time that help has to dedicate to Allacrost. With that in mind, here are the positions that we are looking to fill before the end of 2014.
This is the first time we've sought to recruit someone to join our team whose primary role is map development. Even with the improvements that will be made to the editor, map design is still a very challenging and time consuming process. This position includes scripting the sprites and events on the map as well, so some Lua development will be required. We'd like to get at least one artist back on our team, but we'll take as many as we can find. There's only a small amount of development related tasks required to be completed for this release, hence why we're only seeking a single developer.
That's it for this update. I'm confident that if we keep our current pace, you'll see a new release from us in the first quarter or first half of 2015.