Soul Train, the game we’ve been working, on has been temporarily placed on hold. The reason is this: Game Salad is terrible. It’s great for what it is – a ‘no coding’ drag and drop engine. Sadly, our game idea requires a lot more customization. We spent a huge amount of time trying to get it to work – but we finally have to admit we chose the wrong engine to develop with. We like to write code. We like to have full control over what we’re building. It’s simply too hard/impossible to do that in Game Salad.
Not sure what engine we’ll look into next, or where we’ll go from here. But, we’re back to the research stage. Sort of disheartening and depressing, as we had gotten the game into a playable, fairly advanced Alpha. But the move from the Alpha into a fully robust experience with the features we want – it’s just not gonna happen in Game Salad. Bummer. But, I guess just gotta chalk it up to experience.
We rebuilt and relaunched the site recently. Our focus has sort of been all over the place lately, and as such we’d been going through a bit of an identity crisis. We started out only developing apps. Then we tried to add in game development, and quickly chose the worst engine possible to work with. Progress was slow on the game, and our app development slowed to a halt because of it. Then, to get the wheels of industry turning again, in addition our own apps and games, we started taking on web design projects and custom software projects. Suddenly what began as iOS app development had turned in to development of all kinds. So, we figured it was probably better to position ourselves as a ‘digital development’ company.
We still intend to focus on creating apps and games in house. Hopefully we’ll wise up and learn an actual game engine soon which will make that development process 1000% easier. But, in the meantime, client projects of all types have been coming in – which is awesome. You can check out what we’ve been up to on our portfolio page.
Well, you know it’s a bad sign when you plan to create an entire game in 6 months, and instead – 6 months have passed since we last updated our development diary, and we still aren’t done with the game! However, it really isn’t our fault. Here’s why:
iOS 7 broke everything. Not only did it break our game, but is also broke gamesalad (until a recent update) and ALL OF OUR APPS. It took us forever to get things fixed. During that period of fixing everything, not a lot of forward progress was made.
As the game gets closer to completion, gamesalad is becoming more and more constricting. It’s just too simplistic. Once this game is released, we’re switching to Unity. Building a game without being able to actually write code is a terrible idea.
There was a long period of laziness. Sometimes when things get crazy (like the iOS 7 release), instead of rising to the occasion and working harder on our game, we instead just spend a lot of time ignoring the problem and playing other people’s games. This was one of those times.
But. We’re back up and running. Our apps have been updated and are working. GameSalad has updated itself and seems to be working with new iPhones. Things are looking good.
With any luck this developer diary will be a more regular thing again. There are a ton of new features. The game is playable now. We’ll try to get a video of it up in the next post. It’s pretty cool.
Maybe we’ll get ambitious and write a bunch of posts and backdate them to look like we wrote a lot of updates over the past few months and then this post will seem really confusing. But I doubt it.
While the June 1st deadline we set for ourselves to complete our game grows ever nearer, we’ve had to take some time away from the game to get ChiTownFestivals up to speed for the 2013 season.
It doesn’t take a ton of time. But going through and finding the dates and times for the events this year is tough, since the entire reason we started the site is because it’s impossible to find up to date information about these things. Kind of a catch 22. But, for the most part we’ve got the website updated. And now that it has a year and change under its belt in the search engines – they are starting to give it more respect. Our traffic is already through the roof, and we aren’t really even into the full festival season yet. We’re ranking above the official webpages of most festivals, and definitely higher than the City of Chicago’s festival information pages. Rahm really should give us a job promoting the cities activities. Especially since the city info is lacking… an app.
We also updated, or at least submitted an update, for our Chicago Festivals app. We updated the graphics, tweaked the layout a little bit, made it iPhone 5 compatible, allow users to send festival information from within the app, and changed the map function to give users a choice of opening directions in Apple Maps or Google Maps.
The app store really seems to be heavily weighting newer apps these days in the rankings. So we ought to be going through and updating all of our apps with at least some minor tweak every few weeks to maximize downloads. But it’s hard to dedicate that much time to the project when you’re trying to get a game done!
Paul also got into a battle with some people on reddit about how our site functions. There really isn’t any way to win an online argument, but cool that people are posting about the site!
From a gameplay mechanics perspective, everything is in place for the game currently known as Soul Train. Since the last functionality update, here’s what has happened:
Placeholders have been replaced with concept art for all aspects of the level
Tunnels and flashlight interaction has been figured out
Collision detection has been refined
Button placement has been streamlined for the player
The bar car has been build out
The dialogue system is in place
The crafting system is in place
So at this point, Paul and I just need to get to work on the fun parts of the game. Sure there’s plenty of ‘coding’ and drawing to do. But we also are finally at a point where we get to figure out what items will be dropped. What weapons players will be able to craft. What health potions can be created at the bar, and which ones will kill you. The fun creative part of designing a game should start taking the place of writing boolean logic and connecting actors to data tables.
I’ll post a video of where the game is at soon. But it’s gotten hard enough that unless I add in keyboard triggers for movement and weapons, just playing it with a mouse I die before I get to the end of the first car. So that’d be a pretty boring video. Maybe I’ll see if Paul wants to take a video of my iPhone screen when I’m playing it next time we have a work party. Technology!
This is where I brushed off some of my old Flash skills and created a new type of enemy with an actual bone structure for (hopefully) easy animation. I based the design for this character off a 1920s “Newsie” type guy, and added some glowing effects and transparency to make it look ghostly. The drawing part was straightforward, but the bones turned out to be a bit tricky to set up. Here’s what he looked like after one of the failed attempts:
Well that looks a little painful…
Once I got all that sorted out it became a fairly simple exercise to give it the shuffle of a dead guy and some ghostly transparency:
I showed this to Ross, and he said he’d feel bad killing a bunch of dudes that look pretty human and could actually be just trying to come over and give you a little ghost hug. We put it into the scene to see what it would look like and I tend to agree with him – the animation for this enemy is much more complex and overall looks more realistic, so having it as another enemy might not be the right fit. So I think I’m going to go back and make some modifications to the look (and definitely the animation), but it might turn out that a variation of this will end up being the main character. For now I’m calling him “Thomas” because that’s the only train-related name I can think of on short notice.
Next I’ll work on making some quick images to replace the current placeholders so we can start to get a better idea of how things are going to look. Check back in the next few days for another update!
Okay this took forever to do and surprisingly still isn’t actually *done*, but it’s pretty dang close. I think we’re making the decision to shorten the roof a bit so you can see more of the land outside the train which I’m in the process of creating now. Here’s a step by step of everything that’s gone into the making of the first train car. I’ll have to make a couple more of these still, but hopefully there’s enough I can reuse from this one that the others will go quickly. Or at least quicker…ly.
Click to see full size image
And as I promised in the last train update here’s a look at all the layers I have going on. I was planning on adding train variation using different frames, but this file is pretty huge right now so we’ll have to see how my computer handles doubling/tripling the amount of stuff in here.
This was a lot of work but I’m pretty happy with how things are going. About two and a half months to go in our timeline and there’s still a lot left to do, so I’ve got a ways to go before I can breathe any sighs of relief.
The level creation, in terms of the technical side of things, is getting pretty close. Since there are no arrays or dictionaries in gamesalad, as you’d expect, everything is governed by tables. The way it works right now, we have a table that keeps all the stats on possible enemies: hit points by level, speed, animation starting image, etc. Then there’s a table that houses the enemy appearance probability – this will make it pretty easy to tweak difficulty during the later testing stages. We have X amount of slots per level, and we put enemies types into those slots, the more slots we allot to a certain enemy class, the more likely it’ll be chosen to spawn. To save on memory, and since we’re using the same level making it get harder as you progress – it just doesn’t make sense to hard code in enemy locations. Instead, they can spawn within a certain amount of distance either ahead of you or behind you. The spawn rate and totally enemy count increases with each level.
For the weapon inventory, the same table idea exists. Since we can’t add rows to the table on the fly, the player starts out with every item and weapon possible in their inventory. But since they have zero stock of those items, they can’t actually see them – so it’s like they aren’t there. Then, when they find an item or craft a weapon, the stock column updates and bam – the player can see the item in their inventory. I’m not sure if that’s how other gamesalad developers have decided to manage inventories – but it seemed like an easy way to get it up and going.
We’d also discussed the idea of the train going in and out of tunnels during which time they player would have to use a flashlight to see anything. The flashlight would of course require batteries, so you’d have to make tough choices about whether to repower your battery, or to craft a better weapon. Not sure if it’s gonna be too much stuff going on for a simple mobile 2D adventure game to include this added twist, but for now – the basics of how it would work are in place. Below is a screenshot (obviously it looks horrible at this point.)
Up until now we’ve been using an exclamation point as a placeholder for an enemy, so I thought I’d whip up go with a new, non-punctuation art style and make a ghost. I guess the skin color makes it look a little more like Slimer right now and I’m now considering a revision that would show the eyes, but you get an idea of what it looks like. I made a quick GIF of the different layers that went into the character, and one with how the animation will look in the game.
Like I said this is an early stage that I just whipped up last night so we’ll probably be making quite a few updates to this and maybe add some more animation to it if I have the time. Let us know if you have any thoughts for enemies you might like to see!
Well, I’m starting to get to the bottom of some of this gamesalad stuff. About four days ago I made this initial test project. I had a static guy. Two bottons that controlled which way he moved. And the background was divided into 3 sections (train cars) that randomly generated a color. Looked pretty terrible, but at least it worked. Also, theses videos are somehow below the lowest resolution you’ve ever seen.
Since then we’ve made some pretty big strides, though admittedly it still looks pretty uber basic. The train cars now randomly populate into a level (though we only have one temp image in place). We found an old running guy animation Paul had made when he was probably 12, and put that in as a character. I added ‘!’ for bad guys, and gave them a basic AI. Added some randomly generating background elements. And probably the biggest headache, I managed to get the camera to behave like you’d expect it to in a sidescroller. GameSalad likes the idea of the character moving towards the far side of the screen, and only allowing it to pull the camera when he hits the halfway point or further. The notion of pushing the camera to give him looking room depending on which way he is facing – takes quite a bit of effort. Anyway – proof that things are happening: