We are now live on the google play store. That didn’t take long at all. I’m so excited, I can hardly contain it.
So this week was insane. We were trying to get everything ready to publish to IOS, Android, and Desura on Tuesday. Well that didn’t happen, we had too much stuff to do. So instead we pulled multiple late nights, going until 3-4 in the morning. This is not healthy and I really wish that it could have been avoided, but gotta do what you gotta do. Anyways.
Icons: So this was a huge pain in my ass. Using flash builder made everything a little wonky when it came to submitting. So each platform has different requirement for the icons that need to be attached. And figuring out how to attach them correctly in flash builder was also a huge problem. It took me multiple hours, video tutorials, and trial and error before I got them all squared away.
I finally got all the builds done. JenJen was doing the Desura submission, so I got her the windows and Mac builds and took the IOS and Android builds. We got the final builds all submitted, and are now just waiting to hear back on them.
So 98% of the art assets are in the game and everything else is all in. So the two engineers on our team were able to make a lot of progress on the bugs and optimizations on the game. We have it running at a much better speed than it ever has before. We got the memory usage down as well as some of the cpu usage. We now have the game running at the correct framerate for about 85% of the game. We also have a good idea about how to do some more optimization.
We are shooting to send in our first builds to the different publishing sites on Tuesday the 14th. This gives us the remainder of the weekend to get some serious bugs fixed. But without having to add new features or art, we can really start to squash some bugs. I think it will be a good first submission, but I also think that it will get rejected. We still have some small tweaks and things to work out before I think it will get through the vetting process. We also need to start working on our thesis defense. This should be interesting.
So I’ve known the two ending to the game that I wanted to have for a long time. I wanted to be able to finish the game and have the captain die, or you could save him. They would both be considered a success since you got the cadets and the ship home safe, but one is happier than the other. With this in mind I have tried to plan out the paths to take to get to these two different endings, but so much changed constantly that I wasn’t able to get really good branching paths through the game. The choice at the end now basically has to come down to which cadet you choose to come and check on the captain at the very end. I left a hint or two through the game which should help guide the player, if they have been paying close attention, to the cadet that will be able to save the life of the captain. So far the feedback has been good, though maybe my hints weren’t strong enough, but I also don’t want to slap the player in the face with the right answer.
This week has seen a lot of progress and some very busy engineers who have so much to do that performance isn’t at the top of the list. is. There has been a ton of progress on the game in the form of getting lots of art assets done and put in the game. I was finally able to ask our main engineer about our performance problems that arose last week when we were trying to get the game onto the iPad. She said that in order to increase performance, we add a line of code that basically tells the device to render everything in low quality. This only effects the appearance of the game by a little bit given that everything is 2D, but the fact that was her answer for solving a performance issue made me frustrated.
Something in the code, or engine is just eating up low end computers and mobile devices, when it shouldn’t be. Our game is a roughly 40mb file, but is eating up 100 percent of a CPU and at times using 1.5gb of ram. This should not be happening. Hailin, and I are trying to figure out what is causing all the problems, but we have very little flash, and actionscript knowledge or experience. We really need some help to get it performing up to snuff.
So, after some discussion, we have decided that we want to try and get the game to the iPad. We will be using my developer account to publish the game to the IOS App store. This has me very excited as I really didn’t just want to dump the game to a flash game portal website. This would have been fine for our game, as it is a flash game, but I just felt like our game belongs in a place with more exposure and ‘prestige’ as it were.
So me and Hailin have been working closely together for the last couple days trying to get the game to work on the iPad. First couple tries that we did, all we were getting was a black screen on the iPad. We made some adjustments, but still only got a black screen. So I went digging through some of the file settings and the Adobe Air packaging that we were using was about 14 versions old. So I updated the all the Air SDK files and tried again. Success, the game was working on the iPad. Next problem, it is running extremely slow, and we have no idea why.
I downloaded the Adobe Scout profiler to see if I could find where the performance killer was coming from. We are getting like 16 fps on a flash game. In some sections we are getting like 4 to 5 fps. Our game is 38mb. Why are we getting such poor performance. Hopefully we can get it figured out, otherwise this will never get published.
So this last week we have been at GDC to show off the games and program. We also did this thing about networking with other people and trying to make contacts with people in industry. I won’t focus here on the networking part, but showing off the game we were able to get some good feedback. The people that played the game seemed to like the game but weren’t really sure what to make of the game. We got a lot of comments on how much they loved the art style of the game and a few comments that they liked the writing. Where our game seems to come up short is in it’s intuitiveness.
I think that people all have a different meaning of what different items should mean, and so there is a disconnect there. We have known about this problem from the very beginning that everyone interprets thoughts differently. One item might have two completely different meanings to different people. So how to get everyone on board with what an Item means is difficult. I tried to solve some of this through writing and showing what that item would mean to the character, not so much the player, and it did help, but maybe not enough. I wonder what other design or writing changes could help.
JenJen has put together some really good playtest sessions and we were able to get some good feedback. The players had some issues with connecting to the characters and knowing who was who. On player even made the comment, “Why do I care about a bunch of crew who are to incompetent to fly their own ship.” This led me to believe that some of the writing needed to be worked on. We added an opening cutscene in which all the characters participate. This added a sense of getting to know the crew. I then went in and changed up the dialogue to try and make it more clear that they aren’t stupid just inexperienced cadets. I am hoping that this will all add up to helping the players care about the characters and knowing who they are and why they need your help.
So my motivation for the game and the project has been really slack as of recently. I don’t ever really feel like working on the thesis game, and would rather work on some other projects. I don’t really know what to do to solve this. So my puzzle production has been really slow. Every time I sit down to write for the game, I get easily distracted and don’t want to keep writing.
I will say that the puzzles that we currently have in the game are still waiting on art assets and have lots of bugs to fix, so I don’t feel really pressured to get the puzzles done. I will also mention here that a while back I got a puzzle suggestion from one of the engineers. Since my brainstorming wasn’t going so well, I asked for suggestions. While a fair amount of the puzzle wasn’t usable I did find it very helpful for coming up with more puzzles. I was able to include some of the original puzzle that she had written. This was also good for her, since her engineering responsibilities have been lacking lately and I think that getting to contribute to the writing has helped motivate her to get more involved.
So our game has had a lot of bugs that we have been working through, and with each new iteration comes new bugs. Because we are using a simple task management to track our tasks and progress we didn’t have a good system in place to track bugs and do QA. This became more apparent as the game progresses. Parts of the game became unplayable and there were many game killing bugs.
Shane and myself were in the lab late one night when Shane had a good suggestion. We made a trello card called bugs. Within this card we created a checklist. This checklist consists of all bugs that people find. Our engineer jumped right on top of this and started fixing and checking off bugs like crazy. I am so glad that Shane came up with this idea. It has really helped to make the game a lot more stable. At EAE day we were able to have people play all the way through the game as it sits right now.
Moving forward, I think we might need to expand a little bit on the system to help keep it rolling, but it is working. This has really made me realize just how important good QA is for a game. If you don’t find the bugs, then the players will, and nobody wants to play a buggy game. It will kill your sells, and reviews.