Today was a short lecture on how to manage your time better. After this I worked more on our game to figure out how to get the Weapons to move with your animations. This in itself became a larger task then I planned, Basically I have to figure out a vector of where the blade is facing on each frame in an animation based on a "Weapon Anchor Point". After I figured this out I changed the animation editor and the XML files to load this based on the new parameters in this. I am currently still working on figuring out the angle between points to face the weapon. After this I'm going to start on getting the actual weapon coded into the game and Hopefully get it Rendering by the time tomorrow.
Thursday our first playable is due, I feel that we are almost there and just missing a few things... Mainly what I just listed above with the weapons and attacks.
-Bern
Aeona
Wednesday, February 29, 2012
NPCs and New Map
Today was a cool day...
I got my hair cut!
I had dinner at Planet Hollywood!
And, of course, I worked on our project and got cool stuff done!
Today I found a cool Tileset on the internet, modified it a little bit and used it to start working on our first map for the project. This level is going to be a village in the woods, the main character's home town, and where his adventure begins.
After creating part of the map, I got it loading in the game, tested if the collisions were working properly, and decided to work on something else for a while. And I'm happy right now cause I just got some of my user stories complete. I have NPCs in the map, and they can speak actively or passively. If the NPC is set to speak actively, he'll automatically talk to the player withing a range. Is he's passive, though, he'll wait for the player to press the action button before starting a conversation.
Pretty cool, right?
Now I want to make this system a little better - get an actual message box to appear on screen and have the NPC's speech look like it's being typed in real time.
Back to work!
I got my hair cut!
I had dinner at Planet Hollywood!
And, of course, I worked on our project and got cool stuff done!
Today I found a cool Tileset on the internet, modified it a little bit and used it to start working on our first map for the project. This level is going to be a village in the woods, the main character's home town, and where his adventure begins.
After creating part of the map, I got it loading in the game, tested if the collisions were working properly, and decided to work on something else for a while. And I'm happy right now cause I just got some of my user stories complete. I have NPCs in the map, and they can speak actively or passively. If the NPC is set to speak actively, he'll automatically talk to the player withing a range. Is he's passive, though, he'll wait for the player to press the action button before starting a conversation.
Pretty cool, right?
Now I want to make this system a little better - get an actual message box to appear on screen and have the NPC's speech look like it's being typed in real time.
Back to work!
Feb. 28
Oh no! I forgot all about the blog last night. Yesterday was my birthday, is that an excuse? =)
In class our team talked very in-depth about what is acceptable and unacceptable for a HUD and we finally came to a middle ground. The HUD is such a crucial part of any game, so I think that's why we're all so worried about it. The layout ultimately tries to have a balanced look that tells all the necessary information to the player in a non-confusing manner, while still not taking up a lot of the screen space. I suppose this is the goal for the HUD on any game.
Anyway, we came to a good layout, so I worked on this computer (my desktop, at my apartment) on the elements in PhotoShop. Definitely nothing time-consuming art-wise, because I can't afford to waste time on art, but I can't draw AT ALL on my laptop touchpad, plus, I don't have PS on my laptop, and I really, really can't use GIMP worth a damn.
I think it will be satisfactory, but if not, thankfully this is a really easy thing to change. =]
In class our team talked very in-depth about what is acceptable and unacceptable for a HUD and we finally came to a middle ground. The HUD is such a crucial part of any game, so I think that's why we're all so worried about it. The layout ultimately tries to have a balanced look that tells all the necessary information to the player in a non-confusing manner, while still not taking up a lot of the screen space. I suppose this is the goal for the HUD on any game.
Anyway, we came to a good layout, so I worked on this computer (my desktop, at my apartment) on the elements in PhotoShop. Definitely nothing time-consuming art-wise, because I can't afford to waste time on art, but I can't draw AT ALL on my laptop touchpad, plus, I don't have PS on my laptop, and I really, really can't use GIMP worth a damn.
I think it will be satisfactory, but if not, thankfully this is a really easy thing to change. =]
Tuesday, February 28, 2012
Today was another fantastic day! I know its starting to sound a bit repetitive, but things are going very nicely and code is just pouring through my finger tips! Honestly, let's hope this momentum keeps stacking well into alpha.
I was able to finish up my Camera System and it works beautifully. You can smoothly track player movement, zoom in for a final deathblow animation, and even focus the screen while powering up your next strike! It all works seamlessly and requires little code from other classes to manipulate. Mostly everything is modular and has just about 3-4 calls in a GamePlayState. I am quite proud of this milestone as I know it will enhance the game play experience immensely! Now, I just need to ask Dan for assistance on adding everything into the final build and we are in business! This should be 10 hours of user stories scratched off!
My task is to speak with Lari from DirectX class. His office hours are tomorrow from, well- I don't know! Regardless, I am excited to meet with him and talk graphics! For the record, my next user story involves rendering point and ambient light throughout the world. This will be a massive uphill battle, but the payoff will be tremendous. I have never implemented a system like light into something so complicated before, and I can't wait to see it running in the final build. I hope I can make my team and myself proud.
Anyway, I'm off to sleep. Tomorrow is another big day......
I was able to finish up my Camera System and it works beautifully. You can smoothly track player movement, zoom in for a final deathblow animation, and even focus the screen while powering up your next strike! It all works seamlessly and requires little code from other classes to manipulate. Mostly everything is modular and has just about 3-4 calls in a GamePlayState. I am quite proud of this milestone as I know it will enhance the game play experience immensely! Now, I just need to ask Dan for assistance on adding everything into the final build and we are in business! This should be 10 hours of user stories scratched off!
My task is to speak with Lari from DirectX class. His office hours are tomorrow from, well- I don't know! Regardless, I am excited to meet with him and talk graphics! For the record, my next user story involves rendering point and ambient light throughout the world. This will be a massive uphill battle, but the payoff will be tremendous. I have never implemented a system like light into something so complicated before, and I can't wait to see it running in the final build. I hope I can make my team and myself proud.
Anyway, I'm off to sleep. Tomorrow is another big day......
First day of class on SGP II
I'm really tired now and I actually had already turned off my computer and laid in my bed when I remembered I had not posted here yet, so this post won't be as long as my other ones. Probably.
Today we had our first actual day of class for Structure of Game Production 2. Our associate producer, Robert Martinez, lectured today. First, he explained how the grading system would work this month and what should we be focusing on each sprint. Then, Rob went over the importance of good planning and prioritizing, and also gave us some tips to mitigate loss.
During lab, I finally finished my collision system for the game objects and got my first user story checked off. I spent the rest of my time fixing the collision with the game world so that it would work for all the game objects too. I got that done at home and I'm ready to be checked off for that too. However, if the enemy pushes the player towards a wall, unpredictable things happen and the player usually ends up on the other side of the screen. That's something I can fix by just not allowing the enemy to push the player. However, I won't be working on that now because first playable should be done by Thursday and I need to focus on other things.
Tomorrow I won't be able to meet with my team because I have personal appointments.
I'll still wake up early and be on Skype through most of the day so I can communicate with them if needed.
Today we had our first actual day of class for Structure of Game Production 2. Our associate producer, Robert Martinez, lectured today. First, he explained how the grading system would work this month and what should we be focusing on each sprint. Then, Rob went over the importance of good planning and prioritizing, and also gave us some tips to mitigate loss.
During lab, I finally finished my collision system for the game objects and got my first user story checked off. I spent the rest of my time fixing the collision with the game world so that it would work for all the game objects too. I got that done at home and I'm ready to be checked off for that too. However, if the enemy pushes the player towards a wall, unpredictable things happen and the player usually ends up on the other side of the screen. That's something I can fix by just not allowing the enemy to push the player. However, I won't be working on that now because first playable should be done by Thursday and I need to focus on other things.
Tomorrow I won't be able to meet with my team because I have personal appointments.
I'll still wake up early and be on Skype through most of the day so I can communicate with them if needed.
Feb. 27
A little late on the posting today, I apologize.
I haven't done much related to the project today. Some things to do today and ended up more or less relaxing today. Unrelated, but soon my friend says he will have something show-able for new music (already?). If I can figure out how, I will upload it here, and it will be awesome, because his music is awesome. =D
I haven't done much related to the project today. Some things to do today and ended up more or less relaxing today. Unrelated, but soon my friend says he will have something show-able for new music (already?). If I can figure out how, I will upload it here, and it will be awesome, because his music is awesome. =D
Work done on Player and Enemy classes and more collision bugs...
Today I spent most of my time finishing the new Player and Enemy classes. I moved the basic AI code we had in Enemy to the actual AI class that needs to handle that, so that it works in a more modular way and it's easier to create new AI states and have them being used by CEnemy. I've spent most of my time on the last days working on stuff that is not really related to my user stories, and at the same time that this makes me feel like I'm not being too productive, I'm glad I could make our build much more solid, clean and modular for everybody to work on. The Player class is now set up to hold Weapons, Masks and Heart Pieces and to cycle through them. All characters hold a pointer to the AI Base State and have a Change State function that will make it easier for the AI to be used later. I could get rid completely of the old TestPlayer class we were using.
After readjusting the whole hierarchy, I finally tried to add the collision code to all of them. I added it to Base Object's Update method, so all objects in the game would be colliding with the world no matter what. I got really happy when I saw it working, but unfortunately I still have the bug related to the objects getting stuck when the animation collision rectangles change. I hope I can figure that out tomorrow with more help during our lab.
Other than that, I changed a little bit my user stories and test cases after receiving feedback from our Associate Producer Robert.
I really don't need to touch anything else on the code that is not related to my user stories right now, so even though I'm sad cause I didn't work too much on them during this weekend, I'm confident it'll be way easier for me and my teammates to work on those user stories since the project is way better organized in general.
Goals for tomorrow: Fix collision bugs, make my Tile Editor save correctly using relative file paths, start working on NPC class.
After readjusting the whole hierarchy, I finally tried to add the collision code to all of them. I added it to Base Object's Update method, so all objects in the game would be colliding with the world no matter what. I got really happy when I saw it working, but unfortunately I still have the bug related to the objects getting stuck when the animation collision rectangles change. I hope I can figure that out tomorrow with more help during our lab.
Other than that, I changed a little bit my user stories and test cases after receiving feedback from our Associate Producer Robert.
I really don't need to touch anything else on the code that is not related to my user stories right now, so even though I'm sad cause I didn't work too much on them during this weekend, I'm confident it'll be way easier for me and my teammates to work on those user stories since the project is way better organized in general.
Goals for tomorrow: Fix collision bugs, make my Tile Editor save correctly using relative file paths, start working on NPC class.
Monday, February 27, 2012
Today I spent the majority of the afternoon fixing bugs withing the tool and engine. I found many errors in the Camera System function for zoom that couldn't be fixed. I need to ask Rob for assistance because he did a project with a movable camera in the past and he would know how to fix my issue.
I also spent some time on Skype with my family and showed them the assets and tools I created for the SGP2 project. They were thrilled to see the current build of our platform and were are excited to see the final game during our expo. Overall, I am happy with my progress.
Animation Editor Bug Fixing
Today I went through and fixed Many bugs in the animation editor that I found. The main bug was actually due to me making a change to code and putting an If Check 1 level to high. This fixed the animations being able to be changed if they were already created but also caused the inability to create new animations. To fix this I moved the check down and now that is completely working again.
Today I also finished writing the test cases for my user stories. Our first playable demo is coming up fast and I hope tomorrow will be a more productive day then today. We have class starting at 9:00 am... waking up that early is not fun... can we please have 5:00pm -1:00am... Or at least 1:00pm - 9:00 pm.
Well I guess I just have to deal with that. The Game plan for tomorrow is to get the animation engine loading the new XML file with Weapon Points and Attack rectangles. Also Need to get the editor to Import and Export the new XML files.
- Bern
Today I also finished writing the test cases for my user stories. Our first playable demo is coming up fast and I hope tomorrow will be a more productive day then today. We have class starting at 9:00 am... waking up that early is not fun... can we please have 5:00pm -1:00am... Or at least 1:00pm - 9:00 pm.
Well I guess I just have to deal with that. The Game plan for tomorrow is to get the animation engine loading the new XML file with Weapon Points and Attack rectangles. Also Need to get the editor to Import and Export the new XML files.
- Bern
Collision checks
Today I continued working on cleaning up the project and remaking some of the main classes. I worked on the Base Character class and the new Player class. I also changed a little bit my friend Bern's Animation Engine so that is returns more data when animations are loaded. While before we had to kind of figure out where the animations were on his array, now the function returns the index of the first and the last animations loaded as output parameters, so you can store that and use it in a much more flexible way.
I also spent some time working on my collision-related user stories. The way we had collision working before, for every time the player pressed one of the movement keys, a copy of the player would be created with the new position, collision would be checked against that copy, and if it returned false (which means it didn't collide with anything in the world), only then we would move the actual player. That was working and it's all right, but can you imagine the waste of memory it is to create a whole new player every frame? What about when we actually created lots of enemies, NPCs and other physic game objects? Would we be creating copies of them at every frame too? Yes, and that could affect our frame rate considerably. At least I think.
So, I decided to change that approach to a better one, I'd move the player first no matter what, check if it collided with the world, and if it did I'd return him to the old position. That is not ideal, but definitely better, and it should work fine. Well, that's what I thought, but it didn't. Since the collision rectangles of the character change as the animation frame changes, eventually the player would still be able to move a little bit towards a collidable object and get stuck there forever.
I'm still trying to figure out what is the best way to handle that.
And I'll be working until late night today.
But I'll do it.
I also spent some time working on my collision-related user stories. The way we had collision working before, for every time the player pressed one of the movement keys, a copy of the player would be created with the new position, collision would be checked against that copy, and if it returned false (which means it didn't collide with anything in the world), only then we would move the actual player. That was working and it's all right, but can you imagine the waste of memory it is to create a whole new player every frame? What about when we actually created lots of enemies, NPCs and other physic game objects? Would we be creating copies of them at every frame too? Yes, and that could affect our frame rate considerably. At least I think.
So, I decided to change that approach to a better one, I'd move the player first no matter what, check if it collided with the world, and if it did I'd return him to the old position. That is not ideal, but definitely better, and it should work fine. Well, that's what I thought, but it didn't. Since the collision rectangles of the character change as the animation frame changes, eventually the player would still be able to move a little bit towards a collidable object and get stuck there forever.
I'm still trying to figure out what is the best way to handle that.
And I'll be working until late night today.
But I'll do it.
Sunday, February 26, 2012
Today was a very productive day!
I was able to finally read in my XML documents into my Engine by fixing the error I had last night. I also was able to meet with David Brown ( a previous teacher of mine ) today during Indie Game Club. He and I went through the long and fun process of converting my Camera Class into a workable engine designed around the functionality of our game. You can zoom and move the camera around the textures without having to offset the world.
There are some changes and some tweaks that need to be made, but I was referred to an old friend of David's to help with the rest. I feel very confident that the Camera Engine will work beautifully! I am very proud of our group and I hope they like what I've been tinkering with these last few days. Can't wait to implement everything tomorrow! =)
I was able to finally read in my XML documents into my Engine by fixing the error I had last night. I also was able to meet with David Brown ( a previous teacher of mine ) today during Indie Game Club. He and I went through the long and fun process of converting my Camera Class into a workable engine designed around the functionality of our game. You can zoom and move the camera around the textures without having to offset the world.
There are some changes and some tweaks that need to be made, but I was referred to an old friend of David's to help with the rest. I feel very confident that the Camera Engine will work beautifully! I am very proud of our group and I hope they like what I've been tinkering with these last few days. Can't wait to implement everything tomorrow! =)
Feb. 26
My friend (Kim) has started working on additional music for the game and I'm really excited to see it.
I'm also really excited about Sprint 2 beginning tomorrow. I actually like that we have 9 AM classes now. This means, in my eyes, we will have more time in a day to just dig in and work for longer times, since we could stay past 5 PM if we wanted to. I think this sprint will be a very productive one, and as always, I'm really looking forward to our game - actually, both teams' games. Hopefully it will be an awesome month.
I'm also really excited about Sprint 2 beginning tomorrow. I actually like that we have 9 AM classes now. This means, in my eyes, we will have more time in a day to just dig in and work for longer times, since we could stay past 5 PM if we wanted to. I think this sprint will be a very productive one, and as always, I'm really looking forward to our game - actually, both teams' games. Hopefully it will be an awesome month.
Animation Editor
Today I went through my animation editor and fixed the few bugs I had and started to work on my Current user stories for this sprint such as:
As a Developer, I want a weapon anchor point defined in the editor
As a Developer, I want a weapon collision box.
In this I'm giving us the ability to have hold a weapon and edit its collision box. Tomorrow I will be editing the actual game to load these positions in and and give whoever needs access to the weapon collision boxes access to it.
I am also going to get the few keys we were missing functions in our input manager.
-Bern
~90 more hours of user stories to go!
As a Developer, I want a weapon anchor point defined in the editor
As a Developer, I want a weapon collision box.
In this I'm giving us the ability to have hold a weapon and edit its collision box. Tomorrow I will be editing the actual game to load these positions in and and give whoever needs access to the weapon collision boxes access to it.
I am also going to get the few keys we were missing functions in our input manager.
-Bern
~90 more hours of user stories to go!
Saturday, February 25, 2012
Feb. 25
Nothing to note on the project today, guys. Went grocery shopping and cleaned my apartment. :)
I've been talking to the composer of the current music we have for our game, and he says he is further modifying his theme in an attempt to make it better. He also volunteered to make additional music for different areas. I told him for him to do all the music alone is impossible, but he wanted a list of all 'possible' music themes we could use, so I gave it to him:
- Main theme (menu)
- Town
- Forest
- Winter mountain
- Desert
- Volcano interior
- Boss fight
- Ending/Credits/Main theme variation
I'm happy that he's already completed a theme, and I don't expect him to pump out a handful of themes in such a short time, but he is a really talented guy and I'm glad (and so is he) that we can incorporate his music in our project.
I've been talking to the composer of the current music we have for our game, and he says he is further modifying his theme in an attempt to make it better. He also volunteered to make additional music for different areas. I told him for him to do all the music alone is impossible, but he wanted a list of all 'possible' music themes we could use, so I gave it to him:
- Main theme (menu)
- Town
- Forest
- Winter mountain
- Desert
- Volcano interior
- Boss fight
- Ending/Credits/Main theme variation
I'm happy that he's already completed a theme, and I don't expect him to pump out a handful of themes in such a short time, but he is a really talented guy and I'm glad (and so is he) that we can incorporate his music in our project.
Clean Up Day
Today I woke up late and didn't have as much time to work on the project as I wanted to. Before really starting to work on something, I wanted to remove a lot of worthless and duplicate project files and backups that were saved on my computer all over the place (my Desktop literally had around 15 folders of different versions of our project). Then, I renamed our Visual Studio solution to the new game name (Aeona) and re-organized all our files (tools, project, notes, resources, etc.) on a folder that I uploaded to our server in Google Code, so that everybody on the group could get a cleaned up project to start working on Sprint 2.
Besides that, our code became really messy by the end of Sprint 1 - It's full of hacks and test cases all over the place. So I decided to organize all that stuff too, making things not only work, but "work in the right way". So far, I split our Base Interface by creating a Base Object class that inherits from it and actually holds all the functionality and data members, while the initial Interface is now only holding pure virtual functions like AddRef, Release and CheckCollision. I added a lot of functionality, written from scratch, to the Base Object class. I want all game objects to inherit from it and be able to use all those functions.
For our Sprint 1 turn-in we were using a Test Player class that wasn't really made as it's supposed to. Tomorrow I'll be remaking that class, using all the functionality I already created in Base Object, and preparing it to be able to store the Weapons and Items that we will be making on this sprint. I'll probably review the Enemy classes too. With this clean up, it will be way easier for me to start actually working on my user stories. Two of them are about collision working properly for all game objects and the world. Hopefully I'll be able to get those done, since most of the work I've been doing on the Base Object class will help me get the collision I've already had on Player working for everything.
With all those done by tomorrow night, I'll be ready to start working on my main challenges for this sprint: NPCs and Puzzles.
I can't wait.
Can you?
Besides that, our code became really messy by the end of Sprint 1 - It's full of hacks and test cases all over the place. So I decided to organize all that stuff too, making things not only work, but "work in the right way". So far, I split our Base Interface by creating a Base Object class that inherits from it and actually holds all the functionality and data members, while the initial Interface is now only holding pure virtual functions like AddRef, Release and CheckCollision. I added a lot of functionality, written from scratch, to the Base Object class. I want all game objects to inherit from it and be able to use all those functions.
For our Sprint 1 turn-in we were using a Test Player class that wasn't really made as it's supposed to. Tomorrow I'll be remaking that class, using all the functionality I already created in Base Object, and preparing it to be able to store the Weapons and Items that we will be making on this sprint. I'll probably review the Enemy classes too. With this clean up, it will be way easier for me to start actually working on my user stories. Two of them are about collision working properly for all game objects and the world. Hopefully I'll be able to get those done, since most of the work I've been doing on the Base Object class will help me get the collision I've already had on Player working for everything.
With all those done by tomorrow night, I'll be ready to start working on my main challenges for this sprint: NPCs and Puzzles.
I can't wait.
Can you?
Spent the whole day trying to debug an issue with my engine not reading in my new XML file. There seemed to be a Linker Error that has nothing to do with my code, but the fact that I sent my files over SKYPE. When the code started recompiling, it was accessing some other files offline. A simple reboot may resolve the issue.
I finished relative filepaths for my Tool and I fixed several bugs. Tomorrow I need to update my UserStories. I am so sleepy......
My rump also hurts! I have been sitting down a lot and am concerned there may be health risks. I've read an article on several news sites regarding an increase of heart attack and blood clots when folks sit too long. I must try and stand around more and remain active.
I finished relative filepaths for my Tool and I fixed several bugs. Tomorrow I need to update my UserStories. I am so sleepy......
My rump also hurts! I have been sitting down a lot and am concerned there may be health risks. I've read an article on several news sites regarding an increase of heart attack and blood clots when folks sit too long. I must try and stand around more and remain active.
User Story Bidding
For each sprint we have to bid on User Stories, Basically saying how much time we think we can complete something in. We use cards and each person puts up the card that they think is the most accurate time they can complete the task in.
The cards values are as followed:
A---2
2---4
3---8
5---12
8---16
J---40
Q---80
K---OMGWTFBBQ
If someone bids over 16 hours the User Story should be divided into smaller user stories and then bid on again. If you bid a king it basically means that you don't understand something and the group should reevaluate or reword the user story. Once all of these bids are completed we go thru and divide the user stories and and continue the progression.
-Bern
The cards values are as followed:
A---2
2---4
3---8
5---12
8---16
J---40
Q---80
K---OMGWTFBBQ
If someone bids over 16 hours the User Story should be divided into smaller user stories and then bid on again. If you bid a king it basically means that you don't understand something and the group should reevaluate or reword the user story. Once all of these bids are completed we go thru and divide the user stories and and continue the progression.
-Bern
Friday, February 24, 2012
FIRST DAY GRAPHICS
I have just spent an entire afternoon converting my Particle Tool XML to the current build of my Engine and got most it working. I haven't committed anything yet because I am afraid of SVN and its nonsensical approach to keeping things simple and easy to understand.
I have spent a lot of time staring at my code because I haven't been as focused as I know I should. I have actually begun to fear my user stories and how I am going to accomplish the look and feel that the Team is going for. I need to create weather effects, day and night cycles, point and ambient light systems, and a 3D camera system that changes dynamically with the battle system.
I have done a few of these systems before, but never at this scale. The reason why I am worried is because I don't know how I can incorporate the codebase that I have into the build that my Team is working on without breaking or reworking everything that has been accomplished over the last few weeks. I have no choice but to ask Lari for assistance on how I can shoehorn the code and get everything done.
As I stare at my computer I am now distracted. I have my brother-in-law and his friends over and they are playing games.....
The sweet sound of "hadouken" and Guile Stage Music beckons. Farewell.
I have just spent an entire afternoon converting my Particle Tool XML to the current build of my Engine and got most it working. I haven't committed anything yet because I am afraid of SVN and its nonsensical approach to keeping things simple and easy to understand.
I have spent a lot of time staring at my code because I haven't been as focused as I know I should. I have actually begun to fear my user stories and how I am going to accomplish the look and feel that the Team is going for. I need to create weather effects, day and night cycles, point and ambient light systems, and a 3D camera system that changes dynamically with the battle system.
I have done a few of these systems before, but never at this scale. The reason why I am worried is because I don't know how I can incorporate the codebase that I have into the build that my Team is working on without breaking or reworking everything that has been accomplished over the last few weeks. I have no choice but to ask Lari for assistance on how I can shoehorn the code and get everything done.
As I stare at my computer I am now distracted. I have my brother-in-law and his friends over and they are playing games.....
The sweet sound of "hadouken" and Guile Stage Music beckons. Farewell.
Feb. 24
I was never a fan of blogs. Expressing my opinions to an audience makes me feel, well, opinionated, so I never really got into them. I prefer discussing things face-to-face, so I have the opportunity to be proved wrong or at least questioned right while I'm saying something. =)
That said, I am a big fan of our game, Aeona, and our group, cleverly named TEAM 4. (because there's four of us, and we're in a team together, get it?)
Today I will be fixing some cosmetic stuff with the text, and making the menu system more modular.
I think we will have a great time next month, and I think our game is going to be awesome.
That said, I am a big fan of our game, Aeona, and our group, cleverly named TEAM 4. (because there's four of us, and we're in a team together, get it?)
Today I will be fixing some cosmetic stuff with the text, and making the menu system more modular.
I think we will have a great time next month, and I think our game is going to be awesome.
Wheel of Misfortune
The Wheel of Misfortune, the name alone makes it seem like something you would never want. This wheel is something you spin at the beginning of every sprint in SGP(Structure of Game Production).
For our spin in sprint 1 we rolled "Super size a feature", This is when you have to make a feature currently planned for your game and increase its overall size in the game. For this we chose to increase the size of our Day/ Night feature which originally just was cosmetic to now change the types of enemies spawned based on Day/ Night time.
For our spin in sprint 2 we rolled "Pain Repeater" which doubles what you have to do on the next roll.
After that we rolled "Team Swap" Which swaps 1 team member from your team with one from the other team. We did not have to do this because the other team rolled before us and that would have made them do two rolls. Our Third roll we rolled "Pain Repeater" again ... I don't think we could have been any more unlucky. Lastly we rolled "Dev Blog" which makes us post a Blog Post every day of the sprint. Because we had "Pain Repeater" we had to do this for every member of the group every day.
Our Next Objective is First Playable...
- Bern
For our spin in sprint 1 we rolled "Super size a feature", This is when you have to make a feature currently planned for your game and increase its overall size in the game. For this we chose to increase the size of our Day/ Night feature which originally just was cosmetic to now change the types of enemies spawned based on Day/ Night time.
For our spin in sprint 2 we rolled "Pain Repeater" which doubles what you have to do on the next roll.
After that we rolled "Team Swap" Which swaps 1 team member from your team with one from the other team. We did not have to do this because the other team rolled before us and that would have made them do two rolls. Our Third roll we rolled "Pain Repeater" again ... I don't think we could have been any more unlucky. Lastly we rolled "Dev Blog" which makes us post a Blog Post every day of the sprint. Because we had "Pain Repeater" we had to do this for every member of the group every day.
Our Next Objective is First Playable...
- Bern
Aeona - First day of Sprint 2
Yesterday, after a week of hard work for our team, we finally submitted everything we needed for our Sprint 1 turn-in to our main producer John O'Leske.
We were all by his side when he went over the grading process. Apparently he really liked our demo build and the only bug he could find on it was that we weren't cleaning up the particles' data when exiting the game. So, if the user opened his save file on a second play section, more particles would be added to the effects that were already there. After playing the demo with the same save file around 10 times, the rain effect had became a really heavy storm and our torch was emitting way more than just a couple fire sparks.
After that, he went to take a look at our tools. I worked on the Tile/Map Editor during this sprint, and this was the first one he checked. We initially had a problem with saving and loading because avast was opening the software in the sandbox. The editor was really good but I wasn't using relative (safer) file paths when saving the tileset image file name to the XML document, which can cause issues when loading the map into the game in different computers. He also recommended me to add a paint bucket option to the editor. Those are all on my Sprint 2 backlog now.
The most funny bug was on my teammate Ari's Particle Editor. A specific blend mode from DirectX was causing a really weird issue on the computer John was using. Not only would the tool stop responding when that blend mode was selected, the computer screen would turn entirely gray for a couple seconds. Ari didn't loose so many points for that though. He spent the rest of the lab time trying to fix that issue, but I'm still not sure if he actually could find the problem.
The Animation Editor from Mr. Schotanes was also working fine and in the end everybody got an A/A+ in the class. Now our team is planning and getting prepared for Sprint 2, in which we'll have two weeks to complete all the main game features. We also should have our first playable version done in one week. Yeah, it's going to be rough.
But we're prepared.
What about you?
Are you prepared for
AEONA?
We were all by his side when he went over the grading process. Apparently he really liked our demo build and the only bug he could find on it was that we weren't cleaning up the particles' data when exiting the game. So, if the user opened his save file on a second play section, more particles would be added to the effects that were already there. After playing the demo with the same save file around 10 times, the rain effect had became a really heavy storm and our torch was emitting way more than just a couple fire sparks.
After that, he went to take a look at our tools. I worked on the Tile/Map Editor during this sprint, and this was the first one he checked. We initially had a problem with saving and loading because avast was opening the software in the sandbox. The editor was really good but I wasn't using relative (safer) file paths when saving the tileset image file name to the XML document, which can cause issues when loading the map into the game in different computers. He also recommended me to add a paint bucket option to the editor. Those are all on my Sprint 2 backlog now.
The most funny bug was on my teammate Ari's Particle Editor. A specific blend mode from DirectX was causing a really weird issue on the computer John was using. Not only would the tool stop responding when that blend mode was selected, the computer screen would turn entirely gray for a couple seconds. Ari didn't loose so many points for that though. He spent the rest of the lab time trying to fix that issue, but I'm still not sure if he actually could find the problem.
The Animation Editor from Mr. Schotanes was also working fine and in the end everybody got an A/A+ in the class. Now our team is planning and getting prepared for Sprint 2, in which we'll have two weeks to complete all the main game features. We also should have our first playable version done in one week. Yeah, it's going to be rough.
But we're prepared.
What about you?
Are you prepared for
AEONA?
Subscribe to:
Posts (Atom)