the2bears 2019-04-04T16:36:26.012400Z

@nbtheduke not sure about your OO envy, if it's that strong you may want to reconsider idiomatic Clojure as your language. In terms of how to structure your code, a turn-based game and a simple platformer need not be so different. This depends a lot on how the platformer is setup, but often (and in my own games, which are typically shmups) the game has a fixed frame rate. I try for 60fps, so I essentially pass the game state (a nested map) through everything. It gets updated, and finally rendered. Your turn-based would be similar, just that it's not updated at 60fps. Store the game state in some kind of map structure, and when an action is performed, update the state. Finally, once a turn is complete, and various checks are made, you update the screen.

NoahTheDuke 2019-04-04T17:12:17.013900Z

So doing a lot of (swap! gamestate update-in [...] blah blah) isn't a code smell in game dev? I think that's one of the issues I'm facing: clojure is built for immutability, and game state manipulation is very mutable, so it feels like I'm doing something wrong by relying on it

NoahTheDuke 2019-04-04T17:12:29.014200Z

and thanks for the reply, it's helpful to hear from other devs

the2bears 2019-04-04T18:21:41.016300Z

Well, swap! is unnecessary in my case until the last step, pre-rendering. Before that, a 2D game is best (my opinion) as a single thread. So just thread the map (state) through your functions and swap! at the end. I suspect you don't need to swap! a lot either.

NoahTheDuke 2019-04-04T18:24:38.016600Z

Oh clever

NoahTheDuke 2019-04-04T18:25:39.017500Z

How do you handle user interaction without pausing the whole thread?

NoahTheDuke 2019-04-04T18:26:43.018500Z

dang, yeah, i love the idea of threading with a swap at the end

the2bears 2019-04-04T18:29:03.020800Z

I'm using play-clj which wraps lib-gdx. What it ends up looking like is each frame I check the state of mouse/joystick/keyboard elements I'm interested in. Been awhile since I've looked at some of the code, but in my "move player ship" function I'll check the state of, for example, arrow keys and shot keys and modify the player component of the state map accordingly. Update location, spawn a bullet, etc. All gets added to the state map and eventually rendered that 'tick' of the clock.

the2bears 2019-04-04T18:29:25.021100Z

(keypressed? UP) etc.

NoahTheDuke 2019-04-04T18:29:42.021700Z

that makes sense

the2bears 2019-04-04T18:29:45.021800Z

so no 'event' thread for input, just current state

NoahTheDuke 2019-04-04T18:30:46.022900Z

(are you cool with me asking more questions? i don't wanna bother if you're busy!)

the2bears 2019-04-04T18:31:26.023500Z

Ask away, I may not be able to answer immediately but I check in on this channel as do others.

NoahTheDuke 2019-04-04T18:31:35.023800Z

thanks, holmes

the2bears 2019-04-04T18:33:02.025400Z is fairly complete as a playable game, while is a work in progress that hasn't seen enough love this last year

NoahTheDuke 2019-04-04T18:38:09.027500Z

with netrunner, there are many times where we're doing something like moving a card from one location to another, or applying some effect to the game state, and an event fires that requires user input (open a prompt, etc). we have an "await" system so both players can interact with the game while we wait for the one to make their decision. how do you handle such things? if at all, lol

NoahTheDuke 2019-04-04T18:42:21.028200Z

I suspect this is more of a generic game dev question and not specific to clojure, but the idea of threading game-state changes is intruiging

the2bears 2019-04-04T20:25:39.030300Z

I think for something like this, I might consider an event queue. The event fires and is added to the queue. This should be handled asynchronously, outside the main game loop. Then, each 'tick' I would check and consume any events on that queue. This is different than keypressed? and more like the key was pressed and we add that to the event queue.