I added a save function to Little One. Most of the data was just easy to write to the file, but the buildings had to be formatted. Writing the dictionary for the buildings didn't take long, but I've had to add values throughout. A dictionary for the wild plants was also needed. Then I had to make sure the build platforms saved their own values while the buildings saved their values.
The fields seemed like a good start, both wild and domestic. They mostly went off without a hitch, but I had some bugs when I programmed out an exploit. Storage was next, and I gave it little thought before moving to the critter pens. Those pens had a few bugs, but the critters were missing. I had to modify the re-parenting function so they'd work, but the critters never seemed to load. Turns out, they did load, but kinematics and rigid bodies don't like each other and critters got flung.
Last night I checked to make sure everything was working, and the storage buildings were not. I was trying to get values from an empty dictionary within a dictionary. Putting the storage cell generator in the global dictionary worked, but I had to modify a few things. Today I added a few new grain plants just for something new. Most of the plants are modeled, but I need to tweak them.
After all that, I'm going to rest before I add more content. This whole project has taught me valuable lessons I'll carry into the next project.
Tuesday, November 26, 2019
White Powder, the Race to Make Cannabis Dangerous
First off, marijuana is a racist term for cannabis. It was originally coined in the 1920's (AFAIK) to associate it with migrant workers (Mexicans) who would use it to end a hard day,s work on a high note. It, and its legal status, has been used to attack groups that American politicians have found "undesirable". From different races, to protesters.
When I first saw pure THC, it looked like cocaine. Cocaine, sugar, caffeine, opiates, crystal meth, alcohol, and various other substances are "WHITE POWDER" drugs. The more racially (chemically) pure, the more dangerous. From off-white to crystal clear, the danger of abuse looms ever near. So when we legalized cannabis, every corporation wanted a toke of the dope. What is their unsaid mantra? Bigger, better, more potent, whiter. Thus cannabis was purified, the amount of THC increased, and thus the power of addiction.
Yes, I do use cannabis to end my day on a high note. I've also used it for migraines. But I regulate when I use it and only get high enough for the munchies. It helps me sleep without the effects that many sleep aides cause. It is a habit, one I may never escape, but I chose this habit and keep it scheduled. Letting it get out of hand is unwise, so I fill my day with activity.
But I'm not as likely to become addicted to substances. When I was told to reduce my sugar intake, I went almost cold-turkey. Considering a substance that is eight times more addictive than cocaine, and is in everything from bread to coke and beyond, that didn't last. So I arranged my addiction by making my own drink mix (Wyler's with one-quarter cup of sugar per gallon) and watching what I consume. Desert should only happen once a day; if at all. You'd be surprised how much sugar is in a can of ravioli (two sandwich cookies per can).
With the businesses increasing the amount of THC in every puff, how long before we say "ENOUGH"? While it may take a lot of cannabis to overdose, I'm sure Big Pharma or some corporation putting profits over safety will achieve the honor of creating the first OD strain (It'll pop a cap in yo' ass).
Sure, you can talk about how many people are now addicted to the new "SuperWeed" (coming to a metropolis near you), but how many are also addicted to coffee, sugar, coke (drug & drink), opioids, or meth (it's chemically malicious). The more you purify most substances, the more dangerous it becomes (except water).
While I'm all for cannabis being treated similar to alcohol, we should treat it similar to alcohol; not water. In fact, we should put stronger regulations on how pure the THC can be, before it's too pure for me. I've been too high, and considered just using all day, but not everyone has the metabolism or control I have. Remember, keep your recreation in its proper place so your life can be productive.
We should learn from previous "WHITE POWDER" drugs that a pure race is a terrible waste.
Cocaine, sugar, caffeine, opiates, crystal meth, alcohol, and various other substances are "WHITE POWDER" drugs.
When I first saw pure THC, it looked like cocaine. Cocaine, sugar, caffeine, opiates, crystal meth, alcohol, and various other substances are "WHITE POWDER" drugs. The more racially (chemically) pure, the more dangerous. From off-white to crystal clear, the danger of abuse looms ever near. So when we legalized cannabis, every corporation wanted a toke of the dope. What is their unsaid mantra? Bigger, better, more potent, whiter. Thus cannabis was purified, the amount of THC increased, and thus the power of addiction.
It is a habit, one I may never escape
Yes, I do use cannabis to end my day on a high note. I've also used it for migraines. But I regulate when I use it and only get high enough for the munchies. It helps me sleep without the effects that many sleep aides cause. It is a habit, one I may never escape, but I chose this habit and keep it scheduled. Letting it get out of hand is unwise, so I fill my day with activity.
Wyler's with one-quarter cup of sugar per gallon
But I'm not as likely to become addicted to substances. When I was told to reduce my sugar intake, I went almost cold-turkey. Considering a substance that is eight times more addictive than cocaine, and is in everything from bread to coke and beyond, that didn't last. So I arranged my addiction by making my own drink mix (Wyler's with one-quarter cup of sugar per gallon) and watching what I consume. Desert should only happen once a day; if at all. You'd be surprised how much sugar is in a can of ravioli (two sandwich cookies per can).
the first OD strain
With the businesses increasing the amount of THC in every puff, how long before we say "ENOUGH"? While it may take a lot of cannabis to overdose, I'm sure Big Pharma or some corporation putting profits over safety will achieve the honor of creating the first OD strain (It'll pop a cap in yo' ass).
meth (it's chemically malicious)
Sure, you can talk about how many people are now addicted to the new "SuperWeed" (coming to a metropolis near you), but how many are also addicted to coffee, sugar, coke (drug & drink), opioids, or meth (it's chemically malicious). The more you purify most substances, the more dangerous it becomes (except water).
Remember, keep your recreation in its proper place so your life can be productive.
While I'm all for cannabis being treated similar to alcohol, we should treat it similar to alcohol; not water. In fact, we should put stronger regulations on how pure the THC can be, before it's too pure for me. I've been too high, and considered just using all day, but not everyone has the metabolism or control I have. Remember, keep your recreation in its proper place so your life can be productive.
We should learn from previous "WHITE POWDER" drugs that a pure race is a terrible waste.
Thursday, November 21, 2019
Saving Games
Godot Engine already has a tutorial about saving games here, but it may not be for everyone. Basically, it grabs all the nodes in the “Persist” group and writes them to a file. It does this line-by-line, but you might just want to dump a dictionary to a file and grab it again.
I'm assuming you are using a singleton (preload) scrip that holds the game data. Singletons are scripts that load before any others and can hold persistent data for the game. Dictionaries are a complex datatype that can keep things organized. Since dictionaries are passed by reference, they are easy to keep updated.
Everyone will tell you that you don't need the "pass" keyword. They are correct, "pass" is used to skip empty functions and does no harm at the bottom of a function. I usually start two or more functions at once and use pass so I don't get errors or red lines as I work on individual functions.
First I created the "saveFile" variable and created a new file. Then I opened a file I intended to save to. The file does not need to exist if you are writing it, godot will automatically create a new file. It is best to use the "user://" location as this is a location that the game is allowed to write to. Now I assign the different variables I want to save to a single variable I initialized at the top of the script. Then the variable is stored in the file and it is closed. Remember to close the file to avoid memory leaks.
Now to load the data back. First we need to create a variable and open a new file. Variables initialized in a function can only be used by that function. Next, check to make sure the file actually exists, since we are getting data from it. I don't check to see if the file has any data since it should be in there.
Open the file and assign the data to another variable, the one initialized at the top of the scrip should work. Now we just apply the different key values to their respective variables. I'm not sure if different keys are passed by reference, but I think it depends on the variable's type. Finally, close the file to prevent memory leaks.
Feel free to reference godot's save tutorial if you want to try different ways of saving data.
I'm assuming you are using a singleton (preload) scrip that holds the game data. Singletons are scripts that load before any others and can hold persistent data for the game. Dictionaries are a complex datatype that can keep things organized. Since dictionaries are passed by reference, they are easy to keep updated.
func save_world():
var saveFile = File.new()
saveFile.open("user://savegame.save", File.WRITE)
saveDat["Cells"] = cells
saveDat["VacDat"] = vacDat
saveDat["PlayDat"] = playerDat
saveDat["Storage"] = storeDat
saveDat["MatDat"] = matDat
saveDat["BuildDat"] = buildDat
saveDat["RingDat"] = ringDat
saveDat["WorldDat"] = worldDat
saveFile.store_var(saveDat)
saveFile.close()
pass
Everyone will tell you that you don't need the "pass" keyword. They are correct, "pass" is used to skip empty functions and does no harm at the bottom of a function. I usually start two or more functions at once and use pass so I don't get errors or red lines as I work on individual functions.
First I created the "saveFile" variable and created a new file. Then I opened a file I intended to save to. The file does not need to exist if you are writing it, godot will automatically create a new file. It is best to use the "user://" location as this is a location that the game is allowed to write to. Now I assign the different variables I want to save to a single variable I initialized at the top of the script. Then the variable is stored in the file and it is closed. Remember to close the file to avoid memory leaks.
func load_world():
var saveFile = File.new()
if not saveFile.file_exists("user://savegame.save"):
print("error, no save file")
else:
saveFile.open("user://savegame.save", File.READ)
saveDat = saveFile.get_var()
cells = saveDat["Cells"]
vacDat = saveDat["VacDat"]
playerDat = saveDat["PlayDat"]
storeDat = saveDat["Storage"]
matDat = saveDat["MatDat"]
buildDat = saveDat["BuildDat"]
ringDat = saveDat["RingDat"]
worldDat = saveDat["WorldDat"]
saveFile.close()
pass
Now to load the data back. First we need to create a variable and open a new file. Variables initialized in a function can only be used by that function. Next, check to make sure the file actually exists, since we are getting data from it. I don't check to see if the file has any data since it should be in there.
Open the file and assign the data to another variable, the one initialized at the top of the scrip should work. Now we just apply the different key values to their respective variables. I'm not sure if different keys are passed by reference, but I think it depends on the variable's type. Finally, close the file to prevent memory leaks.
Feel free to reference godot's save tutorial if you want to try different ways of saving data.
Tuesday, November 19, 2019
The Rain in the Game Falls Mainly on Nothing?!
There are many ways to do rain and other weather effects. Some games use particles, which can clip through objects. A few just add/remove objects, but the physics needed and constant object flow causes lag. In 2D it can just be a screen effect. A few use shaders or have dedicated weather systems. For newer developers, that don't have the resources or experience, rain systems can seem awkward.
Either you have particles or objects, but those either clip through objects, or cause lag. I've found another way. First, a little advice and an example. Everyone seems to think the rain needs to fall, preposterous. Take two coins, fairly new ones, and stack them between your thumb and pointer finger. Now rub the coins together, slowly getting faster. If done correctly, three coins should be visible. It's an optical illusion, the same as an after-image that some anime characters can create.
How does this help us create a rain system? By taking several rain meshes and shuffling them around the player, we can cause an illusion of rain. I'll walk you through the steps.
First, make two rain objects, a drop and a splash. We'll add them to a parent object/node as meshes with a basic water or blue texture, no colliders or transparency needed, just meshes. I like to add each to a different group or have some other way to grab them from code. Don't try to grab them directly or through paths, we're going to copy them. The scene should be a parent node with a few dozen drop/splash children.
Make a few dozen copies of the drops and splashes. Add the scene to a scene, preferably as a child of something positioned at (0,0,0). Now let's create a new scene with any positional node. Since I'm doing 3D I'll use a spatial node. This can also work in 2D with minor adjustments. Add a raycast and make sure it is casting down (-y) by about 300. Move it up to +y 200/250, make sure it is active as well. Create copies and change their x/z to whatever you feel like. Keep them relatively close to the center, but not on the center.
About 12-32 raycasts should be good. Add a script to the top (parent) node. The scene should be a parent node with a few dozen raycast children. On ready you should get the splashes and drops from the scene tree using groups. If you've added the raycast scene to the same parent you added the drops scene to, you can just get the parent and then the drops scene's children. Either way is good.
Get the raycasts as well, you can just add the children to a variable. Get the player node/character as well. You should have two main functions, shuffle_rain and unshuffle_rain. The unshuffle_rain function should just get all the drops/splashes and place them somewhere hidden. I suggest changing their translation to (0,-200,0).
The shuffle_rain function is a bit more complex. Grab a random raycast, drop, and splash. Check that the raycast is colliding and get the collision position. Place the splash at the collision position, and the drop at a higher position. You can add a random number to the position's Y axis. You would do this several times a frame, feel free to experiment.
The final things to do is to get the raycast parent to rotate and change it's X/Z translation to that of the player. Randomizing the Y rotation can help make the rain move more randomly. Now all you need is signals/Boolean to start/stop the rain.
No odd clipping, no lag, no physics, easily editable. It's a good rain system if you want something easy to implement.
Either you have particles or objects, but those either clip through objects, or cause lag. I've found another way. First, a little advice and an example. Everyone seems to think the rain needs to fall, preposterous. Take two coins, fairly new ones, and stack them between your thumb and pointer finger. Now rub the coins together, slowly getting faster. If done correctly, three coins should be visible. It's an optical illusion, the same as an after-image that some anime characters can create.
How does this help us create a rain system? By taking several rain meshes and shuffling them around the player, we can cause an illusion of rain. I'll walk you through the steps.
First, make two rain objects, a drop and a splash. We'll add them to a parent object/node as meshes with a basic water or blue texture, no colliders or transparency needed, just meshes. I like to add each to a different group or have some other way to grab them from code. Don't try to grab them directly or through paths, we're going to copy them. The scene should be a parent node with a few dozen drop/splash children.
Make a few dozen copies of the drops and splashes. Add the scene to a scene, preferably as a child of something positioned at (0,0,0). Now let's create a new scene with any positional node. Since I'm doing 3D I'll use a spatial node. This can also work in 2D with minor adjustments. Add a raycast and make sure it is casting down (-y) by about 300. Move it up to +y 200/250, make sure it is active as well. Create copies and change their x/z to whatever you feel like. Keep them relatively close to the center, but not on the center.
About 12-32 raycasts should be good. Add a script to the top (parent) node. The scene should be a parent node with a few dozen raycast children. On ready you should get the splashes and drops from the scene tree using groups. If you've added the raycast scene to the same parent you added the drops scene to, you can just get the parent and then the drops scene's children. Either way is good.
Get the raycasts as well, you can just add the children to a variable. Get the player node/character as well. You should have two main functions, shuffle_rain and unshuffle_rain. The unshuffle_rain function should just get all the drops/splashes and place them somewhere hidden. I suggest changing their translation to (0,-200,0).
The shuffle_rain function is a bit more complex. Grab a random raycast, drop, and splash. Check that the raycast is colliding and get the collision position. Place the splash at the collision position, and the drop at a higher position. You can add a random number to the position's Y axis. You would do this several times a frame, feel free to experiment.
The final things to do is to get the raycast parent to rotate and change it's X/Z translation to that of the player. Randomizing the Y rotation can help make the rain move more randomly. Now all you need is signals/Boolean to start/stop the rain.
No odd clipping, no lag, no physics, easily editable. It's a good rain system if you want something easy to implement.
Thursday, November 14, 2019
Pulling Together the Last Bits
There will come a time when you are done with most of the major parts of a game. Everything looks like it can just be quickly pulled together. Just finish up a few assets and add them to the game. Finish up the programming and element placement. Then just code the save/load system and you are done; a few weeks, tops.
Before you know it, you have another unfinished project giving you stress. Sure, sticking with a project is a nice strategy, but how long until you burnout. I'm trying something else. Trying to make all the needed assets for a specific area/mechanic is very time consuming. Adding just one is much easier.
Add an asset, finish some code, fix a bug. Staying on a single task is boring, and you need to complete something to feel like there is progress. Don't try completing every asset for an area, just one. It takes less time and adding it feels good. Program a minor mechanic to feel like you are adding something, and prep a few things needed for bigger scripts/mechanics.
Work in a way that has steady accomplishments. Adding assets singly may take extra import time, but the accomplishment feels nice. Now there is something new to show in far less time. Finishing or adding mechanics is good. Finish the small things and add to the bigger things. In this way there is something new every day, and there should be less burnout.
Also Little One has energy, health, and master storage containers in the build.
Have to create a few more assets.
Re-do some more assets.
Forgot I had to program this thing.
Came across a problem, need to fix it.
Why are these assets taking so long.
Is there an easier project?
Who can help me?
That's future self's problem.
I think this other project might be easier.
Before you know it, you have another unfinished project giving you stress. Sure, sticking with a project is a nice strategy, but how long until you burnout. I'm trying something else. Trying to make all the needed assets for a specific area/mechanic is very time consuming. Adding just one is much easier.
Add an asset, finish some code, fix a bug. Staying on a single task is boring, and you need to complete something to feel like there is progress. Don't try completing every asset for an area, just one. It takes less time and adding it feels good. Program a minor mechanic to feel like you are adding something, and prep a few things needed for bigger scripts/mechanics.
Work in a way that has steady accomplishments. Adding assets singly may take extra import time, but the accomplishment feels nice. Now there is something new to show in far less time. Finishing or adding mechanics is good. Finish the small things and add to the bigger things. In this way there is something new every day, and there should be less burnout.
Also Little One has energy, health, and master storage containers in the build.
Tuesday, November 12, 2019
Youtube can't keep its ads off the children
So it's making us pay. I thought youtube only allowed accounts for people over 13. Doesn't help that the parent's want everyone else to raise their children.
So I'll be looking at my old Vimeo account. I'm sure I can do something with that small amount of data they give free accounts. Not that I have any money, or health insurance, or... you know what?
Would you kindly support me on either Patreon or Ko-fi?
My main concern is that youtube can change the rating of a video at its discretion.That's fine if a video needs to be marked from child-friendly to NOT. But, while I do upload game videos, and some of my projects are child-friendly, I'd rather not have my videos marked as so. I don't want to have trouble because the YOUTUBE AI deemed a video of mine as child-friendly when it isn't. Or worse, have someone claim that gamedev and gameplay videos are indirect advertisements aimed at children. I really hope youtube notifies people when their video rating is changed, but it seems like another way to remove channels they don't like.
Little One now has a sky with day/night function. The day cycles a bit fast and it still needs work. I'll have to unwrap my own sphere and not rely on Godot's sphere. Skies are slightly hard to get right and the shaders in Godot don't allow you to layer images. The bad UV layout for the sphere warps things too much.
It made the sun square-ish.
It doesn't help that unwrapping spheres is difficult with all those seams and the sun still has to traverse the sky. That is a problem for later though. I did my best, but the visual shader is still lacking. Layering images, or having several image slots, would help quite a bit. Currently, I need to blend the images with math. Even with all the functions they give you, I had to split it into two materials to get close to what I wanted.
A staircase of material passes would be annoying, but it might be the only way.
Blast it, I'll work on getting the health and energy stats done along with master food/water storage next. I should just focus on getting individual items into the game instead of doing all items at once.
So I'll be looking at my old Vimeo account. I'm sure I can do something with that small amount of data they give free accounts. Not that I have any money, or health insurance, or... you know what?
Would you kindly support me on either Patreon or Ko-fi?
My main concern is that youtube can change the rating of a video at its discretion.That's fine if a video needs to be marked from child-friendly to NOT. But, while I do upload game videos, and some of my projects are child-friendly, I'd rather not have my videos marked as so. I don't want to have trouble because the YOUTUBE AI deemed a video of mine as child-friendly when it isn't. Or worse, have someone claim that gamedev and gameplay videos are indirect advertisements aimed at children. I really hope youtube notifies people when their video rating is changed, but it seems like another way to remove channels they don't like.
***
Little One now has a sky with day/night function. The day cycles a bit fast and it still needs work. I'll have to unwrap my own sphere and not rely on Godot's sphere. Skies are slightly hard to get right and the shaders in Godot don't allow you to layer images. The bad UV layout for the sphere warps things too much.
It made the sun square-ish.
It doesn't help that unwrapping spheres is difficult with all those seams and the sun still has to traverse the sky. That is a problem for later though. I did my best, but the visual shader is still lacking. Layering images, or having several image slots, would help quite a bit. Currently, I need to blend the images with math. Even with all the functions they give you, I had to split it into two materials to get close to what I wanted.
A staircase of material passes would be annoying, but it might be the only way.
Blast it, I'll work on getting the health and energy stats done along with master food/water storage next. I should just focus on getting individual items into the game instead of doing all items at once.
Friday, November 8, 2019
Worst Laid Plans
I'm starting to see the working on video games needs a bit of balance. It takes planning, resolve, and steady progress to complete a game. Little One needed more planning before I started, but I'll put more into planning with the next project.
I should plan the critters and beasts, along with the parts needed. Some parts you'll have to find, others need to be fabricated. I'll have to model, texture, and animate these things as well. Minor static objects are not that bad, but animated, organic, or complex objects take the most time. Tubes and gears are easy, engines and ants tend to be more complex.
The player and NPC animations are simple and mostly done. Usually you can get away with just a walk animation for NPCs and maybe an attack animations for enemies. Bosses take far more work, as much or more than the player. The textures are also basic and need some work, but I still need to model NPC accessories.
Plants and resources need to be distributed across the map for the player to find. I might have a ship somewhere on my PC, along with some other resources. Might take stock of, and arrange all the old models I've made. It's time I gathered my resources and started a collection for later projects.
That's the good thing, even in failure you learn and gather resources. I advise keeping models, textures, and sprites; they may be useful someday.
Posts Versions: RED & BLUE
I should plan the critters and beasts, along with the parts needed. Some parts you'll have to find, others need to be fabricated. I'll have to model, texture, and animate these things as well. Minor static objects are not that bad, but animated, organic, or complex objects take the most time. Tubes and gears are easy, engines and ants tend to be more complex.
The player and NPC animations are simple and mostly done. Usually you can get away with just a walk animation for NPCs and maybe an attack animations for enemies. Bosses take far more work, as much or more than the player. The textures are also basic and need some work, but I still need to model NPC accessories.
Plants and resources need to be distributed across the map for the player to find. I might have a ship somewhere on my PC, along with some other resources. Might take stock of, and arrange all the old models I've made. It's time I gathered my resources and started a collection for later projects.
That's the good thing, even in failure you learn and gather resources. I advise keeping models, textures, and sprites; they may be useful someday.
Posts Versions: RED & BLUE
Monday, November 4, 2019
A Small Matter
It always seems like two steps forward, one step back when you are a singular gamedev. I'm having problems with the textures/materials in Little One and there is still so much to do. Sometimes I wish these problems didn't happen, but I enjoy solving problems. Once the material problem has been corrected, and I know a good way to correct it, I'll start adding and testing the final mechanics.
The dialog system is in another project and needs to be modified for Little one. Player and NPC models are mostly done, just need textures, animations, and a few minor accessories. Critters need some more programming and they'll give way to beasts within the game. Building upgrades need to be modeled, textured. and fully implemented. There needs to be a way to dispense materials from destructible objects. Many of the parts and player upgrades need to be coded and implemented. Opening and ending scenes need to be done along with success/fail conditions. World data and save/load systems need to be finished.
I should do some planning on the final parts needed. Most of the player upgrades are partly implemented. There is a collection on open game art that has resources for Little One, as well as what I'm making now.
Speaking of planning, I'll be planning a project a bit this month. If I finish Little One this month (November 2019) I can work on another project in December. Little One will have taken about five or six months at the end of November 2019.
I wonder if I can make a bigger game in two months if I planned it well.
The dialog system is in another project and needs to be modified for Little one. Player and NPC models are mostly done, just need textures, animations, and a few minor accessories. Critters need some more programming and they'll give way to beasts within the game. Building upgrades need to be modeled, textured. and fully implemented. There needs to be a way to dispense materials from destructible objects. Many of the parts and player upgrades need to be coded and implemented. Opening and ending scenes need to be done along with success/fail conditions. World data and save/load systems need to be finished.
I should do some planning on the final parts needed. Most of the player upgrades are partly implemented. There is a collection on open game art that has resources for Little One, as well as what I'm making now.
Speaking of planning, I'll be planning a project a bit this month. If I finish Little One this month (November 2019) I can work on another project in December. Little One will have taken about five or six months at the end of November 2019.
I wonder if I can make a bigger game in two months if I planned it well.
Subscribe to:
Posts (Atom)