Star Child Dev Log #9
Jay Ingle - lead developer, designer, and artist:
I made my first video game, Toleo, in one year. That is, one year from the moment I decided that it was time I made a video game, until the moment that it was 100% completed. I worked on Toleo for 6 months while working a regular job. At that point, I quit the regular job, focused on Toleo for the next 6 months, and shoved it out the door.
When I started Toleo, my background in programming was very minimal. I learned BASIC when I was a child. I read a book on C when I was a teenager. I took a Visual Basic class, and a programming microcomputers class (in Assembly language) in college.
I knew what a variable was, but I had never actually written a program before. Not to completion, anyway. I also had zero prior knowledge or experience with the Godot game engine that I used for creating the game.
The code in Toleo is bad. But you wouldn't know that unless I told you. It doesn't matter to the player, as long as the game works.
I want to be a better programmer because it gives me more options when working with other people. It also makes game creation faster, and less confusing.
Here is your devlog lesson for today: if you want to make a video game, do not be intimidated by programming. You can make a perfectly good video game with bad programming. You can make a good game with extremely limited programming knowledge. Just do your best to make the code in your next game a little better than last time.
Janne - the other guy:
I want to continue a bit on the same theme as Jay, though from the perspective of a very experienced developer. I see constantly people getting demotivated to do any programming because they're not great programmers, and from my point of view all they really have to do is choose things that are reasonably feasible to actually accomplish with your skill level.
If you don't understand how to build dynamic code, you probably shouldn't expect to build a very dynamic game. Start small, use the skills you do have, and build things in a way you know works. It's ok if it's not perfect, if the code is ugly, whatever. Once you get sick and tired of copy & pasting you'll learn how to avoid that, and also why you want to do things a better way at the same time. You'll be motivated to learn, not just forced to learn by some prick who insists you must learn to program this way without an actual purpose to it.
If you don't know what is feasible, ask for help to figure that out, but you can also get some idea based on existing games. If you're thinking of building something similar to a game where the list of credits is very long it's probably not feasible for you if you have to ask.
Start small, and if you want to stay motivated find a way to build on successes, instead of failures. Learning to finish projects and ship them is a difficult thing as well, and it's best to learn on small projects.
Now on what I've been working on - last time I shared a bit about the internals of the automapping, next I worked on our release system. I like build and release automation systems, so I knew I wanted one for Star Child a long time ago. Initially I set up one that can download Godot, the export templates, and then run Windows + Linux builds and upload them to cloud storage for when we want to share them manually. Now I think we're getting close enough to wanting real feedback from a few players so I also wanted to have Steam releases working.
Took quite a bit of setting up with Steam's partner interface being a very clunky mess, but now we've got things working rather well. When Jay or I push to our Git server, automation starts the build. After the build completes, it checks if the changes were pushed to the "beta" branch or something else - if on "beta" branch we use steamcmd to release it to the beta branch on Steam, and if anything else we release to "latest" branch on steam. This way we can always get the latest changes easily tested for anyone, we can easily release a controlled state to beta, and we still need manual confirmation to publish anything to the default branch that people will install when buying the game.
The "SteamPipe SDK" which you need is a pretty awful creation and is distributed in a rather stupid manner, but distributed it are "ContentBuilder scripts", which are the various .vdf files you need to set up for steamcmd to upload your game correctly to Steam. Check the examples, they are largely nice, however debugging issues with it is incredibly annoying as the errors you just get are short non-descriptive errors like "Failed" instead of explaining what is wrong.
We set up 2 depots for the game, one for the Windows build, one for Linux+SteamOS, and before running the upload script I ensured we had a separate folder with the ready build in each available. I pointed the ContentRoot, and FileMapping paths to the correct places, and set up the AppID and DepotIDs correctly and after some trial and error I ended up getting it to work.
One of the annoying things is that the upload happens with a logged in Steam account on steamcmd, so you have to have this Steam account login information somewhere, and ensure your build server can log into it. In practice for me this meant manually logging into Steam on each of the build agent machines, because Steam insists on sending some login verification code over email to it. Also you'll want a separate unique Steam account with only the necessary permissions for it, which Steam explains in their uploading documentation (at the moment "Edit App Metadata" and "Publish App Changes to Steam").
If you're comfortable with DevOps work this scripting wasn't significantly more difficult than most release pipelines, but the dependency on these poorly documented tools with some weird configuration file formats, poor error messages, etc. definitely made it unnecessarily complicated. If you're not comfortable with DevOps work I can see this being rather annoying to do reliably, you'd probably end up doing it on your own computer, manually, when you feel like releasing something.
I've been pondering if at some point I should release some of the scripts I built for building and releasing Star Child, but a lot of it depends on tools I install on my own build agents, and many of the scripts are very opinionated, so it's probably not going to be directly usable by anyone else anyway. Also I'm not particularly interested in trying to maintain some repository of Godot release tooling for others to use, as I can expect it to spiral out of control with people wanting it to support everything imaginable under the sun.
Either way, right now I'm pretty happy with what we have. It gives us easy stress-free releases, and sufficient control over what is released to whom and when.
One last thing to add - Jay worked a bit on the new structure for the "start game" menu, and I helped with some of the logic for it. Here's a sneak peek of how it looks like - very much placeholder visuals, but way more usable.
I made my first video game, Toleo, in one year. That is, one year from the moment I decided that it was time I made a video game, until the moment that it was 100% completed. I worked on Toleo for 6 months while working a regular job. At that point, I quit the regular job, focused on Toleo for the next 6 months, and shoved it out the door.
When I started Toleo, my background in programming was very minimal. I learned BASIC when I was a child. I read a book on C when I was a teenager. I took a Visual Basic class, and a programming microcomputers class (in Assembly language) in college.
I knew what a variable was, but I had never actually written a program before. Not to completion, anyway. I also had zero prior knowledge or experience with the Godot game engine that I used for creating the game.
The code in Toleo is bad. But you wouldn't know that unless I told you. It doesn't matter to the player, as long as the game works.
I want to be a better programmer because it gives me more options when working with other people. It also makes game creation faster, and less confusing.
Here is your devlog lesson for today: if you want to make a video game, do not be intimidated by programming. You can make a perfectly good video game with bad programming. You can make a good game with extremely limited programming knowledge. Just do your best to make the code in your next game a little better than last time.
Janne - the other guy:
I want to continue a bit on the same theme as Jay, though from the perspective of a very experienced developer. I see constantly people getting demotivated to do any programming because they're not great programmers, and from my point of view all they really have to do is choose things that are reasonably feasible to actually accomplish with your skill level.
If you don't understand how to build dynamic code, you probably shouldn't expect to build a very dynamic game. Start small, use the skills you do have, and build things in a way you know works. It's ok if it's not perfect, if the code is ugly, whatever. Once you get sick and tired of copy & pasting you'll learn how to avoid that, and also why you want to do things a better way at the same time. You'll be motivated to learn, not just forced to learn by some prick who insists you must learn to program this way without an actual purpose to it.
If you don't know what is feasible, ask for help to figure that out, but you can also get some idea based on existing games. If you're thinking of building something similar to a game where the list of credits is very long it's probably not feasible for you if you have to ask.
Start small, and if you want to stay motivated find a way to build on successes, instead of failures. Learning to finish projects and ship them is a difficult thing as well, and it's best to learn on small projects.
Now on what I've been working on - last time I shared a bit about the internals of the automapping, next I worked on our release system. I like build and release automation systems, so I knew I wanted one for Star Child a long time ago. Initially I set up one that can download Godot, the export templates, and then run Windows + Linux builds and upload them to cloud storage for when we want to share them manually. Now I think we're getting close enough to wanting real feedback from a few players so I also wanted to have Steam releases working.
Took quite a bit of setting up with Steam's partner interface being a very clunky mess, but now we've got things working rather well. When Jay or I push to our Git server, automation starts the build. After the build completes, it checks if the changes were pushed to the "beta" branch or something else - if on "beta" branch we use steamcmd to release it to the beta branch on Steam, and if anything else we release to "latest" branch on steam. This way we can always get the latest changes easily tested for anyone, we can easily release a controlled state to beta, and we still need manual confirmation to publish anything to the default branch that people will install when buying the game.
The "SteamPipe SDK" which you need is a pretty awful creation and is distributed in a rather stupid manner, but distributed it are "ContentBuilder scripts", which are the various .vdf files you need to set up for steamcmd to upload your game correctly to Steam. Check the examples, they are largely nice, however debugging issues with it is incredibly annoying as the errors you just get are short non-descriptive errors like "Failed" instead of explaining what is wrong.
We set up 2 depots for the game, one for the Windows build, one for Linux+SteamOS, and before running the upload script I ensured we had a separate folder with the ready build in each available. I pointed the ContentRoot, and FileMapping paths to the correct places, and set up the AppID and DepotIDs correctly and after some trial and error I ended up getting it to work.
One of the annoying things is that the upload happens with a logged in Steam account on steamcmd, so you have to have this Steam account login information somewhere, and ensure your build server can log into it. In practice for me this meant manually logging into Steam on each of the build agent machines, because Steam insists on sending some login verification code over email to it. Also you'll want a separate unique Steam account with only the necessary permissions for it, which Steam explains in their uploading documentation (at the moment "Edit App Metadata" and "Publish App Changes to Steam").
If you're comfortable with DevOps work this scripting wasn't significantly more difficult than most release pipelines, but the dependency on these poorly documented tools with some weird configuration file formats, poor error messages, etc. definitely made it unnecessarily complicated. If you're not comfortable with DevOps work I can see this being rather annoying to do reliably, you'd probably end up doing it on your own computer, manually, when you feel like releasing something.
I've been pondering if at some point I should release some of the scripts I built for building and releasing Star Child, but a lot of it depends on tools I install on my own build agents, and many of the scripts are very opinionated, so it's probably not going to be directly usable by anyone else anyway. Also I'm not particularly interested in trying to maintain some repository of Godot release tooling for others to use, as I can expect it to spiral out of control with people wanting it to support everything imaginable under the sun.
Either way, right now I'm pretty happy with what we have. It gives us easy stress-free releases, and sufficient control over what is released to whom and when.
One last thing to add - Jay worked a bit on the new structure for the "start game" menu, and I helped with some of the logic for it. Here's a sneak peek of how it looks like - very much placeholder visuals, but way more usable.