Dungeon Master Forum

I know there are several people here who want to make games of their own and thought I would write a little bit about the process as I understand it based on my experience having worked on a few commercial titles myself and having abotu 80% of my students going into companies like Relic, Rockstar, Radical, EA, Monolith, etc..

Game creation is one heck of a daunting task. Not only do you need a good idea, quite often you need a skilled team. You need someone who can make decent art and in many cases you may need more than one. Not just because the task is so large but often artists may have one solid primary skill and may be weaker in others. For example, in many companies, you have character modelers and environment modelers. You have character animators and FX animators. These are all 4 seperate skill sets. The environment people often do the lighting, or they may have a specific person JUST for lighting. And of course.. it all starts from concept design and story outlines, and story boarded events if you have any story.. on and on

That doesn't even get into play testing, coding, interface design, sound design, music..

I'm currently working on a title which has required no less than 4 people. Code, Music, Concept, Modeling. This game concept requires very simple needs as there is no real animation involved and the story is simplistic. The levels contain a fair bit of art but lots of reuse so that we don't need to make too much stuff.

Despite the simplicity and the number of people, it's still taken a year and not a line of code has been writen for the main engine because we needs to be certain of everything that's going in there and it evolves. This is common for games, they can have a preproduction stage of about a year where ides are thrown around and concepts done and redone until the game is formulated on paper first. Then it moves to the computer.

In a few cases though a mock engine has been built to test such as in the game God of War, where test engines were made which were kludgey at best with simple artwork and mock animation.. just to test their theories on how to work the game. How the interaction with controls would work and if it would be fun to play. Once they got all that down the went and reworked all the art and concept to make for the real game and rewrote the whole engine from scratch.

In terms of making games for sale on the independant games market I've discovered that it's often hard to make money. Some are honest and others try the demo and then run to the nearest warez site to download it for free. One company I worked on a game for, it ended up being their first and last game essentially because the company invested so much to make it known and have good production value that they went bankrupt due to the fact it was being illegally downloaded. So keep that in mind when you're downloading the latest and greatest current game from some site.. can the company afford to be stolen from? Not if they are small. If you want to keep small bussiness running, support it. Independant game makers like myself often need to have their day job to support them because the games certainly don't.

If you want to sell your game to a company then you need to think about who to contact, getting rights to your IP so that they can't simply steal the idea from you in a meeting. Make sure your presentation is strong and you can have argument to back up your claims. There have been more than a few small games companies who have made games that went pro. In some cases the company once they buy it adapt the game to run on platforms which are easier to fight piracy on. Xbox live is also a delivery system that supports the independant games companies as they have a delivery system that makes it easier to pay and play the games. You just need to be sure that you do some good testing of it before release. If your company becomes known for too many bugs in your games people will likley stop buying them out of reputation alone.

All in all, what I'm saying is it's hard to do, but it is possible if you know what you are doing, make a clear plan, and account for all possible problems. Pick the best delivery system possible and maybe try to shoot for something that is manageable.

moo

A nice bit of reading there cows. I'm always interested to hear about the inside of the games industry and different people's opinions of it, especially when they raise some good points.

Video games have always been a passion of mine since I was a kid, and from an early age I was certain that the games industry is where I wanted to end up. So when I finished my A-levels I decided that I wanted to study Games Development at university.

However, after studying games dev for 3 years, I've decided that programming a game (or anything else for that matter) is one of the last things I want to do in my life. It's not the long hours / stressful work that puts me off, I just absolutely hate programming. I mean it's horrifically vile in my opinion. I don't know why I dislike it so much, I just do!

One of my lecturers used to work for a games company and eventually formed a company with a few other employees. He tells us all stories of days gone by in the industry, the ins and outs of it all, how arsey publishers can be and such like. However one point he brought up in a lecture is how today, companies can survive and make a profit by not making any games at all, moreso make a part of the game. Middleware and engine creation seems to be where everything is heading at the moment. Unless your company is a large one, making a game engine seems to be unviable. You might as well purchase a license for another engine and refine it to the particular game style you are creating.

We've been taught to develop flexible code that can be adapted for almost any use. Unless you are creating a very specific and niche game, you can more or less use existing code and build on that.

