• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
  • entries
  • comments
  • views

About this blog

Even more clever description, but really it's just slightly wordier.

Entries in this blog


Space Money

I got a little reprieve from parenting duties this weekend, so here's the latest build of the PSP demo. I'm using Visual Studio to code and build for testing on Win32, then compiling against the PSPSDK and uploading to the real hardware. So far no major problems have come up, although it would be easier to have display lists working for using the standard bitmap font routines on the PSP.

Here's a video of an attempt to break the logic.

Currently it uses some Othello/Reversi logic to swap cube colors, and that mode of play is pretty much complete except for an exit/win condition. Hopefully I'll get more time to work on this and add some new features.

My new job affords me a couple of interesting perks. One of which happens to be a decent library of games along with their respective console hardware. After talking to my cube neighbor, the local PSP aficionado, I became interested in the PSP homebrew scene. So I checked out the company PSP, (which luckily is a 1.5 firmware rev) and got to tinkering. With the dev tools set up and a fresh compile of the PSPGL lib, writing 3D code for the PSP is a snap.

I have an idea for a turn based game, and if time allows I'll develop it further, but for now I'm content to have gotten something running on hardware that's a tad more exotic than a PC/Mac.

So I took a chance and upgraded my Ubuntu installation from 5.10 to 6.6. And by upgraded ladies and gents, I mean a clean install, as there truly is no other way to install an OS. Maybe it's just that I'm fractionally more familiar with it, and conscious of the fact that I'm going to HAVE to open a shell to issue a half dozen commands, but this install was by far the quickest from blank partition to working development environment.

The default setup provides a good base, and the subsequent updates were painless. I still dislike searching through innumerable packages with Synaptic, but and once the basic dev tools (gcc, g++, headers, etc) were installed the only imperative that remained was the video drivers. Been there done that, wrote it down. Nvidia driver install was not an issue, but that's not to say it can't be greatly improved upon.

After the miserable failure of MinGW Dev Studio to do anything whatsoever on 5.10 without crashing, I had downloaded and installed Borland's C++ IDE. Atrocious interface aside, it worked. But before I went that route again, I wanted to give Code::Blocks a try. Last time an install would have required compiling it from source, which is not something I was (or am) willing to sacrifice any of my time for. Let's face it, life is too short and my family is too important for me to waste time compiling something which amounts to a trivial pursuit.

I looked... lo and behold, there was a recent nightly build in a Debian package. What happened next was beyond my wildest dreams. I downloaded it, the Debian package installer opened, Code::Blocks landed on the hard drive and was added to the development tools menu. I opened the IDE up, converted a simple Visual Studio solution and the thing just worked. Amazing.

Suffice to say I'm impressed, as it basically Just Works(TM). This environment is very livable if not slightly more compelling than it has been in the past. Mind you, I still think Linux has a 'slapped together' feel about it, but for now I'll say that if I HAD to work with it, I would consider it far less painful (maybe even enjoyable) than it has ever been.

File Nostalgia

Have you ever gone into a massive collection of folders and files to organize them, only to find something you'd forgotten about? That happened today when I ran across scans I had made of a card box sometime in 1998.

I had scanned them to learn texturing/material application in 3DS Max, but somehow they got shuffled off into nested folder oblivion. So I cleaned them up and threw them together and voila..

They never made it into 3DS Max, but that's only because I became acquainted with Maya in the meantime.
So this weekend, after a bit of hacking, I've got an x86 machine running Max OSX. It's truly a weird thing to behold, having both a shiny aluminum G5 chassis and a semi-plain Dell Dimension case sitting next to each other running the same operating system.

Previous builds of my game framework using Universal Binaries on the G5 presented no problem, but for some reason or another they just weren't happy on the P4. After shuffling the project across, the x86 builds were up and running in a native configuration.

At any rate, defintely worth a day of effort to see something that almost nobody thought would ever come to pass.. a Mac OS on PC hardware.
Recently my friend Nick (Laz on the forums here) happened on a run of bad luck. I an act of spite against his dear friend Murphy (and his Law) I bought for Nick one Sapphire Radeon 9600 of the AGP variety. Now it seems Nick's fortunes are becoming a bit more upbeat and no longer needs this bit of friendly charity.

So here's the deal. I fully intend to give this video card away. It's nothing major but here are the specs:


Now I'd like your opinions on how to give this away within the GameDev community. My first thought is to just let it go to some random respondant, but given the unique position of having alreay made an investment, I thought of something else. How about a raffle? Not for the sake of recouping costs, but to perpetuate this kind of giveaway. I'm not really interested in running a contest, as there are a few of those already. A raffle could have a much shorter run, and depending on the amount of entries could allow for a fast turn around for the next one. Your thoughts??


GDNet subscription unpaid?! What's going on here?! Seems something happened around the way at PayPal, and they discontinued my subscription. Thanks alot PayPals!

Had a rough patch over the last few weeks. A childhood friend of mine passed away, and the means by which this happened I'll leave at unnatural causes.

But work goes on in the 'Game Project Referred To In The Journal Of Schmedly'. The designs I have in mind are largely based around recreating certain classic arcade games, which lend themselves easily to a tile based structure, but how to handle that in 3D? How about a 3D tile engine? Given the fact the game designs incorporate forced perspectives, it seems natural to do it this way. It also makes culling extremely simple. Anyway, a shot of the world editor affectionaly known as Schmedit.

Currently limited to loading/saving and basic editing. The editor mostly needs work in the editing controls (note the hacky buttons) but I also need to figure out a more robust way to handle the tile connectivity. At this point it only supports branching nodes and will simply overlap when nodes are connected in a loop.

