.

.

You can read those books and I'd also recommend Practical Common Lisp

To implement the game, you can have a look at Blackthorn game engine, which was initially intended for RPG games.

Have a nice hacking

xibalba wrote:What free, online, and preferably all-in-one Lisp books should I read, and in what order?

Paul Graham's ANSI Common Lisp and On Lisp are the books I'd recommend, in that order.

Having a background in ROM hacking myself, I'm compelled to remind you that real, high-level programming is very different than what you might be used to. You're not reverse-engineering; you don't need to mentally convert hex, and if you actually need to work with hex there's a function for that built in to your Lisp implementation, which you can use from the REPL. You won't gain anything by being masochistic, just to be clear.

At the same time, however, learning assembly is still a good idea for what it teaches you about how high-level languages work under the hood, and NES 6502 is a good, simple one to learn. You might have been put off diving into a ROM since all the functions and memory addresses are naked, but it gets easier if you use the memory watch and debugger tools in recent versions of FCEUX to help you document what things are. The rest is simple: a handful of opcodes and CPU flags, and it only takes an afternoon or two to pick those up.

If you want real authenticity, I guess you could try decoding and reimplementing the PRNG from the original Final Fantasy.

Of course, these are just my opinions. Take 'em with a grain of salt, or four.

BTW, are you going to fix it so that AMUT is actually good for something?

.

xibalba wrote:What's AMUT?

AMUT = anti-mute. There were few enemies in the entire game (if any) that actually casted mute, so giving AMUT to a mage was a waste of a spell slot.

PRNG = pseudorandom number generator. Consoles in the old days were deterministic (i.e., they had no source of randomness except player input) so games usually did a little bit-twiddling to generate a non-random but reasonably obscure series of numbers. It's just an artifact of older machines, but kinda funny to think of putting in a modern game that doesn't have the same limitations.

I remember the pSX guy. It is a shame there are no decent alternatives. IIRC, PCSX will build in Linux if you bang on it, but you'd probably need to fix a few segfaults, rebuild the UI, and then write the debugger yourself. Far from impossible, but no mean feat for a newbie. :/

I'm kinda curious, though- what's your endgame in this endeavor? Do you mean to just clone FF7, FFT, etc or did you want to write an original plotline, or add multiplayer? There might be easier ways than making an engine, such as RPGMaker, or possibly the Lua interface in PCSX, if you care to brave that well-thought-out piece of software architecture.

.

xibalba wrote:I intend to use whichever method of generating randomness takes up the least amount of memory. Maybe a time-based RNG like SaGa Frontier, though it could use some work.

In practice, I think random number generation requires almost no memory, and modest CPU time. Nothing you need to worry about- RANDOM should be just fine.

I'm not stupid enough to make homebrew. The crappiest free computer game has more downloads than the greatest homebrew console game. RPGMaker does not have the functionality I want. I wouldn't mind hearing more about this Lua interface; I'm just curious.

Basically, Lua is a real programming language (a pretty good one, at that) that can be "embedded" in a C or C++ program. Using Lua, you can call a predefined set of the C program's functions programmatically.

In the context of an emulator, you could write Lua scripts that use the emulator's save/load state, frameadvance, memory read/write and other functions, and then run the script inside the emulator during runtime. You can write entire programs that, to a limited degree, extend the game without having to alter the ROM or read any assembly. I've heard of people adding mouse controls to the original Super Mario Bros, and online multiplayer to Tetris, as well as bots that play various games using learning algorithms and whatnot.

My absolute final goal is to make a free lightweight SaGa Frontier type MMORPG, which generates money by selling ad space in the in-game universe. Along the way, I want to build games that integrates the modding community with the developer, and I want to build the kind of games I want to play.

I agree with what you said about the difficulty. Most developers don't seem to put any stock in creating frighteningly strong AI, though I'm not sure how sophisticated an AI can get in an RPG, aside from Tactics-style SRPGs.

Anyway, I had a look at the design doc you have so far.

only one module need be loaded into the RAM at any given moment, which frees up a lot of room

RAM shouldn't be a problem. Certainly not to the point where you have to design around it for such a small game. Even a mobile device AFAIK should have at least 10 MB of RAM available to the user these days.

What you should consider as far as memory usage is concerned is which Lisp implementation you plan to use. They tend to be huge- I fired up SBCL just now and it was using 33 MB. I'm guessing ECL would have the smallest memory footprint, and I've heard of it being used on iPhones, but I've never used it myself so I can't really say.

Also, Lisp is a dynamic, garbage-collected language, so you don't even have to allocate memory manually. (You should know how memory allocation works, of course, but it's not something you need to spend a lot of time on in Lisp.)

separate Data module for handling duplicate data

You should aim primarily for simplicity in the design, and I think you can go a lot simpler than what you have in mind here. Your program should be modular, but in the sense that individual parts of the program don't depend on each other, and make as few assumptions as possible about the rest of the program. You can more easily reuse your code for different games that way.

If you haven't already, take the time to read the codebases of open-source games, and let that inform your design. I can't recommend any particular games since, TBH, I haven't taken my own advice on this in quite a while.

I remember when I used to make RPGs. Except that was waaaay before I got into Lisp. I used a tool called Verge RPG creation kit, whose description said they wanted to make an RPG maker that could replicate FF1-5 style games.

Are you remaking FF1, or building something like FF1? If the later case, I'd probably use Verge to prototype tilesets, sprites and plot stuff -- like little 'sketches' of game while I worked on the Lisp engine.

I would read Practical Common Lisp as mentioned, and Successful Lisp, at the same time. For graphics though your best bet will be looking at existing game engines.

Start here: http://lispgames.org.

.

xibalba wrote:I noticed that GNU Common Lisp outputs C code. How would a binary generated from that C code manage garbage collection?

If you mean to ask "how can a non-dynamic language like C do garbage collection", then the answer is that dynamic languages can be implemented in C; all languages are essentially abstractions of ASM. Otherwise, I don't know the particulars of how GCL works.

^From ANSI Common Lisp. How is (x) in the above expression a list when it isn't quoted? Is it a list because it isn't a number or string (no double quotes)? Then how is it also not a symbol? Are all such variables defined by defun lists? Or should I just keep reading as it will be explained to me later on?

It will become clearer after you read about macros, but basically the lambda-list (x) doesn't need to be quoted because it's not evaluated directly. Rather, when it's passed to a macro (i.e., defun) it's transformed into valid s-expressions.

That's my understanding, anyway.

I read through your design document. I have some advice:

• Don't worry about making it modular. Its much easier to hardcode things. In particular, hardcode the battle menu options, the character stats, and the spells. You might hardcode the character sprite & animation information.
• Code a walk-about first. 1. get your game to load up, setup gfx, and draw some random pixels on the screen. 2. get it to blit a hardcoded land tile all over the place 3. get it so you're arrow keys move the camera around the map 4. draw a 1-frame of a hardcoded sprite where your character is. When you've completed these steps you can start work on loading tile graphics, loading maps, and animating sprites.
• You have a pretty good handle on the sort of data that goes into a map. The design document looks good.

.