One interesting assignment we had to do last year was to create a prototype of a game with the guys from the Games Design course. Split into groups of eight (four designers and four developers) we were to design a game and create a working prototype / proof of concept in about eight weeks. All we were given was a basic engine we had done all our previous assignments in, VS2005, 3DSMax / Maya, and Photoshop. It was certainly an interesting learning experience, having to divide up tasks and knowing your work was a small part of a bigger picture. What was even more amazing, however, was the wide variety of the games produced with that one basic engine. Different people with different visions can produce massively different things from a single piece of clay. Imagine what we could have done with a bigger peice of clay...

Athough the last two lines in your post cows has never been so true. Unfortunately, during that assignment, we all found out the hard way!

PadTheMad wrote:All we were given was a basic engine we had done all our previous assignments in, VS2005, 3DSMax / Maya, and Photoshop.

Man, I feel for you. What could they possibly have expected you to accomplish with such a disgraceful set of tools? </sarcasm>

Seriously, though, I too have been fanatical about games my entire life. I can even pinpoint when my infatuation began. I was initially inspired by an issue of EGM one of my grade school friends had brought onto our school bus. I used to type up fake magazines about games and consoles that didn't exist beyond the confines of my imagination. Since then I've made game design my element. I don't consider myself an expert on the matter by any means. I've had my own doubts about the validity of pursuing game design as a career — no matter how you slice it, something about making games just feels immature, but it's a multi-billion dollar industry, and that can't be all wrong.

I once thought programming was what I really wanted to do until I seriously pursued it as a hobby, and after a few weeks of full-time grind I became disillusioned by the prospect of coding an entire application. I think it was really more the fact that I was doing 100 percent of the work, including design and graphics. Anyway, the fun part about programming is problem solving, but once all your problems have been solved, you have to actually write some code. While it can be relaxing and thought-provoking, most of it is boring, especially when you get down to stuff like device initialization and, more than anything, error-handling.

Since then I've tried to convince myself that any project, however sophisticated, can be accomplished by a single programmer if you break it down into enough recognizable parts. Maybe this is true; maybe not. Either way, I haven't found the breaking point yet, so I resigned myself to simplifying my projects. The fact of the matter is, even the simplest game is fairly sophisticated when compared to the simple apps most of us start off writing, like batch renaming utilities, color space converters, and so on.

My first real game was not Pong but a four-player rendition of Super Puzzle Fighter. I had the idea one day, and the next day I started work. For three weeks I literally worked at home full-time developing this game, rendering the graphics in 3dsmax and posting them in Photoshop. Twice I had to start over because my design was flawed; in my eagerness I simply didn't take the time to write up a solid design doc. After the second total overhaul, I finally ran out of motivation, and I gave up. Over the years I've dabbled with the project, written down some algorithms, coded some new GUI's, but for the most part it's dead code.

Since then I haven't coded anything more sophisticated than the color space converter I recently made (and revised numerous times) for Adamo. As much as I hate to admit it, I think my coding days are about over. I need a powerful injection of coder fuel if I'm going to pick myself back up. Motivation is what I've been working on as of late. I have a few ideas I really want to make happen.

When my programming fetish abided, I thought graphics might be more up my venue. I'm not a good modeler. Most of my time is spent taking other people's models and lighting them to achieve the best results. I'd be the artist who makes scenery and landscapes rather than characters. I don't know if that will ever change; the more I think about it, the less ambitious I feel about spending my days in front of a computer. I can do that at home. I'd rather get into the world and do something important.

Big ideas come easy. Work does not. Cows is right: the most important tool in finishing a project is knowing how to divide it into manageable parts and conquer those parts in a timely fashion. A good idea will get you started, but only proper organization will get you to the end. I can say this from personal experience. Of course, you do need some motivation now and then to make it through the rough parts.

Tom Hatfield wrote:Man, I feel for you. What could they possibly have expected you to accomplish with such a disgraceful set of tools? </sarcasm>

Forget games - become a comedian(!) Hoho, just kidding, I jest and do not mean to be harsh - I asked for it!

What I should have emphasised was the time constraint, not the tools. It was kind of a wake up call really - we were set with four strangers we'd never met before and had to make a working prototype. Trying to fit that in with the student lifestyle (read: lazy bastards), was just asking for trouble. I really learned something about time and resource management through that experience.

