First of all, I'm really glad at the fact that the clients actually liked our game, as a game(don't know if this makes any sense =_=!), this really means a lot to our 4 week's work. But there is still a llot of things that could be done but hadn't because of the limit of the time and also because of the fact that this is just a prototype.
For post-mortem, the team, as always, has some issues. Take communication for instance, although we exchanged a lot of messages and emails, I still got lost track with the other engineer. And we both agree that we should have talked more about the game structure during the second and third week. And our game idea settles fast, maybe too fast (2-3 hours on the first day, we already all agreed on making a 3D Pacman-like castle game), but I'm pretty happy with the outcome though, maybe it's because the idea itself is awesome! ha!
As for myself, there is a lot to improve and talk about, I'll just do a post-mortem and summarize mixed-up here:
Shaders are amazing, it's fantastic to see how a few lines of code could actually change a lot of how the game would look. I actually had big plans on learning and writing the shader of this game during the fall break, but the lame work of laying out all the gems and fixing the models took me more time than I thought and I only had the time to do the point lights using prelighting, which is already a highlight of this game. And this is something definitely worth dig in during Thanksgiving or winter break.
But the main thing I'm gonna talk about here is optimizing. This game is actually the first program that I wrote that actually get a performance hit, which hurts me so bad it actually changes the way I think when I'm programming. Yes, we're all kind of raised by education that we must keep a good programming practice and write efficient code. But it's a total different thing to "know" it than actually facing it. When you go through all your code, adding and cutting logic statement to avoid unnecessary loading, simplifying math calculations and changing structures for memory and time saving just for raising ten frame rates. You kind of become vigilant about this kind of stuff. So now when I start writing anything, I always get these questions stuck in my head: What structure should I use? Is this the best way? What's the prior concern? Is it fit for the possible future use? I'm glad I'm thinking about these stuffs now, although it kind of slows you down at first, but it really makes things easier for you when the project grows big, at least that's what happened in my current prototype. All thanks to this.
I actually thought a lot about how to optimize this game, and I wrote something about it two weeks ago, I'll just copy and paste it here you want to check it out:
"Recently I have thought a lot of stuffs about optimizing my game. Should I update my frustum culling to triangle accuracy, so that I could use a vertex buffer to draw primitives instead of using draw models, which could be more fast since shaders deal with vertexes directly and it also provide me a way to send vexters to GPU by batches. Also, is it wise to use the same octree for both collision check and graphic culling? Because for many times many things you see shouldn't even be considered for collision check, and load them into the octree are simply a waste of memory. And also, some shapes are too delicate for collision check, like for pillars and railings, sometimes what you need is really just a cuboid or cylinder. I know that sometimes a bounding box or bounding sphere can do the job, but in order to get a smooth collision reacting, you still need to use all the coordinates of those stuff to recreate the triangles to get the normals and plane, which is actually easier to achieve if you just replace all those models in the scene with simple shapes that you think the collision accuracy would be. But to achieve that, the overhead is you need actually two versions of scene models to load and two tree structures to store. But considering the cost of not doing all these, it's actually worth it. And again, for math, right now for all the ghost, I actually determine all the x,z speed by sin and cos of the rotation from the x axis. But for the patrol ghosts, is it really wise to calculate sin and cos for every frame they move? For the visual rotation, I can just add a bool at their rotation point, so the model will only rotate every time they reach the rotation point. Which will reduce a lot of math!
As for framework, am I using the most efficient data structure? Should I use interface or class for base model? And maybe it's better to use a quad tree for collision check since height value is really not a concern of collision.
All those questions and stuffs are stick in my head, but right now I really need to consentrate on the HTML5 since that's what my next game will be."
Well, I'm very glad to be able to work on this prototype, it really gives me a chance to have a glimpse and have a "dry-run" on most sides of 3D game programming. It's ironic that the more I learn, the more I find out that I don't know anything. There are still a lot of things for me to dig in, and time is indeed a luxury here.
BTW, writing blog like this is really suffering, hard to read and time consuming, I'm gonna try a different approach from now on.
-Max
No comments:
Post a Comment