Every single time. Every Single Time!
I keep finding new bugs in Little One. Recently I realized there were problems with the critter loading and egg dropping. It took a day to fix them, but I wanted to get so many other things done. The object loading also caused a bit of lag in the beginning, so I distributed the loading over several frames. Basically, instead of looping and loading a list of objects at once, I just loaded one object per frame. Many process functions are just infinite loops.
Constant bug-fixing is starting to get depressing. With a library of resources and assets, game creation might be faster. Sure there are many different asset sources, but the assets must fit with the game you are making. Some assets are too common. Dozens of barrels and crates can be found easy, but a fully animated character or enemy is rater hard; especially if you need a specific design.
I'm considering re-using assets from my projects, and even releasing them under permissive licenses on open game art. Asset creation can become boring if you need to make a lot of assets. Creating assets randomly for others might not be the best idea. Having a plan, or creating a full asset set is a better idea.The main reason I prefer to use my own assets is the licenses. I don't mind giving credit, but I don't want to forget to give credit.
My plans after I'm done with Little One will be to slowly release select assets first. I'll focus on planning a few different games with cross-asset use. Minor assets will be modified or created during the planning stage. These assets I make might be released publicly before the game is done.
Every month Little on isn't completed feels like a failure. I keep plugging away at it, but the downloads still remain at zero. If others did play my game, they might not like finding crashing bugs. While I'd like to have help finding bugs, I know there will be toxic people who would hate finding a bug in their game. That could become even more stressful.
Size and complexity also makes game creation take longer. Lack of planning also makes game development harder. I'm going to try detail-planning my games and trying to simplify the mechanics as much as possible. Useless or over-complex things will be dropped or modified.
The next game I'll be working on will probably be Blue Bloom. This will be the game I create and refine my planning process. The idea will be to use numbers under ten (0-9) to structure the planning. I think having restrictions from the start might help the planning process.
There is a link here where you can get Little One. Get it before it updates and all the good bugs get patched.
Showing posts with label dev. Show all posts
Showing posts with label dev. Show all posts
Thursday, March 5, 2020
Tuesday, January 7, 2020
Mechanically Disinclined
You've got a fantastic game idea, don't you? Listed all the things you want to be in it and put in a little planning, right? Maybe you've planned the maps and resources needed as well? Now you are just sitting there, wondering where to start. Enemies, crafting, inventory, which mechanic should you start upon?
The place to start in any major project is the foundation. In games, that would be the core mechanic. There are several types of mechanics in games, core, supporting, challenge, and extra/other. I'll go over these mechanics so you can better identify them and choose the actual core mechanic.
Core mechanics, although there is usually just one, are used throughout the game; or to beat the game. Minecraft is obviously crafting, since you have to craft tools, weapons, and armor to progress. Mario games have Mario's base moveset (jump, punch, kick) as the core mechanic. Fighting games have character movesets as the core mechanic. Can you guess Pokemon's core mechanic? It's not capturing, but battling. You have to battle to progress or win the game, like any base RPG, but capturing is needed to get more characters to battle with. Capturing is a support mechanic.
Support mechanics are used to support the core gameplay. Minecraft has mining. You have to mine wood to get materials to craft tools for more mining. Mario usually has support pickups (mushroom, fire flower, tanuki) while most fighting games just use the core mechanic. With Pokemon, capturing is the support mechanic to get characters to battle with (no capture nuzlocke anyone). Most challeng mechanics are used to control the games pacing or make it more fun. If you could just beat Bowser without collecting the macguffins and unlocking the worlds, Mario games would be boring.
Challenge mechanics are used to give the player a challenge. For most games, this is usually the enemies you fight. Sometimes the challenge mechanic is a support mechanic as well, like in Pokemon. Minecraft would be even more boring without the mobs to kill, but it would still be nice to explore. Timers, puzzles, goals, and achievements are usually challenge mechanics. Anything that is used to determine/cause a losing scenario is usually a challenge mechanic. Player stats are a great example of a simple challenge mechanic.
Now for the final type of mechanic. Extra/other mechanic usually don't affect gameplay much, but it can add to it. For Pokemon, the trading mechanic is extra. All the Pokemon could be in a single game, but trading was added to expand the game. Similarly, items in Super Smash Bros. and Mario Kart are extra (but fun) mechanics. Wile these extra mechanics add to the game, too many can bog down the game or expand development times (going to ludicrous dev time). If it isn't a core or support mechanic, work can usually be delayed upon it.
Some things to consider about mechanics. Some games are just a core mechanic (fighting games). The advertised mechanics are not always the core mechanic (pokemon). Some games can have either two core mechanics, or core/support symbiosis (minecraft) where the core and support mechanics work together to hold up the game. Core mechanics can also support other mechanics. Extra and challenge mechanics should be the last worked on and the first to be cut. Online play is almost always an extra mechanic. Inventories are almost always a support mechanic.
You should almost always work on the core or support mechanic first. As a developer, you can give yourself the macguffins needed to use the core mechanic. Unless the core mechanic really needs a support mechanic, start with the core mechanic. Mechanic don't have to be perfect, just working; polish can come later.
Little One just had two main mechanics when I started, the vacucell collector and farming. Item collection was the core mechanic and farming was actually supposed to support a challenge mechanic. Those were the first two mechanics I started with.
Blue Bloom has several mechanics, more than Little One. I was confused at first what mechanic to start upon, but crafting will be the core mechanic. Resource collection will be a support mechanic with the flora and fauna being challenge mechanics. In fact, Blue Bloom will have several challenge mechanics.
The place to start in any major project is the foundation. In games, that would be the core mechanic. There are several types of mechanics in games, core, supporting, challenge, and extra/other. I'll go over these mechanics so you can better identify them and choose the actual core mechanic.
Core mechanics, although there is usually just one, are used throughout the game; or to beat the game. Minecraft is obviously crafting, since you have to craft tools, weapons, and armor to progress. Mario games have Mario's base moveset (jump, punch, kick) as the core mechanic. Fighting games have character movesets as the core mechanic. Can you guess Pokemon's core mechanic? It's not capturing, but battling. You have to battle to progress or win the game, like any base RPG, but capturing is needed to get more characters to battle with. Capturing is a support mechanic.
Support mechanics are used to support the core gameplay. Minecraft has mining. You have to mine wood to get materials to craft tools for more mining. Mario usually has support pickups (mushroom, fire flower, tanuki) while most fighting games just use the core mechanic. With Pokemon, capturing is the support mechanic to get characters to battle with (no capture nuzlocke anyone). Most challeng mechanics are used to control the games pacing or make it more fun. If you could just beat Bowser without collecting the macguffins and unlocking the worlds, Mario games would be boring.
Challenge mechanics are used to give the player a challenge. For most games, this is usually the enemies you fight. Sometimes the challenge mechanic is a support mechanic as well, like in Pokemon. Minecraft would be even more boring without the mobs to kill, but it would still be nice to explore. Timers, puzzles, goals, and achievements are usually challenge mechanics. Anything that is used to determine/cause a losing scenario is usually a challenge mechanic. Player stats are a great example of a simple challenge mechanic.
Now for the final type of mechanic. Extra/other mechanic usually don't affect gameplay much, but it can add to it. For Pokemon, the trading mechanic is extra. All the Pokemon could be in a single game, but trading was added to expand the game. Similarly, items in Super Smash Bros. and Mario Kart are extra (but fun) mechanics. Wile these extra mechanics add to the game, too many can bog down the game or expand development times (going to ludicrous dev time). If it isn't a core or support mechanic, work can usually be delayed upon it.
Some things to consider about mechanics. Some games are just a core mechanic (fighting games). The advertised mechanics are not always the core mechanic (pokemon). Some games can have either two core mechanics, or core/support symbiosis (minecraft) where the core and support mechanics work together to hold up the game. Core mechanics can also support other mechanics. Extra and challenge mechanics should be the last worked on and the first to be cut. Online play is almost always an extra mechanic. Inventories are almost always a support mechanic.
You should almost always work on the core or support mechanic first. As a developer, you can give yourself the macguffins needed to use the core mechanic. Unless the core mechanic really needs a support mechanic, start with the core mechanic. Mechanic don't have to be perfect, just working; polish can come later.
Little One just had two main mechanics when I started, the vacucell collector and farming. Item collection was the core mechanic and farming was actually supposed to support a challenge mechanic. Those were the first two mechanics I started with.
Blue Bloom has several mechanics, more than Little One. I was confused at first what mechanic to start upon, but crafting will be the core mechanic. Resource collection will be a support mechanic with the flora and fauna being challenge mechanics. In fact, Blue Bloom will have several challenge mechanics.
Friday, January 3, 2020
A Fungus Among Us
I'll be starting on my two-month project, but it may actually take three or four. It's a sci-fi "horror" game called "Blue Bloom". You'll have to clean a planet of an infectious, parasitic, fungus while stationed upon an island. This means that most clean-up efforts will be long-range. Cures will have to be analyzed and built via a crafting and modular building system.
This project will use resources from my two previous projects, along with adding more resources. while it will draw from previous experience, I'll be learning new things as well. Currently I'll be setting up a basic player and testing distance. I'll be adding a LOD system to this game for optimization. I think large faces render slower when they are close to the player, so this should break that up.
There will be several different spawn caps for creatures, both soft and hard. The soft cap is just for normal spawning, while the hard cap controls "event" spawning. Since creatures may be spawning in/out regularly, I'll be using signals to coordinate the spawns; reducing lag. This entire project is me seeing how fast I can put a game together when I have numerous resources.
Little One will still be worked upon, and updated. Many ideas from that game will be adapted for Blue Bloom. Not only the vacucell, but the crafting materials as well. A few materials will be added in Blue Bloom, making the count about twelve or more. If I use preexisting resources, most of this project will just be coding.
The map for Blue Bloom will be comprised of smaller scenes, also comprised of smaller scenes. Each map piece will be made of cells. The idea is to make a handful of specific cells and use a lot of them to build the map pieces. These pieces will be controlled via scripts to change their mesh or visibility as needed. I think the map will run a bit faster if I set the cell visibility even outside the player's view. I'm not sure if the creatures will have navigation abilities, but I'll try to include that from the start.
The map will be 8x10 areas in size and the areas might be roughly 10x10 cells. That's 800 scripts running a loop of 100 each frame to handle cell visibility, or is it? If I only check one cell per frame, I eliminate all those loops. The script can get through all the cells in 1.5-3.4 seconds (depending on frame rate). This will cause some problems with low-frame rate or lag.
While a single script could handle all the map areas, iterating all the cells of all the map areas every frame or X-frames could cause lag. To reduce even more lag, I might just check the nine map areas around the player.
To do this, I'll probably surround each map area in an area node and give them all grid coordinates. When the player enters an area, the current grid coords will be changed and I can write a script that organizes and acquires the map areas.
Creatures will change their own animation progression and visibility since they'll all have scripts. They should spawn within a pair of ranges from the player, to be changed by other factors. Any critters spawned will be direct children of their spawner and should only travel a set distance from their parent before returning/despawning. To keep the pressure on the player, I'll be playing fast and loose with the spawns.
Major hard points will include the sky, navigation, creatures, collision shapes, and map handling. I'm in no way ready for this project, but I'll be doing it anyway.
This project will use resources from my two previous projects, along with adding more resources. while it will draw from previous experience, I'll be learning new things as well. Currently I'll be setting up a basic player and testing distance. I'll be adding a LOD system to this game for optimization. I think large faces render slower when they are close to the player, so this should break that up.
There will be several different spawn caps for creatures, both soft and hard. The soft cap is just for normal spawning, while the hard cap controls "event" spawning. Since creatures may be spawning in/out regularly, I'll be using signals to coordinate the spawns; reducing lag. This entire project is me seeing how fast I can put a game together when I have numerous resources.
Little One will still be worked upon, and updated. Many ideas from that game will be adapted for Blue Bloom. Not only the vacucell, but the crafting materials as well. A few materials will be added in Blue Bloom, making the count about twelve or more. If I use preexisting resources, most of this project will just be coding.
The map for Blue Bloom will be comprised of smaller scenes, also comprised of smaller scenes. Each map piece will be made of cells. The idea is to make a handful of specific cells and use a lot of them to build the map pieces. These pieces will be controlled via scripts to change their mesh or visibility as needed. I think the map will run a bit faster if I set the cell visibility even outside the player's view. I'm not sure if the creatures will have navigation abilities, but I'll try to include that from the start.
The map will be 8x10 areas in size and the areas might be roughly 10x10 cells. That's 800 scripts running a loop of 100 each frame to handle cell visibility, or is it? If I only check one cell per frame, I eliminate all those loops. The script can get through all the cells in 1.5-3.4 seconds (depending on frame rate). This will cause some problems with low-frame rate or lag.
While a single script could handle all the map areas, iterating all the cells of all the map areas every frame or X-frames could cause lag. To reduce even more lag, I might just check the nine map areas around the player.
To do this, I'll probably surround each map area in an area node and give them all grid coordinates. When the player enters an area, the current grid coords will be changed and I can write a script that organizes and acquires the map areas.
Creatures will change their own animation progression and visibility since they'll all have scripts. They should spawn within a pair of ranges from the player, to be changed by other factors. Any critters spawned will be direct children of their spawner and should only travel a set distance from their parent before returning/despawning. To keep the pressure on the player, I'll be playing fast and loose with the spawns.
Major hard points will include the sky, navigation, creatures, collision shapes, and map handling. I'm in no way ready for this project, but I'll be doing it anyway.
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, September 30, 2019
Node of Command
So I told the build menu, to tell the build system, to tell the building; to upgrade. This all while the game was "paused". Any node with a script is able to get another node to run functions within their script. Something like node.function() where node is the node that has the function, and function is the function. Clear as mud until you try it.
This is great in situations where signals may be too troublesome to set-up. I'm not talking about default signals, but custom connections. It is also helpful where you can get or pass a node with w function you want to run. Not sure if you can run a node's functions on another node, but if I can I'd probably crash the engine every day. Might try it just to check.
The game is never truly "paused". Pausing the scene tree in godot just pauses processing functions (process, input, physics). Signals and calling other nodes' functions from an active node still works. (Running the _process function on a node from an un-paused menu node might crash godot) This means I can cause NPC expressions, object building, and general mischief while the game is paused just from a single active node. Cascading function calls anyone? (How to mess with the player, 101)
Arrays (really?) and dictionaries are passed by reference, not copied. This means that if a node's script sets a dictionary as equal to another dictionary, changes are synced across all instances of this dictionary. So my silos will grab the parent's exported dictionary which will be referenced from a global building dictionary (or even a nested dictionary). So updating the silos when you add/remove items will update the master dictionary.
And there are still tricks to find.
This is great in situations where signals may be too troublesome to set-up. I'm not talking about default signals, but custom connections. It is also helpful where you can get or pass a node with w function you want to run. Not sure if you can run a node's functions on another node, but if I can I'd probably crash the engine every day. Might try it just to check.
The game is never truly "paused". Pausing the scene tree in godot just pauses processing functions (process, input, physics). Signals and calling other nodes' functions from an active node still works. (Running the _process function on a node from an un-paused menu node might crash godot) This means I can cause NPC expressions, object building, and general mischief while the game is paused just from a single active node. Cascading function calls anyone? (How to mess with the player, 101)
Arrays (really?) and dictionaries are passed by reference, not copied. This means that if a node's script sets a dictionary as equal to another dictionary, changes are synced across all instances of this dictionary. So my silos will grab the parent's exported dictionary which will be referenced from a global building dictionary (or even a nested dictionary). So updating the silos when you add/remove items will update the master dictionary.
And there are still tricks to find.
Thursday, September 26, 2019
It's a cube, it's a sphere, it's a placeholder!
Added a build system to Little One. I'm currently using placeholders for the upgrades and a couple of buildings. So far it is going good, but there are only upgrades for one building. The upgrades are hidden below the building and moved up once activated.
As you can see, the buildings can be created, deleted, and one can have upgrades. The final version will require materials to create the buildings and upgrades. After the upgrade placeholders are done, I'll add the actual upgrad objects and material requirements.
As you can see, the buildings can be created, deleted, and one can have upgrades. The final version will require materials to create the buildings and upgrades. After the upgrade placeholders are done, I'll add the actual upgrad objects and material requirements.
Subscribe to:
Posts (Atom)