You hit the nail on motivation there Tom. I've tried my hand at other things besides programming: Level editing / creation, mod scripting, modelling etc. and they all end up the same way - I loose interest halfway through and they never get finished. It saddens me really because I have some good ideas, I just don't have the motivation to realise them. Short of my university assignments, I don't think I have a finished project to my name.

Hopefully that's going to change though. I'm retaking the third year of my degree, and with the power of hindsight behind me I can hopefully finish this time. To add to that, I've just ordered a new mobo, processor, RAM and GFX card which will hopefully allow myself to try some TES4: Oblivion modding. I might keep a diary of my progress and update you all on how it's going, which I hope should add to my motivation!

I will chime in my two cents coming from a completely different direction, as I am actually not that opposed to programming, and have been known to enjoy it from time to time. Crazy, I know! I'm not a terribly incompetent 2d artist, though my style tends to be somewhat retro and cartoony-- or perhaps I'm just not patient enough to draw anything realistic. I don't have a clue about 3d modeling, though, and I have a hard time getting excited about things like level design. So maybe it's programming by default.

I have completed a few game projects, at least, in the state of "completeness" that I could play them through, release them, and so on, and see how things went. I don't think that a freeware game project worked on by one person in their spare time is ever going to be "complete" in the sense of a commercial release, because there's always something to enhance or polish, and there are no deadlines that say such a thing can't happen.

My most recent "completed project," or at least in the state where I could release it and get some feedback, was DSB of course-- which I am sure you are all familiar with... if not, you should try it.

Being a reproduction, a lot of the time with DSB was spent extracting, rather than creating: Ripping graphics from DM rather than drawing them myself, analyzing DM's algorithms rather than designing them from scratch, and so on. I think that it still took a fair bit of time, though perhaps not as much as if I had to create absolutely everything myself.

The programming part of it was fairly lengthy, of course, and there were interesting problems to solve. I had never embedded Lua in an application before, either, so that was something else I had to learn as I went. Though I had drawn up my data structures and such in advance, and the fact that I was working with an existing game design meant some of the work was already done, I ran into the inevitable gotchas, too. I will admit that if I were going to do it all over again I would do DSB's renderer in a completely different way, for example.

Recently, though, I have suffered from faltering motivation as well. One thing I do not enjoy coding at all is GUI stuff. The next big thing on my agenda for DSB, and what it really needs, is a graphical editor, but that's a whole lot of coding of clicky boxes changing values, checking to make sure those values are sane, and so forth and so on-- not nearly as much fun as getting your hands dirty with a game engine.

It's been a long time since one guy could write a smash hit game in his bedroom in six weeks http://en.wikipedia.org/wiki/Matthew_Sm ... grammer%29

PadTheMad wrote:What I should have emphasised was the time constraint, not the tools.

Group presentations were a semi-regular part of my business class, and those were a pain. I can only begin to imagine what building a game might have been like. "Not easy" is a start. I'd be interested to know how your group divided and managed the labor.

PadTheMad wrote:I've tried my hand at other things besides programming: Level editing / creation, mod scripting, modelling etc. and they all end up the same way

Same here. When decent (read: user-friendly) Doom tools came out, I tried my hand at building levels, and I even replaced one sprite to get a feel for it: the marine's first-person hand. I did more with Hexen since it was scriptable, and I dabbled in Quake C, though I never understood it well enough to make any real mods. (That was before I really started programming.) I've even considered using Unreal engine as a base for one of my own projects, but the thought of learning the intricacies of UnrealScript is overwhelming, let alone building levels and models.

I typically learn enough about an engine to understand how it works but not enough to actually change it. This aids design but does nothing for development. For example, I recently started playing "Two Worlds," and I'm constantly noticing flaws and saying things like, "they should have a hotkey for that," or "there should be a shortcut button there," or "they could improve the renderer by doing this," and so on, wondering the while how these issues were missed during play-test. (I do believe I would make an outstanding play-tester.)

Interface design is profoundly important; the GUI is literally how the user views and interacts with your project, and yet so many people overlook it altogether, and it really upsets me that people get paid tens of thousands of dollars a year to be so blatantly ignorant. There's no excuse for freeware developers either.

Also bear in mind that the word "interface" covers not only how users interact with your software, but how your software interacts with itself, i.e., class interfaces. In that sense, designing solid interfaces should quite literally be the focus of your efforts. I came to this conclusion a couple years ago after many failed attempts at designing (on paper) a framework for my engine.

