CSE 125 Group 3 Project Review Document Finished June 11, 2010

ruralrompΛογισμικό & κατασκευή λογ/κού

2 Δεκ 2013 (πριν από 3 χρόνια και 6 μήνες)

53 εμφανίσεις

CSE 125 Group 3 Project Review Document

Finished June 11, 2010


1. Game concept: How and why did your game concept change from initial concept
to what you implemented?


Really it hasn't changed much, it just ended up being a subset of the original
game pla
ne. It makes sense to first explain the initial concept, that is:


to have a
base defense / resource gathering game where you play as a bird. The 'resources'
gathered would be food, and you would gather them by pooping on people. The
'base' defended was pl
anned to be a nest.

What was completed was simply flying around pooping on people. This was a
result of programmers who actually contributed to the project being spread thin.
The engine was already mature at an early time (due to Ryan working on it for th
e
past 3 years) and supported smooth skin animation, most collision detection (Ray
vs. Mesh, Ray vs. Sphere, Sphere vs. Mesh, Sphere vs. Sphere) since the 4th
week. It also had a robust 3rd person camera system with an adaptable orbiting
radius (camera mov
ed closer to player rather than popping through walls) early
on.

Had more of the team understood what functionality the engine already had
(and how to use it properly) much more would have perhaps ended up being in
the final implementation. For instance m
ore animated characters could have been
added, the items could have easily been done: sphere vs. mesh/sphere was already
fully supported!


Some programmers preferred to work in isolation on this project, believing
what they were adding was actually contrib
utory without hardly any interaction
with other teammates as to what actually needed to be done, or what had
already
been done. This inevitably lead to code being completely re
-
written, broken, and
multiple different versions of code designed to accomplish

the same effect.




[Haili] In short, time.



2. Design: How does your final project design compare to the initial design, and
what are the reasons for the differences, if any?



[Ryan]No bird nest to 'defend'
-
no items to pick
-
up. Shadow mapping not
impl
emented.


[Louis]Resource collection via food items was originally in the design, but we
did not have the time to implement it.


Ultimately, we had to drop the entire
resource collection idea, as well as the base defense concept, and implement a
simple sco
re system.


Again, this was due to time.


3. Schedule: How does your final schedule compare with your projected schedule,
and what are the reasons for the differences, if any?


[Louis]We were working on network problems pretty much until the last day.


We
were working on implementing shadow maps until the last day.


Debugging
and optimizations were worked on until the last day.


NPC states had problems
until the last day.


We did not implement multiple NPC animations.








[Mehran] Had to rewrite the

network many times due to design flaws.


[Ryan]


We were consistently behind, mostly due to code being used in the
engine prior to being stress tested. People would move on, assuming a module
was functional until later on in development 'new' bugs would b
e found in the old
modules. This led to alot of time being wasted simply to hunt down bugs in old
code, before we could move forward with new code. This could have been
avoided had we unit
-
tested more.

This class is very different from others in that you m
ust be self motivated; I
feel most of my team expected a 'to do' list from me daily
-
and if I could not come
up with anything, they would silently do nothing. I really didn't want to micro
-
manage, but that was what was called for.




[Haili] We had high ex
ception of graphic, but we was not able to finish them
in the end. For instance, We spent two weeks on figuring out shaders for shadow
map and normal map, but only got the normal map to work. We thought we could
use sample demo from the Internet and use th
em as black box, but that was not
the case and lot of time was wasted. We could have prioritize simple tasks such
that normal map shaders could have been implemented before shadow map.


Tasks sometimes were too big for each individual to finish without int
eracting
with others. However, some programmers through that not interacting is better
than causing problem in the later integration. We did not have a systematic way of
breaking down the tasks, nor detecting problem with future integration.

















4. What software methodology and group mechanics decisions worked out well, and
which ones did not? Why?


[Louis]Having a separate weekly meeting seemed to work for those that
showed up because it acted as a physical check
-
in process and it was motivati
ng
to display your past week's work. Not using SVN from the very beginning was
not a good idea; not only did that require having to manually merge code, it left
people with unaccountability.



[Haili] We practiced pair programming for a while, and switche
d out when
time came. I wish we had more time to walk through code with the author. No one
really did any kind of spec before we code, and really not one had time to do that,
but lots on confusion might have been avoided if we did spec before digging too
d
eep.


Each of us had some kind of coding style, and we had quite a bit of arguments
about them.



It may have been beneficial for us to test each other's code more often, in
order to offer better quality assurance. This also may have been more plausible i
f
we began using subversion earlier.


[Ryan] Getting people to work together in lab helped. Taking turns explaining
at the white board what we were doing also helped. It is easy to justify using a
particular algorithm in your head even if it's incorrect, b
ut when you have to
justify it to 6 other people it needs to be correct. I found that simply planning how
to explain my algorithm to others helped me find insight on improving it.









[Mehran] Things started to get better as soon as everyone start
ed using
subversion. Wish we had done that from the beginning.


[Eric] At first, when I started learning how to use Maya to make statics, I was
mainly doing tutorials and working alone. That worked up until a certain point
because I really needed Ryan's fe
edback to make sure I was doing things
correctly. So, when I started going to the lab more and working with the group, it
was more beneficial because I started getting feedback from Ryan about what I
was doing right and what I was doing wrong. This allowed

