When i start a new project or game i usually work only in notepads and spreadsheets for at least a few weeks. That way i can refine ideas and how systems interact. I think it really helps save me time coding because i start with a solid plan. In the meantime, if any fun narrative, art, or ui ideas spring to mind I'll just jot them down in a big ol' list to implement later. And if I'm ever lacking for motivation that list can remind me of what im working toward.
Keeping a notebook (or cloud folder) as an expanded design doc is very handy on a long project - you'll want to be able to go back and recall why you made decisions, or reference ideas & directions/features that you couldn't implement.
Had a big laugh at the intro since I’m learning Unreal at your recommendation, but I’m definitely learning how to inject shootyfaceitis into 3D models.
Well, I do it somewhat similar. I use mind maps instead. I find them more dynamic and easier to work with. With modern mind mapping software, you can have x mind maps on a page/file, so it's easier to work with relations between different things. Sure, I would not define each Pokémon in there, that is still a thing for a spreadsheet. But I use it to define what is a Pokémon. What can they do and why. I don't know if that makes any sense to anyone.
My problem with mind maps is that they aren't connected to code at all. While conceptually diagrams like that are very similar, in practice the purpose here is to have a structure to hang actual code in an actual game engine onto.
@@CraigPerko I guess it is different depending on how one's brain works. To me, it's just easer and quicker to read and make those. And modern tools allow building structures that sort of resemble UML. I find it way more convenient, but I can understand that other folks prefer spreadsheets. I normally use those later on for balancing and such.
Would it be weird to say that I'd still be happy to work on a spreadsheet and be proud when I look through it and be "WOW THATS A LOT OF STUFF I CREATED THIS!!!"
I think you could have also mentioned Entity Relationship Diagrams (ERD) which this would effectively be in the end. ERDs would help with the relations on the spreadsheets. Also going into what happens when changes occur or are necessary would be helpful. Many Designers struggle with "but what if..." scenarios and get softlocked in "fixing" their spreadsheets. All in all, thank you very much for this great example and detailed explanation! This should help new Devs find a much easier start :)
I think the issue is the relationship between ERDs and code. It's easy to think "these entities are related" but then have no code that actually creates those buckets. But if you think in terms of spreadsheets, creating code that points to a spreadsheet entry should be second nature.
@@CraigPerko Might be more intermediate-level than the general audience here warrants, but there are plenty of web-based tools out there now to help translate ERDs into starter object+method code (or SQL, UML, etc). Some are even free, or only charge to share/save, etc. I'm still a paper-diagrammer mainly, but an undergrad in my group introduced me to one we used for Postgres - was very handy for collaboration/discussion purposes.
I don't know the Unreal equivalent, but Unity has its ScriptableObject class, which is a data-centric asset, separate from its GameObject-MonoBehaviour component model. For anyone working in Unity, each of the spreadsheets described here would work well as an object subclass of ScriptableObject (or list/collection thereof) once you're ready to translate to code. There are several tutorials out there, it's been around since Unity 5 days. .NET also supports other data structures like actual databases, but that's more advanced, and not as performant in Unity unless you know what you're doing.
This was a very lovely video. No sense getting hyper focused on the aspects that will have a lot of churn like the UI or the rendering/shading before there's even anything for the user to interact with, or to render/shade.
Thank you for this! I've been working casually for the past year or so on a turn-based rpg and I've done nothing but play with formulas and values and how systems interact to make sure they incentivize the behaviour I want and disincentivize the behaviours I don't.
This might be uncommon, but I actually do most of my game design with pen and paper. While I do eventually transfer it to an electronic format (spreadsheets, code, etc.) when I'm happy with it, most of the iterations still happen on pen an paper.
@@CraigPerko Not just from the masses, either. All the collective wisdom re: PC/console games seems to be start with the look, get your Steam page, or pitch deck, or Patreon/Kickstarter going, and then work out the underlying *game* later. Interestingly, I think mobile games, being as they are intensely data-driven, live and breathe this approach the most. (Though with them it's tying systems design to estimated KPI metrics.)
I personally wouldnt start there... You need the systems first before you can populate it with content. You need to know how the battle system works before you start filling out spreadsheets of detailed data about an individual enemy. So I would detail out how the system works first, throw in a few placeholders to test it, THEN create more entities in data. And even before that you need to know the genre and setting (fantasy, scifi, grim dark, etc). So to me it goes genre --> setting --> systems --> THEN content to populate system.
Thank you, this is super helpful. Seems like a good place to start even for the Game Shootman Versus Shootman. Are there classes? Okay, put each class's stats in a spreadsheet. How many classes of weapons are there? What are the weapons in each class? Spreadsheet and spreadsheet. Pickups? Spreadsheet. What if a shootman shoots the spreadsheets with their weapons? Better track the effects in a spreadsheet.
The books I learned from are too ancient to be of any use now, but I think the best thing to do would be to use a tiny engine to make simple games for a while.
1- Every time you said spreadsheet, I said table/object - nearly 30yrs(!) of RDBS will do that to a person. Just wrapped a mid-career Masters, and my fave prof said that "video games are just databases with great UI" 😂 2- Board to Bits posts infrequently these days, but he had a very good run of systems-focused design vids, plus a lot of other good stuff that's worth checking out, or a cross-link. 3- I don't know much about Pokemon, but yes, decent racing games are also systems-based, from Forza to Mario Kart.
@@CraigPerko To be sure, it can have other semantic/domain meanings, but OO context is still the first that pops into my mind. Sheets is a perfectly reasonable on-ramp - though I've been finding that a lot of folks, in & out of game-dev, have little/no practical experience with spreadsheets anymore. It's a little frightening, actually 😅 If this can be a lure to get folks to understand a versatile tool, for game-dev and beyond, then hey, go all-in.
but craig spreadsheets are not sexy ! ! how are they going to get the patreons?? how will they get people to buy their course?? and the ads craig the ads!!
Meanwhile I'm just over here having spent 6 years explicitly on code and systems of a light grand strategy with tactical hex-based combat. XD Edit: In case it wasn't obvious I agree with everything said. Spreadsheet data, art assets, and any other "content", "interface", or "visuals" are meaningless if systems don't exist to give them some purpose inside the context of the game.
6yrs? You might want to be wary, as focusing too exclusively on system design, for too long, can be its own sort of trap. Getting some of the visuals, aesthetics, and player-facing decisions sorted out can seriously aid in both defining the actual feel of the game for yourself, as well as convey it to others. Both sides are going to evolve, eventually in tandem, so you might want to watch out for the allure of numbers-only development. I blew a solid year near the start building out deep architecture for systems that I quickly scrapped once I advanced to a better understanding of my engine (Unity) and got a better sense of what I wanted to be custom, and what I should leverage elsewhere.
When i start a new project or game i usually work only in notepads and spreadsheets for at least a few weeks. That way i can refine ideas and how systems interact. I think it really helps save me time coding because i start with a solid plan.
In the meantime, if any fun narrative, art, or ui ideas spring to mind I'll just jot them down in a big ol' list to implement later. And if I'm ever lacking for motivation that list can remind me of what im working toward.
Seems good to me!
Keeping a notebook (or cloud folder) as an expanded design doc is very handy on a long project - you'll want to be able to go back and recall why you made decisions, or reference ideas & directions/features that you couldn't implement.
Had a big laugh at the intro since I’m learning Unreal at your recommendation, but I’m definitely learning how to inject shootyfaceitis into 3D models.
Well, I do it somewhat similar. I use mind maps instead. I find them more dynamic and easier to work with. With modern mind mapping software, you can have x mind maps on a page/file, so it's easier to work with relations between different things.
Sure, I would not define each Pokémon in there, that is still a thing for a spreadsheet. But I use it to define what is a Pokémon. What can they do and why.
I don't know if that makes any sense to anyone.
My problem with mind maps is that they aren't connected to code at all. While conceptually diagrams like that are very similar, in practice the purpose here is to have a structure to hang actual code in an actual game engine onto.
@@CraigPerko I guess it is different depending on how one's brain works.
To me, it's just easer and quicker to read and make those.
And modern tools allow building structures that sort of resemble UML. I find it way more convenient, but I can understand that other folks prefer spreadsheets.
I normally use those later on for balancing and such.
@@mcgeufer Ah, then I have failed to make myself understood.
Would it be weird to say that I'd still be happy to work on a spreadsheet and be proud when I look through it and be "WOW THATS A LOT OF STUFF I CREATED THIS!!!"
That's a good sign you'll go far in game dev.
I think you could have also mentioned Entity Relationship Diagrams (ERD) which this would effectively be in the end. ERDs would help with the relations on the spreadsheets.
Also going into what happens when changes occur or are necessary would be helpful. Many Designers struggle with "but what if..." scenarios and get softlocked in "fixing" their spreadsheets.
All in all, thank you very much for this great example and detailed explanation!
This should help new Devs find a much easier start :)
I think the issue is the relationship between ERDs and code. It's easy to think "these entities are related" but then have no code that actually creates those buckets. But if you think in terms of spreadsheets, creating code that points to a spreadsheet entry should be second nature.
@@CraigPerko Might be more intermediate-level than the general audience here warrants, but there are plenty of web-based tools out there now to help translate ERDs into starter object+method code (or SQL, UML, etc). Some are even free, or only charge to share/save, etc.
I'm still a paper-diagrammer mainly, but an undergrad in my group introduced me to one we used for Postgres - was very handy for collaboration/discussion purposes.
I don't know the Unreal equivalent, but Unity has its ScriptableObject class, which is a data-centric asset, separate from its GameObject-MonoBehaviour component model.
For anyone working in Unity, each of the spreadsheets described here would work well as an object subclass of ScriptableObject (or list/collection thereof) once you're ready to translate to code. There are several tutorials out there, it's been around since Unity 5 days.
.NET also supports other data structures like actual databases, but that's more advanced, and not as performant in Unity unless you know what you're doing.
Yea, unreal has actuall builtin tables.
This was a very lovely video. No sense getting hyper focused on the aspects that will have a lot of churn like the UI or the rendering/shading before there's even anything for the user to interact with, or to render/shade.
That's the basic idea.
Unfortunately I’m late but I totally thought this would be a world anvil sponsor
I don't know what that means, sorry.
Thank you for this! I've been working casually for the past year or so on a turn-based rpg and I've done nothing but play with formulas and values and how systems interact to make sure they incentivize the behaviour I want and disincentivize the behaviours I don't.
Well, don't get so caught up in it you forget to make the game!
This might be uncommon, but I actually do most of my game design with pen and paper.
While I do eventually transfer it to an electronic format (spreadsheets, code, etc.) when I'm happy with it, most of the iterations still happen on pen an paper.
Same here. I find you can iterate a lot faster on pen and paper, especially if you're in the beginning conceptual phase.
Very useful vid, but god how tempting it is to start with real-time shadows and stuff
That's why it happens. You get a lot of positive feedback if you can show a pretty screenshot.
@@CraigPerko Not just from the masses, either. All the collective wisdom re: PC/console games seems to be start with the look, get your Steam page, or pitch deck, or Patreon/Kickstarter going, and then work out the underlying *game* later.
Interestingly, I think mobile games, being as they are intensely data-driven, live and breathe this approach the most. (Though with them it's tying systems design to estimated KPI metrics.)
Games are basically databases with fancy graphics
I personally wouldnt start there... You need the systems first before you can populate it with content. You need to know how the battle system works before you start filling out spreadsheets of detailed data about an individual enemy. So I would detail out how the system works first, throw in a few placeholders to test it, THEN create more entities in data. And even before that you need to know the genre and setting (fantasy, scifi, grim dark, etc). So to me it goes genre --> setting --> systems --> THEN content to populate system.
Sure, design all you like before you start coding. Clearly I didn't explain myself very well.
Thank you, this is super helpful. Seems like a good place to start even for the Game Shootman Versus Shootman. Are there classes? Okay, put each class's stats in a spreadsheet. How many classes of weapons are there? What are the weapons in each class? Spreadsheet and spreadsheet. Pickups? Spreadsheet. What if a shootman shoots the spreadsheets with their weapons? Better track the effects in a spreadsheet.
Sure, but shootman games really need excellent gamefeel, so I can see focusing on that first in that situation.
Is there any book that you recommend before i start to develop games/understanding the basics of game development? I like your channel by the way
The books I learned from are too ancient to be of any use now, but I think the best thing to do would be to use a tiny engine to make simple games for a while.
Ay I'm taking your advice. Got me a lil excel sheet
In Unreal, you can literally import and export excel sheets. Well, .csvs.
1- Every time you said spreadsheet, I said table/object - nearly 30yrs(!) of RDBS will do that to a person. Just wrapped a mid-career Masters, and my fave prof said that "video games are just databases with great UI" 😂
2- Board to Bits posts infrequently these days, but he had a very good run of systems-focused design vids, plus a lot of other good stuff that's worth checking out, or a cross-link.
3- I don't know much about Pokemon, but yes, decent racing games are also systems-based, from Forza to Mario Kart.
Object means something pretty specific in game dev. Table is fine, though.
@@CraigPerko To be sure, it can have other semantic/domain meanings, but OO context is still the first that pops into my mind.
Sheets is a perfectly reasonable on-ramp - though I've been finding that a lot of folks, in & out of game-dev, have little/no practical experience with spreadsheets anymore. It's a little frightening, actually 😅
If this can be a lure to get folks to understand a versatile tool, for game-dev and beyond, then hey, go all-in.
but craig spreadsheets are not sexy ! !
how are they going to get the patreons?? how will they get people to buy their course?? and the ads craig the ads!!
That is absolutely the issue, yes. Time for me to make my awesome explosion filled video on how to actually make spreadsheets!
@@CraigPerko dont forget to add lots of jumpcuts, sound effects and animated gifs
Meanwhile I'm just over here having spent 6 years explicitly on code and systems of a light grand strategy with tactical hex-based combat. XD
Edit: In case it wasn't obvious I agree with everything said. Spreadsheet data, art assets, and any other "content", "interface", or "visuals" are meaningless if systems don't exist to give them some purpose inside the context of the game.
6yrs? You might want to be wary, as focusing too exclusively on system design, for too long, can be its own sort of trap. Getting some of the visuals, aesthetics, and player-facing decisions sorted out can seriously aid in both defining the actual feel of the game for yourself, as well as convey it to others.
Both sides are going to evolve, eventually in tandem, so you might want to watch out for the allure of numbers-only development.
I blew a solid year near the start building out deep architecture for systems that I quickly scrapped once I advanced to a better understanding of my engine (Unity) and got a better sense of what I wanted to be custom, and what I should leverage elsewhere.