Hacker News Reader

Comment by clock_tower | Hacker News Reader

From my experience back when I was 12: once you get ambitious enough in QBasic, you start to wish for some way of organizing the code and making it easier to follow. At that point, an intro to structured programming or OOP is natural.

(Probably not functional programming, though, since functional's not very good for games, and what else do you think QBasic is going to be used for?)

View on HN

> you start to wish for some way of organizing the code

Yes, this is a critical and valuable step in learning. You can't easily learn the solution until you've encountered the problem.

QBasic supports subroutines (called SUB for procedures and FUNCTION for functions). You can write very structured code with QBasic; pretty much the only thing it lacks is pointers, but it's a very capable language otherwise.

GOSUB got me pretty far!

> pretty much the only thing it lacks is pointers, but it's a very capable...

You can PEEK and POKE arbitrary memory addresses and use CALL ABSOLUTE to call assembly shell code at any address.

I remember typing out a mouse driver shell code in hexadecimal from a magazine. QBasic does not have built in mouse routines and the young me was baffled when you could make that happen with a long string of digits.

I learned programming in QBasic when I was 12, wrote thousands of lines creating a Windows 3.1 style GUI complete with a help file reader that included hyperlinks. For me the limiting factor wasn't organization -- functions and subs worked well (and I loved the byref and byval parameter definitions). The real limit was speed, which drove me to learn C and was amazed that everything I wrote appeared to execute instantly compared to QBasic

> Probably not functional programming, though, since functional's not very good for games

Can you elaborate on that? People have actually written games in FP languages ([1], [2]).

[1] http://www.cliki.net/game

[2] https://en.wikipedia.org/wiki/Game_Oriented_Assembly_Lisp

I think this isn't that FP languages themselves are not good for programming games, but that the languages don't really bring much more to the table.

Even when writing games in C, you end up writing many things in a very functional way by default. You have some state variables, and on every tick you advance things around in a very defined fashion, and redraw the screen.

The "default" pattern for making games is so close to functional languages already that the only thing moving to purely functional languages gives you is a tutorial on State monads.

In a way, this is a way of saying that functional languages are good for games, though...

meanwhile, OOP-style tools are extremely useful in games, because you often find yourself working with Entities with a lot of shared behaviour. The abstraction maps well to the concrete structure of a game.

Going to an FP-language will often cause you to sacrifice many OOP-centric language niceties without bringing much to the table to replace those niceties. In game programming, I think the tradeoff is much harder to justify than in other domains.

Once the Haskell people have figured out lenses properly, you can have all your OOP niceties (that anyone actually cares about).

We've already got those niceties (including the ones that you don't care about), and we get them without having to learn Haskell's enormous universe of exotic terminology. How do we get them? We don't use Haskell.

Oh, you get much more, and better with Haskell. (It's just that stuff is currently widely in flux. Not at the base language, but at the level of basic libraries there's great improvements.)

Games would benefit from having the ability to plug in FP to resolve particular rules, but the aggregate game-world is stateful. (Remember that article here on HN where someone took several months to sort of write Pac-Man in Haskell, then admitted at the end that it would've taken him a week in C; and look at some of the other hoops that Haskell tutorials jump through when writing games.)

OOP is just an enormous win for games; I actually learned OOP with ZZT and Megazeux. Something simple like Pac-Man _might_ fit in a stateless paradigm, more or less, if you have a non-painful way to do I/O; but the more ambitious a game gets, the more it benefits from objects (including rule-processing objects).

MVC is also a good thing to use in gaming. For those who haven't heard yet: the model is the database and the deterministic, stateless parts of processing ("characters lose 1 point of nutrition per turn"); the controllers are the player's and any AIs' decisions (both are almost certainly stateful across rounds/timer-ticks); and the views are drawing the game (for the player) and giving a selective picture of the gameworld's state (for the AIs).

(Talking about FP, but mainly aout Haskell and other languages with some weak OOP tools)

The statefulness is managable in FP generally, you could see things like the State monad in Haskell. After all, the current state is just recursive applications of the rules. Experienced users of the FP languages will feel at home

The high nesting that would end up in your data will probably mean you want to reach for deep data accessors and the like. This is managed through things like Lenses in Haskell. But that's an extremely high learning curve to basically get what you get for free with dot notation in so many other languages. If you're experienced in the language already, it's fine, but if you're just starting out in the FP language, and you had experience in iterative-style languages... ouch.

I really like the idea of applying MVC for game patterns. it makes so much sense! Going to explore that the next time I have the chance.

How is the current state just recursive application of the rules, if the rules integrate randomness? It would mean saving every call to rand(), as well as every piece of user input...

GOAL is hella imperative by design -- it gives you better-than-C-level control over memory and control flow, and the option to drop down to assembly (for the PS2 CPU, GPU, or sound processor) inline, in Lisp syntax.

GOAL had a fast coroutine implementation written in it that enabled, among other things, autosave while the game engine kept running without a hitch in the Jak & Daxter series.

Saying "FP languages" and only giving examples for Lisp is cheating. Lisp has state, it has an imperative-programming mode, and it has well-developed database libraries; it's not monomaniacally FP (and therefore aggressively unhelpful for games) like Haskell is.

(Lisp also has terminology that's much easier to understand than Haskell. What exactly is a monad, again? And why would I care about monads when I already have Java?)

(And also note Bitwize's observation that GOAL is imperative with the option of doing a little FP.)

Well, sorry, I happen to be a lisp hacker and as such don't regularly follow other FP languages. But I googled it for you:

https://wiki.haskell.org/Applications_and_libraries/Games

I still don't get the "aggressively unhelpful for games". FP does not mean "no state", just that state is expressed differently.

If you do Lisp, why are you fighting for Haskell?

(For the aggressive unhelpfulness of Haskell, I mentioned that Pac-Man project -- and see my other posts in this thread.)

I don't fight for Haskell, I was hoping for an enlightening answer; since all I got was a referral (not a link) to another comment that again refers to some other thread (again without link) that apparently only provides anecdotal evidence based on one guy's story who had a hard time with his project I call it a day you a troll.

Call me whatever you like, just don't make me use Haskell. The language makes my hair stand on end; it feels math-y and determinist, like the triumph of H.G. Wells and B.F. Skinner. I want nothing to do with it, and I fear the consequences if it spreads.

> I fear the consequences if it spreads.

What would those consequences be?

Determinism, libertarianism, Science!, that sort of thing. I suspect that Haskell creates a predisposition towards thinking that way...

John Carmack ported Wolfenstein 3D in Haskell.

And people have written games in Erlang. [0]

[0] http://prog21.dadgum.com/23.html

Oh, I did not know about Carmack's port of Wolfenstein 3D, very neat. Here he is talking about motivations and lessons learned: http://functionaltalks.org/2013/08/26/john-carmack-thoughts-... (Summary: The worst problem he had with the port that he could not motivate himself enough to work on a learning project instead of a current, commercial one.)

I was in the same boat at that age. I was trying to build a text-based BassTour clone in QBasic, and the book my dad bought from Radioshack didn't get into OOP. It would have made it much easier to do than that static-state version I cobbled together.

I would love to see that if you did built it.

Reply on news.ycombinator.com