Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 23 Jan 2002
Offline Last Active Jan 28 2013 02:49 PM

Posts I've Made

In Topic: Learning LISP

06 September 2011 - 01:02 PM

Paul Graham is a nut. He did well in the .com bubble and he let it really go to his head. His books might be worthwhile, but he's a fanatic elitist and you should take everything he says with salt.

The Little Schemer is an interesting book, but the format gets very irritating after a while. I read it after the whole concept of lisp "clicked", so maybe it's better when the ending is a surprise.

The absolute best book on LISP is "SICP" (Structure and Interpretation of Computer Programs). It was the old MIT textbook for programming 101. It uses a minimal Scheme dialect. The last two chapters are devoted to the interpreter (they call it the "metacircular evaluator") and a full-fledged LISP compiler that compiles LISP to an assembly language DSL which is also written in LISP. You can find cheap library resell copies on eBay.

The SICP lectures are also online: http://groups.csail.mit.edu/mac/classes/6.001/abelson-sussman-lectures/

Just a few tips overall about Lisp. Common lisp is the world's second oldest language. Even though it is a "functional" language, the standard CL libraries do very weird shit. The CL community (especially #lisp on freenode.net) are kinda assholish.

Scheme is an academic language. It's small and easy to learn, but it has crappy library support.

Clojure is a modern lisp. If you want to do anything with Lisp seriously, I would suggest you start there: http://clojure.org/

In Topic: Game Controls and Logic Question

04 August 2011 - 05:14 PM

I would think it appropriate to separate the window control stuff from the actual game logic (e.g. separating the code that checks for mouse clicks from the code that actually moves the player to the location that you clicked the mouse).

Separating logic out is an important part of good software engineering. It's great you picked up on that need.

Of course, usually the way it works is you start off writing a Horrible Mess, then later (but not too much later) you go through and separate it out. If you're inexperienced, you probably want to start this way. Worrying about architecture before you can "play" your first game is usually a Bad Thing.

I've yet to figure out a way to do this without using a ton of globals (or by faking globals through using static class singletons).

One thing I didn't understand for a long time was why you should avoid globals. All programs are taught that globals and singletons are a sin against mankind, but the actual lesson to be learned is omitted from the lecture. My advice: use globals and/or singletons where you feel you need to. There will come a point where one of two things will happen:

1) You will forget where something is declared, or
2) You will want two instances of something that there is (by definition) only one copy of.

Both can be fixed. How hard it is to fix it depends on how proliferated the problem is in your code.

One important lesson often omitted is that EVERY application eventually references a singleton. You eventually want to reference THE screen, THE database, THE network, THE sound subsystem, etc. It's helpful to have those things loosely coupled for testing (talking to a mock database, for example), but in an actual application, there's only going to be one of each of these things in existence. Ever. So, it's perfectly fine to make them singletons.

Keep in mind the cost of making something local (as opposed to global) is that you are responsible for keeping track of it. You always either have to pass a reference to it or some object which keeps a reference to it. This kind of plumbing can be its own nightmare to manage.

In terms of events, what you probably want is two layers of events. You have UI events (mouse clicks and keyboard inputs) and you have game events (move commands, attack commands, etc). Then, at the top level of your program, your job is to translate UI events into game events and pass them to your game's event loop. From the event loop's perspective, all it does is expose one callback ("sendEvent"), and other than that, all it knows about are events. The UI, on the other hand, knows how to create a game event and how to send it (using "sendEvent"), but it doesn't know what the events mean past what creates them.

So as far as defining a class hierarchy, if it were me, I'd create a singleton game event loop, give it a sendEvent() method, then have the UI callbacks (onMouseClick() or whatever) create game events and send them via GameLoop::singleton()->sendEvent(...). There's no real need for inheritance here. (Though I'm sure you could find another good architecture that uses it well).

If you have a setup like this, and you need to swap out the UI component (say you're porting your game to a console system or a smartphone platform), you just need to rewrite the UI with whatever toolkit is at your disposal (provided by iOS or PS SDK or whatever). As long as you keep most of the game logic in the event loop, you don't have to rewrite very much at all.

In Topic: When is it time to put down a project you've been working on as a hobby?

22 April 2010 - 10:00 AM

The real lesson to be learned is that projects are always a LOT more work than they seem.

You start off with a game with space ships. You give them the ability to fly around, each one has armor points and gun attributes. You're done, right?

What about the art? Not even the actual image files, but the graphical design overall. How big are the images compared the the screen? What formats do you keep everything in? If your sprites are animated, how many frames? How do you control their animation cycle? What about other graphical effects? What about the user interface? Have you done menuing? How do you handle the text for the menus. Do you have a menu system out of the box or do you have to write one? Does the game have an options screen? What options are available? Graphics? Sound? Do you have a high score? How does the player enter their high score? When do players see the high scores? Is all that done? Great, your engine is done. How do you create levels for the game? Oh, crap, I forgot about levels. Does the game support progression between levels? How is that indicated to the player? How is the transition between levels done? (Cut screen? Just everything abruptly stops and the new level loads?.... (Oh yeah, what about loading screens?)). So level editor, crap, that's an entirely different program to write. What menu options are needed for that? How do you place objects on the screen? How do you do all this AND make it fun?

That's the last 10% of your game. The devil is always in the details. And not just for games. For every project of any kind you'll ever do in life.

It's better to start off working with more experienced people than to try and launch your own project. You will learn a lot from working with other people that you can't really teach in school. Things like:

* How to deal with problem people.
* How to spot scope creep and identify critical features.
* How to track and handle issues that come up.
* How to persevere when problems seem insurmountable.

In addition to a major long term project, there is nothing at all wrong with dabbling. If you want to try writing a toy compiler, game mock up, website, or play with a new language or API, do so. But don't commit to it and don't trick yourself into thinking it's a long-term thing. Learn and move on.

In Topic: "Slow" 2D Arrays

22 April 2010 - 02:18 AM

Original post by phresnel
Though that is not standards compliant,

Yeah, but it will work in any modern C compiler.

You could also just define a Vertex as an alias for float[3]. Vertex[n] is more meaningful than float[3][n].

In Topic: Clarify pointers?

22 April 2010 - 02:14 AM

Original post by nobodynews
Original post by Tac-Tics
Original post by nobodynews
It's the same in Java, references are passed by value. There is no pass by reference in Java.
I didn't say this, I assume it was a copy-paste mistake somewhere.

Whoops, sorry about that. That should have been DevFred. Apologies.

Original post by DevFred
Wrong. There is no pass by reference in Java.

This article is arguing semantics. What exactly IS the object you're manipulating? What do you care about in your code? A Foo? Or a reference to a Foo? Depending on your answer, there are two interpretations.

If you're talking about manipulating Foos, you pass by reference.

If you're talking about manipulating references to Foos, you pass by value.

Like I said, it all boils down to pass by value in the end. Every reference parameter must ultimately be turned into copying a pointer. So every language is "pass by value" in a meaningless sense.

Original post by Whatz
Click here to follow this "pointer" to an article about pointers

URLs are excellent examples of pointer :)

Don't send your friend the HTML code for the page, send them the URL.

Hell, sometimes the URL is too long, so you encode it as a tiny URL, which is a pointer-to-a-pointer.