

What could have been a good career in game development - fzkl

Back in 1996 when I was learning C, disconnected from the rest of the world without an internet and no one to help me with and no books that decribed concepts of C in detail, I tried my hand in trying to make my own version of games like digger and dangerous dave. In the process of coding this game, I came across problems to which I couldn't find solutions and eventually gave up on game programming. Since then I have been into other things and I now want to start off from where I left things previously. Following are the issues that I faced when making the game:<p>1) The program code was linear and used a shitty switch/case construct to take keyboard inputs and call functions that would move my character on the screen. However, since moving the character meant redrawing bitmaps on the screen, a lot of CPU cycle was spent on this (on a 486) and I wasn't able to get fluid motion from other objects in the game screen. For eg: I would have a moving paddle that I need to jump on top off. However to do this, the paddle should move independant of my character. But if I pressed and held an arrow key to move the character, all CPU cycles would go into moving the character and then the CPU would have to wait for no inputs from the keyboard to move the other objects in the game. I was never able to get things work independant ofone another.<p>I now know that the solution to my problem is threading but I am not really sure how to create threads that have functions in them and call them. It would be nice if someone can point me to a beginners tutorial on threads that addresses the kind of problem I am facing.<p>2) I was always amazed at how games like dave and such had more colors than the 16 colors Turbo C would allow. I have now come to know that int13 is used to gain access to a larger color pallete. However the usage seems very confusing. Any links that can give me a good insight into this?<p>3) Considerable amount of CPU cycle was spent drawing bricks and blocks on the screen. I figured the way games did it was use tiles and replicate them. How do I get any bitmap I create to come up on the parts of the screen where I want it to? Are we doing a direct frame buffer write, if yes, how do I gain access to the frame buffer and what are its controls?<p>I am not a CS major and nor do I obviously code for a living but I would like to get back into it seriously. Any help is appreciated. Thanks.
======
docmach
Do you still want to program for the 486 or are you looking to program using a
more modern environment? If you are going to program for a modern platform,
which one would you like to target? No matter which platform you choose you
will probably want to use OpenGL. For that I recommend
<http://nehe.gamedev.net>. If you want to develop for Mac OS X then I
recommend <http://www.idevgames.com> and in particular
<http://www.idevgames.com/forum/showthread.php?t=11896>.

------
rtf
First of, I second the others. By the time I got around to seriously learning
programming and specifically game programming I was using Python/Pygame on a 1
gigahertz machine and it gave me about as much power as a 486 would running
optimized C code. (more in some instances, less in others) If you're after
concepts and not retro-technical details this is a good route to go.

But as for the questions:

1\. Threading is not the answer; it was a missing concept on DOS machines.
Interrupt polling is what you want to look at. 2\. I recall reading about this
but never did it myself. These days you're lucky if both the monitor and
graphics card support mode 13h. 3\. The term you want is "fast rectangle
blit". This is still relevant if you use software rendering.

~~~
VinzO
What are the advantages of an interpreted language for game programming? My
idea is that it is probably much slower. I can't see the advantage. Is it that
there are a lot of usefull libraries or else? ( I almost don't know
python/pygame ).

~~~
marvin
The distinction interpreted/compiled is largely moot these days, since most
popular interpreted languages are actually compiled (or at least bytecode-
compiled) before they are run.

The real question is whether you would want to use a modern, abstract, weakly
typed language like Python instead of a strongly typed and machine-code
compiled language like C++. The latter _is_ , usually, considerably slower.
The decision all depends on how serious you want to get. For small-scale
experiments, Python is just fine because it takes half the time and half the
effort to write and test a piece of code. Unless you are pushing the limits on
how fast you want something to run, Moore's law works in your favor and you
can very quickly create something which does what you want and is fast
_enough_. If you need the speed, you will know, but at least then you will
have a simple prototype which will keep you from falling in any stupid traps
on the way.

So to answer your question, development speed is the factor that makes people
want to use these languages. You don't have to jump through hoops unless you
need run-time execution speed.

And yes, Python has excellent library support for doing just about anything
that doesn't have to be blazingly fast. This, along with better language
constructs (more dynamic classes and methods, weak typing, versatile and easy-
to-use lists and mappings, list mapping functions etc), is what makes
development much faster. Oh, and it doesn't hurt that you can dynamically test
the things you've written, if you want to.

~~~
VinzO
Thanks for your reply. One more question, I am maybe old fashionned, but weak
typing kind of scared me. I am more used to strong typing and I find it weird
when I look at python variable declaration. In my point of view, strong typing
helps avoid bugs and write cleaner programs. What advantages do you see in
weak typing?

~~~
jcl
Some arguments I have seen for dynamic typing:

\- Code is shorter and potentially easier to read.

\- While static typing can identify some bugs at compile time, these are
usually the easiest bugs to find regardless of the language you use. The hard
bugs -- the ones not caught by the compiler -- only become obvious through
testing. So if you have a good suite of tests, you will find both classes of
bugs, whether or not you use a statically typed language.

\- In a dynamically typed language, you spend less time wrestling with the
typing system -- instead of casting in C or Java, doing long template-related
declarations in C++, or convincing ML or Haskell that your program should be
allowed to run.

\- And, more theoretically, a statically typed language limits the space of
programs that you can write. While most of the programs disallowed by static
typing are buggy, some are useful, and a statically typed program with the
identical useful functionality is longer.

Of course, static typing has its benefits as well. It's the reason our fastest
languages are as fast as they are, and it's a comforting safety net,
especially in large projects.

