A few minor things between client and server still exist; as it seems, even if Team 2 captures a point; it is captured for Team 1. Additionally, the player scores, names and other variables are not being cleared in new sessions; and names from the lobby are currently not being used. These kind of problems are easily fixed.
This semester is at it's end, and the team which worked on it will now be working on their own projects; hopefully, with much enthusiasm! I believe they will do very well.
The programmers were more involved in this project than the last; and we even had designers this time round; but as with any project, things went askew and the fathomable happened (as it was known to be a probability).
Josh and Mitchel both have good concepts, and seem quite eager to get their projects off to an early start; with concepts and teams already established I wish the best of luck to you guys.
A few things you might want to consider before getting stuck into it of course. Such as talking to your programmers about what limitations there will be, what can be done; and what you want to do. These guys know the engine and what it is capable of, and they can research what could be done to make what you want possible.
Even if things don't look great at first, you can always refine them. Commercial games go through the same thing. This is apparent in animation, scene construction and well, pretty much anything to do with the game.
Communicate well and manage your time; if something is out of reach it's most likely best to push it back and put a 'maybe' sticker on it. Programmers need to remember to document their code from day one; it is useful stuff! Really, just make sure before you do anything; roles are assigned.
Wednesday, December 9, 2009
Monday, December 7, 2009
Mysterious Errors
Well we thought multiplayer was still fine; it seems we thought wrong.
The client fails to connect most of the time.
The unpack for projectile.cpp is missing a few enhanced weapon data reads. Adding these in results in 'disagreeable' packet CRCs when projectiles are fired with enhanced weapons; but it appears to have solved the load error for Graham's blankRoom.mis which he tested it in.
We kind of need the game to work over the network.
Hopefully this will be a short-fix. :)
The client fails to connect most of the time.
- 65% of the time it's at 42% - the unpack of the projectile.cpp
- 10% of the time it's at 98% - unknown cause
- The rest of the time, it miraculously works and you can play and complete it
The unpack for projectile.cpp is missing a few enhanced weapon data reads. Adding these in results in 'disagreeable' packet CRCs when projectiles are fired with enhanced weapons; but it appears to have solved the load error for Graham's blankRoom.mis which he tested it in.
We kind of need the game to work over the network.
Hopefully this will be a short-fix. :)
Wednesday, December 2, 2009
Review:
The tribulations of our project were not easily overcome. With a very ambitious goal and over scheduled tasks the project fell behind in the second semester.
Concept
We needed a better one as space flight alone is too empty. Considering we stuck to the spaceflight concept it needed a lot more detail on what the space flight component of the game would contain, the concept was mainly about the style of art and what the character part would appear like. Although starting with the character component may have ended with a game you could actually play and complete. Cutting out the character completely from the spaceflight would have probably been the better choice than what we went with this time as the multimedia team was mainly working on art and areas for the character side which we intended to leave till last.
AI
AI for flying vehicles was pushed back into the second semester. This could have used with a bit more attention, but there were difficulties getting them to move at first; so anything further was out of the question.
Animations
We did not get to the point where we could utilize the character art content within Torque; animation of so many bipeds, and to the extent of the game criteria, seems utterly impossible with the amount of time at hand. Given that this is in conjunction with space flight features, the game concept entailed of almost everything; RPG, FPS, Space Sim, and Multiplayer.
Scene & Model Handling
At the beginning of the project it was estimated that problems would occur when we had to make model and scene scales larger than Torque’s usual boundaries. Rendering issues occurred when things were scaled, such as clipping and shadow inversion. AI also has difficulty flying vehicles that are too large.
As ship handling on the programming side changed over the first 2 months, animation of ships was not stressed; it would be better if the setup of ships was given a specific schema from day one; as the uniformity is a necessity within the game.
Combat & Controls
Combat needed a fair bit more attention, at least on the space-combat side of things. It lacked any design work behind it, and felt dull. Controls being the same, they were not interactive enough to provide an enjoyable level of control over the ships.
SVN
The SVN server could have been better utilized. It was set up and put on the blog as a link but never really told to anyone other than the project managers that it was there and available for use. It could have assisted greatly in the merging of code.
Although not all used it, it did serve as the backup and mediator.
Communication
Due to the new working environment, communication did not start on good ground, and altogether the multimedia and programming teams did not feel like one working entity. An envoy for each team or just simply a combined project might be more efficient. This does of course require a level of interest or motivation (alongside communication) for good output.
Management
With over scheduled tasks we did not want any one team member being encumbered with too many things to do; additionally team members had required assignments. Load balancing was introduced in cases where this was prominent; and tasks were leveled amongst the team.
Planning
Something that was overstepped; with the time constraint of the project, haste was taken over careful deliberation and the project got out of hand. Things were improvised because of this, and there was no clear lining.
A full-bodied concept including art (and model formats), dialog, features, title, and progression would be a sure way to get ahead.
Concept
We needed a better one as space flight alone is too empty. Considering we stuck to the spaceflight concept it needed a lot more detail on what the space flight component of the game would contain, the concept was mainly about the style of art and what the character part would appear like. Although starting with the character component may have ended with a game you could actually play and complete. Cutting out the character completely from the spaceflight would have probably been the better choice than what we went with this time as the multimedia team was mainly working on art and areas for the character side which we intended to leave till last.
AI
AI for flying vehicles was pushed back into the second semester. This could have used with a bit more attention, but there were difficulties getting them to move at first; so anything further was out of the question.
Animations
We did not get to the point where we could utilize the character art content within Torque; animation of so many bipeds, and to the extent of the game criteria, seems utterly impossible with the amount of time at hand. Given that this is in conjunction with space flight features, the game concept entailed of almost everything; RPG, FPS, Space Sim, and Multiplayer.
Scene & Model Handling
At the beginning of the project it was estimated that problems would occur when we had to make model and scene scales larger than Torque’s usual boundaries. Rendering issues occurred when things were scaled, such as clipping and shadow inversion. AI also has difficulty flying vehicles that are too large.
As ship handling on the programming side changed over the first 2 months, animation of ships was not stressed; it would be better if the setup of ships was given a specific schema from day one; as the uniformity is a necessity within the game.
Combat & Controls
Combat needed a fair bit more attention, at least on the space-combat side of things. It lacked any design work behind it, and felt dull. Controls being the same, they were not interactive enough to provide an enjoyable level of control over the ships.
SVN
The SVN server could have been better utilized. It was set up and put on the blog as a link but never really told to anyone other than the project managers that it was there and available for use. It could have assisted greatly in the merging of code.
Although not all used it, it did serve as the backup and mediator.
Communication
Due to the new working environment, communication did not start on good ground, and altogether the multimedia and programming teams did not feel like one working entity. An envoy for each team or just simply a combined project might be more efficient. This does of course require a level of interest or motivation (alongside communication) for good output.
Management
With over scheduled tasks we did not want any one team member being encumbered with too many things to do; additionally team members had required assignments. Load balancing was introduced in cases where this was prominent; and tasks were leveled amongst the team.
Planning
Something that was overstepped; with the time constraint of the project, haste was taken over careful deliberation and the project got out of hand. Things were improvised because of this, and there was no clear lining.
A full-bodied concept including art (and model formats), dialog, features, title, and progression would be a sure way to get ahead.
Workshop Woes
Sorry about the art presentation problems guys. It was my bad. Once again, leaving things until the last minute doesn't work.
It's also an example of one of the many mysteries of the ancient art of programming. You have something that you think works, but as soon as you show it to someone else it breaks. It's as if the code can sense the presence of another person and it gets stage fright and freezes. So again, my apologies.
A a side note - Nick, I've uploaded all of my resources and documentation to earth. It's in my folder in the documentation folder.
Tuesday, December 1, 2009
A few comments... and questions.
First of all, I think everyone did a pretty good job with their speeches, we weren’t as boring as I was expecting us to be :D
The stuff about the 3d radar was cool, would like to see that working in action.
Although as a side note, so you programmers don’t think we’re stupid or lazy, “pulling it out of our asses” wasn’t exactly a very accurate origin for the majority of our designs… :\
Anyway, the multimedia team has a few questions regarding the content of the game demo we saw, namely: Where the hell was the stuff we made?
The only thing any of us noticed that came from our classroom was the slightly modified targeting reticule.
So uhhh yeah, we’re kinda VERY interested as to why.
Anyway, again, good job to all for the speeches, lucky Tim didn’t invite anymore people ;D
The stuff about the 3d radar was cool, would like to see that working in action.
Although as a side note, so you programmers don’t think we’re stupid or lazy, “pulling it out of our asses” wasn’t exactly a very accurate origin for the majority of our designs… :\
Anyway, the multimedia team has a few questions regarding the content of the game demo we saw, namely: Where the hell was the stuff we made?
The only thing any of us noticed that came from our classroom was the slightly modified targeting reticule.
So uhhh yeah, we’re kinda VERY interested as to why.
Anyway, again, good job to all for the speeches, lucky Tim didn’t invite anymore people ;D
Friday, November 27, 2009
Shield Update!
After a nice long day of hard work i have made good progress with the shield.
Then engine changes are sorted and I have set up a few torque functions to Apply damage to the energy of the player. However, this is slightly buggy as no matter what the evnergy level is, as soon as you shoot it it goes to zero and the shield is destroyed.
Here is a screenshot of my shield :D
I will investigate the damage problem. Probably something wrong with my shield::damage function.
Then engine changes are sorted and I have set up a few torque functions to Apply damage to the energy of the player. However, this is slightly buggy as no matter what the evnergy level is, as soon as you shoot it it goes to zero and the shield is destroyed.
Here is a screenshot of my shield :D
I will investigate the damage problem. Probably something wrong with my shield::damage function.
Tuesday, November 24, 2009
Final Week: Programmers
Need to clean up some things before The 30th.
Then final build will not be anything spectacular; and my review, will not be an entirely positive one. :)
Decided to stick with the title suggested by Adam; for now we need one, and we may as well use it; regardless of it's complete irrelevancy.
- Finish References
- Update Wiki
- Finalize Review on the Project
- Practice Presentation / Add all PP Slides together
- Port all remaining modifications into one build
- Test the final build of the engine
- Sam's Shield Mod
- Health/Energy/Ammo Items in the scene
- Datablocks for Weapons, Ships, Particles etc
- AI Fixing (AI Clients/Respawning)
- Battlefield Finalization
Then final build will not be anything spectacular; and my review, will not be an entirely positive one. :)
Decided to stick with the title suggested by Adam; for now we need one, and we may as well use it; regardless of it's complete irrelevancy.
Subscribe to:
Posts (Atom)