26k.dev

So this post yesterday by Mark Sibly has the Blitz community all excited, and rightfully so. The promise of a modern 3D engine with the same mixture of ease/power that exists in the current B3D engine is a dream that a lot of us have had for awhile now. There’s a couple megaposts in the forums now, with people going back and forth about wishlists and whatnot. Immediately, all I cared about was built in support for things like shadows, reflection, shaders, etc. However, the more I’ve thought about it, there’s def some additional non-graphical upgrades that would be incredibly substantial. Cross-platform compatibility would be tremendous for the community, as right now we’re unable to publish for anything except Windows. Being able to export to Linux would be significant for me personally, as I’ve had a few conversations with people lately about building games for proprietary hardware.

Going back to the visual side of things, obviously an upgraded graphical engine is what’s going to bring in the customers so I assume the majority of the focus will be in this area. The big one for me is shadows. I’ve lamented about this in the past, most recently with ERH. To be able to add a light (either hardware of software) to a scene and define it’s shadow casting properties in a single line of code would make my life easier in so many ways I can’t even begin to try and express here. I have maybe 20 or so mockups for games I’ve done in an 3DS Max that never make it to the coding stage because the shadowing system would be impossible in the current engine.

Interoperability between B3D and standard shader languages would be another huge upgrade for me as well. Things like reflection, refraction, and other common things I use everyday in 3D animation would finally be made accessible for my games. The key here is the built-in support, knowing that I won’t have to code one-offs and hackjobs to get someone else’s hack maybe working in my game.

The promise of an end of the year availability sounds exciting but is most likely wishful thinking. Nevertheless, it’s encouraging to know that work is being done on my engine of choice and thus the necessity of having to learn a new language very soon is significantly less now. Looking forward to more news on the matter.

Looks like the next TIGSource competition has been announced, this time it’s for procedurally generated games. I’m really excited about the theme, as I think it would be perfect for a shooter idea I’ve had for awhile but honestly time is going to be a major concern. With ERH, I put some stuff on hold and while I was able to catch up to some extent, it puts an incredible strain on my workload to toss another project on the burner.

Without going into the psychological reasons why, one of my ultimate hatreds and frustrations in games stem from gameplay that heavily requires extensive memorized or predictable routines to be performed. I can tolerate it of course, but the old school gamer in me still craves pure, twitch action. The appeal of procedural content to me is creating a game experience that forces a player to always be on their toes. With most games, no matter how hard a section may get, you can always break down the fourth wall and remember that a game designer somewhere created this challenge with a specific solution in mind. Conversely, I would love to provide an experience where a player can go into a battle and honestly not know whether or not they can survive the challenge. There’s something to be said about fighting valiantly against inescapable odds and not backing down against certain death, something that doesn’t really exist in modern games today. If nothing else, I would want to create a game that provided that exact opportunity, while wrapping the player in pure, unhinged action.

Nothing much to report, as I mentioned before I’m still trying to make up for lost time on other pressing matters right now. I’m hoping in about a week I’ll have something significant to report, as I’ve been tossing around a few ideas and working on some prototypes in my very limited spare time.

Over the weekend my daughter was kinda acting up and it was really hot outside, so I was looking for things to do to calm her down. I remembered in the past that she really dug watching me play the NES so I hooked it back up (not sure how it got unhooked…) and fired up a few games. She sat transfixed with Zelda but then she started rummaging through the carts (she plays with them like blocks) and picking stuff for me to play in increments of 1-5 minutes. I had to rush through some of my better titles until she finally settled on something she really liked: Karate Champ. If you’ve never had the distinct displeasure of playing this little gem, I wholeheartedly encourage you to continue down whatever path you’ve chosen in life that has kept you away from its existence. I don’t like to rail too much on games, knowing first hand how difficult they are to make. Especially with older titles, the hardware and technology restrictions were incredible and it’s a miracle that people were able to create some of the greatest games under such adverse conditions. However, very little of that applies to Karate Champ. There’s plenty of crappy games out there, but it’s torture being forced to settle on such a lackluster port when so many classic games are just within arm’s reach. However, The Taskmaster would have nothing of it, as my daughter made it clear that Karate Champ was the game to be played that afternoon.

Point.

