 |
|
|
|
|
|
||
|
|
||
|
|
||
|
|
|
|
|
|
||
|
|
||
|
|
||
|
|
|
|
|
|||||||||||||||||
Add Forum to Favorites | Send Topic To a Friend | View Forum FAQ | Track this topic |
Last Thread Next Thread |
| Programming Role Playing Games Chapter 11 |
|
 |
Grul Member since: 3/6/2001 From: Linköping, Sweden |
|||
 Posted - 7/13/2004 2:37:52 PM |
||||
| The coding style in this book, though useful, seems to be surprisingly arcane. It's completely devoid of stl algorithms, there's lots of structs and macros and other positively c-ish stuff. I guess this book is directed towards beginners since simple c-ish code might be easier to understand in the beginning. |
||||
|
||||
 |
hplus0603 Moderator - Multiplayer and Network Programming Member since: 6/3/2003 |
|||
|
Posted - 7/13/2004 2:44:18 PM |
||||
| A lot of real, production code uses C-like conventions as well. Contrary to some's belief, always pushing to the latest and greatest seldom makes good business sense, and is not the mark of a true professional. |
||||
|
||||
|
hplus0603 Moderator - Multiplayer and Network Programming Member since: 6/3/2003 |
|||
|
Posted - 7/13/2004 3:17:06 PM |
||||
| What I didn't like about the article was that it didn't talk about problems or alternatives. For example, many industrial strength engines will use something like a SQL database for their item table design, and a nice SQL front-end for editing the database. What's maybe worse was the total lack of item identity in the item control system. This means that all items are identical; you can't modify an item. For example, un-identified items would have to be removed, and the identified counterpart added to the inventory when using scroll-of-identify. Items with use counts (rather than infinite or one-time use) also don't work right with this system. Last, if items don't have identity, then item duping bugs are easy to accidentally create, and really hard to detect and avoid. Meanwhile, if each item instance actually has identity, you have much better control over these things, and more flexibility in how you deal with items. Granted, it uses more memory, but only a little, which doesn't matter on a modern machine. Another funny was the suggestion that 1024 items of 128 bytes each would be "a lot of memory" to keep in RAM at the same time -- but maybe he's on a console. Like, a 16-bit console :-) Props for making sure that there's suitable tools to support the code, though. |
||||
|
||||
| All times are ET (US) |
Last Thread Next Thread |
|
