Advisor Advising and Week 2
Originally I was planning on having us start a rather major change in the graphics engine, the possibility of which I alluded to in a previous blog post. Our goals for the Term were re-aligned this Monday. We have a much shorter list of goals to complete now. So short in fact that we'll be in Beta after this week.
Team goal for this week: Implement Level 2 and all functionality required to fulfill this goal.
Level 2 must be working and debugged. No crashes and playable to completion. Lacking only animations.
Steve:
Dialog Overhaul:
Fix Dialog - It's really ghetto now, could use some optimization.
Pages - add functionality for multiple screens of dialog to appear sequentially.
Spontaneous - add functionality for dialog to spontaneously appear at any time.
Kevin:
Level 2 Script - we needs it done
Hamster Maze
Joe:
Paper Outline & Organization - In which he tells us what we need more precisely. Ideally we should all have everything we need to start writing this paper after this week.
Finalize L2 Assets - We make sure we have everything we need and if not, make it.
Level 2 Dialog
Add sound effects
DC:
Level 2 Script coordinates
Finalize L2 Assets - We make sure we have everything we need and if not, make it.
Last few Tiles
Hamster
Add sound effects
Graham:
Fix music code
Redo classical and metal
Figure out exactly what is required for 32px tiles conversion (more on this in next week's blog)
Mary:
Level 2 Animations
Problems with NSStrings
For the past few weeks, Kevin and I have been attempting to change our script system from timer-based to event-driven. A couple days ago we had it working fine, except for one (seemingly) small bug that we had no idea how to fix: NSStrings were getting released without us explicitly doing so. We spent an hour or two tracking down the bug, and were completely surprised when we found out what was happening. I have no idea how something like this could possibly happen. We tried a few solutions such as calling retain on it a few times, or duplicating the source C string, but nothing helped. Eventually we gave up and decided to change the parameter from an NSString to an int, because technically, for that specific piece of data, it didn't matter what it was, it was only an identifier for LUA to use.
However, we're going to need to fix this bug eventually. The same thing happened when we changed the dialog system so that every NPC Mote had it's own dialog text; the NSStrings seemed to just disappear out of nowhere. I think it might have to do with all our memory leaks; Objective C might not have enough memory and is releasing objects that it determines to be low priority. That's just a guess though, I don't really know how Objective C memory management works. Also it seems odd that it is only happening now, and that a single string was enough to push it over the edge.
I should have done this in the first place, but I'm going to try changing it to some other object, to see if those get released too. If it only happens with NSStrings then I'm going to be completely confused.
Sup D-Term, Sup Scrum
Should be a fun last term. Relatively easy, anyway. What we have is an alpha which is maybe a couple weeks close to a beta. This term we'll be trying something different. At GDC last week I attended a number of lectures, many of which were about Scrum and Agile game development. The ideas behind them make alot of sense to me. Also seeing as how many people are adopting these methods in the industry, I figured it might be worth trying with this project.
For our first meeting this term, we put all the things we'd like to finish and see in our game by the end on sticky notes. We then arranged these notes on a wall according to priority and prerequisites. Goals were then assigned to people as well as a few rounds of Planning Poker to figure out what could be done in a week. Given our weekly advisor meetings, week-long sprints seemed appropriate. We have a fairly clear idea of what we'll have by the end of this term, but given the ambiguity of term-long goals, we'll be taking this one week at a time for the most part.
Here's what the first meeting yielded:
Week 1
DC: Music Menu Recoloring(<1), 32px Tiles(5 days)
Graham: Music (Shanty, Rap, Ambient)(5 days)
Joe: Main Menu Redesign(2.5 days), Research Paper Requirements(continuous)
Kevin: OpenAL additions(2 days), Events System(5 days)
Mary: Level 1 Animations (Sleeper, Hammer, River) and C-Note(5 days)
Steve: Events System(5 days)
Music Menu Recoloring (DC):
I messed up the riffs on the menu. Gotta make it right.
32px Tiles (DC):
The first step of converting level1 and 2 tiles from 64px to 32px. The result will have all level tile assets being 32px wide and tall. This also includes some preliminary planning using the Level Editor for when Graham converts the graphics engine to use 32px tiles, which is later this term.
Music (Graham):
Pirate Shanty and Rap riffs are not yet made and will be needed for Level2. Ambient music is made, but has not yet been implemented.
OpenAL Additions (Kevin):
To implement the ambient music, some minor functionality needs to be added to the sound engine.
Main Menu Redesign (Joe):
The current menu doesn't fit the style of our game. Joe is going to remake the menu using level tiles and mote animations that have previously been made, as well as create new buttons to match this scene.
Research Paper Requirements(Joe):
Joe will gather past MQP papers and determine what we'll need for ours in a general sense.
Events System (Kevin, Steve):
Currently the way things happen in the script is ghetto. Kevin and Steve will make it all slick and easy. This involves converting the script from a timer system to an events system. This will make level scripts much more manageable and possibly more resource-efficient.
Level 1 Animations and C-Note (Mary):
There's an animation for the sleeping dude that was previously unplanned for. The hammer dude's animations are also left. C-Note will now have a character portrait to accompany his dialog. The character portrait itself will not be implemented into the dialog system until later this term.
Animations, In Summation
Over the course of the term I've made 30 animations in my task to bring the characters of Mote to life. The end of the term, specifically, was about making probably half the animations for level 1, and fixing any animations that had problems (ex, the baby's rattle being cut off in 2 animations, whispy backgrounds that went beyond the frame, repositioning the guard). I was going to only post the animations I haven't yet posted, but since what has been posted isn't in gif form, I'm just going to show everything.
--Order--
Main character, Metalhead, Babby, Sleeping Dude, Guard, Emo.
Note: The Sleeping Dude long animation is two animations combined.
C Term!
So, C-Term is over, and I feel that we got a lot done this term. On my end, I made our scripts, changed our audio engine to use OpenAL, integrated timers, and made an event system. Both the scripts and the events have already gone through multiple iterations, but I feel that where we are now is a good place for beginning work D Term. I'm confident that we'll be able to finish the second level within a week or two, and the event system should be fully integrated by then, as well. We also are going to be writing our MQP paper next term, but I'm guessing that that won't be as much of a headache as some of the scripting bugs we've encountered were.
-Kevin
Minor Tweaks
Over the last few days I've been making a few small changes to our game to make it nicer to play. Among them are the following:
Instead of colliding with an NPC to interact with them, you simply tap them. Before, when collisions triggered the interaction screen, it was very frustrating to try to walk past a Mote, because as soon as you touched them, the game play stopped. It became nearly impossible to walk between two motes without colliding with one of them and pausing the game. Now, you explicitly tell it when you want to interact with someone, so it can't happen by accident, and moving past a Mote isn't a chore.
Holding down your finger on the screen will continue to move the player Mote until you release it. Previously, when you touched a point in the world, the mote would move to that point. However, that point did not change as the mote moved, so in order to keep walking, you had to move your finger around a bit to update the target position continue walking. Now the target position gets updated automatically as long as your finger is on the screen. Again, it wasn't anything that broke the game, but it made for poor user experience.
Collisions between Motes are now "soft." What that means is when a player collides with an NPC, he will not stop as if the NPC was a solid block, they will overlap slightly, and the player Mote will be slowly pushed away. It looks a little nicer than if the player Mote slid around the NPC as if it was a rock with infinite weight.
Assign, Retain, and Copy
For about 2 weeks, we had an outstanding bug that crashed the game when you tried to change a Mote's sprite from a LUA script. At first I thought it was caused by the LUA hooks that I mentioned in a previous blog post, but after I sat down to fix it, I discovered that we were using (copy) for the Mote Sprite property, instead of (assign).
In Objective C, when synthesizing a property that is a sub type of id, you need to specify the way the object will transfer the data when performing a set operation. The three main ways are (assign), (copy), and (retain). (assign) is the most basic method; it simply sets the property pointer to the exact value that is passed to the function. (retain) is similar, except it will increment the retain count on the id, so that your object is an owner of the id. The third way is (copy), which performs a deep copy of the id, and sets the object's property to that copy. This requires the id to have a method called copyWithZone, so that it can properly clone it.
As I said, our code was using (copy), but our Sprite class does not define the method copyWithZone, so it could not perform a deep copy of its data. Once I changed it to (assign), it worked perfectly.
This isn't the first time that Objective C properties have confused me, but it was the first time it caused a major bug. I made sure to go through our code and make sure we were using (assign) where necessary, so that it doesn't bother us anymore.
OpenAL Integration
I've been working mostly on integrating OpenAL into our project this week. Basically, this would allow us to have several sounds play at once, and do so more efficiently than it does now. This would avoid the bug that we currently have where we can only have one note playing at once, even if the player presses many in succession.
I found out that OpenAL is not compatible with .mp3s, which has been the sound file format that we've been using so far. I converted our sounds to .caf files, which work quite nicely with OpenAL. I'm currently trying to finish integrating the last few sounds left with OpenAL, and adapting the code to be able to handle compressed .caf files.
-Kevin
squashing bugs
...left and right. There's a loading screen now, but it's lacking artwork atm. I'll post a screen when it's made pretty. Particles are also inches from completion.
Also working on putting together a test plan and composing the music. Got my work cut out for me.