lisp-game-dev

lisp-game-dev@common-lisp.net

73 discussions

[lisp-game-dev] [Announce] 2010 International Lisp Games Expo
by David O'Toole 30 Jun '10

30 Jun '10

Greetings, list. It's time for our growing community's biggest event ever, the 2010 International Lisp Games Expo! I'd like to begin using the mailing list as a sort of permanent record of our "conference proceedings". And I know that I'd like to reach some of you who don't get onto #lispgames IRC :) So, check out the conference page at http://dto.github.com/notebook/2010expo.html, and make some noise :) -dave

2 1

[lisp-game-dev] Thopter 0.4 Released
by Elliott Slaughter 17 May '10

17 May '10

Thopter 0.4 has been released! Thopter is a 2D scrolling shooter game in the style of Raptor: Call of the Shadows, with support for LAN multiplayer co-op mode. Version 0.4 includes a major graphics overhaul in addition to gameplay tweaks. Downloads for Windows<http://blackthorn-engine.googlecode.com/files/thopter-0.4.1-win32-install.e…> and Mac OS X<http://blackthorn-engine.googlecode.com/files/thopter-0.4.1-macos.dmg> are available now, with Linux coming soon! -- Elliott Slaughter "Don't worry about what anybody else is going to do. The best way to predict the future is to invent it." - Alan Kay

1 0

[lisp-game-dev] Thopter 0.3 Released
by Elliott Slaughter 25 Apr '10

25 Apr '10

Thopter 0.3 <http://code.google.com/p/blackthorn-engine/wiki/Thopter> has been released! Thopter is a 2D scrolling shooter game in the style of Raptor: Call of the Shadows, with support for LAN multiplayer co-op mode. Version 0.3 includes new support for arbitrary numbers of player in multiplayer, and the *first ever build that does not crash on Windows* :-) Downloads for Windows<http://blackthorn-engine.googlecode.com/files/thopter-0.3-win32-install.exe> and Mac OS X<http://blackthorn-engine.googlecode.com/files/thopter-0.3-macos.tar.gz> are available now, with Linux coming soon! -- Elliott Slaughter "Don't worry about what anybody else is going to do. The best way to predict the future is to invent it." - Alan Kay

1 0

[lisp-game-dev] Gamemacs: an idea for a modular, extensible, capable and easy to use game-development IDE
by Joop Kiefte 05 Apr '10

05 Apr '10

