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:
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:
update() #required to force draw line to update, not clear why?
func get_mouse(): #turn/react to mouse
mouse_pos = get_viewport().get_mouse_position() #need to get local pos, as global fucks up
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:
if event is InputEventKey and event.pressed and input_delay.time_left :
var s = OS.get_scancode_string(event.scancode)
if pInput.size() < 6:
for i in range(0,pInput.size()):
complete += pInput[i]
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!