------
dhouston
wow, time warp. (i think it was int 10h though, for the video bios, and you
had to poke around different ports to change the vga palette :))

things have, um, changed significantly -- nowadays libraries like directx
abstract away the details of direct hardware access and handle graphics,
sound, input, timers, etc.

if you're just looking to play around with games, pygame is perfect for you --
<http://www.pygame.org> .

if you're really looking to learn the details, you should probably grab a
couple books on amazon (hard to recommend one in particular without knowing
what you wanna do.)

~~~
pistoriusp
I completely agree with you but I would rather recommend Pyglet
(<http://www.pyglet.org/>) than pygame.

~~~
whacked_new
pygame obviously has better coverage (10-to-1 hits on google)... this is the
first time I saw pyglet. What's better about it?

~~~
pistoriusp
I couldn't use pygame on os x because it required a dependancy that wouldn't
compile, I'm not sure which dependancy is was.

Pyglet has no dependencies and I just found it a lot simpler than pygame to
get started with.

------
VinzO
That sounds exactly like my story... in 1995-1996 I started to develop a clone
of Football Manager That I had on C64. I used Turbo Pascal and the game was
running under DOS. Like you I had no internet connection at a time and I found
only a small book about a few graphic functions. I was never able to do a
fluid animation of my games. It was too laggy only to draw the ball on the
screen ! Then I dropped and unfortunately continue my studies as Electronic
Engineer. I wish I could turn back... Now, like you I would like to continue
the work I started, but I couldnt find backups of my source code :(

I wonder if I should start a new degree in CS, but I am 30, I have a child,
and I am not sure if it's better to learn by myself or if it's worth doing a
degree. Can online studies be a good idea? Or do you guys think it's just a
waste of time?

~~~
marvin
There are plenty of guys (and girls) over 30 in my undergraduate CS class. A
few over 40, as well.

~~~
thorax
Probably no better time to get into CS if you find a good program.

~~~
VinzO
Does anyone experienced online CS degree?

------
wlievens
Threading is not what you need right where. What you need is called a "game
logic loop" (for want of a better term). Keyboard events should change only
the "action state" of your game objects and entities, e.g. when you press a
key to move left, the player should be in the "moving left" state, but the
actual movement should not be handled there.

Parallel to the input (okay you will need a separate thread of keyboard
listening and for game logic) you will loop over your entities and update
their state, processing things such as movement.

------
barrettcolin
Have a look at this article for some useful links on VGA tricks:

<http://en.wikipedia.org/wiki/Mode_X>

If you really want to pick up where you left off, I'd suggest downloading
djgpp (gcc for dos - <http://www.delorie.com/djgpp/zip-picker.html>) along
with the Allegro library, which wraps up a lot of the nastiness of direct
hardware access.

------
wehriam
If you're interested in simple game design, you should consider experimenting
with Flash. Websites like <http://www.kongregate.com/> and services like
<http://mochiads.com/> could help with distribution and revenue on what might
otherwise be just a hobby.

~~~
VinzO
Do you have an idea of how much renenue you can do for an average game on that
kind of websites?

~~~
wehriam
From what I've heard, a very successful "casual" game makes tens of thousands
of dollars.

------
xirium
Firstly, skip all of the low-level, platform-specific details and learn
JavaScript. This will give you all of the colours and performance that you
require for sprite based games. I've seen a very good version of OutRun done
in JavaScript. A 2D platformer can definitely be implemented. Also, if you
implement in JavaScript then you'll also get a wide audience for your work
without requiring anyone to install anything.

Secondly, a real-time game is a turn-based game where the turns occur in real-
time. Unlike a strategy game, the computer continues even if you don't make a
move. Imagine AD&D melee combat at 30 rounds per second. This doesn't require
threading.

~~~
Tichy
When you say JavaScript for games, presumably what you have in mind is
ActionScript and Flash?

~~~
xirium
Knowledge of JavaScript is transferable to ActionScript but I was quite
specific about the use of JavaScript. There's a large amount of code and
documentation which is ideal for the task.

~~~
Tichy
Any pointers? I have considered creating games in JavaScript (OK, arguably my
boobs memory is a game in JavaScript), but I still would not consider it the
obvious choice for action games. For a beginner, I would rather suggest
something classical, where you have a screen/bitmap/whatever that you can draw
to?

~~~
xirium
A good example to start would be BreakOut. You have a grid of tiles. Some are
bricks. Some are spaces. This you can implement as an HTML <table>. The bat
and the ball can be implemented as floating <div>s. You can detect the x
position of the pointer and use this to control the position of the bat. When
the ball hits a brick, you want the brick to disappear. If you label each tile
in your grid then JavaScript can replace any tile with any other image.

~~~
Tichy
I was just thinking in terms of the original poster. There are lots of books
and articles on writing "normal" games (game loop, sprites etc.). I think
Javascript games would be a bit different, so I don't think they would be a
good starting point. Unless you think that in the future there will only be
Javascript games. For the time being, it would be much harder work to make a
Javascript game look reasonably smooth, compared to other technologies.

------
goofygrin
You just gave me tired head.

Unless you really want to deal with all this blitting stuff, I recommend that
you look at making flash games. You get to deal with the more interesting
problem (to me) of making a fun, playable game vs. dealing with the nuts and
bolts of graphics programming.

Also ask those guys at popcap how their financials look. I bet they aren't
doing too poorly :)

For about 3 years, I've said that the minigame will rule the world and it it
beginning to turn that way. Look at 90% of the Wii games and they are all
minigames. Games like Peggle and the downloadable content for XB360 are all
minigames that make bank.

