tag:blogger.com,1999:blog-79484814542667026872024-03-13T08:19:31.237-07:00Power GoatJoshuahttp://www.blogger.com/profile/10155409131938284592noreply@blogger.comBlogger16125tag:blogger.com,1999:blog-7948481454266702687.post-74198377640372716052015-07-31T15:47:00.002-07:002015-07-31T15:47:51.276-07:00Mecromage video updateJosh put together a great <a href="http://mecromage.com/2015/07/31/mecromage-status-jul-15/">Mecromage development video</a> detailing what we've been working on recently. Follow @mecromage twitter for the latest game updates. Take care, friends.goathttp://www.blogger.com/profile/05707356566945919856noreply@blogger.com5tag:blogger.com,1999:blog-7948481454266702687.post-46304619105775850132015-06-28T09:54:00.001-07:002015-06-28T09:54:24.952-07:00Still rollin' ...I'll have a track on the upcoming Vampire Variations 3 ocremix album...my first Super Castlevania 4 song remixed! In other news, still working really hard on Mecromage. Expect a lot more frequent updates about the game...<a href="http://mecromage.com/2015/06/28/mecromage-status-jun-15/">here's the latest!</a>goathttp://www.blogger.com/profile/05707356566945919856noreply@blogger.com3tag:blogger.com,1999:blog-7948481454266702687.post-64666707520473402502014-11-21T07:36:00.002-08:002014-11-21T07:36:22.876-08:00Mecromage November updateThe november Mecromage update is posted, detailing more main character details.
<a href="http://mecromage.com/2014/11/20/mecromage-status-nov-14/"><img class="aligncenter" style="display:inline;" title="BannerUpdateOct" src="http://www.joshuakeyes.us/simonbelmont/MecromageBlog/Images/ace2ff264cde_83F4/BannerUpdateNov_thumb.png" alt="BannerUpdateNov" width="625" height="100"></a>goathttp://www.blogger.com/profile/05707356566945919856noreply@blogger.com0tag:blogger.com,1999:blog-7948481454266702687.post-51145576872715000972014-10-14T13:58:00.001-07:002014-10-14T13:58:45.638-07:00Mecromage monthly updates.A few months ago we started posting Mecromage developer diaries. The latest post details some main character work. <a href="http://mecromage.com/2014/10/14/mecromage-status-oct-14/">Here it is!</a>goathttp://www.blogger.com/profile/05707356566945919856noreply@blogger.com3tag:blogger.com,1999:blog-7948481454266702687.post-82309835001881802672014-08-31T13:01:00.002-07:002014-08-31T13:17:49.448-07:00New Mecromage Track - Blade HuggerHere's another track from <a href="http://www.mecromage.com">Mecromage</a>. It's called <a href="http://powergoat.com/Music/goat%20-%20Blade%20Hugger(Mecromage).mp3">Blade Hugger</a>. As we draw closer to finishing the game, we'll continue to make monthly update posts at the game's site in a this-is-how-we're-making-the-sausage style, placeholder art included! Take care.goathttp://www.blogger.com/profile/05707356566945919856noreply@blogger.com5tag:blogger.com,1999:blog-7948481454266702687.post-41375775248723388472013-11-04T07:55:00.001-08:002013-11-04T07:55:25.276-08:00New track, "Krush Kontrol"<a href="http://powergoat.com/Music/goat%20-%20Krush%20Kontrol(Castlevania%20Rondo%20of%20Blood).mp3">Krush Kontrol</a> is a Castlevania: Rondo of Blood track I did for the <a href="http://kngi.org/vampirevariations/">Vampire Variations II</a> project. It's a remix of "Former Room," a spooky chiptuney song that lets you know the boss is near.goathttp://www.blogger.com/profile/05707356566945919856noreply@blogger.com3tag:blogger.com,1999:blog-7948481454266702687.post-54122678691804018692013-10-25T15:24:00.002-07:002013-10-29T11:52:25.587-07:00"Mecromage"Pleased to share more music! The game I'm working on is called <a href="http://www.mecromage.com/">Mecromage</a>. It's heavily inspired by classic adventure platformers, and more info will be forthcoming. In the meantime, here's a music track from the game, <a href="http://powergoat.com/Music/goat - To the Death(Mecromage).mp3">To the Death</a>goathttp://www.blogger.com/profile/05707356566945919856noreply@blogger.com2tag:blogger.com,1999:blog-7948481454266702687.post-38233042502933299102012-08-06T20:30:00.001-07:002012-08-06T20:41:38.992-07:00Asset management–roll ‘em up<p>An “asset” is a relatively large chunk of data used by a game. Examples include sound effects, textures, meshes, music and movies. While it’s important to have a runtime resource management system to avoid duplicate assets residing in memory, it’s also important to have a way to track runtime assets during development. Games tend to have a lot of assets.</p> <p>One way to ease asset tracking is to reduce the number of assets by rolling some up together. In a 3D game, it’s often necessary to keep individual texture assets separate as they are reused across different meshes. In a 3D game, textures often describe surface materials but rarely do they describe object contours (that’s left to mesh geometry).</p> <p>In a 2D game, however, textures usually define both surface material *and* contour, and as such there’s less likelihood that textures will be reused across different meshes. One example is sprite sheets. Some characters are defined by sprite sheets that span multiple textures. There is never going to be a case where these sprite-sheet textures have meaning outside the shape/material they represent. As a result, our runtime asset representing the visual characteristics of a character is a single asset: an “animation” asset. While we can “nest” animations, the exposed assets (file-wise) never drop below “animation asset” level (for example, the runtime files visually representing a guy holding a sword are a “guy” and “sword” animation asset). Animation data, mesh data and sprite-sheet textures are generated/rolled into one asset on export from our animation tool.</p> <p>Similarly, larger backgrounds may span multiple textures at runtime, and thus there is no reason for the runtime to need these textures to be floating around separately. Thus, just like character assets, a background asset accumulates multiple textures on background export and all reside in a single asset file.</p> <p>Reducing the asset count by rolling up “atomic” asset groups is good practice, both for runtime and for tools.</p> goathttp://www.blogger.com/profile/05707356566945919856noreply@blogger.com2tag:blogger.com,1999:blog-7948481454266702687.post-68995547104620684492012-07-17T13:44:00.001-07:002012-07-17T13:46:37.739-07:00Don’t hide the flow!<p>Design patterns have their place in C++. Don’t abuse them! Let’s look at one of the most common design patterns used in games- the “strategy” pattern. Games often define an “Entity” base class which specifies an interface that all game objects adhere to. Game objects derive from this Entity class and, via polymorphism, exhibit different behavior without the underlying engine having to know anything other than the base Entity interface.</p> <p>It’s tempting to stuff as much common behavior in the base class as possible, and, when that becomes too bloated, create more classes in an inheritance scheme between the base and the final child (for example Entity<---WalkingEntity<---Human).</p> <p>Don’t get in the habit of stuffing tons of behavior towards base classes! As the behavior is spread out amongst more classes, it’s very hard to track the program flow, and more difficult to anticipate the effects of changing something.</p> <p>What’s an alternative way to get code reuse? You’ll often hear “use composition” floated. Instead of a deep inheritance chain, you get your reuse via attributes- in the case above, Human would derive from Entity, and then have, as an attribute, an instance of a Walking behavior class. Now, the flow can be more easily tracked at the Human level…there’s no hide and seek with virtual overrides. Components are nice because unintended side effects are low, and program flow can be traced at the Human level more easily.</p> <p>That being said, in practice I use both. There is some functionality that is *so* widespread and *so* predictable and *so* self-contained that stuffing it in an intermediate class in an inheritance chain makes sense. This is more a walling-off intent- I know that 100% of the children that derive from that class will not override those methods.</p> <p>Finally, I’ve found a place where neither inheritance nor composition does the trick- AI. I use state machines for AI, and I’ve found two annoyances. One, a lot of boiler-plate code is needed. Two, it’s difficult to get reuse out of state machines. To solve the first problem I rely on macros (yes, #defines, to a hilarious extent- whole state classes in a single macro, and hooking up the states to their owner’s callbacks). The second problem, reuse in state machines, is interesting. There doesn’t seem to be a good solution without destroying the flow. For reuse of actual behavior, I mostly fall back on functional programming. I go oldschool and create functions with no side effects…they operate solely on data passed to them by the AI state execution, and they live independently of everything else. This way, to decipher an AI state’s behavior I at most have to remind myself what those functions do.</p> goathttp://www.blogger.com/profile/05707356566945919856noreply@blogger.com3tag:blogger.com,1999:blog-7948481454266702687.post-83630820732714404152012-07-06T16:44:00.001-07:002012-07-06T16:44:19.499-07:00The benefits of building your own game engine and tools<p><a href="http://twitter.com/#!/Jonathan_Blow/">Jonathan Blow</a> (developed Braid) recently tweeted that building stuff yourself is the way to go, time and money permitting. It was nice to hear him chime in, as those with strong opinions usually don’t have a game to back it up (hint…don’t listen to me!!).</p> <p>Here’s how having our own tools/engine has been useful so far:</p> <ul> <li>We “own” it</li> <li>We know how it works</li> <li>We can enhance it quickly (a single tool programmer working on exactly what is needed is better than a team of tool programmers trying to satisfy every possible use).</li> <li>We can fix bugs in it quickly</li> <li>Customization for the type of games we hope to make is a priority</li> <li>User interface fits our preferences</li> <li>Feels good- morale boost.</li></ul> <p>The drawback is time and money. One-time fixed cost in my humble opinion. Don’t take my word for it though. Up next, tool shiznits…</p> goathttp://www.blogger.com/profile/05707356566945919856noreply@blogger.com3tag:blogger.com,1999:blog-7948481454266702687.post-56005668571578522922011-11-06T09:30:00.001-08:002011-11-06T11:17:03.233-08:00Smart pointers are dumb<p>C++ requires one to manage heap memory. Memory management can be tedious and error-prone. If different things reference this memory, and you de-allocate the memory without someone knowing, bad things can happen. If you forget to de-allocate the memory, you have a memory leak.</p> <p>One solution is to use smart pointers. They let a programmer use similar syntax as normal pointers, with the benefit of memory being automatically cleaned up when nothing references that memory.</p> <p>What you’ve gained by using smart pointers:</p> <ul> <li>Anxiety reduction as you believe you are insulated from having to think about memory management</li> <li>Potentially less typing</li></ul> <p>What you’ve lost by using smart pointers:</p> <ul> <li>Stuff is now happening behind the scenes, but the syntax looks as though nothing is happening behind the scenes. Operators are overloaded. Evil is in the air!</li> <li>The timing of memory de-allocations is implicit. Hidden both in time and in the code.</li></ul> <p>Normally I’m fine with memory management being done behind the scenes. Our tools are written in C#, a language with a memory manager built in, and I could care less about memory. Tools can be memory hogs to a certain (certainly huge) extent.</p> <p>However, our runtime game needs to care. I want the easiest, most transparent way to manage memory. </p> <p>To ease memory management in C++ I do the following:</p> <ul> <li>Memory allocations using “new” are only allowed when a chunk (or level) of the game is loaded. Not frame to frame. Likewise, de-allocations are only allowed when a chunk (or level) of the game is unloaded. </li> <li>I use a naming convention for class attributes. An “m” prefix means member, an “mp” prefix means a member that is a pointer, and that the class is responsible for allocating and de-allocating its memory. Finally, I use “mpe” for member pointers for whose memory the class is responsible for neither allocating nor de-allocating. The “e” means external.</li> <li>I use simple macros to ease the typing related to allocation/de-allocation. </li></ul> <p>So, I centralize (in time) allocations and de-allocations, choose names that immediately identify a class’s responsibility, and wrap some of the clunkiness (such as checking for null before a de-allocation, setting to null after a de-allocation) in macros.</p> <p>Some people use memory pools to achieve centralizing allocations and preventing a ton of frame-to-frame allocations. If I weren’t the only programmer on this project I would research this. As it stands my solution is easy to implement and transparent, and I can’t waste time researching “best” solutions to a problem that’s under control.</p>goathttp://www.blogger.com/profile/05707356566945919856noreply@blogger.com2tag:blogger.com,1999:blog-7948481454266702687.post-78175842438437517992011-11-06T01:19:00.001-07:002011-11-06T01:19:07.878-07:00Programming shiznits? Oh no he di’n’t!<p>I view programming as a tool, and am not interested in it for its own sake. A lot of people get hung up on being evangelists about certain styles. There are always tradeoffs, and if you’re the only programmer on a team you better value time-to-implement and ease-of-understanding-for-you over most anything else. That being said, reusability is still important as you hope to be lucky enough to make more than one game.</p> <p>The runtime stuff is being written in C++. I’m not sure if there’s a “best” way to organize code when making a game. I found it nice to break out stuff as follows (each a library except for the executable):</p> <ul> <li>Core - Platform-independent stuff (vector/matrix and file/memory parsers, some macros to ease memory allocation/de-allocation), and interfaces for stuff that will be platform specific.</li> <li>Platform specific – provides concrete implementations to stuff like audio, input, windowing, error handling, timer. It adheres to the interfaces laid out in Core. The name of this library contains the platform (for example MS_Windows).</li> <li>Game engine – game-independent and platform-independent framework (entities, messaging, collision, animation, scenery, spawners, path-following, simple scripting, lighting, triggers, asset management, camera (and other generic entities and some AI helpers).</li> <li>Game – game specific code</li> <li>Executable – small as possible</li></ul> <p>Dependencies</p> <ul> <li>Core – depends on nothing</li> <li>Platform specific – depends on Core</li> <li>Game engine – depends on Core</li> <li>Game – depends on Game engine and Core</li> <li>Executable – depends on everything, but care is made to have the least amount of code here as possible.</li></ul> <p>Everything other than “Game” and “Executable” are meant to be reused from game to game.</p> <p>Coming soon, why I think smart pointers are dumb.</p> goathttp://www.blogger.com/profile/05707356566945919856noreply@blogger.com2tag:blogger.com,1999:blog-7948481454266702687.post-71532411746265390032011-11-01T21:06:00.001-07:002011-11-01T21:06:07.932-07:00Just another full-time indie game developer…<p>Here are my thoughts, one month in of full-time work:</p> <p>Cats are weird. We have two, and full-time exposure has swung my opinion from “furry guys with personality quirks” to “if these guys were any bigger, they’d have made a double-team attempt on my life by now, quietly munching my remains with cold dead stares.” That’s the same expression they wear when eating everyday kibble, by the way. I now have to coddle them each day less I get ambushed due to some random reptilian synapse firing in kitty #1.</p> <p>This is fun. I love the magnitude of work and the challenge. Our tools and our engine are our own, which was the right decision. We don’t have a product yet, so don’t listen to me. I trust my intuition though, and having an in-house engine and tools to fondle and nurture is a blast.</p> <p>This was a great decision. Life’s about making rash decisions, failing, being humiliated, and slinking back to whatever soul-crushing “real job” you came from while that guy you hated re-enacts the “they’re reeling ‘em in!” scene from Shawshank Redemption.</p> goathttp://www.blogger.com/profile/05707356566945919856noreply@blogger.com0tag:blogger.com,1999:blog-7948481454266702687.post-90970718764368811732011-10-14T15:30:00.001-07:002011-10-14T15:30:19.979-07:00Catching Up<p>The main plot-points since finishing Unchosen Paths are I now have 2 kids and I’ve just left my job to pursue the game stuff full time. More to come.</p> goathttp://www.blogger.com/profile/05707356566945919856noreply@blogger.com10tag:blogger.com,1999:blog-7948481454266702687.post-71677861184542207112011-10-14T14:21:00.001-07:002011-10-14T15:22:39.420-07:00Back from the brink….<blockquote></blockquote> <p> </p> <p>Stay tuned…</p> <p align="center"><a href="http://lh3.ggpht.com/-1r-mDUaG8_U/Tpin4DAS8YI/AAAAAAAAAlo/SpYAJd-FN_Y/s1600-h/widescreen_addition_ss_01%25255B10%25255D.jpg"><img style="background-image: none; border-right-width: 0px; padding-left: 0px; padding-right: 0px; display: inline; border-top-width: 0px; border-bottom-width: 0px; border-left-width: 0px; padding-top: 0px" title="widescreen_addition_ss_01" border="0" alt="widescreen_addition_ss_01" src="http://lh5.ggpht.com/-iWLdImoHSik/Tpin5HnEbMI/AAAAAAAAAlw/JIlQh8dHNUo/widescreen_addition_ss_01_thumb%25255B7%25255D.jpg?imgmax=800" width="352" height="192"></a></p> Joshuahttp://www.blogger.com/profile/10155409131938284592noreply@blogger.com2tag:blogger.com,1999:blog-7948481454266702687.post-47175794647179880072010-03-05T04:02:00.000-08:002010-10-08T12:32:24.466-07:00UPDATE<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh-rmGmcmKLO5Ldb-vloXHE5wcDOwCVW5vBh82yDRcFYuPrgt_4AMw548UfaN_RN8EMroV8seTkhy3UJhNsYn13qCRiE8-iVvSairBrReRXVyceB9N-4kpXvCP0hVVPMl6p-31cCaidfJo/s1600/cvAventures_rebirth.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh-rmGmcmKLO5Ldb-vloXHE5wcDOwCVW5vBh82yDRcFYuPrgt_4AMw548UfaN_RN8EMroV8seTkhy3UJhNsYn13qCRiE8-iVvSairBrReRXVyceB9N-4kpXvCP0hVVPMl6p-31cCaidfJo/s1600/cvAventures_rebirth.png" /></a></div><span class="Apple-style-span" style="font-family: Arial;">Castlevania Adventure Rebirth is nice. While parts of certain levels are repetitive, beggars can't be choosers when non-handheld 2D Castlevania is in short supply. The music is great, and mixed nice and loud with respect to the sound effects.</span><br />
<div style="text-align: center;"><span class="Apple-style-span" style="font-family: Arial;"><br />
</span></div><div style="text-align: center;"><span class="Apple-style-span" style="font-family: Arial;"><span class="Apple-style-span" style="font-family: 'Times New Roman';"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEivr1RUmg_XUjhQAxLX4k-EqLvK3OJ2ETxDZXamHM7WWF6_zRXJJn92qWaTQgK1XTvWwXaeb_U_5hCbyPcGBUbyo3IoUYxNv5UeJ_MJ1Zly2v3fVCPfRBdeP9UF1sH1Kehm04K-JxxcsxM/s1600/castlevania-rebirth-2.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="240" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEivr1RUmg_XUjhQAxLX4k-EqLvK3OJ2ETxDZXamHM7WWF6_zRXJJn92qWaTQgK1XTvWwXaeb_U_5hCbyPcGBUbyo3IoUYxNv5UeJ_MJ1Zly2v3fVCPfRBdeP9UF1sH1Kehm04K-JxxcsxM/s320/castlevania-rebirth-2.jpg" width="320" /></a></span> </span></div><span class="Apple-style-span" style="font-family: Arial;"><span class="Apple-style-span" style="font-family: 'Times New Roman';">--Goat</span></span>Joshuahttp://www.blogger.com/profile/10155409131938284592noreply@blogger.com0