[Beta] Dodj - Dodgeball in CC!

dodj help -- displays the help text
dodj <players> -- choose the amount of players (need to setup controls for players 3 and up)

1. You can only catch the ball if you are facing where the ball is coming from.
2. Don't hold the action button after you have caught the ball, otherwise when you release it it will instantly throw the ball. Just press it right before the ball reaches you.

(key section:)
if not PLAYER_1.CATCHING and not PLAYER_1.CATCHING_CD then
	PLAYER_1.CATCHING = os.startTimer(0.5)
end
.
.
.
(timer section:)
elseif button == PLAYER_1.CATCHING then
	PLAYER_1.CATCHING = false
	PLAYER_1.CATCHING_CD = os.startTimer(3)
elseif button == PLAYER_1.CATCHING_CD then
	PLAYER_1.CATCHING_CD = false

nitrogenfingers, on 07 September 2017 - 05:15 AM said:

I had a quick play with this. There's definitely potential for something really fun here, but a few things I'd suggest:

- The ability to change your facing without moving. A second button could do this without overloading the scheme I think.
- A smaller playfield. Right now it's just too easy to miss unless you're quite close
- More dodgeballs on the field. I'm not sure what a good ratio would be but I think it should be reasonably difficult to move around when all are in motion.
- Tweak catching. I found it really challenging to catch the ball- either the game is moving too fast or the window to catch is just too small. Some visual indication of when/where that window is would be really good as well.

As a later deliverable one idea that came to me is to have playfields with obstacles that reflect the dodgeballs in different directions- you could use slashes or teletext characters to bounce the balls 90 degrees. Particularly if these obstacles could be moved, that could lead to some interesting gameplay.
Another layer might be having multiple players- either you move them all at once with the same directions or cycle between them. That could really raise the stakes of the game, make it like spinning plates.


Also I noticed some flicker when I played it. It looks like you're redrawing the game each cycle- you can probably trim this down as there aren't many visual elements on the screen- like only draw a player when an appropriate key event is fired etc.

Bomb Bloke, on 06 September 2017 - 04:35 PM said:

Do you intend to add an AI player? The basic routines feel like they should be pretty simple - move towards a ball, attempt to catch it, move to the same row/col as the opponent, throw, repeat with other ball…

for k, v in pairs(Balls) do
  if k.X then
	k:reset()
  end
end

Dave-ee Jones, on 07 September 2017 - 06:04 AM said:

Smaller playfield would definitely be more interesting, but it wouldn't really make use of the screen unless I made some kind of scoreboard or screen that displays more information or something to fill it up.

Dave-ee Jones, on 07 September 2017 - 06:04 AM said:

How would you draw it? You still have to draw the players after you clear the screen (needs to be cleared otherwise old player positions will be showing).

local function drawFrame()
  term.current().setVisible(false)
  -- clear the terminal, draw stuff, do whatever you like.
  term.current().setVisible(true)
end

if not term.current().setVisible then term.redirect(window.create(term.current(), 1, 1, term.getSize())) end

Dave-ee Jones, on 07 September 2017 - 06:45 AM said:

How would I do a mass call of functions for each ball? Can I do something like this?

Bomb Bloke, on 07 September 2017 - 09:06 AM said:

However, a quick'n'dirty method of preventing flicker is to make use of the setVisible function in the window buffer multishell is running your script in:

local function drawFrame()
  term.current().setVisible(false)
  -- clear the terminal, draw stuff, do whatever you like.
  term.current().setVisible(true)
end

Dave-ee Jones, on 07 September 2017 - 11:47 PM said:

In regards to redrawing characters instead of the whole screen, won't the characters still draw where they were last time? I guess I could draw an "empty" pixel over where they were last time, but what ifa ball's there? Or another player? Or a wall..

Dave-ee Jones, on 07 September 2017 - 11:47 PM said:

Oh boi. Is that supposed to update things without updating things on-screen then it instantly redraws it over everything on-screen when you set to visible again? Wouldn't you still notice a flicker or even lag inbetween keyboard inputs?

Bomb Bloke, on 08 September 2017 - 12:44 AM said:

Setting the buffer to invisible causes it not to render its contents the your screen until you set it to visible again. When you do so, it doesn't clear the screen before redrawing - it just straight-up redraws. Most of the screen effectively remains unchanged, and so there's no flicker.

Bomb Bloke, on 08 September 2017 - 12:44 AM said:

But a simple order of operations is to wipe every area of the screen where a mobile was, and then redraw all the mobiles.

Dave-ee Jones, on 08 September 2017 - 01:11 AM said:

It makes sense, but wouldn't you still notice a bit of lag?

Bomb Bloke, on 08 September 2017 - 01:44 AM said:

Dave-ee Jones, on 08 September 2017 - 01:11 AM said:

It makes sense, but wouldn't you still notice a bit of lag?

Ultimately code doesn't execute instantly - the best you can do is to minimise the amount that gets pumped through your processor. That means a frame update should clear just the bits that need clearing, and redraw just the bits that need redrawing. Doing that, it's unlikely anyone'll notice any issues.

