First Release of 2015 Available

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.

Moving to a New Home

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.

April 2015 - The One Man Army

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.

Hosting Platform
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.

Competition
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).

Ageism
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.

February Status - Back on Target

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.

Allacrost Capital Map Drafts

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.

Map Editor Improvements

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.

https://www.youtube.com/watch?v=2Su31AWg3t4

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.

10 Years of Allacrost - Culture and Recruitment (July 2004 - October 2004)

    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 [1]. 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.

Sources:
    [1] - Allacrost Team Policies

Coming up next:

  • Dealing with reduced availability
  • Readjusting project goals to be more realistic
  • Summary of 2004

Forum Discussion Thread

10 Years of Allacrost - Initial Development (June 2004 - August 2004)

    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 [1] 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 [2] 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 [3] 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.

Sources:
    [1] - SDL Library - http://www.libsdl.org
    [2] - Allacrost Forums - Recognizing the need for a graphics programmer
    [3] - OpenAL Library - http://www.openal.org/

Coming up next:

  • Creating a positive culture
  • How to find motivation without money
  • Recruiting team members

Forum Discussion Thread

Project Status Update: Its All About the Maps

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.

  • Map Designer (1)
  • Pixel Artist (1 or more)
  • C++/Lua Developer (1)

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.

10 Years of Allacrost - Ignorance (June 2004 - July 2004)

    I was filled with confidence when I wrote the first lines of code for Allacrost. Although I had no experience in game development, I had been writing code in over a dozen different languages for four years through my college coursework, as did our other primary developer. Additionally, I thought that the game we were building was rather modest in terms of its complexity. We were making a 2D single-player RPG, not a MMORPG with 3D graphics. It would be a few months before I began to realize how enormous the amount of work was to make the dream of Allacrost into a reality.

    I had already familiarized myself with the technology and libraries used by Battle for Wesnoth [1] before work on Allacrost begin. Initially, the plan was to start from the Wesnoth codebase and make the necessary modifications to transform the turn-based strategy game into a RPG. As I began studying the Wesnoth code however, I found myself both frustrated and disappointed. The code was unorganized, difficult to understand, and there was virtually no documentation. After spending a couple days trying to make sense of it, I decided to abandon that path and began writing the code from scratch. Let me clarify that I did not regard the Wesnoth code as bad, just difficult for an outsider to comprehend at that time. I’m sure it has improved over the years, and Wesnoth has undeniably been a more successful project than Allacrost over the years.

    This experience had a profound impact on both myself personally and the Allacrost project as a whole. I vowed with conviction that I never wanted anyone to look at the Allacrost code and feel as disappointed and confused as I had been with the Wesnoth code. And we’ve been very successful in that regard. I’ve lost count of the number of messages and e-mails I’ve received over the years from people who were impressed with the quality, design, and documentation of the code. The work that we’ve put in to keep the Allacrost code well understood and organized is something that I’m very proud of this team for doing.

    After writing a few hundred lines of code [2], I began to realize just how ignorant I was about software development. I had no understanding of build systems, how to handle a large number of source files, logging and debugging, and many more critical pieces of knowledge. All of this I had to learn as I went along, as did many other programmers on the team as most of us were young students with little to no professional experience. Still, we seemed to be doing okay for ourselves. We were able to draw maps and sprites, play audio files, and navigate simple menus with a few days work. Things appeared to be coming together. I was deceived by how easy it all seemed to do, and others likely were as well.

    Before work on the code had even begun, I had set out some goals [3] for the team to achieve over the course of the summer. I admitted that they were aggressive, but in reality they were simply impossible. The primary goal was to release the first playable module of the game on August 25th, 2004. And here we are in 2014, and that module still has not been released. Frankly speaking, highlighting that fact is rather embarrassing. Setting these types of goals at this time was a huge mistake, as there was no way to set any sort of realistic expectations with the massive collective ignorance of the team. Our goals should have been much more simplistic and aligned with gaining the necessary experience to produce a screenshot or simple demo. That summer passed with us not achieving much of anything noteworthy, although by the end of August we were definitely closer to moving ourselves and the project in the correct direction.

Sources:
    [1] Battle for Wesnoth - http://www.wesnoth.org
    [2] Allacrost Forums - First Lines of Code
    [3] Allacrost Forums - Initial Project Goals