I have to say, I’m really enjoying this whole game development thing :) 2133 people have played ERH so far and from the feedback and response I’ve received, it seems like people are really enjoying the game. Before ERH ever existed, way back to the very first day I started down the path of gamedev, I always told myself I just wanted people to play and enjoy my games. I realize I’m never going to make any money from this venture and that’s completely fine. It’s been a great learning experience throughout and now to have something completed and enjoyed by others, the whole thing is just really rewarding. So thanks again to everyone who has played ERH, can’t wait to get something new in your hands!

Of course, that will definitely be later than sooner with the amount of things going on right now. ERH made me temporarily push a lot of things to the back burner and now I’m trying to attack multiple fronts at once. Whatever I decide to do next tho, it’s going to be small and simple. I just don’t see me having the time nor energy over the next couple months to take on anything larger at this point. Whatever I do tho, I will try to post more images when I update. Looking back on previous months, this blog is just a giant block of text (now including this post).

Also, thanks to Sciere for adding ERH to Mobygames. It’s like a real game now!

My entry for the TIGSource Video Game Name Generator Competition is finished! Get it here:

Download Enraged Rocket House
3.4mb | requires a somewhat decent 3D card

YouTube Gameplay Video

In celebration of my first, actual, completed game I decided to write a short Gamasutra styled postmortem about the process. Hopefully that makes up for my month-long posting dry spell.

About The Game
If you’ve followed this blog for any amount of time, you probably know I have a lot of trouble sticking with and ultimately completing my games. I’ve touched on a variety of reasons/excuses for why this trend has been so hard to break in the past, but usually it came down to time and focus. Too little or too much, from each category. So awhile back, I promised myself that I would try to break the pattern by entering a competition. I figured that the deadline, the specific rule set, and the public exposure would help keep me on the path and ultimately finish a game. Seems like I was right :)

Enraged Rocket House (ERH from here on out), came up on my 20th or so try with the name gen. I had a Google Doc file open and was just copying and pasting titles I liked that came out of the VGNG. When ERH came up, I instantly thought of the Simpsons episode where Mr. Burns and Homer get trapped in a cabin after an avalanche. I even used the quote on my entry page. I spent about a day going back and forth between a couple different scenarios but ultimately settled on a semi-serious vertical shmup where the ERH fights against the evil Bank looking to foreclose. I thought it was topical and could throw a little personal experience into the storyline (we’re selling, not foreclosing…) to make it work. After a few days tho, I felt making a shmup would take me too long to complete since I was unexperienced with the genre, so I went back to familiar territory. After a few iterations and some inspiration from one of my favorite classics, Yar’s Revenge, I settled on a delivery/chase game.

What Went Right

1. The Rocket House
The idea of a rocket house made perfect sense to me the second I pulled that title. It’s a house with a rocket in it, brilliant! Once I settled on the name, I drew about 2 or 3 tame sketches before saying screw it, I’m giving him a giant, snarling mouth. I immediately started modeling and by the end of the first night I had finished the mesh. This never happens for me. Typically, I go back and forth, trying different things revising and revisioning, etc. etc. I’ll attribute it to the deadline, but hammering out the model in the first night was the best thing I could have done. It set a precedent for the rest of the development, as I finished the Ice Cream Truck the following night and the kids a few nights later. I had all the primary models finished within the first 5 days, which meant visually I had something substantial to work with as I started building the code base.

2. All Green
As I always do, I built a task list on Google Docs broken into 3 categories: Code, Art, Sound. I typically write down everything I can think of onto the list, then organize the list by priority. Once that’s settled, I usually do a series of reality checks and finalize my task list. Obviously, the list is fluid and things get shifted/added/subtracted over the course of development. I track progress by leaving unworked tasks in black, in-progress tasks in blue, ‘nice to have’ tasks in orange, and finished tasks in green. If you know my history of completing games, you wouldn’t be surprised to see the majority of my lists never getting out of the black and blue. For the first time ever tho, my entire list was green. I actually finished everything vital and even promoted a few orange tasks up the ranks (I never thought I’d have time to build the neighborhood, so it was orange until the last week).

3. Tasty Treats
I don’t typically rant and rave about my own work, but I love the way the treat gui worked out. The little renders of the 9 different treats came out better than I originally expected and I think really added to the game’s character.

What Went Wrong

