Process & Methods

quote:

---

Original post by cdtrrrst
I find that the majority tend to do ''heroic coding'' first then try to reverse engineer to an object-oriented architecture. Buzzwords like ''framework'' and ''architecture'' is all but lost in a coding frenzy. The fact that there aren''t a lot of response in the SE forum proves this, no?

---

No, it doesn''t. Remember who your subjects are and who they are not. These forums are filled primarily with amateur coders (amateur as in hobbyist/non-professional as opposed to amateur as in skill), not those who are in the industry and coding as their employment.

Taking these forums as an indication of the kinds of processes and methodologies used in game programming present in the whole of the industry is a bad assumption. Of course, if you had not made that assumption (best I could read into it), forgive me.

quote:

---

There seem to be a number of threads criticising the so-called "university students" who can''t do crap on game programming. Well, I can say that most of our time is spent on perfecting implementation of codes through processes and methodologies. The GDC proceedings on SE methods don''t seem to be encouraging as well. Perhaps, everyone is waiting for extreme programming? Well, that''s all I have to say.

---

In general, I''d rather hire a university student with a strong background in mathematics and true software engineering (processes and methodologies included) who hasn''t written a scrap of game code over someone who has "mad skillz" (sarcasm intended) but lacks a background in engineering. Heck, that''s how I got in.



---- --- -- -
Blue programmer needs food badly. Blue programmer is about to die!

quote:

---

Original post by cdtrrrst
The fact that there aren''t a lot of response in the SE forum proves this, no?

---

mossmoss is correct, but in addition, the SE forum is relatively new. It''s been around for less than a year, while most of the other forums have been around for three.

Back to the topic, though. From my personal experience, and from those I''ve talked to, SE practices are not widely used in the game industry. The question of why that''s the case, and whether or not it needs to change, would be the subject of a rather lengthy paper.

Personally, I think that a lot more needs to be written about SE practicies as applied to games. That''s why we''re going to be launching a column called "Game Engineering". We haven''t actually announced it yet, but we''re looking for article submissions. If anyone''s interested in writing for it, send me an e-mail.

quote:

---

Original post by cdtrrrst
Perhaps, everyone is waiting for extreme programming?

---

For some reason my SE prof talks about extreme programming like its the best thing since sliced bread, yet described it as such: "Its like extreme wrestling, you keep your programmers in a room until they are done." Sounds to me like this would produce really crappy hastily written code. Maybe you are talking about something different.


University is a fountain of knowledge, and students go there to drink.

Wow, that's really misrepresentative. For a better description of what XP really is, check out extremeprogramming.org or xprogramming.com.

quote:

---

Original post by cdtrrrst
There seem to be a number of threads criticising the so-called "university students" who can''t do crap on game programming.

---

At my university, most of the people on the Computing degree hate programming. Personally, I don''t understand it, but there you go. The last year here has involved hardly any programming.

The problem with covering methodologies in game development is that there generally isn''t one. As I think you already saw, a recent round-table at the GDC showed that the majority were using "code and fix". A quick scan of the Gamasutra Postmortems also shows that most projects had nothing like a formal process and often got months into the project before they had a clear idea of what they were coding.

Personally, I''m a fan of using a very cut-down version of the RUP (split the project up into tangible pieces of functionality, and add these features one at a time, riskiest first, and ensuring fully integrated and tested software at each stage), but my project isn''t really successful enough to warrant writing an article on it. Additionally, I think that a lot of the standard methods aren''t very good for games, but that''s another matter. Anyway, maybe we''ll get lucky and someone else will write an article soon...

[ MSVC Fixes | STL | SDL | Game AI | Sockets | C++ Faq Lite | Boost | Asking Questions ]

Currently, I''m using Boehm''s Spiral model with emphasis on prototyping for my project. The risk-based analysis is great but I find that the XP approach, creating test plans before going for the "rougher" phases seems to be a positive approach in a process. I find that it helps visualization of anticipated problems and risks involved in the project. In RUP, I find that setting milestones is an excellent approach. Helps keep the "feature creep" in check. User stories in XP sounds very similar to use case contracts in UML. I think they should change the name because it sounds really crappy.