Sophia wrote:Being a reproduction, a lot of the time with DSB was spent extracting, rather than creating

It certainly makes things easier, working with other people's resources instead of crafting all your own. Throughout the development cycle, you even make them your own, or at least it starts to feel that way. When I take someone else's model and light it, render it, and post-process it, it becomes a product of my own labor. I was able to bring someone else's work to life in a way they hadn't intended.

In the interest of expediting my own development, over the years I've accrued a tremendous cache of resources from other games: models, textures, sounds, even scripts that I could use as a basis for designing my own virtual machine. (My favorite scripting language so far, besides UnrealScript, is Daedalus, which is used in Gothic II.) Here's a screeny if you favor a taste.

The idea was to use this resource pool to develop a freeware, personal project that I never intended to release publicly. I've always wanted to create an "ideal" game that my friends and I could enjoy together. (We're were all vidiots growing up.) Unfortunately, even with this phenomenal amount of work already done for me, rendering and posting prefab models is a time-consuming chore, and like all chores it chips away at your motivation level. Anything that takes too long to accomplish will suck up all your mental fuel before it rekindles your inspiration. Hence the need for a development team.

And then you have to code the sumbitch so it actually does something stimulating, and we're back at square one.

DSB is a pretty amazing product of love and labor. I like popping into the clone forums when there are new posts because I want to see how people are coming along. It inspires me. Not enough, obviously! But it does inspire me. I used to do the same over at GameDev.net when I was still taking the time to learn, but not so much anymore. I've been a member there for a long time, so long that I got to use my name (Tom) as my login ID.

Anyway, for the last several weeks I've been feeling these restless, ancient urges to start coding again. The color space converter made me remember how important it is to start with a solid design, even on the seemingly simplest of projects. So, my first endeavor is to think like the code and walk through step-by-step so I can figure out what I need to start each module. Then we'll see where it takes me.

Tom Hatfield wrote:Interface design is profoundly important; the GUI is literally how the user views and interacts with your project, and yet so many people overlook it altogether

Amen to that!

Tom Hatfield wrote:There's no excuse for freeware developers either.

What about the excuse of "you get what you pay for"?

Tom Hatfield wrote:It certainly makes things easier, working with other people's resources instead of crafting all your own.

Somewhat, though, as you alluded to below, some parts of it become worse, because rather than going through a creative process, there's a lot of tedium as you go about extracting everything. Staring at the tangled spaghetti of CSBwin code trying to extract a formula wasn't exactly a piece of cake, either.

Tom Hatfield wrote:My favorite scripting language so far, besides UnrealScript, is Daedalus, which is used in Gothic II.

My favorite, in case anyone had any doubts, is Lua. It has a bit of syntax weirdness for someone used to C, but it is very readable and packs a lot of functionality in. The API for adding functions to it-- Lua was pretty much designed for embedding-- is pretty good, too.

Tom Hatfield wrote:DSB is a pretty amazing product of love and labor.

Thanks

Tom Hatfield wrote:I used to do the same over at GameDev.net

That site is... interesting to say the least. I don't have an account, but I've lurked for several years, and yet never really felt the urge to register and post. There is an interesting cross-section of talent there, though of course, a lot of wide-eyed newbies who are trying to bite off way more than they can chew. It is somewhat amusing, I guess, to see the latest MMORPG projects starting up-- I give the average one a couple of months.

Tom Hatfield wrote:Anyway, for the last several weeks I've been feeling these restless, ancient urges to start coding again.

I know that feeling.
Not to sound like I'm tooting my own horn too extensively, but, if you're getting creative urges, and the theme is somewhat "dungeon themed" perhaps-- I do remember reading about some sci-fi dungeon ideas of yours, anyway-- but you don't feel quite like tackling a whole engine from scratch, you could always give Lua and DSB a try.
(It might be a rather symbiotic motivation boost for both of us, too!)

Tom Hatfield wrote:Group presentations were a semi-regular part of my business class, and those were a pain. I can only begin to imagine what building a game might have been like. "Not easy" is a start. I'd be interested to know how your group divided and managed the labor.