Hello guys, At the moment I am gathering together all pieces of the Climacs editor to start an open source project to create a modular, extensible, capable and easy to use game-development IDE. Until I switched to Linux I have made some games with Game Maker, a fine but windows only piece of software that is too commercialized nowadays for me to like it as it is now, and I (and some others as well I think) have been looking for a good replacement on linux for quite some time. As most good programmers I am extremely lazy and don't like to do repetitive work if I can prevent it, and as such have skipped things like py-game. I have done a little bit of fiddling with clojure and as I see it now some gaming stuff is coming up for clojure as well, but I didn't feel like gaming is the perfect bet for clojure. Now I am programming for a small company in common lisp and doing that I feel like I need some open source project to keep in shape on common lisp on the side line. So I thought, let's make a game maker clone! I am not going to make things from scratch, it won't be useful to do and besides, if there is nothing to build upon, we won't even get started. So I thought this might be a perfect use for climacs. It might even be a revival of the climacs project if you like. Gamemacs is just a working name (and a bit more, as I will explain later), I mean to contribute to the several sub-projects and with normal add-ons as much as possible, to keep everything as modular as possible. To not keep things vague, and to have a good direction, this is a list of things I want to have for a nice game-editor (and in general to make of Climacs an emacs-killer instead of an emacs-clone), most of it taken from Game Maker: * Integration of something like Lispbuilder (most probably just Lispbuilder). - It has SDL - It has OpenGL - It has an .exe-creator/binary compiler * Integration of the .exe-creator/binary compiler in the editor itself * Publish versions of Climacs compiled that way to make further development easier - so for basic development of games you don't even need to install anything else than that compiled version of climacs - we can call this compiled package with extensions Gamemacs, and keep the source pure climacs, so it remains as modular as it can be * I would like to have a generic graphical editor for lisp-code on top of the textual editing mode. - and this to be extensible with cool graphical editors for example to create levels (I think I will need to make a mock-up of this idea to get it clear) * Create libraries for game-development that are included by default and work nicely with the graphical interface so you will be able to make simple games with mostly point and click and harder games with a great emacs-like editor :) I have all this quite detailed in my head, but after dumping it all here I want your input as well, so it will be great to work with. In the end my goal is to have fun creating games on linux and to be able to sketch and prototype and build games all in one place. (If you can develop everything for emacs in emacs without leaving it, why shouldn't you be able to create games without hassle?) First things I will do anyhow (but help is appreciated on all sides!): * Put all the dependencies of climacs on Git * Build climacs and fiddle with it to get accustomed to the inner workings * Same with lispbuilder etc. What do you think? Greetings, Joop Kiefte -- Communication is essential. So we need decent tools when communication is lacking, when language capability is hard to acquire... - http://esperanto.net - http://esperanto-jongeren.nl Linux-user #496644 (http://counter.li.org) - first touch of linux in 2004

3 6

[lisp-game-dev] Climacs on GitHub!
by Joop Kiefte 04 Apr '10

04 Apr '10

I have just pushed the Climacs and ESA parts to GitHub. Soon enough the other dependencies will be there as well. http://github.com/LaPingvino/Climacs http://github.com/LaPingvino/ESA Have fun! -- Communication is essential. So we need decent tools when communication is lacking, when language capability is hard to acquire... - http://esperanto.net - http://esperanto-jongeren.nl Linux-user #496644 (http://counter.li.org) - first touch of linux in 2004

2 1

[lisp-game-dev] Thopter 0.2 Released
by Elliott Slaughter 02 Apr '10

02 Apr '10

Thopter 0.2 released: http://code.google.com/p/blackthorn-engine/wiki/Thopter. Thopter is a 2D scrolling shooter game in the style of Raptor: Call of the Shadows, with support for LAN multiplayer co-op mode. Version 0.2 includes bosses, an autofire button, and improved LAN support. Downloads for Windows and Mac OS X are available now, with Linux coming soon! Thopter is not associated with the current LGDC, but with the previous contest from last year. The game has been under development since December. Enjoy :-) -- Elliott Slaughter "Don't worry about what anybody else is going to do. The best way to predict the future is to invent it." - Alan Kay

1 0

[lisp-game-dev] LGDC2010: Cloze Call post-mortem.
by Jacek Złydach 01 Apr '10

01 Apr '10

Cloze-Call Postmortem 01.04.2010 Hi, This is a postmortem for my 2010LGDC entry, called "Cloze-Call". It derives its name from Clozure Common Lisp, in which it was written (more on that topic in Section 2). It is also a reference to a phrase, "close call", which means achieving something or escaping by a narrow margin, which corresponds to the ball maneuvering between planets. The game itself is a very simple "Gravity Pong". Your goal as a player is to shoot a ball into a hole. The ball must not collide with any of the planets that are on screen. To make things more fun, all planets attract the ball by means of gravity force. 1. What did I learn? Common Lisp, first of all. It is my first real project in Lisp. I started learning this language in summer 2009, but (thanks to university) I didn't have much time to write some real programs. Using ASDF - at least a little bit. That my old design concept for Game State Manager code (which I used for years in at least three other languages) has flaws to get ???? 2. What went right? Setting up the environment. I am working on 32-bit Windows 7. Even though I had to try out SBCL (which crashed on SDL examples), CLISP (too slow), ECL (also too slow) and SBCL on Ubuntu before ending up with well-working lispbuilsder-sdl and Clozure Common Lisp, I am suprised that the installation and setting up process wasn't that complicated and things actually worked first-time. I spent two days before the Challenge on setting up SDL and working environment. Graphic Design. This project confirmed what I actually learned recently - it is important to sacrifice some time and get decent-looking graphics / media for your product (be it a game, or anything else) and make it look nice. I'd be very unhappy if this game had circles and squares instead of those pictures, which I found on OpenGameArt.org. Fixed-step physics. I am using and promoting fixed time step approach to simulation in computer games, and it's the first time I really saw how good it is. During first physics test I had a fixed initial velocity vector for the ball, and I could see how it always travels the same path and lands in the same place. The game. It isn't finished, but it is playable and has most of the game mechanics implemented. I had to cut down on features as I was running out of time, but I shipped. 3. What went wrong? Transparency in SDL - I made some little voodoo and made planets use alpha channel, but the same trick didn't worked for any other image. I'm still confused why it's not working, and this phenomena is responsible for ugly Victory/Defeat screens. Watching movies - I'd have at least few more hours to work on my game if I haven't found myself some stuff that I really, really wanted to watch. Bad naming conventions. I heard it's hard to give names to vector-math library functions. I done it wrong, and had to look for a bug for almost an hour. My vector math library that I wrote for this game had two kinds of functions - some were returning a new vector with the result of an operation, and some modified their arguments. In particular, I had (negative-vector) which returned a new vector representing inversed input parameter. The complimentary function was (negate-vector), which just negated its parameter. I used the latter instead of the former in physics code, and spent almost an hour trying to discover why graphics was flickering. 6 days instead of 7. If I were more careful and wrote 2010-04-01 23:59GMT+1 instead of 2010-04-01 00:00GMT+1, I'd have one more day to work. I found my mistake about a day after signing up and decided not to change my initial declaration. 4. What's lispy about my entry? It is in Lisp :). It is not that common to see a game in Lisp :). Few lambdas and high-order functions here and there. I think that my code is more like C++ with Lisp-syntax. But I guess, as for a first Lisp project, it's not that bad. 5. What interesting algorithms or designs did I use? My good, old Game State Manager abstraction that I use everywhere. It simplified managing different game screens. Apart from that, I guess everything else is typical stuff you'll find in any computer game. At first I wasn't sure if I want to take part in the Contest. I have lot of stuff to do at university (and other places as well), I don't know that much Common Lisp, ect. etd. But, I thought, it would be a good occasion to actually learn much Lisp in short time, and write another game. I decided to sacrifice some university lectures and now I'm happy I did it. I'd like to thank David O'Toole for inviting me to #lispgames and encouraging me to take part in the Challenge. And I'd like to thank all of you #lispgames guys for support and nice time wasted (I should have been coding, not chatting :P) on IRC :). Jacek Złydach, http://temporal.pr0.pl/devblog TRC - Bringing you tomorrow's soulutions yesterday.

1 0

[lisp-game-dev] post-mortem for CONS
by David O'Toole 30 Mar '10

30 Mar '10

#+TITLE: LGDC10 Postmortem *Tuesday March 30, 2010* First let me thank everyone for participating in the 2010 Lisp Game Design Challenge! I think the whole contest has been a success. With ten registered entries (8 individuals and 2 teams), I think we'll have a lot to discuss in the coming days. The LGDC also brought some new people to the lispgames community, and we're continuing to build a knowledge base for developing and delivering games in Lisp across multiple platforms. For example the http://www.cliki.net/LispGameDesignChallenge cliki registration page now has a big list of links to various libraries and tools, and the IRC channel's ranks have swelled to an average of over 30 people. I've read the postmortems mailed so far and I think these documents will be a great contribution to the lispgames noosphere. And now for my postmortem! For my 7-day Challenge entry I implemented the core gameplay mechanics and settings of a loosely Lisp-themed sci-fi combat game called CONS. I'm classifying my entry as a failure because I did not finish a complete game within the time limit. I will continue working on CONS though, and I'm looking forward to fleshing out the design. * What's lispy about my entry? The player is a multi-segment Lisp list snake! See the design document at http://dto.github.com/notebook/cons.html for details. In addition some interesting "minilanguage" techniques were used for this game, see the algorithms section below. * Tools and technology My entry is programmed in Common Lisp running on SBCL. I used my own [[file:xe2-reference.org][XE2 game engine]], which is based on LISPBUILDER-SDL. Image editing was done with the GIMP, and program development with GNU Emacs and SLIME running on Ubuntu. For music and sound I used varying combinations of Hexter (a software Yamaha DX7 emulator), Audacity (digital audio editor), Ardour (digital audio recording workstation), and Milkytracker (MOD tracking application.) * What went right? - The 7-day process is good for focusing on the core play mechanics, despite being a bit stressful at times. - My design called for five different level types plus an overworld map. This forced me to focus on improving XE2's random level generation framework, and led to some interesting new functionality. See the "interesting algorithms" section below. - Focusing on usability led to simplified controls---gameworld interaction uses only the arrow keys, Z, X, and Shift. The number one category of user feedback complaints about my games relate to controls, so this is a big win. I also made the controls user-configurable through an interactive spreadsheet screen, which is also joystick-compatible (with some glitches at the moment.) This is (finally) a port of my circa-2006 OO spreadsheet program "Cellmode". However, this was a time-sink, see next section. * What went wrong? My only real mistake was developing CONS as a 7-day thing. The design is a bit larger than my recent games and only the skeleton was finished by that time. Also, I spent an inordinate amount of time on the input configuration screen, and on the music for the game, when I should have focused on fleshing out the gameplay. * What did you learn? Don't attempt to port major features from an old codebase while in the middle of a 7-day challenge. Although porting Cell-mode and creating the configuration UI was unquestionably time well spent, I should have waited until after my entry was complete to work on these features. * What interesting algorithms or designs did i use? There are two main points here, one relates to level generation and the other to user interfaces. (The combination of both elements mean we will soon have a user interface for level generation.) Development on my 2010 7DRL challenge entry XIOTANK was troubled by the issue of how to generate solvable puzzles while still randomizing the layout. This is a hard problem, and occasionally-unsolvable levels have been a criticism of XONG (see http://playthisthing.com/xong ) In XIOTANK the more elaborate combination-lock style puzzle was unexpectedly hard to implement, and the result was still less than satisfying. Late in development, I overemphasized combat to compensate for this, and the result was (according to some players) an overly difficult game. I realized I had a bunch of level generation tools but nothing to tie them together. With some new functionality implemented in XE2 this has changed. First came support for randomly generating sentences (Lisp lists of individual words, strings, or symbols) according to simple context-free grammars. http://en.wikipedia.org/wiki/Context-free_grammar This is similar to L-systems except that substitutions are not simultaneous. Here's an example grammar for a fictional sci-mission: : (defparameter *test-grammar* : '((mission >> (at location please goal+ in exchange for reward)) : (location >> mars zeta-base nebula-m corva-3) : (goal+ >> goal (goal and goal+)) : (goal >> (defeat foe) (defend friend) (activate button) (retrieve documents) : (collect mineral+)) : (mineral+ >> mineral (mineral and mineral+)) : (mineral >> endurium technetium molybdenum francium a-biosilicates) : (foe >> scanner biclops unique) : (friend >> transport skiff soldier scientist) : (unique >> zx-90 xioblade) : (reward >> money part) : (money >> 10000 20000 30000 40000 50000) : (part >> muon-pistol lepton-cannon ion-shield-belt))) When "foe" is encountered for example, it is replaced with either "scanner" "biclops" or "unique". (Sublists represent concatenation.) A few example output sentences. : (AT MARS PLEASE COLLECT A-BIOSILICATES IN EXCHANGE FOR MUON-PISTOL) : (AT NEBULA-M PLEASE DEFEAT XIOBLADE IN EXCHANGE FOR MUON-PISTOL) : (AT CORVA-3 PLEASE RETRIEVE DOCUMENTS AND ACTIVATE BUTTON IN EXCHANGE FOR : ION-SHIELD-BELT) These are unintepreted data, but it is straightforward to give them an interpretation. I haven't yet done this with mission structures as in the example, but I *have* made a working implementation of a simple LOGO-like language, to interpret randomly-generated LOGO programs like this: : 9 :JUMP :PUSHLOC CONS-GAME::=BARRIER= :COLOR 90 :RIGHT 7 :DRAW :POPLOC 9 :JUMP : :PUSHLOC CONS-GAME::=BARRIER= :COLOR 90 :RIGHT 7 :DRAW :POPLOC 9 :JUMP : :PUSHLOC CONS-GAME::=BARRIER= :COLOR 90 :RIGHT 7 :DRAW :POPLOC 9 :JUMP : :PUSHLOC CONS-GAME::=BARRIER= :COLOR 45 :RIGHT 7 :DRAW :POPLOC 10 :JUMP 90 : :RIGHT :ORIGIN :PUSHLOC 45 :RIGHT 5 :JUMP CONS-GAME::=EXIT= :COLOR :DROP : :POPLOC 90 :RIGHT 20 :JUMP 90 :LEFT 25 :JUMP 90 :LEFT :PUSHLOC : CONS-GAME::=BARRIER= :COLOR 5 :DRAW :PUSH-COLOR :PUSHLOC 90 :LEFT : CONS-GAME::=BOMB-DEFUN= :COLOR 1 :JUMP 2 :DRAW :POPLOC :COLOR 5 :DRAW 90 : :RIGHT 4 :DRAW 2 :JUMP 4 :DRAW 90 :RIGHT 10 :DRAW 90 :LEFT : CONS-GAME::=BARRIER= :COLOR 5 :DRAW :PUSH-COLOR :PUSHLOC 90 :LEFT : :RIGHT 4 :DRAW 2 :JUMP 4 :DRAW 90 :RIGHT 10 :DRAW 90 :RIGHT 6 :JUMP :PUSHLOC : CONS-GAME::=PURPLE-BRICK= :COLOR 5 :DRAW 90 :RIGHT 5 :DRAW 90 :RIGHT 2 :DRAW 1 : :JUMP 2 :DRAW 90 :RIGHT 10 :DRAW 90 :LEFT CONS-GAME::=PURPLE-BRICK= :COLOR 5 : :DRAW 90 :RIGHT 5 :DRAW 90 :RIGHT 2 :DRAW 1 :JUMP 2 :DRAW 90 :RIGHT 10 :DRAW : :POPLOC :PUSHLOC CONS-GAME::=BLUE-BRICK= :COLOR 5 :DRAW 90 :RIGHT 6 :DRAW 90 : :RIGHT 5 :DRAW 90 :RIGHT 6 :DRAW 90 :LEFT CONS-GAME::=BLUE-BRICK= :COLOR 5 : :DRAW 90 :RIGHT 6 :DRAW 90 :RIGHT 5 :DRAW 90 :RIGHT 6 :DRAW 90 :LEFT 1 :JUMP : :NOOP :PUSHLOC 90 :RIGHT 3 :JUMP :DROP-REACTOR :POPLOC :POPLOC :POPLOC : :DROP-DRONES The twist on LOGO is that it's a Forth-style prefix notation. I maintain a stack of data items for each world. The LOGO program is generated according to a supplied grammar. When a non-keyword symbol is encountered, push its value onto the stack. When a string or number is encountered, push it onto the stack also. But when a keyword-symbol is encountered, we invoke the correspondingly-named method on the =world= object, which may pull arguments from the stack. The operation :COLOR sets the "paint color", in this case the type of game object to draw. The operations :PUSHLOC and :POPLOC save and restore (respectively) the turtle's current position and orientation. :DRAW and :JUMP move N squares in the current direction, either painting (with :DRAW) or not painting (:JUMP). Here's part of a "reactor level" generation grammar: : '((world >> (rod-square : :origin : :pushloc : 45 :right : 5 :jump : =exit= :color :drop : :poploc : 90 :right : 20 :jump : 90 :left : 25 :jump : 90 :left : :pushloc security-structure :poploc : :drop-drones)) : (rod-angle >> 90 45) : (rod >> (9 :jump : :pushloc : =barrier= :color : rod-angle :right : 7 :draw : :poploc)) : (rod-row >> (rod rod rod rod rod 10 :jump 90 :right)) : (rod-square >> (rod-row rod-row rod-row rod-row)) : (side-chamber >> (:pushloc : room3 90 random-turn : room3 90 :left : 1 :jump : gun-maybe : :pushloc : 90 :right : 3 :jump : :drop-reactor : :poploc : :poploc)) : (gun-maybe >> :noop :noop (=shocker= :color :drop)) : (security-structure >> (room 90 :left : room 90 :left : room 90 :left : room 90 :right : 6 :jump : :pushloc room2 90 random-turn room2 :poploc : side-chamber)) : (random-turn >> :right :left) : (random-brick >> =purple-brick= =blue-brick=) This is a big change for XE2. With turtle graphics it's easy to scale and rotate drawing elements, and express their mututal arrangement in both absolute and relative terms. But the drawing elements can be anything, because the keywords in the randomly generated sentences can trigger any method you choose to define---not just LOGO-like operations. So all the other existing tools in XE2 (lines, boxes, circles, plasma) are now tied together into a cohesive and extensible framework for procedural content generation of all kinds, not just levels. (I'm interested in seeing what can happen with procedural story elements.) A related development is the porting of cell-mode from Emacs Lisp into Common Lisp. It's a sort of object-oriented spreadsheet program with dataflow from left-to-right amongst cells of different types. Instead of implementing a new grid structure, I made a new system called "forms". One can build a spreadsheet UI out of game objects, or open an editable spreadsheet view of a game world. Combine this ability to hand-edit with the procedural generation tools, and we could have a very powerful interactive gamesdev environment. Thanks for reading everyone.

1 0

[lisp-game-dev] LGDC010 entrant questionnaire
by David O'Toole 30 Mar '10

30 Mar '10

I'd like everyone to post an entry postmortem, even if (like me) you failed to produce a complete game. Just present what you do have and perhaps touch on the following questions: 1. what did you learn? 2. what went right? 3. what went wrong? 4. what's lispy about my entry? 5. what interesting algorithms or designs did i use? Thanks everyone for participating!

3 2

[lisp-game-dev] Registration reminder
by David O'Toole 19 Mar '10

19 Mar '10

Welcome, participants! Whether spectator or Challenger, please register yourself at the Cliki page if you haven't already. http://www.cliki.net/LispGameDesignChallenge

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

lisp-game-dev