me to correct my work
and make sure everything I made would fit into the game correctly (e.g. not slow
it down).


2. What aspects of the implementation were more difficult than you expected, and
which were easier? Why?


[Louis]At the beginning of the quar
ter we had a numerous problems with
implementing libraries.


This was definitely not something that I expected to be
such a large task, but when we finally got it down, it became a much simpler task.


[Haili] It's always not easy to work with someone’s cod
e.


[Ola]


Making NPCs behave realistically was more difficult than expected,
especially since this was to be done in unfamiliar code. Specifically, getting them
to sit only on chairs and to turn toward the appropriate direction beforehand.


[Eric] At the
beginning, the most difficult part, for me at least, was figuring
out what to do. It seemed like every one else already had some definitive task to
work on and I just latched on to what Louis was doing. He had it all figured out
already, however, and I was

still not sure what to do. Luckily, after having a nice
talk with Ryan, we were able to make me useful by focusing my efforts on
modeling. Surprisingly, I was able to pick up Maya in about two and a half days
and I started work immediately on making stati
cs.


[Ryan] Getting two player spheres to bounce off of one another was
surprisingly simple

in fact, it worked first try during multi
-
player.



3. What aspects of the project are you particularly proud of? Why?


[Zach] The enormous size of the level
--
it

really showcases the engine, models,
sounds, and game logic well.


[Louis] Thanks to Ryan we have fully functional sphere vs. tri
-
mesh for the
character vs. environment.

I'm definitely proud of all of the things that were developed, yet did not make
it in
to the game. For instances, our method of bounding the level by having the
bird get hit by a jet, the many models into which members put quite a bit of hard
work, different NPC textures and animations, etc. There was a lot of good stuff.


[Ryan]Our camera
system is amazingly well done (another good job by
Ryan!)


[Mehran] I would like to second Louis on that. The camera system is just
magnificent. Thank you Ryan. I'm also proud of the fact that we wrote everything
including the game engine and the network e
ngine from scratch.


Our smooth skin animation engine (completely from scratch!) worked well.

The poop projection onto animated/static mesh worked well.

The 3D sound was amazing, without the screaming the game just isn't as good
(Good job Louis!)


[Eric] I

am really proud of all of my work even though most of it,
unfortunately, did not make it into the final game due to time constraints.
However, I am proud of all of the hard work that all of my team mates put into the
game. The network code was amazing and

it allowed the game to run smoothly.
The collision detection and graphics were amazing and the fact that we were the
only game with NPCs is another thing we can be very proud of. Finally, the Price
Center level was excellent and very fun to play on.


4. W
hat was the most difficult software problem you faced, and how did you
overcome it (if you did)?









[Ryan] Probably finding the bug in our animation engine, which actually
ended up being a singularity in the matrix conversion to Euler angles (ha
ppens
near poles, for a particular ordering of rotations).

A quick fix was just to change the order of rotations and hope no singularity
will be encountered. A better fix (in progress) would be to 'special case' near
-
pole
conversions.


[Haili] Shadow map
for our advanced camera system. We did not solve it in
the end.


5. In implementing your project, you relied upon a number of tools, from the
DirectX

OpenGL libraries to modeling software.

What libraries and tools did you
use for the various parts of your
project? What was your tool chain for modeling,
exporting, and loading meshes and animations?

What is your opinion of them?
Would you use them again, or look elsewhere?


[Louis] FMOD Designer was great and made implementing 3d sound very
straightforward.


Though we didn't have time to implement reverberation or
hardware driven effects, implementing this did not appear like it would be
difficult either.




[Zach] Our pipeline for modeling, exporting, and loading started in 3ds Max. I
modeled everything in Ma
x, exported as an .obj and imported into Maya. We used
cvxporter for Maya because it seemed to work the best and the loader was up and
running quickly. I simply exported the file as a .x and Ryan's loader could read it.
It was solid, if a little roundabout
.


[Haili] We tried two shader libraries, GLEW and GLEE. GLEW was
suggested by nVidia cascaded shadow map demo, but we stuck at the CSM demo
and GLEW and could not get anything done. So we dig up the old CSE167 shader
code and use GLEE instead. Maybe I had

played with GLEW for a while already
by the time I switch to GLEE, everything turned our smooth for this library.





[Ola] OpenSteer definitely made NPC implementation a simpler task.


[Eric] For 3D modeling and design, I used the AutoDesk Maya software
. I
thought this software was very good and easy enough to work with despite having
only two days to learn it. Despite its occasional buggyness, I was comfortable
using it and I would definitely use it again. For exporting the models, I used a
Python scrip
t called cvxporter as advised by Ryan. This tool was particularly easy
to use and I would definitely use it again.


6. Would you have rather started with a game engine like Ogre or would you still
prefer to work from scratch?


[Louis] Only ogres use Ogre,
you an ogre?


[Haili] It would be nice

to have a one to one comparison of Ogre and what we
have to implement.