1. Form over Function
I’m very proud of how the game looks considering the short deadline and the numerous other real life things I was juggling along with the development of the game. That being said, I spent way, way too much time on the visuals and I feel the gameplay suffered. I realize that the timeframe I had to work in means corners had to be cut, but I spent too much time refining things that had no impact on gameplay, while never fixing things that clearly did. The big one for me is the lack of collision with the kids, knowing people will probably complain about that. I wanted to add things like repairs and restocking of inventory so you could play longer but just ran out of time to implement it to a level I felt was worthwhile. So while the game for the most part looks great, there’s some minor nagging gameplay issues that will endlessly bug me.

Secondly, the game is lacking in the sound and music department. A friend of mine made the little ice cream jingle that plays but aside from that, I was only able to add 3 sfx. Throughout the game, the ERH is completely silent, which to me is a little disappointing.

2. Cleanliness
Perhaps building off of the last item, I felt I wasted too much time trying to make clean systems and functions. I spent about 3 days getting the menus and GUI to animate and behave properly, building a fairly complex and decent animation system. While it’s something I can build upon for a future game, within the scope of time I was operating in, the creation of new technology was probably a bad idea as the power of the system would never really be utilized in any significant fashion. In the end, I should have a little more urgency in my tasks, so I didn’t have to work at a breakneck pace heading towards the deadline.

3. Shadows
The amount of time, energy, and ultimately video ram I invested in giving the game realistic shadows was probably a mistake. It looks nice enough (except the houses), but that’s the last time I bake shadows into lightmaps. Never again. My future games will have at the very least stencil shadows, even if I have to buy a system for them. Ugh. In the end I totally cheated on the truck and kids, just adding blobs underneath them. It’s enough to sell the visuals and probably should have been my system from the onset.

Conclusion
It’s amazing that it’s been over five years now since I first decided to give game programming a try, a long, frustrating road full of pit stops and breakdowns. ERH is by no means the greatest game ever and I’m sure it’s probably something I’ll look back on in 5 years and laugh at, but it’s important to start somewhere and for me, this is it. It’s a fun little game and I’m proud to have something finished and available for other people to hopefully enjoy. This game has been a great experience for me and a boost to my confidence that I can create a good game one day. Right now, I’m looking forward to the next big idea…

Have fun!

I’ve been using 3DS Max since version 2, which seems like an eternity ago (1997?). 7 versions and 3 companies later (Kinetix for life!), I’m still finding new and useful ways to use the program. Well, technically I’m still on v6 but you get the point. About a year ago I decided to look into Maxscript, thinking it might be useful to learn for my work. I dug around the manual a bit and read some online tutorials but for whatever reason, none of it was really sticking so I shelved the idea.

As my programming abilities have matured, I’ve found more and more use for data driven systems. 5 years ago, I would just place everything on screen using randomized functions whereas now I try to build flexible, extensive data sets. Furthermore, I’ve refined my setup in Max and Blitz where I can export a correlating scene with full accuracy. Until recently, this setup has worked flawlessly but on my current project I noticed some z-ordering issues on my exported scenes. The map in question involves a system of clouds that the player can fly through and between, so I really have to nail the aesthetic to pull it off.
Struggling for a solution, I remembered an old article I read in Game Developer about how Microsoft Game Studios made a complex cloud system for Flight Simulator 2004. Re-reading it now, I found it not only to be relevant in terms of the visual approach I’m aiming for, but lo and behold they wrote a customized tool in Maxscript for the artists to export scene data.

After reading that piece and checking out the site of the author Niniane Wang, I decided to come up with my own tool for my game. Returning to Maxscript, this time I had a purpose. It’s amazing how much more you can learn when you have a set goal in mind. After a few hours of figuring out the syntax (typically my number one problem) and some trial and error, I have a fully functional data exporter working with my game, able to write out position, rotation, scale, material info, and custom attributes. The best part is, I don’t have to constantly re-export my scene every time I make a small change, cutting down on time spent waiting.

Maxscript has a boatload of functionality of which I haven’t even scratched the surface and probably never will. But it’s nice to know I have another tool at my disposal and a slightly firmer grasp on how to use Maxscript. Most importantly, the map I’m working on now is starting to really come together, clouds and all.