Not much for words today, but completed a rewrite of the original Maya exporter. All the important data except for animations are extracted from the DAG. The mesh and joints are exported together, all that remains is finishing the Quaternion class so I can implement animations. Neat.


Skinned meshes

This week is starting off rough.. feeling rather sickly today. Hope I don't give it to the rest of the family. At any rate, journal readers love pictures I've been told, so here's the latest, exporting joint heirarchies for animated skinned meshes.

Still very much in the works, but code reuse is at an all time high here. I had written a simple .rtg model viewer ages ago, so the basic framework was used for the new viewer.

Here's a shot of the original skeleton in Maya, and loaded much the same way into a very slim version of the engine.

More as this progresses...


It's alive!

Cue Oingo Boingo's Weird Science!

Although there's a problem with the system timing calls, which I'm trying to figure out... everything else compiled and ran perfectly. Actually there was one namespace collision that X refused to give up on, so I renamed my object, which ended up being more accurate.

As suggested by stormrunner (and somebody else a long time ago) I used MinGW Studio and it handled everything great. I had to add newlines to the end of each file to remove all warnings but it was worth it to see a clean build. Only thing wrong with MinGW Studio is that it doesn't allow for nested folders inside the file pane. It will access the files in nested folders without issue, but it just doesn't give you the option to create a folder structue inside the IDE. Eh, it looks a little messy, but maybe a fix will come along at some point.

Oh well, I get to marvel at a little coolness now.. because to me it's great when something 'just works.'

EDIT: Timing calls fixed, but still not reporting the initial interval as I'd expect. Truly weird science!

The Linux, Reloaded

You recant your previous declaration, turn around and 'try one more thing.' You get a small step closer.

So the Linux endeavour continues.

I *can* build the game with Anjuta running on Ubuntu, but... I *can't* build the game. You see, somehwere along the line, somebody chose to make it hard to include and build source from multiple folders. Within the confines of this Linux IDE that is. So you see this is why I *can't* build my game. I refuse to reorganize all the source files into one directory and rewrite all the include statements. And why should I? Visual Studio and XCode have no problem dealing with this structure.

This all sounds like more bitching and moaning of course, but what it boils down to is that intuition alone (given previous exposure to other IDE's) should be enough to make this build happen. But it's not. My refusal to touch a makefile certainly limits the available options to compile in Linux, but that's really not my point. If Linux is ever going to cater to a wider audience (like certain religious pundits predict) it's going to have to have 'stuff that just works.'

Why do I bother?

It seems fair to say that each time I want to attempt developing with Linux, I have forgotten all the pain it caused the previous time. Once again I got the urge, and once again I'm left jaw agape, completely befuddled and wondering why I'd put myself through *THAT* again.

Sure, it feels good having my project running like a charm on both Win32 and OSX, so naturally I thought, "Well I'll give Linux a try again. People say Ubuntu is soooooo good these days. Hmmm, okay that settles it."

While I admit the basic install for the OS was pretty painless, the fact is that nothing for development was installed by default. Only the common desktop apps were to be found. So I gave in, yet again, and started the tedious task of tracking down all the crap I'd need.

Much later, after all the googling and apt-get'ing I should have had everything. Bear in mind that I rather dislike using the commnand line. Some people love it, but I swear somebody once told me this is the twenty first century, and in my opinion, I should have a GUI to do everything. Typing poorly named commands and even worse package titles is just so 70's style. But I digress.

The bright spot in using all that junk was Eclipse. It took three steps to have it running...
1) Download archive
2) Unpack archive
3) Double click eclipse icon
It doesn't get any better than that in terms of expected results.

Okay, let the real pain begin. Next comes endless lib searches and all sorts of nasty linker errors from the eclipse C/C++ perspective. Sigh, I'm thinking to myself, "I could solve these problems with little to no effort in Win32 or OSX." But an hour later, even after I tracked down all the function containing libs, I sit here with a nebulous *** [App] Error 1. That kills it folks... Screw Linux. Again.

Last time it was Mandrake and KDevelop that refused to work correctly. The time before that it was ummm... Mandrake and Anjuta. The time before that it was RedHat and something-or-other. I don't even *like* Linux in the first place for crying outloud!

For a few shining moments two days ago, I thought it would be cool to have my game running on Linux. Now, once again, I remember why I chose NOT to continue that effort many times before. Sheesh, if I was going to throw away two days worth of my free time on something that produced nothing, I'd have plopped myself down in front of the TV.
Alright, I feel like I've accomplished enough to merit writing in my journal. I'd also like to get some feedback on some design thoughts I have.

The scenario:

Working on a little dungeon crawling project with a forced perspective (psuedo isometric). What I'm attempting to do is use a series of meshes to represent the world, connected by portals. When a world mesh is present in the scene, it's subdivided by a quadtree. Each quad node holds an index array for rendering that chunk of the world.

The choices:
My first thought is to provide a 2d collision proxy which represents the collidable floor of the dungeon. The other alternative is to use the world geometry. The 2d proxy would probably be faster since it would contian less triangles.

The path:
I've got a Maya exporter to handle all my pre-processing needs, so I can generate the 2d geometry at export time. With that in mind I could also define a world file structure to arrange all the world mesh/portal data beforehand.

The rest:
One thing I'm still a little fuzzy on is how to handle the actual collisions themselves. Not the testing mind you, but how to relate the current triangle of collision to it's neighbors. I guess you'd say I need a little advice on how best to handle the grouping and testing of the world geometry.

Again, feedback is very much welcome and in fact, encouraged :)

Schmedly - out
Sign in to follow this  
Followers 0