Urgh, group presentations. I've done my fair share of them in the most useless module ever - Professional Skills. I mean, in one module we're learning how to write all sorts of code such as how to write shaders and complex renderers, and in PS (should be BS more like) we get taught how to send an email... Dividing the workload was simple, and perhaps that was our downfall. The artists (or 'designers' as they preferred to be called) did their own thing like not listening to the specifications of the models and textures we needed from them, not to mention making unreasonable demands on the scope of the game. IIRC, I worked on the controller implementation (which coincidentally, was never finished), and the other three members each worked on the AI, Frontend and level implementation.

All in all, it was a botch-job. Deadlines weren't kept to, certain members didn't attend meetings, there was incompatability problems with models etc. In the end, the guy working on the AI more or less took over and finished it for us!

I forgot to mention in my last post that I did manage to finish ONE 'project' - a DeuxEx map conversion. I remember playing DeusEx and thinking the VersaLife office building in Hong Kong would make a brilliant 1on1 multiplayer level, albeit with a few alterations. So I set to it, making sure every little detail and tweak was just right, and about 3 or 4 days later, it was finished. My brother and I wasted many an hour on that game and the map was pretty cool once I'd finished it - I remember feeling quite proud of myself for doing a good job on it. I make backups of nearly all of my stuff and unfortunately, that map seems to be one of the things that I've lost

Tom Hatfield wrote:I'm constantly noticing flaws and saying things like, "they should have a hotkey for that," or "there should be a shortcut button there," or "they could improve the renderer by doing this," and so on, wondering the while how these issues were missed during play-test. (I do believe I would make an outstanding play-tester.)

I have a few friends who work as playtesters for big companies and unfortunately, unless they discover a game-stopping bug, the development team rarely listen to them. One such example involves a friend working for a company synonymous with scarce. He was handed a copy of the game he was testing at the time more or less as it was going gold, and disovered some serious geometry flaws in at least two of the levels. They delayed the game to fix said flaws but when he suggested they change a useless and frustrating game mechanic, they flat out refused. The aforementioned mechanic was left in and is bloody annoying to say the least, and stops me from playing the game.

On a similar, but more humourous note, another games-testing friend came accross something bizarre when testing a particular map in the XBox conversion of a popular PC shooter. All the testers found that this map would run dead slow compared to the other maps in the game and noone could figure out why. It turns out that the map designer had sneakily expanded the boundries of the level and decided to write his name with crates waaaaay off in the distant sky. Needless to say he got a severe bollocking for that!

Whilst I'm on the subject of devs hiding stuff in games, this certainly makes an interesting read: http://games.greggman.com/games/locoroc ... _codes.htm
Makes you wonder how many games have supersecret codes that only the devs know about, and will possibly take to their graves....

Sophia wrote:My most recent "completed project," or at least in the state where I could release it and get some feedback, was DSB of course-- which I am sure you are all familiar with... if not, you should try it.

Shoot me now - I've only played DSB once and that wasn't really playing it Because I've been quite busy of late, I've not been around these parts as much, and as a result, have been unable to follow the progress of new projects. I'm sure sometime soon I can sit down with a cup of tea and have a good ol' fashioned play-around with your creation, Sophia. I'm still keeping my dungeon warm, and hopefully I'm hoping it's not too difficult to rework the existing design from it's current format to DSB. The only thing that worries me is the lack of a GUI editor. I know you said you're going to be working on this, and I hope you follow it through! I like guis, not faffing about with txt editors and such like - I like to see things visualised!

Sophia wrote:I will admit that if I were going to do it all over again I would do DSB's renderer in a completely different way, for example.

One of the possible methods we have been taught to use when programming an engine is to do exactly that. Obviously, it's very time-consuming but it will produce a better product in the end. As a matter of fact, I'm pretty sure Nintendo adopts this method.

I'm going to have to get my act together sometime soon though - I have to come up with an idea for my final year project. And on that note, I will end this epic post! Phew

Staring at the tangled spaghetti of CSBwin code

Try staring at the original code:

Sophia wrote:What about the excuse of "you get what you pay for"?

Well, there's that, but I'm also a firm believer that there's no point in doing something unless you're gonna do it right. When Paul complained about the gradient bars on Adamo's color-space converter disappearing, I rewrote the algorithm, free of charge.

Sophia wrote:...rather than going through a creative process, there's a lot of tedium as you go about extracting everything.

