ID:1829376
 
I am working to build my first BYOND game. The idea I have in my head is very similar to The Last Robot Standing, since it is a turn based game, where the players are robots, and the abilities they are allowed to do are based off a shuffled deck of cards, but I would like to enable the players to have their own configured decks, as well as the option of selecting a robot that has different default abilities. Also, the game would have an alternate winning condition – make it to the goal. Each map would have a goal that is an equal distance from all the spawn locations (measured in steps).

What I will need to get accomplished:
1. Waiting list that players can join before, or during the game.
2. Game start procedure that will pull up to five players from the list, and randomly spawn them in rooms, at designated spawn locations.
3. Lock players movement, unless it’s that player’s turn (Turn based game)
4. Tile based movement (one step per tile)
5. Deck shuffling, card dealing procedures.
6. Deck constructing interface that can save the player’s deck choices.
7. Proc that removes a card from the main list (only allowed one per deck) when added to their deck.

I am very limited on time these days, due to having three kids and a wife who are very demanding, as well as still being fairly new to this. I’ve played around in DM a few times over the years, but this is the first time I’ve gotten serious. I’m not asking for all the answers, but if anyone has any suggestions on where I can look into any of the items in my list, that would be a big help. Yes, I am aware that there is a DM reference (I've been reading it), and a search button. I’ll begin looking into these things a bit more, as soon as I can. I hope to dedicate this topic to the updates that I make.

Currently I have a basic shell - a default player sprite with 4 animated directions, some walls/floors, a couple objects, doors.
Killer_Vulpix wrote:
I am working to build my first BYOND game. The idea I have in my head is very similar to The Last Robot Standing, since it is a turn based game, where the players are robots, and the abilities they are allowed to do are based off a shuffled deck of cards, but I would like to enable the players to have their own configured decks, as well as the option of selecting a robot that has different default abilities. Also, the game would have an alternate winning condition – make it to the goal. Each map would have a goal that is an equal distance from all the spawn locations (measured in steps).

That sounds freaking awesome. Have you ever played RoboRally? In that game you're trying to reach a number of flags in sequence or destroy the other robots, and you're dealt new cards each phase. The cards you get can be deployed in a sequence, and your robot follows that sequence until the next phase.

What I will need to get accomplished:
1. Waiting list that players can join before, or during the game.

That'll be one of the easiest parts, since it's just a list and some verbs/procs to handle joining or leaving. The list will basically be a queue so that when you remove players from it to start the game, you'll use Cut() so you can remove them from the beginning of the list.

3. Lock players movement, unless it’s that player’s turn (Turn based game)

Also presumably you'd limit move points as in LRS. Locking movement can be done a number of ways. The easiest is by overriding mob.Move().

5. Deck shuffling, card dealing procedures.

Simple shuffling algorithm:
proc/Shuffle(list/deck)
var/i, j, l=deck.len
for(i=1, i<l, ++i) // 1 through l-1
j = rand(i,l)
if(j>i) deck.Swap(i,j)

Dealing is similar to the waiting list: You treat the deck as either a queue or a stack. With a queue you'd use grab deck[1] to get the top card and call deck.Cut(1,2) afterward to remove the card. With a stack, the deck's "top" is at the end, so you pop a card off by grabbing deck[deck.len] and then you can just say --deck.len.

6. Deck constructing interface that can save the player’s deck choices.

This will be one of the harder parts of the project. You might want to save it for later down the road, giving everyone the same deck for now. (That could also be a special game mode to reuse later.) But a basic deck builder should consist of:

- A list of available unused cards (maybe limited to that player, if it's collectible)
- A list of cards used and in what quantities

An associative list might serve you very well for a deck-saving format. Something like list("Spin Attack"=2, "Move 3"=8), etc. I prefer using names instead of types when saving. I suggest for extensibility that you mostly use names to reference the cards--it'll probably save you grief down the road.

7. Proc that removes a card from the main list (only allowed one per deck) when added to their deck.

That's sort of a sub-component of the card builder system, but easy enough to manage. I don't think you need to worry about this too much as it should become very clear once you get to working on that system.