© 2023 by Andrew Jonhardt. Proudly created with Wix.com

  • Andrew Jonhardt

Switching mid-stream (for an easy win?)

My newest prototype of FTR was assembled and shipped in 4 days, and the Dallas Designer Group (DDG) has confirmed receipt (I waited to post this until I had their confirmation, thus the delay). At this point, my chief concerns for FTR are:

  • The time of the livestream (it's supposed to be sometime next month).

  • Whether there will be any cost issues with getting the prototype returned.

I didn't think to include a return label, as I have the ability to create one and email it as a PDF thanks to FedEx. Additionally, I haven't verified whether DDG actually has a budget setup for printing off shipping labels or purchasing packaging. Thankfully, if for any reason DDG refuses to return my prototype, I will only have lost:

  • 4 small meeples (general use board game figures) from The White Box.

  • 100 card sleeves (4 different colors).

  • The time it took to cut out and sleeve all 100 player cards.

  • The time it took to cut out all 34 Event cards.

I'm thankful for the cheapness of my design on FTR. My goal is to get the prototype back in 1 piece but, if I was being rational about it, it might actually be cheaper just to purchase another 400 card sleeves and another White Box (or some other pack of components/meeples). I'm hoping everything will work out, and I've got a plan if it all goes sideways.


Now, while I wait for the livestream, I will be taking a hiatus from FTR and board game design. It doesn't make sense to continue testing a game I explicitly sent off for testing and feedback, and I've been wanting a bit of a break to focus on Godot.


I already started work on a project I'm calling A Beginning for Pointman the week below last. It's the same project I detailed in my 3 projects post; it's a top down shooter with a story emphasis, and the whole project is intended to challenge my Godot skills. This is what I have so far:

Watch out for me lazer.

As you can see, I've successfully created a line from the player object to the current mouse position. It took me a day to figure this out with my current knowledge, which is strange to me. I figured twin stick/top down shooter tutorials would be as plentiful in Godot as they are in Unity. Instead, I had to dig this code out of random form posts:


func _process(delta):

get_player_pos()

get_mouse()

update() #required to force draw line to update, not clear why?


func get_mouse(): #turn/react to mouse

look_at(mouse_pos)

mouse_pos = get_viewport().get_mouse_position() #need to get local pos, as global fucks up


func get_player_pos():

player_pos = self.get_position() #this does appear to be the preferred way to get self pos


func _draw(): #Draw a red line from self to mouse position.

draw_line(Vector2(), mouse_pos - player_pos, Color(1,0,0), 1)


For the uninitiated, anything with a # sign is a comment or note regarding the code. As you can tell, I don't fully understand what is going on in this code.


For example, update() is a built in part of Godot I've never used or had any need for before. Yet, without update(), the game will create a line between the player position and the mouse exactly 1 time. So, a line will be drawn when you start the game, and then never move or change size for the rest of the game.


Initially, I believed the simplest solution would be a Raycast2D or a Line2D node. After all, if there's already a line in the scene, all you have to do is connect the line from the player's position to the mouse position and make is visible, right? I couldn't make that work! So, as illustrated above, I had to draw the line entirely in code.


Given how much time it took me to figure out that line, it's pretty clear that A Beginning for Pointman will not be a quick project. It's a major project, given my current skills, and I will have to return to FTR once the upcoming testing livestream is over with. So, in the meantime, I'm going to try for what I believe would be an easy win.


There is a game I've tried to make a few times that was intentionally designed to be easy. I failed to make it in Love2D because I couldn't figure out how to program the camera. I failed to make it in Unity because I believed I was ready to make a card game instead.


This weekend, I'm finally going to try and finish a completely playable version of the Ghost game!

OK, I know, it's nothing to look at yet. Here's the thing, though: what you're seeing is what I managed to get done in 2 hours on a weekday. Player scene, Level scene, an initial script, a global script, camera, and text on screen. There's only 1 problem (that will probably take me all weekend to solve): Text from the keyboard.


This is what I've currently got:

func _input(event):

if event is InputEventKey and event.pressed and input_delay.time_left :

var s = OS.get_scancode_string(event.scancode)

pInput.append(s)

update_player_output(pInput)

input_delay.start()


func update_player_output(pInput):

if pInput.size() < 6:

for i in range(0,pInput.size()):

complete += pInput[i]

else:

pInput.clear()

complete = ""

Global.POut.set_text(complete)


This doesn't work! Not because it fails to capture keystrokes, but because I keep getting duplicate inputs!


I don't know if the problem is my mechanical keyboard or how Godot handles string inputs through code. There is a node that might help here, LineEdit, but I'm going to try handling the issue first in code, possibly with timers.


Until next week!