Coming up next:

  • Designing a game engine from scratch (and why its a bad idea)
  • Selecting code libraries
  • Technical feature creep

Forum Discussion Thread

10 Years of Allacrost - Style (June 2004 - July 2004)

    One of the most important decisions we had to make dealt with our artistic style. We needed to figure out both the technical details, such as the size of our tiles and sprites, and what the general appearance of the artwork in the game would be. We needed to establish our musical style and influences as well, which was a bit more nebulous to define than our art style. During this phase, we employed concept artists who read the story and interpret these words into stunning visuals, some of which are still in use today.



    Naturally, we turned to the artwork found in our two primary sources of inspiration to get an insight into how large our tiles and sprites should be. There were a few different options that we put on the table and discussed [1]. We ultimately settled on 32x32 pixel tiles, 32x64 pixel sprites, and a default game resolution of 1024x768. It proved to difficult to decide on this without being able to see it, so I quickly wrote some test code that allowed us to see what the game would look like with various size tiles and resolution. While there are algorithms out there to scale pixel art [2], we strongly preferred the game to run at a resolution that would preserve the dimensions and quality of the art.

    We need a style to match the serious and somewhat dark nature of the Allacrost narrative. It was easy for us to agree to seek a style that was realistic and slightly gritty. This meant avoiding cartoonish looking characters and soft, bright colors. In addition to the pixel art you’d find in a game like Allacrost, I suggested that we include more traditional artwork (we toss around the phrase “digital paintings” to describe this). Originally my idea was to have one or two “scene paintings” for every chapter of the game, but this feature was shot down by the rest of the early team for being too much of an interruption from the flow of the game. Still, there are plenty examples of this type of artwork found in the game today, from character portraits to location graphics and even battle backgrounds.



    To determine our sprite style, we searched around for games similar to ours and started a discussion. The goal was to agree on which of these styles would best fit Allacrost, and then use that source as our inspiration. The earliest sprite made was, naturally, for the game’s main protagonist. It was well done, but as you can see below it didn’t really fit the sort of style we were looking for. In a few months we would revisit this design and go a different direction entirely.



    I thought that getting high quality, original music into Allacrost was going to be the most difficult type of content for us to create. I was somewhat anxious about finding composers, as I thought there weren’t going to be very many out there interested in a project like Allacrost. Especially considering that they wouldn’t be financially compensated for their work. However, reality was entirely contrary to my expectations. Throughout the lifetime of this project, we have had to turn down several composers who wanted to join simply because we had too many. And the music that every composer on this team has produced for Allacrost has been phenomenal, and blew away my expectations for the quality of our soundtrack.

    The technical standard for our music was easier to define than our artwork. We knew we wanted to use Ogg files as MP3 files require you to pay a hefty licensing fee [3], and we didn’t want to invite any sort of trouble. Because Allacrost targeted PCs where storage space was plentiful, we chose a compression level that left songs of a somewhat high quality and file size. Some of our composers wanted to use an even higher quality (twice what had been agreed upon), but eventually agreed upon the standard as there was little to be gained from these higher qualities and they greatly increased the file size. Our music already consumed more disk space than the rest of the game’s content combined.

    Our early composed pretty much defined the musical style of Allacrost themselves. Rain and Loodwig were the core of our composition and remained so for many years, and the two together are the fathers of Allacrost’s music and musical style. They read through forum posts and after understanding what type of game we were creating and what our primary sources of inspiration were (both musically and otherwise), set to work. The first piece of music composed for the game was titled “Hopeless Desert” by StarPilot and it sounded phenomenal...but yet somehow very familiar. Eventually, I figured out that it sounded extremely similar to the piece “Sandy Badlands” from Final Fantasy VII. The composer didn’t even realize it himself, but had that tune in his head as he was creating the work (and to be fair, the music really fits in well with what he was tasked to create). After some discussion, we regretfully decided to pull it from the game due to this striking similarity [4].

Sources:
[1] Artwork Technical Discussion

[2] Pixel Art Scaling Algorithms (Wikipedia)

[3] MP3 Licensing

[4] Issues with Hopeless Desert

Coming up next:

  • Writing source code for a game from scratch
  • Recognizing and dealing with ignorance
  • Setting the project’s first goals, and how we got them all wrong

Forum Discussion Thread

Syndicate content