Agreed. It's a tradeoff between keeping yourself interested and actually getting work done. Either way, you generally ending up doing something creative. When I was making my SPF clone, I had the privilege of doing all the graphics in 3ds max, which was fun. I even redid them all a week later, just so they'd look better.

No matter what project I end up pursuing, even with 43.4 GB of prefab data at my disposal (very little of which I'd actually use), I'll end up doing the GUI graphics on my own. If I pursue LEGO Master instead, I'll be doing nearly all the graphics, but I have tools to make it substantially easier. For example, I don't make the individual parts myself. Those are done by the LDraw community. I just have to build and render the models!

Sophia wrote:My favorite, in case anyone had any doubts, is Lua.

There are things about Lua that I enjoy, like the whole tables aspect. This would be possible to implement in a .NET application, and of course you can easily do it with old school Visual Basic using Variant arrays. (In fact, if you're not worried about speed, VBScript would make a fantastic, robust scripting language — and yes, I have considered it.)

Sophia wrote:...you could always give Lua and DSB a try.

Believe it or not, the thought has entered my mind, but I am a proud programmer, and as such I am resigned to following my own path. To be honest, I don't think DSB can do all the things I'd want it to do, regarding lighting and movement, and I want to have absolute control over all aspects of GUI creation and operation. Perhaps you noticed, but I think the user interface is the most important part of any app.

On the other hand, DSB would be good for prototyping my dungeon and graphics.

PadTheMad wrote:I make backups of nearly all of my stuff and unfortunately, that map seems to be one of the things that I've lost

After playing the "Doll of Aargh" map for Hexen and being duly impressed by the author's use of ACS (Hexen's scripting language) and sheer cleverness, I was sorely disappointed by the anticlimactic ending: you walk into a teleporter and it's over. I added an entirely new section to the level called the "Temple of Aargh" and made it as dramatic as possible. I was so impressed with myself, I wanted to send it to the author, but I had no way of doing so.

Eventually it vanished among so many other things I neglected to preserve, but it was probably the biggest project I've ever accomplished. I also improved the Cannons map by adding an ammo type display to each platform using my own custom textures. Lost forever, though I do still have the script in hardcopy. Come to think of it, that would make a great UT2004 level. . . .

PadTheMad wrote:...unless they discover a game-stopping bug, the development team rarely listen to them.

I didn't figure they would listen to me. I just know I would be great at it. But it would be nice if somebody listened to performance advice. For example, in Two Worlds they used the intelligent technique of culling the entire interior/exterior of a building when the door was closed. If the door's closed, obviously you can't see inside/outside, so there's no reason to render it. Except they failed to acknowledge that, if the door is open but you're not looking directly at it, you still don't need to render or process what's on the other side.

It's called overdraw, and there are zillions of ways around it, yet surprisingly few people bother implementing one. Morrowind is another prime example; the amount of overdraw in that game was insane. What is the solution, you ask? Attach a portal to the doorway, and if the portal isn't visible, don't bother drawing anything beyond it. Unreal uses this. Most every 3-D engine has been doing this since the mid-90's. Why some people see fit to ignore the obvious is utterly beyond me.

PadTheMad wrote:It turns out that the map designer had sneakily expanded the boundries of the level and decided to write his name with crates waaaaay off in the distant sky.

Another design issue. I am also a firm believer that easter eggs are bullcrap and the game should contain nothing outside the context of the world it's trying to portray. I really enjoyed Fallout, but the designers took too much leeway putting their fingerprints on it, and as a result certain parts of the game make it all seem like a great big joke. That just ruins the game for me. In the case of boxes in the sky, where it has an adverse affect on performance . . . well, that's just ludicrous and irresponsible.

I'm turning this into a design thread. Sorry about that. Like I said, this is what I do, and I could go on for weeks, so I'll stop while I'm ahead.

No worries, I'm glad it got people talking. That was the point. To share a bit of info and get people talking about it. I know there are several people here who want to make games and some who want to make money at it. My comments were to help clear up just how much work and skills were needed. What is typical... beyond that the more discussion, the more we all learn

How can anyone hate programming? Creating something from nothing. Trying to aspire to the grand dreams of making games....

I was always a bit more theory-than-practice when it comes to coding. STOS did for me, and the most recent thing I know is Visual Basic - got me City n Guilds n everything. (The bestest ever machine was the TI99/4a, proper coding machine that, sprites, music, everything. Big fan of the old CPC too - lovely BASIC on that)

Ok, so yes the good old days of bedroom-based winners are long gone and perhaps that is a good thing. Similar argument for sport - professional versus amateur. Professional is far superior but where's the motivation - money? Pah. Oh dear, this really has turned into 'jumpers of goalpaosts' territory. sorry!

Many a pub-discussion involved the ever elusive 'minimal team' - could you get away with just a coder, an artist and some guy with a midi keyboard? Are designers over-rated? Leave it to the coders - all raised as hardcore gamers? Do you need artists? Coders either render everything or use Microsoft Paint and maths.
etc.

What do I know, I've ended up a producer (I can hear the boos from here). Turns out that yes it has gone all professional and yes there are still big bucks to be made. But that's not why we're here, playing a game made in the 80s.

But back in my amateur days, back when Dungeon Master was an aspiration not emulation, that's when I had the most fun with programming and with games. Learnt a lot, and I think that the planning and preparation of any project is one of the most important facets overlooked.

Being so technically cursed, I always designed games I could never fully realise - and I won't blame BASIC on this one. I could create really great games with it. But if you could get someone who has the talent and the will to work on a project, along with others, it's great. You don't even have to have your game design in there anymore for it to payoff.

There is a lot of pressure for people to carve a name out for themselves, but a good solid team, working together, bouncing ideas off of each other - man that rules. (am sure this has gotten back to football somehow, bah)

Game production has become a professional career. There are proper routes into it and support throughout it. It may have lost a lot of it's romance, but being in a big dev team with a pension is quite a comforting thought, considering it is one of the riskiest businesses in the world.

Mind you, this does all sound like the sort of thing a producer would say. No wonder we never get picked in the pub discussion dream teams.

There's one guy on our course who hates programming more than me and, funnily enough, he wants to be a producer!

Some nice points there boyflea and from another industry insider no less

PadTheMad wrote:I'm hoping it's not too difficult to rework the existing design from it's current format to DSB.

CSBwin and RTC dungeons can be converted into DSB, with some problems--but the layout is usually preserved. Please post on the DSB forum if you are interested, I don't want to hijack this thread (any more)

PadTheMad wrote:Obviously, it's very time-consuming but it will produce a better product in the end.

Yes, I agree. In theory, it's great.
I've just had trouble with that "time-consuming" thing.

Paul Stevens wrote:Try staring at the original code

I hope you didn't take my comment about spaghetti code as a complaint.
I'm actually quite amazed the code is at all human readable, considering what you started from. The fact that it's merely a mess is a good thing, I think!

Tom Hatfield wrote:if you're not worried about speed, VBScript would make a fantastic, robust scripting language

Not to keep pushing Lua, but that's another thing I love about it: it is so fast. DSB is able to call Lua functions on every frame (35x/sec), and the game still runs smoothly.

Tom Hatfield wrote:Believe it or not, the thought has entered my mind, but I am a proud programmer, and as such I am resigned to following my own path.

I know that feeling.
Wanting to follow my own path is a big part of why DSB exists in the first place. Of course, I tried to make that path a wide one, hence the large amount of scripting and flexibility... so if there's something specific you're missing, feel free to ask, of course.

Sophia wrote:I'm actually quite amazed the code is at all human readable, considering what you started from. The fact that it's merely a mess is a good thing, I think!

Another good piece of advice: document your source thoroughly and use sensible identifiers. This is most important when you're sharing your code or working with other people, but it's important even if you're coding by yourself, because you may take a break and come back several months later without a clue as to what you were trying to do.

The opposite is also true. I was reading some code I had in my projects folder that looked absolutely amazing. It was well-documented and very easy to understand, and I thought, "this code is beautiful, I wonder who wrote it?" I shortly came to realize that I had written it several months before, apparently taking my own advice! I wasn't used to writing clean code because most of the apps I make are slapped together in a matter of minutes.

Sophia wrote:Not to keep pushing Lua, but that's another thing I love about it: it is so fast. DSB is able to call Lua functions on every frame (35x/sec), and the game still runs smoothly.

I'd considered VBScript because I'm a VB programmer, and it seemed like a logical extension. Microsoft created a script control (cleverly named the Microsoft Script Control) that was specifically designed for executing VBScript at run-time. After toying some time with the idea of using it for my scripting engine, I've decided it simply can't offer the kind of organizational and performance benefits I'm looking for.

I'd also considered Lua as a possible alternative, but I intend to set forth using a .NET language (either VB or C#), and I wouldn't know the first thing about integrating Lua into a .NET application. Therefore, I have looked into using .NET's CodeDOM compiler to create program segments on-the-fly that basically behave as scripts, although they're actually compiled code. This would give unparalleled performance and power, at the cost of learning how to link stuff in CodeDOM.

Unfortunately, there isn't a single best solution for me. I may end up writing my own functional, pre-compiled language using command classes. This is an old idea that I rather wanted to avoid.

Sophia wrote:I know that feeling. :D
Wanting to follow my own path is a big part of why DSB exists in the first place.

Naturally. Of course, we do draw a line. Obviously I'm not going to write my own software renderer, so I use Direct3D. While it might be incredibly fun to write my own physics engine, I simply don't have the know-how, so I'll use PhysX (once I get moving on that). Clearly it would be an absolute waste of time to write my own DSP (even if I could), so I'll use BASS to cover all my audio needs.

Otherwise, I want to write my own network module, matrix transforms, bit conversion, sinusoidal regression . . . whatever my app needs that isn't so complicated that I can't do it myself.

Sometimes writing your own modules pays for itself because, when you create the software, you understand it better. Other times it doesn't, because it extends your development cycle by at least the same amount of time you'd spend learning how to use a third-party solution. Licensing an engine follows the same principle: can you modify an existing engine in the same or less time it would take to make your own? In most cases, yes, and that's why companies license engines.

For Two Worlds, the developers decided to make their own tools. Rather than using SpeedTree like most other companies do, they created their own tree generation module so they could have more control over how the trees look. I can't tell the difference. They designed a sophisticated particle system that tends to slow the game to a crawl. They created their own animation visualization tools because, in their words, Maya was too slow. The only third-party component they used (besides DirectX) was AGEIA PhysX, and I honestly can't tell how they used it because the game doesn't incorporate any physics aside from the occasional humanoid ragdoll; all other deaths are animated. I'm almost at the end of the game, and I haven't seen one example of rigid body dynamics, soft bodies, fluids, cloth, etc.

Personally, the game does not strike me as a technical marvel. I think they would have done better to license an existing engine. CryEngine would have done the same job better. (Incidentally, Sophia, scripting with CryEngine is done using Lua.)

Anyway, third party tools are like any other tool: you have to know how to use it to get the most out of it. If you don't, you may end up using it in such a way that your project suffers rather than benefits from it (like when I tried using a plumber's wrench to hammer my rim back into shape, and I broke a piece off the wrench). A lot of people are still skeptical about AGEIA PhysX hardware because they're not seeing the kind of performance benefits they expected. It's because they're running synchronous tests, and the hardware is designed to be used asynchronously so it runs in parallel with the CPU (20 ms CPU + 20 ms PPU = 20 ms).