[Ryan] From scratch definitely put hair on my chest (and gray hair on my
head). I definitely learned more from doing it from scratch then from
modified
Ogre or Open Dynamics Engine (ODE) game demos I've worked on in the past.
Without 3rd party engine dependence, any problems were of our OWN making,
and our OWN un
-
doing; this is crucial to allowing unlimited directions as the
project matures, or i
f/when it is revisited in the future.


7. For those who used RakNet, would you use it again if you were starting over
knowing what you know now?

Describe any lessons you learned using it (problems
that you had to troubleshoot and how you addressed them) fo
r future groups who
may use it.

If you did not use RakNet, judging from the experiences of the groups
that did, would you have used it in retrospect?


[Louis]We did not use Raknet and in retrospect we would not have chosen to
use it.


[Ryan] RakNet should
be banned, networking is not that tough
-
that being
said we re
-
wrote our network server about five times ;
-
) The 'tough' part is
designing the game engine to work around updating packing/unpacking and
drawing, which is not necessarily a networking challeng
e.



8. Looking back over the past 10 weeks, how would you do things differently, and
what would you do again in the same situation?


[Louis] I wish that we had allocated the tasks that were handed out differently.


[Zach] I would have spent more time a
nd thought on the design document. We
pretty much ignored that as soon as we wrote it (or so it seemed to me). If we had
really thought about it more, I think everyone would have been more on board
with the scheduling.


[Mehran] I would have designed the n
etwork engine in a much smarter way,
so that the changes in speed would not create problems.


[Haili] I would reject Ryan harder on implementing shadow map.

Establish agreement on coding styles at the beginning of the project.


Test plan before coding.


[R
yan] It would have been nice to have some sort of editable flow chart of all
the parts of the engine (complete with inputs/outputs per module) to have
everyone on the same page. I would have stressed the importance of testing your
code before moving on. A
programmers job is to organize and write clean,
commented, bug free code
-
and not to generate a mess of hacks that can
somehow
compile.


[Eric] I would have worked a lot harder to crank out more models and I would
have exported my final models a lot sooner

so that they could have been placed
into the game. Also, I would have spent more time learning how to make low poly
models look better by using techniques like normal mapping. I didn't spend too
much time on the normal mapping, but it definitely would hav
e made my models
look better (I only used normals on models that had simple textures that allowed
for automatic normal creation like a concrete bench).


9. Which courses at UCSD do you think best prepared you for CSE 125?


[Zach] Coming from an ICAM perspe
ctive, I think just the group
-
oriented
classes in some upper
-
division series helped me work in a group setting (albeit
nothing this large). VIS 147B (Electronics for Art II) had 4
-
person groups; my
ICAM 160A/B group is 3 people, and other classes had pairs

and small groups.


[Louis]
CSE 123 was a great help with understanding basic networking.


CSE
120 was a great help with understanding multi
-
threading.


[Mehran] CSE120 (multi threading and mutual exclusion), CSE160 (Multi
-
Threading and thread synchronizati
on) CSE123 (Networking and TCP/IP),
CSE124 (Networking and TCP/IP) and compilers.


[Haili] CSE167 and CSE121




[Ryan] CSE169 (animation), CSE190 (GPU programming), CSE167 (intro to
graphics), CSE198 (ray
-
tracing)


10. What was the most important thing
that you learned in the class?











[Louis] I learned a great deal about developing a large project in a large group
setting, with multiple people handling multiple responsibilities.


I also learned
how to utilize libraries.


[Mehran] Learned a
bout socket programming and multi
-
threading in
windows.


Learned about working in groups and writing adaptable code for integration
purposes.



[Ryan] I learned that organizing a real time system (of teammates, software,
or teammates writing software) is n
on
-
trivial.



[Eric] I learned that working on a large, complicated software project with a
team can be a rewarding experience.


1. What books did you find helpful that were not on the recommended list but
should be? What books were on the recommended list

but were not useful and
should be removed?


[Ryan] I found notes from Steve Rotenberg's class (CSE169) to be most
helpful, and they remain on
-
line.


2. I will be teaching this course next Spring. What advice/tips/suggestions would you
give students who wi
ll take the course next year?


[Zach] Any ICAM majors coming into the class might be unfamiliar with the
actual amount of work that this class takes. Simply saying "it'll be a commitment"
doesn't really prepare us for the workload that most CS majors take
for granted.
Perhaps giving a more solid number might be more helpful?


[Louis] Know about graphics.


[
Haili] wiki page + email reminder when new update is available in svn.


Guest lectures at the very beginning about graphics for everyone.

Get to know you
r teammates better as early as possible.


[Ryan] Stress the importance of putting the team first, and not working in
isolation.





3.How can the course be improved for next year?


[Louis]GET BETTER HARDWARE PLZ. Implement some kind of system
that ensure
s that every individual is contributing (some) work all the time.


[Mehran] Faster machines please.












[Haili] Peer review would be good.


[Zach] Advertise to ICAM classes. Make sure it's very clear what is expected
of the artists and what kind o
f workload it is. I guarantee you'll still see a lot of
applicants. Even a simple email to ICAM majors would be good.


[Ryan] Find TA's who know their stuff.