ProSteveSmith

Members
  • Content Count

    6
  • Joined

  • Last visited

About ProSteveSmith

  • Rank
    Newbie

Contact Methods

  • Website URL
    https://robopotato.com/
  • Twitter
    https://twitter.com/ProSteveSmith

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. @mattstyles That's awesome! @b10b Here's my explanation of how functional programming works and how I use it. The idea behind functional programming is to have most of your code be pure functions. A pure function is one that returns the same thing every time given the same arguments, just like a mathematical function. A pure function also has no side effects, like printing to the screen or saving to disk. Here's an example: const f = x => 2 * x f(3) will always return 6. f(6) returns 12 every time. This what Matt means by "referentially transparent"; if you wanted you could make a table of arguments and return values instead of actually calling the function. Also, calling f never causes side effects like modifying the database or opening a network connection. If most of your program behaves in this predictable, purely functional, way, it's easier (so claim functional enthusiasts like me) to debug and refactor. Of course your program still needs to have side effects, but if you push that stuff to the edges and keep it out of program logic, the rest of your code becomes much simpler to understand and modify (again, imo). So how would you write a game this way? Here's my approach: Think of game state (the position of your player, monsters (their health and positions on the field), pretty much everything your game is keeping track of) as one big data structure called gameState. This is @mattstyles's single source of truth. const gameState = { monsters: [ /* monster data goes here */ ], player: { /* player stats go here */ }, //...and whatever else you need to keep track of } Then think of player input, as well as the game clock as a big stream of data. Every time something new comes down the stream we call the game function: const game = (oldGameState, input) => /* a pipeline of functions that return a new game state */ The game function then returns a new game state, which triggers a re-render to the screen, the playing of a sound, or whatever. Replacing old game state with new game state is a side effect, as is rendering to the screen or playing a sound, but that doesn't happen in the game function, the game function stays pure, and thus remains easy to reason about, extend or fix. One problem with this approach is that the game returns a whole new version of game state every time, which is expensive in terms of memory. But libraries like immutableJS can optimize this for you. Also, languages like Elm, ClojureScript, and PureScript do this kind of optimization at the language level. Like Matt says, it's also possible that you might run into performance issues, this is more true for JavaScript itself than an actual functional language that optimizes at the compiler level. If you run into that kind of problem you can look at whatever functions are your bottleneck and write them in an impure but optimized way. In my game, there is a constant input stream of clock ticks, commands to create new asteroids, as well as up and down button presses from the player. The game function takes these along with current game state and returns a slightly modified version of game state with the rocket's position changed and/or a new asteroid appearing. I don't see why this approach to programming wouldn't work for any game genre. I'm starting another game project using Elm that will be a simple rpg battle engine and (possibly) a shop you can use between battles. Any time new input comes in, the game function will respond with a monster attack, the using of a potion to heal a player, or changing game state so the game renders "You Died" to the screen.
  2. Hey all, I was wondering if anyone else was doing functional or functional-ish programming out there. My current game uses RxJs to stream a clock tick and user input into the composed function that is most of my game. I clearly separate side-effects (like generating random numbers) and rendering to the screen into their own functions. (I've open sourced my code for those who are interested). At the moment the performance could be better, but I'm currently doing a rewrite using ImmutableJS and the results are good so far. I've already started working on a second game and plan to use the functional language Elm (which compiles to JavaScript) and am thinking about trying to use PureScript and possibly even ClosureScript in the future. How 'bout it, any other functional fans out there? If you don't know what functional programming is, but would like to know, I could go on about it for hours and hours (could be a good or a bad thing depending on your point of view ).
  3. Extremely beautiful and atmospheric. I was sucked into the narrative in no time. Is only the demo available or can I buy the full game yet?
  4. I'd encourage you to try. If this seems too complicated, maybe try a text adventure first? The simpler the project is the more likely you are to finish it.
  5. This doesn't look like the full project. It looks like you're missing space.js, and pen.js among other files.
  6. Hey all, I've made a simple dodge-the-asteroids game in the tradition of Chrome's dinosaur jump game. It's free to play at robopotato.com/spacerocket updates and behind-the-scenes on twitter at @robopotatogames Although it's ready to play I'm still working to make it better. Any feedback, suggestions, comments are welcome.