This concept applies to all dedicated hardware, especially graphics (and now physics) cards. I'm hoping more people figure this out and we start seeing more PhysX games, because this would likely drop the price of the hardware and API licensing . . . which is something to consider from a marketing standpoint. You might also receive free (or cheap) support from the API developer. This is why you see a lot of NVidia or Intel logos during game intros: companies bring in experts to help optimize their software for specific hardware.

I'm glad we're having this discussion. It makes me want to start coding.

Interesting topic.

I just spent 3 or so months helping to playtest and design a game with a good friend of mine. Our Programmer was....well....he wasnt terribly good at programming. Tried to cut every corner he could and made the most ridiculous mistakes on earth. But EVENTUALLY he got it right! (eerr after like 250 minor changes )

Its gonna come out in a fortnight or so, and its a Java-based mobile game. Probably the least respected gaming platform on earth Mobile phone games (and rightly so!), but we cross our fingers and hope that this game will be recieved differently, because it has genuine heart and soul in it (as well as a fine helping of Working-class-against-all-odds grit )

I shall post a link in the Creative Endeavours section when all is done.

Mobile phone games in Java? Sounds familiar.

Getting around the hideous control system, the interrupts, making them work on a wide range of handsets to be viable - there is nothing wrong with 'em.

Don't get me started on JV either...

I'd be interested in seeing that.