local t_PLAYER_SETTINGS = {
[1] = {
  LEFT = keys.a, -- Left key (press to move left)
  UP = keys.w, -- Up key (press to move up)
  RIGHT = keys.d, -- Right key (press to move right)
  DOWN = keys.s, -- Down key (press to move down)
  ACTION = keys.leftShift, -- Action key (press to pickup/throw/drop)
  STOP = keys.z, -- Stop key (press while pressing a move key to not move)
  SPRITE = "\1", -- Sprite (1 character)
  TEAM = colors.blue, -- Team, colour based. Defaults are blue and red.
  X = 3, -- X position at the start of the game and when players are reset
  Y = 3 -- Y position at the start of the game and when players are reset
},
[2] = {
  LEFT = keys.left,
  UP = keys.up,
  RIGHT = keys.right,
  DOWN = keys.down,
  ACTION = keys.o,
  STOP = keys.p,
  SPRITE = "\2",
  TEAM = colors.red,
  X = t_TERM.W - 3,
  Y = t_TERM.H - 3
},
[3] = {
  LEFT = keys.g,
  UP = keys.y,
  RIGHT = keys.j,
  DOWN = keys.h,
  ACTION = keys.u,
  STOP = keys.i,
  SPRITE = "\2",
  TEAM = colors.blue,
  X = 3,
  Y = t_TERM.H - 3
}
}

dodj <players>

• If ball is white and sitting on the ground
• If ball is any colour and the player is facing it

• If ball is NOT the same colour as the player and not white

local player = { x = 10, y = 10 }
local keyboard_states = { [keys.up] = false, [keys.down] = false, [keys.left] = false, [keys.right] = false }
local key_timer_length = 10
local key_timer = os.startTimer(key_timer_length)
while true do
  local id, p1 = os.pullEvent()
  if id == "key_down" then keyboard_states[p1] = true
  elseif id == "key_up" then keyboard_states[p1] = false
  elseif id == "timer" and p1 == key_timer then
    if p1 == keys.up then player.y = player.y -1
    --etc etc
  end
end

nitrogenfingers, on 11 September 2017 - 06:38 AM said:

Bug: Once one team scores a point and the field resets, players are no longer able to pick up dodgeballs

nitrogenfingers, on 11 September 2017 - 06:38 AM said:

One last suggestion, particularly seeing as this game appears to be about fast movement, you might want to instead of using key events to move your characters, you could keep the state of the button as 'up' or 'down'- setting it to either when a key_up or key_down occurs. Then just have a running timer in the background and evaluate each movement when it ticks over. If you do that, you avoid that delay after the first key event fires and you have more control over how fast the characters move.

local player = { x = 10, y = 10 }
local keyboard_states = { [keys.up] = false, [keys.down] = false, [keys.left] = false, [keys.right] = false }
local key_timer_length = 10
local key_timer = os.startTimer(key_timer_length)
while true do
  local id, p1 = os.pullEvent()
  if id == "key_down" then keyboard_states[p1] = true
  elseif id == "key_up" then keyboard_states[p1] = false
  elseif id == "timer" and p1 == key_timer then
	if p1 == keys.up then player.y = player.y -1
	--etc etc
  end
end

• Fixed the bug where you can't pickup balls after someone gets hit.
• Also added a feature to change the speed of the player's movement.

• Thinking about making a 'config' file to store the player controls and settings (including player/ball speed) and sprites
• Thinking about making other items for +1 in the fun area (bombs, blocks/walls, teleporters etc.)
• Thinking about changing the 't_BALLS' metatable to 't_ITEMS' so I can turn the whole program into an API so you can create your own items (ooooooo!)

Dave-ee Jones, on 11 September 2017 - 06:55 AM said:

Because I made the player's teams changeable it means that players can change their team via the colour, which means that if I have a set scoreboard and people change the colours they aren't going to be scored..Can't think of a way to implement this without having each player have their own score.

local players = { [1] = {team = colours.red}, [2] = {team = colours.blue}, [3] = {team = colours.red}, [4] = {team = colours.green}}
local team_scores = { }

local function createTeams()
  for _,player_entry in pairs(players) do
    team_scores[player_entry.team] = { score = 0 }
  end
end

local function displayScores()
  for team_color, team_score_value in pairs(team_scores) do
    term.setCursorPos([...])
    term.setTextColour(team_color)
    term.write(team_score)
  end
end

nitrogenfingers, on 11 September 2017 - 08:07 AM said:

Dave-ee Jones, on 11 September 2017 - 06:55 AM said:

Because I made the player's teams changeable it means that players can change their team via the colour, which means that if I have a set scoreboard and people change the colours they aren't going to be scored..Can't think of a way to implement this without having each player have their own score.

If you can assume players can't change their team once a game starts, then you can loop through each player in the game, get a unique list of colours and use that for scorekeeping.

local players = { [1] = {team = colours.red}, [2] = {team = colours.blue}, [3] = {team = colours.red}, [4] = {team = colours.green}}
local team_scores = { }

local function createTeams()
  for _,player_entry in pairs(players) do
	team_scores[player_entry.team] = { score = 0 }
  end
end

local function displayScores()
  for team_color, team_score_value in pairs(team_scores) do
	term.setCursorPos([...])
	term.setTextColour(team_color)
	term.write(team_score)
  end
end

Incidentally I haven't tested any of these code snippets :P/> but hopefully you get the gist.