Busy, busy. To say my time has been diverted lately would be an understatement. Between work projects, home projects, my daughter’s birthday/start of preschool, Jury Duty, and a pair of toilets that needed complete valve replacements, game development has become a distant memory of my past. Hopefully, with all of that finished I will be able to dig back into where I was.

I can’t remember if I’ve mentioned it in the past and I’m way too lazy this early in the morning to search my archives, but I’m currently working on a longer term project with a friend of mine. Details at this point are irrelevant, but I’m still using Blitz to program the various interactive parts. Moving forward, I’ve been researching a different type of play style, something a little bit non-traditional at least in the sense of how you interact with the game. Think Dragon’s Lair. In that sense, relying more on timing than anything else, my primary focus on the game lies in presentation.

I’ve championed the Blitz 3D Pipeline in the past and once again I find myself amazed with the amount of functionality packed into the system. For whatever reason, I never really looked into the Extensions that were available on export, but I’ve found the camera extension to be invaluable on this new project. I can directly export camera animation from Max, even when tied to a complicated rig of control points. Ideally, I will be able to build out the complete timeline in Max and use the exported camera to move exactly how I want through the scene. I should be able to build placeholder nodes to represent and possibly trigger game events, tied together by a simple scripting system. The actual interaction mechanism I won’t get into now, but should be relatively painless to integrate within this setup. But having the freedom to move a camera in a real time scene exactly how I want to, opens up a realm of possibilities I didn’t know were possible. In my professional work, camera animation is probably one of my stronger skills and something I enjoy immensely, so I’m really excited about the opportunity to integrate that into game development.

Believe it or not, I hate writing these vague posts as much as people probably hate reading them. It equates to me sitting at my desk and thinking aloud. With the little amount of time I’ve had lately, almost all of my game ‘work’ has been relegated to the time I spend driving to and from my job. The one benefit of having a long commute is I get in a good 10-20 minutes worth of focused thinking before someone inevitably drifts into my lane and forces me into defensive rage mode. This blog is usually just an extension of that process, where I try to wrangle as much thinking time as possible so that I’m 100% focused going into the night’s gamedev session.

Whew.

Finally, finally got UDP working. Since my first post about it, I’ve made about 3 or 4 simple test apps to try and get UDP chat working. Nothing complicated or interesting, each client opened a stream and whatever text you typed got sent to the other side. No error control, no string control, just raw data. My goal was just to get the network in place and move from there. Well last night revision D, version 2 finally worked. After multiple failed attempts and a couple half-steps, I was finally able to get communication working in both directions. I added a bit of code that flipped the ports around and on the second setting, it worked.

Now I have to go back in and figure out how to both improve the code and to get it working in a practical sense. My first challenge will be to establish a ‘host’ mode for one of the players, and the other player ‘connects’ to him. I use quotes because, there is no physical server role in this setup, both players directly connect to each other. In the host scenario, the ‘client’ will send a challenge packet to the host containing his IP address and some additional identification (username, port, etc.) that once received, will start the game. I want to limit the amount of IP wrangling each side has to do if possible. The more transparent, the better.

My immediate goal is to build a little app that creates the client/host relationship, establishes usernames with chat, and lets each player move a little cube around the screen. If I can get all that working, then technically what I have planned for my platform game should be obtainable.

The caveat of course is time. I finished my two immediate projects over the weekend, but now my long term one has to get some serious attention. Couple that with some of the mundane housework (replacing toilet valves) I put off the last two weekends and you can imagine how I’m feeling pressed for time. Nevertheless, this little breakthrough is exactly the kind of stimulus I need to keep this game moving forward so I’m excited for the next step.

So not too much to report as of late, I’m currently wrapped up in 3 projects (aside from my game) leaving no time for development (nor sleep for that matter). 2 of the 3 should be complete by Sunday and the last is a long term project, so hopefully a window will reopen for me to dig back into this networking code.

After many failed and half-failed attempts to get the code working over the internet, I’m back at square one I’m afraid. I managed to get one-way network traffic to work, but haven’t been able to nail down the problem that is keeping outgoing packets from being sent. I have a different codebase I started to develop that I think will rectify the problem, but it will take me a moment to get back up to speed from where I was a week ago. In principal, this stuff should be working, so I can only assume I’m overlooking or not fully understanding the implementation. In other words, I am my own worst enemy :)

That seems to happen a lot.