<?xml version="1.0" encoding="utf-8"?>
<!-- If you are running a bot please visit this policy page outlining rules you must respect. http://www.livejournal.com/bots/ -->
<feed xmlns="http://www.w3.org/2005/Atom" xmlns:lj="http://www.livejournal.com">
  <id>urn:lj:livejournal.com:atom1:mammal_games</id>
  <title>Mammal Games Development</title>
  <subtitle>Furry engineering</subtitle>
  <author>
    <name>Cat</name>
  </author>
  <link rel="alternate" type="text/html" href="http://mammal-games.livejournal.com/"/>
  <link rel="self" type="text/xml" href="http://mammal-games.livejournal.com/data/atom"/>
  <updated>2006-02-07T23:55:52Z</updated>
  <lj:journal userid="9403020" username="mammal_games" type="personal"/>
  <link rel="service.feed" type="application/x.atom+xml" href="http://mammal-games.livejournal.com/data/atom" title="Mammal Games Development"/>
  <link rel="hub" href="http://pubsubhubbub.appspot.com/"/>
  <entry>
    <id>urn:lj:livejournal.com:atom1:mammal_games:1788</id>
    <link rel="alternate" type="text/html" href="http://mammal-games.livejournal.com/1788.html"/>
    <link rel="self" type="text/xml" href="http://mammal-games.livejournal.com/data/atom/?itemid=1788"/>
    <title>[Saturday] Development 01 - Early rationale</title>
    <published>2006-02-04T03:27:52Z</published>
    <updated>2006-02-07T23:55:52Z</updated>
    <category term="development"/>
    <content type="html">There are plenty of practices and applications I want to investigate. The following have been on my mind in that they all have potential to help standardise and improve game development. Some of them are already in use but I have felt like pushing my knowledge and their case strongly.
&lt;ul&gt;
&lt;li&gt;&lt;a href="http://en.wikipedia.org/wiki/Doxygen"&gt;[Doxygen]&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href="http://en.wikipedia.org/wiki/Unified_Modeling_Language"&gt;[UML]&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href="http://en.wikipedia.org/wiki/C_Sharp"&gt;[C#]&lt;/a&gt; (for tools)&lt;/li&gt;
&lt;li&gt;an interpreted language (possibly &lt;a href="http://en.wikipedia.org/wiki/Python_programming_language"&gt;[Python]&lt;/a&gt; or &lt;a href="http://www.lua.org/about.html"&gt;[LUA]&lt;/a&gt;)&lt;/li&gt;
&lt;li&gt;mature development practices (automated testing / unit testing etc)&lt;/li&gt;
&lt;li&gt;significant pre-programming planning and research&lt;/li&gt;
&lt;/ul&gt;
&lt;a name="cutid1"&gt;&lt;/a&gt;There are usually many alternatives to the problem each of the above solves, however from general experience opinion has settled on one system over another. Eg. Doxygen is recognised as one of the best platform independant software documentation generaters. Perhaps I won't please everyone with my choices, but then I believe that using something second best is still better than &lt;i&gt;using nothing at all&lt;/i&gt;.
&lt;br&gt;&lt;br&gt;
Proliferation of new technologies in games is frustrating when it isn't monitored. How can we compare old and new systems when nobody knows how to evaluate and use either? (eg. replacing &lt;a href="http://en.wikipedia.org/wiki/Make"&gt;[Make]&lt;/a&gt; with &lt;a href="http://en.wikipedia.org/wiki/Perforce_Jam"&gt;[Jam]&lt;/a&gt;, Python and/or &lt;a href="http://en.wikipedia.org/wiki/Scons"&gt;[SCons]&lt;/a&gt;) What is the business case for introducing new technology that solves a problem well, but requires obscure knowledge to maintain? (eg. Jam, Python and/or SCons again!). "Using the right tool for the right job" is worthwhile, as long as a credential for being the right tool is that anyone can use it.
&lt;br&gt;&lt;br&gt;
For example, coders often create new text readable data formats and tags in .ini files or custom made files, with custom readers. However, &lt;a href="http://en.wikipedia.org/wiki/Xml"&gt;[XML]&lt;/a&gt; is a standard, and has robust tools for editing, validation and numerous parsers for C++ (eg &lt;a href="http://en.wikipedia.org/wiki/TinyXML"&gt;[TinyXML]&lt;/a&gt;). Why ever use anything else?
&lt;br&gt;&lt;br&gt;
&lt;b&gt;The Project&lt;/b&gt;
&lt;br&gt;&lt;br&gt;
The demonstration project is deliberately going to be small(ish), and also minimise the risks in its design and scope. Firstly, by not setting the standard too high I can manage expectations better. (Especially important for motivation on a spare-time project). Secondly, I consider it good business practice to not pull out all the stops to create something new. This creates an equation with too many unknowns, and unknowns equals risks. Producing a risk-averse product definately seems to jar with the "art and craft" of games development, but I will propose that this should come second to the "business" of games development. 
&lt;ul&gt;
&lt;li&gt;top down 2D RPG, similar to &lt;a href="http://en.wikipedia.org/wiki/The_Legend_of_Zelda:_A_Link_to_the_Past"&gt;[Zelda]&lt;/a&gt; and &lt;a href="http://en.wikipedia.org/wiki/Secret_of_mana"&gt;[Secret of Mana]&lt;/a&gt; on &lt;a href="http://en.wikipedia.org/wiki/Snes"&gt;[SNES]&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;technical and gameplay risk #1: game content creation has almost zero programmer input&lt;/li&gt;
&lt;li&gt;technical and gameplay risk #2: world scrolls continuously, there are no "levels"&lt;/li&gt;
&lt;/ul&gt;
Coding won't start until I have planned and researched the problems I will face.
</content>
  </entry>
  <entry>
    <id>urn:lj:livejournal.com:atom1:mammal_games:438</id>
    <link rel="alternate" type="text/html" href="http://mammal-games.livejournal.com/438.html"/>
    <link rel="self" type="text/xml" href="http://mammal-games.livejournal.com/data/atom/?itemid=438"/>
    <title>[Thursday] Muse 01 - Open for business</title>
    <published>2006-02-02T11:04:54Z</published>
    <updated>2006-02-06T21:09:19Z</updated>
    <category term="muse"/>
    <content type="html">After a couple of hours trying to get this page to &lt;i&gt;not&lt;/i&gt; look like an LJ page, finally I've reached a compromise. Just dont look at the &lt;a href="http://mammal-games.livejournal.com/calendar"&gt;[Archive]&lt;/a&gt; page. It suffers the worst.&lt;br /&gt;&lt;br /&gt;Enjoy.</content>
  </entry>
</feed>
