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.
What the hell is a datagram?
Upon learning what UDP stood for, that was my immediate second question. The whole multiplayer aspect of gaming has existed in my mind as the equivalent mix of alchemy and advanced calculus: two things I have zero understanding of. When I decided to test the waters of online gaming, I knew at some point I would have to crack the books and learn a thing or two about how all this stuff works.
Blitz has support for both UDP and TCP, but from my reading, UDP seems to be the quickest and easiest protocol for multiplayer gaming. Unfortunately, it’s one of the lesser documented topics within the community, so learning it is going to be a bit of an adventure.
From my fledgling point of view, the trouble lies in quality and latency. Quality, in the sense that UDP is an unreliable protocol with no inherent handshaking nor quality of service. Latency becomes problematic due to the fact that because there is no handshaking, the UDP stream is not guaranteed to come in correct order (or at all.) The good thing is, you can always program the missing functionality on your own, to fill whatever gaps and pitfalls the game uncovers. For me, this is perfect because 1. it allows me to get framework netcode into the game, and 2. it provides me with the opportunity to develop my own structure to fit my needs.
I’ve forged ahead into the arena starting with a simple 2 player chat ‘game’ that consists of each player moving a red or blue box respectively, around the screen while chatting to each other. If I can eventually get that working, then the multiplayer basics of my floating platform game should be attainable. Starting with the chat portion, I modified some open source UDP code to accept up and down stream communication and after a bit of tweaking, I got my program working from my desktop to my notebook. A joyous, but fleeting moment of triumph indeed.
Now, whether or not this will carry over to the internet with another, real live person on the other end remains to be seen. Hopefully, one of my late night friends, *ahem*, will be online to test this out with me…
I’ve been jumping back and forth between 2 options, trying to figure out which will work best. And by ‘best’ I mean, which one will present me the best opportunity to actually finish a full game. The conundrum of sorts I face is how to balance these two needs: I need to finish a game and I need to be proud of the art. Sadly, in my experience those two needs are diametrically opposed, locked in a constant deathmatch that always ends in a stalemate.
So I chose option 3.
I built out this very nice map, even started texturing it. It had a good mix of strategic and vertical challenges and I felt really played well. However, once I got into production, as I so often do, I realized that it was something I would never be completely happy with. There was actually a point where I imagined myself working on it a week later and asking myself, ‘ok, when is it time to say it’s finished?’ It was so literal and grounded that I could conceivably spend forever tweaking it. And that’s the part that resonated the most and the reason for why I stopped.
Instead of agonizing over the decision, I cracked out a piece of paper and immediately got back to the drawing board (so to speak.) I spent about 5 minutes sketching an abstract map and came up with a very unique and different concept unlike anything I had designed before: Floating platforms in the sky. Right, wtf, that’s not original at all! Agreed, however, for me, it marks a bold step in a new direction.
My rationale was simple: make something that looks good but is easy to tweak and build on top of. I’ve wasted so much time in the past trying to come up with these very solid, very realistic structures that I let myself get lost in their construction rather than focusing on their utility in the game. The game should take precedence over the art, aka, gameplay over graphics. I should be making these maps with the intention of completing a game with them, as opposed to making these maps so I can say, ‘wow those are really great maps.’
So with that, I’m about 40% into my new map and should have a screenshot or 2 to show very soon. Gameplay is a snap to tweak since everything is loose and, well, floating. Hopefully, this will be the impetus that I’ve been searching for.
2am is my cutoff. It’s the latest I can stay up on a work day and still remain functional the next day. When I was in college, 3 or 4 am was no big deal even with 9am classes. I’d trudge to school, half-awake and sleepily take notes or develop negatives and no one really cared as long as I showed up. Much later now in the real world, 2am means I get five and a half hours of sleep, which is the bare minimum for me to have a useful day. While I can appreciate the thought process behind structuring your day like Michal here, unfortunately, this doesn’t work for people who have children and jobs that keep them from home for 10+ hours a day. At this point now, I don’t even start working until midnight, which gives me a whole 2 hours before I have to turn it in. Part of the reason why I never seem to finish anything is the fact that when things aren’t clicking (which they usually aren’t in the 18th hour of being awake) it’s real easy to get frustrated.
On the contrary, last night was one of those nights where everything clicked, so much that by the time I realized what was going on, it was just past 2am already. And I was wide awake. Typically, I spend the last 30 minutes of my night shaking my head trying to fight off impending sleep. There’s been times where I’ve dozed off while coding and actually typed out what I was saying in my dream. I know this cause the next day when I opened up my project, I had some very curious code that wouldn’t compile…
I didn’t fall asleep until somewhere around 3:30, so that means 4 hours of rest. On a friggin Tuesday. And while that is annoying and frustrating enough, the worst part is I was on a roll last night and I could have got a ton accomplished in that hour and a half I spent tossing around in bed listening to my dog snore.
Yawn.
Long ago when I first started using Blitz 3D, I learned how to import animated meshes from Max using the excellent B3D Pipeline. My process of learning has mostly been trial and error, mixed with hints and tips from informative forum posts. While that is the most effective way for me to pick new stuff up, unfortunately, either by my own doing or through mistakes by others, I learn how to do something incorrectly. Or more precisely, incompletely.
As I mentioned in my previous post, I needed to do some more research on how Blitz handles skeletal animation and singling out specific bones. This is the part where I tell you, woohoo, I figured it out! Ok, that much is true, but the more entertaining part is about me slapping myself in the forehead when I realized how I actually already knew the answer to my own question, I had just being doing it wrong all this time.
Blitz has a very useful function called getChild() that lets you recursively search through an imported mesh for a specific object. In the case of animated skeletons you could use:
r_hand = getChild(my_mesh, "right_hand")
and it will assign the handle “r_hand” to the bone named “right_hand” in your mesh. With that, you can do neat stuff like parent an object to the character’s hand for instance.
The part where I screwed up was not understanding that you were only assigning a handle to be used to call that specific object. While I was partially correct in my prior usage, I was under the impression that getChild() was only used in concert with extractAnimSeq() to pull keyframes from the animated mesh and didn’t realize the versatility of the function. The beauty lies in the fact that you can assign multiple handles to multiple objects within an imported mesh. In the past, I always exported out separate meshes when I needed to reference them individually. As you can guess, this became a hassle. This was a big problem with animated characters as I need to have individual control over sections of the body. I have to be able to assign different animation cycles to the upper body versus the lower body, so I can have the character shoot while running. Otherwise, I’d have to make separate animations for each weapon doing each action.
So at some point the other night, it finally clicked and while I was both relieved and excited, I couldn’t help but feel a bit annoyed with my ignorance. I realize it’s part of the learning curve, but still it’s tough to swallow some time. The end result is the important part tho and now I have complete control over my character. I seriously feel like a great burden has been lifted off my shoulders now that I finally get it. Now I can concentrate entirely on animation and not worrying about how I’m going to get it all to work. To be honest, that’s been one of my major stumbling blocks in game development. I’ve never struggled with the actual art production, but rather with the implementation. Hopefully, this will lead to bigger and better things.
