|
Jon |
|
Game concept fell short of what was wanted but it still looks very nice. Originally we planned to have knights protect a wagon traveling across the forest infested with thieves. However, integration took longer than expected and we had to settle with a good knights vs. thieves skirmish without a wagon. Thus, our scenario became whoever kills the most wins the game. Most of the concepts did not change over the course of 10 weeks. We maintained cross-platform capabilities, generated realistic trees, generated random levels, and had both melee and ranged weapons.I was in charge of making the menu and a level generator. These were completed without much change from the original game concept. We decided to use a menu built from scratch rather then using some free ones made online. The ones online either crashed often, took too much resources, or were not cross-platform compatible. The menu I made included textured buttons, multiline textfields, single line textboxes, labels, meters, and translucent buttons. The level generator was originally just a level generator. This system would randomly place objects throughout the map but allows the user to easily add walls and other patterns to the level. I found that it could also contain information on paths for the AI to navigate through. Therefore, path generation was included with level generation. Once path generation was completed, I focused my efforts on creating an NPC originally called trogdor after the bad-ass dragon from homestarrunner.com. It would have been a teapot that shot flames as it navigated through the forest. However, time was short so trogdor became a naked man that shoots arrows out of his crotch while following a random path throughout the level dodging trees and rocks. The closest players to trogdor becomes trogdor's target. Based on the trigonometry of the arrow system, trogdor adjusts angle and speed to attack players. The further a player is, the harder trogdor shoots. To be fair to other players, his cooldown rate is increased based on how hard he shoots. Also, trogdor evaluates which direction his target is going and compensates for that by aiming where the target would be when the arrow lands. A melee attack mode could have been easily added but trogdor's arrow attacks were deadly enough.
|
|
Ben |
|
I think that originally we were focussed more on scenario-based play and this kind of went out the window as the quarter went on. We determined that a playable Slayer scenario was more important than a perhaps unplayable Capture the Flag or other scenarios in a less playable and most likely less fun environment. Originally, I thought killing would be secondary to our game, but it ended up being the primary focus, and it turned out better than I expected.
|
|
Fred |
|
Our initial concept involved completely procedurally generated everythings. Procedurally generated maps, rocks, trees, bushes, players, scenarios, weapons, etc. We wanted the each game experience to be totally unique. As time evolved, few things survived in their originally procedurally generated concept: mostly the trees which were randomly placed. Because we didn't have time for multiple scenarios, (only a slayer mode) it could not be procedurally generated either. Had this been a 15 week project, rather than 10, I have little doubt that more things would have become procedurally generated (with random variance) which would have led to much more dynamic game play.
|
|
Mike |
|
Fred pretty well summed up what I was hoping to create. We were a bit far-reaching with our initial ideas, but what trickled down helped to make our game very unique.
|
|
Scott |
|
I was concerned early on in the design phase that we might be biting off more than we could chew when discussing possible things to add to the game. However, from that far-fetched list we were able to come back to reality when we actually started work on it and it gave us a good understanding of the kind of game we were striving for. All things considered, I think we were true to the original plans we had for the game, minus a few specifics.
|
|
Ryan |
|
The only real change in concept was that we had to go with "Slayer" gameplay instead of randomly generated scenarios because of time constraints. But this was a change that really happened in the first week or two (check the feature list -- randomly generated scenarios wasn't even a wishlist item), so I don't know if it even counts.
|
|
Fred |
|
Although our game concept seemed to have changed significantly (because game scenarios were not procedurally generated) the project's design in terms of different modules, and how they interacted remained relatively close to what we had originally planned.
|
|
Ryan |
|
We didn't really have much design to begin with -- we split it up into separate tasks like networking, graphics, and audio, and all of those were in the final game. I never did get around to character state machines (although in the last week I found out where they might have been useful). We also ended up adding more things like resource management, particles, collision detection, scene management, etc.
|
|
Jon |
|
We stayed mostly ahead of our projected schedule during the first half of the quarter. When integration started mid-quarter, we were behind by about a week. But we were still able to implement many of the "nice-to-haves" such as a blood particle system and NPCs.
|
|
Ben |
|
Networking and integration took longer than expected. We had to do a few rewrites on the networking code as part of the learning curve for TNL, but in the end it worked itself out. We ere very close to finishing off a few interesting nice to haves, and the continued development of this project would likely lead to a very nice game.
|
|
Fred |
|
With my personal schedule I was ahead of where I was planning up until about week 5. After that I spent several weeks helping with integration of various components onto the server, and working on scene management (which was not in my original schedule). During the last few weeks of the project I tried to look for things that would improve the game's performance and general playability (tree imposters, blood, special arrows, minimap) which may not have been in my original schedule but seemed more important than what I was original planning for the last few weeks (climbing trees etc.) Overall, however, I think around week 4 or 5 we fell a bit behind on the integration which took until week 8 to really complete. This step took longer than anyone was anticipating and was a bit challenging with the difficult (although very solid) TNL libraries.
|
|
Mike |
|
My personal schedule had me working at a fairly steady pace throughout the ten weeks. Even so, I still felt that there was a bit of a rush towards the end. That said, I still managed to produce a large amount of content that was unable to be integrated due to time constraints.
|
|
Scott |
|
To be honest, I didn't really look at the schedule after about week 2. That was when the network stuff started to become an issue. Since network was pretty much indispensable, everything else got brushed off my plate until that was working. And by the time it was, I found myself in an entirely different position than the beginning of the quarter. I still managed to work on most of the topics which I planned to in the beginning, but I also spent time working on things which I couldn't forsee, such as the menus, powerups, death code, scenarios, etc. I basically worked on whatever things I could find that needed to be accomplished, but hadn't yet.
|
|
Ryan |
|
We really fell behind when we started working on integration. I really think this is because we didn't do any design. At one of the first meetings we split up audio, networking, arrows, menus, etc. But there was no discussion of how these would work together, so almost all of it had to be rewritten (sometimes repeatedly) once we tried to integrate things. That blue and white square week probably could have been avoided if we'd planned ahead more.
|
|
Jon |
|
Doxygen was supposed to help us comment our code and make it readable for other members. However most of us did not use it. We were able to understand each others code just by reading it. CVS proved essential since the code was being modified multiple times everyday. Sometimes CVS had bugs in it which corrupted our code for no reason which caused many headaches and panic attacks.
|
|
Ben |
|
I found the most productive time to be the last 36 hours before the game was due when everyone was in the lab at once and working together. This allowed us to query each other about parts of the code we were unfamiliar with without waiting hours or days for a response through e-mail. We were also able to make quick decisions on what features to work on, what to add, and what to drop. I think that if we were able to all meet in the lab more often earlier in the quarter we would have accomplished much more in our game. The modular design of our code was also essential to our later work. We spent a lot of time getting the basic code to be clean in order to make it easily expandable in the future and it worked beautifully in the later part of the quarter.
|
|
Fred |
|
The most important software methodology was keeping code modular and separate. The more things we managed to separate off into its own module the less collisions there would be between our code and the more we could work separately. On the other hand, as Ben mentioned, our most productive time was spent together. Even if we weren't all working on the same thing, having everyone in the same room led to the quickest and best results.
|
|
Mike |
|
I, as most of us did, found the most productive time was spent in conjunction with other group members. Exporting of models and animations from 3DS Max to our engine was very difficult at first, but Dave did an amazing job, which really allowed me to create content that I wasn't sure was going to be possible otherwise.
|
|
Scott |
|
Being in the lab together always made us more productive. It was hard at times, though, since finding everyone a computer was a challenge toward the end of the quarter. As such, sometimes if group members were only going to be gone for an hour, they wouldn't log off, and we would have to “save” the computer for them when they got back. I'm not proud that we did this, but given the limited resources in the lab and the necessity of us to be able to use the computers, it needed to be done. We're not the only group that was guilty of this, however.
|
|
Ryan |
|
Being cross-platform had a few problems, but overall it worked really well. Everyone could use their own computers. Plus, OpenGL Profiler was really helpful. As I said before, not planning how modules would be used and how they would interact was a major problem.
|
|
Jon |
|
Network seemed difficult...Perhaps Scott can explain better.
|
|
Ben |
|
Networking was more difficult than expected. The learning curve for TNL was higher than expected and required a dedicated effort on the part of a few members (especially Scott) to implement successfully.
|
|
Fred |
|
Integrating our original client side modules into the sever was more difficult than I had expected because it required "ghosting" some required information to all the clients. Although I think this was the best way to do it, it took us longer than I had expected. Most other things seemed about as difficult or as easy as I was expecting: particle systems are relatively easy to set up while collision detection was relatively difficult.
|
|
Mike |
|
Again, importing models and animations from 3DS Max was fairly difficult at first, but after some serious coding, the fixes turned out to be much easier than I had expected.
|
|
Scott |
|
Yeah, the TNL ghosting stuff was definitely the biggest challenge we ran into, from a non-graphics perspective. The TNL library promised to be almost exactly what we needed, but with a price – there was almost no documentation for how things worked. All we had to go on were pre-implemented examples. This led us down the wrong track quite a few times when we were first struggling to understand the model they used for things. However, once these issues were figured out (and it did take us much longer than we anticipated), using the ghosting stuff became pretty easy and even adding more types of ghosted objects (such as arrows) was easily accomplished.
|
|
Ryan |
|
As everyone else said, networking and animations were more difficult than expected because TNL and 3ds max have horrible documentation. Audio was simpler than I expected because OpenAL is awesome and there's some great tutorials for it.
|
|
Jon |
|
It seemed like 3dMax studio was sufficient for drawing realistic models in our game. We did not try other software such as milkshape? or ogre. Since our game was based on opengl, we did not try directx extensions. Of course, if there were opengl special effects libraries or other fancy tools for opengl, we would have looked into it.
|
|
Ben |
|
TNL needs better documentation. Overall, I liked the cross-platform compatibility we offered, but finding good libraries was difficult. TNL seems powerful, but the documentation is poor and it may have been the source of our unexplainable choppy gameplay.
|
|
Fred |
|
I think the tools we used were great. OpenGL was great for graphics, TNL was difficult to use but very powerful for networking, and OpenAL seemed to do the job for the sound. Maintaining cross platform compatibility was difficult, but I think it led us to the direction of some great tools, i.e., poorly written tools don't often find themselves ported to multiple platforms. CVS did the job for maintaining versions of our software, but I think SVN would have been better. There were many times we found ourselves with broken code on the repository and struggling to find a past version that worked; SVN (in my opinion) makes this easier as it assigns a different revision number to each commit in the code. Rather than spending a lot of time trying to guess the exact time CVS had a stable version, it would have been nice to know that "revision 342" was very stable with SVN.
|
|
Mike |
|
Again, I have to give credit to Dave for the 3DS max importing/exporting code. Without his hard work, our game definitely wouldn't have looked the way that it did.
|
|
Scott |
|
I concur with Ben that TNL could have used some much better documentation, but thats kinda out of our hands. I also think Fred makes some good points about SVN aswell. One library which hasn't been mentioned yet was Cmake. Simply put, Cmake made our game possible. Without a way of generating Makefiles on *nix platforms and Project files for Visual Studio, we wouldn't have been able to do things cross-platform. Cmake performed beautifully, and I would definitely recommend it to any groups in the future who wished to do things cross-platform. I would argue, however, that the biggest detriment to our game was Visual Studio. On countless occasions the other people in my group had to sit back and wait 5-10 minutes for the program to compile, even after making a small change to one file. I think this gave us an incredibly slow development cycle. Using my laptop (PIII, 800MHz) with linux installed, I could compile the entire project from scratch in less than a quarter or the time it took Visual Studio. Imagine the time we wasted just waiting for our stuff to compile...
|
|
Ryan |
|
A good max exporter would have been very helpful instead of having to write our own. Also, we couldn't find a good OpenGL gui designed for a game's menus instead of a gui application.
|
|
Jon |
|
Writing our game engine was a good idea. We were able to add new modules and also optimize certain parts of the game. Using multithreading, our game loading and running time was significantly improved. We saw that people who used the OGRE engine had an easier time in the beginning but ultimately had no room for expansion later. Also it seemed like the OGRE engine presented problems that were very difficult to debug. Part of this class should be about innovating and OGRE doesn't let you do that. On the other hand, our game engine has plenty of room for innovation and is probably easier to debug and understand.
|
|
Ben |
|
Groups using a game engine seemed to have prettier games, but less innovative gameplay. I think the game engine helps you make it look nice, but at the cost of restricting your artistic freedom, which should be the focus of the game development. I don't recommend using a game engine if you want an interesting game.
|
|
Fred |
|
I'm very glad we didn't use an engine because writing your own engine (in my opinion) was half the fun of this project. I loved the flexibility to add or do whatever we wanted. Indeed we struggled with some things that might have been trivial otherwise (like importing models) but in the end we have our own somewhat beautiful game engine completely created by our own hands which certainly gives a feeling of pride and accomplishment.
|
|
Mike |
|
I'm so glad that everyone agreed we should write our own engine. I think that what we learned and accompished would not have been possible with a pre-existing engine. As Fred said, the most rewarding part of our experience was seeing something of our own creation running on the projector, and hearing the crowd's response.
|
|
Scott |
|
Agreed.
|
|
Ryan |
|
No.
|
|
Jon |
|
I would have liked to write the game in Java instead of C++. Because each of us were using different platforms, there were many incompatibilities between source code. Java would have been much easier and eliminated cross-platform incompatibilities. Much time was wasted debugging the incompatibilities which could have been spent improving the game.
|
|
Ben |
|
I would have liked everyone to put in more lab time together towards the beginning and middle of the project. We picked up a lot of slack at the end and some people ended up working more than they should have needed to. I think that coming together in the lab environment for long periods (maybe not all-nighters) solves many problems and greatly increases productivity.
|
|
Fred |
|
I disagree with Jon that Java would have been the way to go. C/C++ is the de-facto standard for games and I think taking what seemed like the easy way out simply because we are more familiar with Java from our classes would have done us a great disservice. I was amazed with how few problems we had with platform incompatibility that couldn't be solved within a couple of minutes. However, I would have done several things differently. I would have made it a point to have a test class for every module I developed rather than just for arrows and blood. Recompiling the source and connecting to the the server took far too long for testing small changes (such as fog constants)that could have better been tested separately. Likewise I would have made more use of our settings file for testing rather than recompiling. Like Ben I would have wanted to spend much more time together coding as together in the same room (maybe 4 hour sessions 2 or 3 times a week would have worked.) This was difficult because everyone had some incompatible schedules but I think if we had made the project a top priority (like was did the last few days) then this would have been possible.
|
|
Mike |
|
Knowing what I know now, I'd probably tell Dave the simple ways to get around our exporting problems. Fred and Ben are correct, some serious time spent as a group hammering out code probably would have benefitted us. Or set us at each other's throats...
|
|
Scott |
|
I originally wanted to do this game in Java, but I believe we made the right decision using C++. Too much of our pre-existing code would have had to be rewritten, plus we wouldn't have been able to use the TNL network library (which turned out to be rather important). The issues we had with cross-compatability were actually pretty small. There were a few differences between the MS Compiler and G++ that had to be coded around, but again, it wasn't a major stopping point. I agree that more meeting time early on would have helped out quite a lot. I rarely used Visual Studio, but when I did I know it took forever to recompile thing. Using settings and so on would have been a timesaver – then again, so would coding it in Linux.
|
|
Ryan |
|
In case you can't tell, I think we needed to do some more software design at the beginning. We spent way too much time rewritting things. Also, some naming conventions would have been good. CVS commit emails would also have been helpful so that we all knew what was going on with the code and so it would be easier to track down who committed broken code.
|
|
Jon |
|
CSE12 for learning C++ and writing modular code. CSE 167 or CSE 123a should be a prerequisite for this class since graphics and networking took the most time and were the most complicated portions of the game. CSE 131b is also a good indicator of the difficulty of the course. All other courses were either too theoretical/useless/boring.
|
|
Ben |
|
Compilers helped emphasize the importance of modular code, which was essential to our sanity in this project. Networks helped with the networking, and if people get AI into the game, I'm certain the AI courses would help. I didn't do any graphics, so I can't comment on that.
|
|
Fred |
|
CSE 169 with Prof. Rotenberg was the best preparation I had. CSE 167, and MAE 293 were also invaluable in terms of OpenGL skills. CSE 123a didn't really provide me with any real useful knowledge that was helpful in understanding the network code. CSE 120's explanation of RPC's was far more useful (also probably for threading, but that was Ryan's undertaking.) CSE 131B in terms of time commitment and code modularity.
|
|
Scott |
|
I actually don't think there is a single course that can prepare you for this class (if you're not doing graphics). None of the topics covered in previous classes really applied here, so the best you can hope for is that previous classes have prepared you to survive on little sleep and deal with large, complex projects. But above all, you need to have learned to throw yourself at a problem and to become familiar with all aspects of it. Thats the only way to solve it on your own. There's no handholding in this class, and problems you run into are entirely your problems. The TA's can give advice, but they will not know the intracacies of your code, nor the methods you are using to implement things.
|
|
Ryan |
|
CSE 131b taught me a lot about good programming style. Can't really think of anything else that really prepares you for this sort of thing.
|
|
Jon |
|
Writing modular code is most important because although it takes more time in the beginning, later, it becomes easier to debug and expand. Also, CVS is the most important tool in this class. In the last hours, our game kept crashing and we could not figure out the problem. When we checked the CVS log, we found the problem and corrected it.
|
|
Ben |
|
I agree [with Jon].
|
|
Fred |
|
Learn to work together. Find the strengths (and learn the weaknesses) of everyone in your group so that you can get people working on what they are interested without interfering with what others are trying to accomplish. Test things modularly. Communication is probably the most important factor of success in a large project.
|
|
Scott |
|
Establishing good lines of communication and methods of keeping others in the group informed of what you are working on is absolutely vital – It keeps people from stepping on each others toes, and the better informed everyone in the group is, the quicker bugs and issues get worked out.
|
|
Ryan |
|
Communication is so important. Even when we were all together in the lab we still had two people doing the same thing at once.
|
|
Fred |
|
"The OpenGL Programming Guide" by Woo, Neider, and Davis (also known as "The Red Book") was the most helpful reference for OpenGL. Other than that it was all about google to learn what I needed to know.
|
|
Ryan |
|
I used the Red Book and Advanced C++ Idioms
|
|
Ben |
|
Spend lots of time in the lab with your group. Be innovative with your game and try something new that hasn't been done. The most interesting games are the ones that aren't cookie-cutter designs. Also, don't use a game engine.
|
|
Fred |
|
Learn to communicate. If something isn't working send an e-mail to the group (immediately) and find out whose working on it and what the problem is. You can save yourself hours of frustration because maybe the whole thing isn't working just because someone forgot to commit a file. Don't go off and do your own thing; work on things that will help the group as a whole. Again this can only be accomplished through communication.
|
|
Mike |
|
I agree, teamwork is the key to any project like this. Using Google Groups was very beneficial to our group, as it allowed for a communication platformthat was much more rapid than wikis or instant messaging.
|
|
Scott |
|
Communication is very important,
as is knowing what other people in the group are doing. If
possible, set up CVS to send an email to the mailing list when
someone checks something into the repository containing the files
changed, comments, and so on. That way, people will actually make
their comments useful, and everyone in the group will know what
is being worked on and who is working on it. This would have been
very useful during the quarter.
|
|
Ryan |
|
communicate and plan ahead
|
|
Jon |
|
There should be a game like Kampus Kombat except that it maps the entire UCSD campus. It should run 24/7 on UCSD servers and allow everyone to log in and play like an MMORPG. This is good for marketing UCSD and giving future freshmen a tour of the campus. The game might not fit the course description but it would be really cool if something like this existed.
|
|
Ben |
|
I think it would be beneficial to have a well-formatted repository of links to web sites for each part of the game development on the course homepage. The slides from lecture are helpful and we can glean links from the previous projects' pages; however, it would be much easier if everything was centralized on the main web site.
|
|
Fred |
|
This course is pretty near perfect as it is; I do like Ben's suggestion, though. It would be nice if there were a "game index" on the course web page where you could keep track of links students found that were really useful. For example, several of the tutorials at nehe.gamedev.net would be pointed to for specific topics like texturing, lighting, etc. That way we would have a nice place to start before turning to the thousands of hits google gives for such subjects.
|
|
Mike |
|
I agree, it was nice to see what other groups in the past had done, and feed off of that for inspiration. I think it would be nice if there was a wiki or messageboard available for inter-group communication and sharing of tutorials.
|
|
Scott |
|
I agree with eveyrthing above. I think it might be useful for the people from different groups who are working on similar aspects of the game to be able to get together and discuss their aspect of the game and issues they run into that might affect other groups, etc. So in general, I would suggest more communication between teams.
|
|
Ryan |
|
All games should be required to have rotating cubes.
|
|
Jon |
|
No way.
|
|
Ben |
|
Never even used it.
|
|
Fred |
|
I used it once for about 3 minutes. I was too busy coding. It was nice however, just to have the thing in the same room with us as a mascot.
|
|
Mike |
|
Hahaha, well put Fred.
|
|
Scott |
|
Come to think of it, I don't think I ever saw anyone using it. Usually someone was using that area for a laptop.
|
|
Ryan |
|
Nope.
|