Scrolling Game Development Kit Forum
SGDK Version 2 => Projects => Topic started by: bluemonkmn on 2009-06-06, 08:23:11 AM
-
I haven't thought of a better name for this project yet, so it's just called Clean Game for now. My intention is to design simple, clean graphics, but make the gameplay interesting. Then if I or anyone else ever gets a chance, the graphics can be enhanced later. That way I don't get bogged down in the graphics never getting back to working on the game.
So far I have:
1. Conveyor belts on which any of my sprites that are affected by gravity can ride like a platform, but the belts are added to the map by simply placing tiles (not sprites). They work well.
2. Worms just crawl along and turn around when they hit a wall.
3. Bombs will show a fuse burning up in about 10 different frames (lasting about 4 seconds) before they explode.
4. Explosions will ignite any ignitable tile next to them.
5. Boxes of explosives will create explosions when ignited, propagating an explosion.
6. Wood piles and torches will create a fire (burning wood pile or burning torch) when ignited.
7. Fire will ignite any neighboring ignitable tile.
8. Bomb throwing Robot will move forward for a certain amount of time, then stop and wait for a short period, then throw a bomb up and forward, then wait another period of time, then continue moving. It turns around when it hits a wall. All of its wait times can be specified as parameters when the sprite is placed on the map.
9. I'm currently working on a sprite that will grow a plant/tree whose shape is determined by the digits of its "structure" parameter, and grows by spawning new tree sprites as it moves and processes the structure parameter.
Most of the graphics are defined in black and white and colored by the frameset so I can create different versions of various graphics by coloring them differently. I haven't done that much yet except to create green and brown ground from the same graphics.
I'm liking the idea of creating ever more complex sprites that spawn other sprites. The bomb robot is a good example. It's a neat sprite because it can spawn a bomb which can spawn an explosion, which can spawn a fire, which can spawn more explosions, so you can get some really sophisticated results out of some relatively simple rules. Maybe at some point I'll make a bomb robot dispensing truck :). I'll probably make some sort of seed planting sprite that can plant these tree sprites.
I wonder how similar my seed idea is to Tanja's. I still haven't been able to get Tanja's game running, unfortunately.
-
You reminded me of this Simpson's monent:
http://www.youtube.com/watch?v=xOnrG6NTmBg
-
i really like your idea, bluemonk! i had something similiar in mind, like plants that spawn other plants in order to revive the planet. but i didn't come to the stage to actually script that.
also the chain reactions triggered by robots, bombs, explosives in boxes etc would be surely cool. that reminds me somehow of games like incredible machines.
how about showing us your results so far?
i bet this game, used as a sandbox could be useful to entice people, either to play, and either to create new sophisticated levels.
ah, i can see it. the plants are growing in the pace of the robots, while these destroy everything in their way. could be tricky for a side to win, if the balance is right.
-
I will try to remember to post some sample when I get my first idea for plant sprouts working.
-
You could do it like a lot of real life plants do... Have plants periodically release a shower of seed sprites that blow long distances in the wind before hitting the ground. This would make the spreading appear less linear. Seeds might even blow over top of gaps or onto different platforms, creating plants in areas that aren't supposed to have them.
-
Here's what I've got so far.
http://sgdk2.enigmadream.com/ben/CleanGame.zip (http://sgdk2.enigmadream.com/ben/CleanGame.zip)
It's possible to make each branch of a plant spawn one of two types of seeds. For now the two types are spawned as bombs and worms, but that will probably change (and you can spawn up to 9 different kinds of seeds if I think of that many).
-
Wow, runs real great. I can't even get mine to do that. I'm able to do graphics if you want. I don't have too much programming skill, but I can serve with graphics! ;)
-
hm, i thought of a topdown perspective and a more tactical strategy thing.
ideas: some plants are type of fire resistant, and their seeds do not sprout until they are burned.
-
Wow, runs real great. I can't even get mine to do that. I'm able to do graphics if you want. I don't have too much programming skill, but I can serve with graphics! ;)
You can't get yours to do what?
If you are able to change only the graphics sheet to improve the graphics, I can import better graphics at any time. If you'd like to change more than the graphics sheet in order to improve the graphics, let me know and maybe we can coordinate our updates so that it won't be too difficult to merge our changes. Of course I can add your name to the credits too assuming I decide to use the graphics.
-
hm, i thought of a topdown perspective and a more tactical strategy thing.
ideas: some plants are type of fire resistant, and their seeds do not sprout until they are burned.
A top-down as it no gravity? Or just more isometric-view-type graphics?
Sprout seeds as in start growing from the seed or drop seeds from their branches?
-
yeah, topdown like no gravity, just a view from the sky.
and when burned, already released seeds start growing.
-
I ran it, but the only problem is i can seem to find the setting to slow the frame rate. (right now it goes at a whopping 300fps) other wise, it looks great. can i suggest something like grabbing the bombs and placing them in places to blow-up elsewhere, like for a stradegy game? or even better! have a huge maze of boxes and three different trails. two lead right back to you and one leads to the goal. place the bomb in the right spot and hope it is not the one that hits you.
-
Add a rule "LimitFrameRate" to the maps plan. Mine was at 500fps before I did that. >.>
This is a good idea that has huge potential. Perhaps water could give plants a boost in growth speed for a period of time, fire/explosions could destroy them (certain species would drop their seeds when burnt(good idea tanja)), the player could have some way to impact it as well, such as wielding a chainsaw.
To make this even better, players should be able to stand on top of the plants, to warrant strategic growth to try and reach secret areas just out of reach.
-
Add a rule "LimitFrameRate" to the maps plan. Mine was at 500fps before I did that. >.>
this helped. maybe this should be an included rule so that it doesn't confuse so many new developers.
-
I ran it, but the only problem is i can seem to find the setting to slow the frame rate. (right now it goes at a whopping 300fps) other wise, it looks great. can i suggest something like grabbing the bombs and placing them in places to blow-up elsewhere, like for a stradegy game? or even better! have a huge maze of boxes and three different trails. two lead right back to you and one leads to the goal. place the bomb in the right spot and hope it is not the one that hits you.
Yeah, the plan is to make the player be able to interact with all these (including maybe even releasing bomb robots), but first I'm just getting a good variety of sprites working.
-
This is a good idea that has huge potential. Perhaps water could give plants a boost in growth speed for a period of time, fire/explosions could destroy them (certain species would drop their seeds when burnt(good idea tanja)), the player could have some way to impact it as well, such as wielding a chainsaw.
The plan is to make water cause a seed to sprout, otherwise all the plants will just grow right away as you see in the demo.
To make this even better, players should be able to stand on top of the plants, to warrant strategic growth to try and reach secret areas just out of reach.
The plan is to make the plants like ladders and the branches like platforms.
-
Wow, runs real great. I can't even get mine to do that. I'm able to do graphics if you want. I don't have too much programming skill, but I can serve with graphics! ;)
You can't get yours to do what?
If you are able to change only the graphics sheet to improve the graphics, I can import better graphics at any time. If you'd like to change more than the graphics sheet in order to improve the graphics, let me know and maybe we can coordinate our updates so that it won't be too difficult to merge our changes. Of course I can add your name to the credits too assuming I decide to use the graphics.
I can't get any of my games to run. But probally because of my programming skill. XD
It depends, on how I do it. I'll get on it soon. Any particular date?
-
There's no specific date or plan for this project. Just working on it as I have ideas. But I hope I can release a Linux version when I'm done too.
-
what about an biological level? one that refrains from classical in the air floating platforms, replacing it with growing plants. the user will have to act a little bit tactical to make some sections grow as he wants to go further. some other sections have to be destroyed because they are in the way.
and i would make some parts of the plants thorny. maybe even as an tactical element. plant sections, which are several times burned or bombed, grow again, but this times with thorns to prevent more danger. this would make them indestructible.
there could be situations, in which the user has to move a few times through the level, maybe coming from diverent directions, gathering things or so. while doing so, he passes some spots over and over, sometimes he has to grow himself a way, on the way back he has to destroy this section. but if he is without plan, this causes the plants to develop thorns or just get hard shelled.
maybe some he has to grow needed items by himself, because all items are born from seeds or so.
-
It's hard to figure out how to make it work with all these considerations:
1) The plants shouldn't be able to grow *anywhere* otherwise the player would be able to freely travel anywhere and there would be no way to block the player.
2) But they shouldn't be limited to very specific places either, otherwise there's no strategy involved.
3) Does the player have some control over the shape of the plants? (maybe picking the right seed grows the right plant?)
4) If the player picks the wrong plant it could make it impossible to play any more; I want to avoid this. Most games prevent the player from getting into a dead end and having to start the game over now.
-
1. Different type of floor surfaces could indicate "fertility" and allow plants to grow fast/slow/not at all. Plants don't grow on concrete right? :)
3. Perhaps watering the left side could allow it to grow faster, or standing on one side could prohibit that sides growth so the other side gets ahead.
4. The player could have a flamethrower/chainsaw/sword to remove plants that are getting in the way.
-
1. have plants that grow specificaly to one direction (one only grows up, another grows more to the left)
2. some how cross pollinate plants to have different growing properties. (cross Up with Left to grow an upper left, cross left with fire to grow on fire to the left)
3. have mulch that makes plants grow slower, faster, or produce more seeds (like on Pok
-
I'm not going to put too much effort into the plants; this game isn't going to be just about growing plants :). I've set that aside for the moment and implemented the ability to climb (plants) and the ability to crouch. While crouching you can move (more slowly) and perform an extra-high jump. It's possible to walk on the branches of a plant using a new tile shape called "TopSolidMidShape". This shape is like top-solid except the solid part starts in the middle of the tile instead of on the top. By pressing down or up you can resume climbing. But that also means you can't crouch while walking on branches, which probably makes sense because you maybe shouldn't be able to perform an extra high jump from such a precarious location. I suppose if you're crouching and you fall you could end up crouching on a branch. I wonder if the player should automatically stop crouching if it turns out he's got nothing solid supporting him (switch to a falling state maybe).
-
you could handle it like the mario games: on ladders/twines you can only climb up or down. hm, i don't remember so really if you could jump out of this. i think yes. but because of the jump Mario had left gone of the twine, so you could jump upwards and just fall down all the way. if you pressed up while being in front of a ladder, you grabbed a hold.
but crouching was only possible on horizontal things.
-
I've spent a number of hours trying to figure out how to make pushable sprites. I've created a "package" sprite to represent a pushable object. Requirements:
1. The packages must be pushable by the player.
2. The packages must not be allowed to move through each other (they should repel other packages).
3. The player should be able to push more than 1 package at once -- push a row of 3 packages for example.
4. The player should not be able to move through packages -- they should push back the player if they can't move any farther.
It's very tricky to allow the player to push a row of 3 packages, but make them all stop when the last one hits a wall.
I think I managed to fulfill all those requirements, but it's much bouncier than I wanted. The packages keep pushing back the player and other packages when they don't need to. It's also not possible to push a package going the wrong way on a conveyor belt. I continue to work on it using various ideas to process rules in the right order to try to make the pushing more smooth without breaking any of the requirements.
-
Sprite collisions such as this should be implemented as preset sprite rules in SGDK2. That's the only thing I believe the engine is missing and as you've said, very hard to implement yourself.
-
Good point Jam0864!
I did a part of what Bluemonkmn is doing in my game. It's not as complicated in my game (no pushing), it's just door sprites that won't allow the player to pass through until the door is opened. This "solid" sprite behavior would really be an asset if it was a preset rule. :)
-
Yes, I was kind of surprised to realize that I neglected to include these as pre-defined rules. For anyone who's interested, here's a couple pieces of what I am using to allow sprites to push each other, but has to be called in the right order if you want more complex pushing to work well. Alone, it should work well to treat sprites as solid, though. Fortunately, it's easy to add this to your own projects even though it doesn't come with the engine, but I will try to remember to add it in the next release. If you add this in a custom code file, it adds two functions for all sprite rules. I think ReactToPush is the one you'd want to use from a simple sprite rule (it calls the other).
using System.ComponentModel;
using System.Diagnostics;
public abstract partial class SpriteBase : GeneralRules
{
/// <summary>
/// Alter the velocity of TargetSprite to plan to move out of the way of this sprite.
/// </summary>
/// <param name="TargetSprite">Sprite whose velocity may be affected.</param>
/// <returns>True if the sprite was pushed, false otherwise.</return>
[Description("Alter the velocity of TargetSprite to plan to move out of the way of this sprite.")]
public bool PushSprite(SpriteBase TargetSprite)
{
Debug.Assert(this.isActive, "Attempted to execute PushSprite on an inactive sprite");
int x1 = PixelX;
int w1 = SolidWidth;
int x2 = TargetSprite.PixelX;
int w2 = TargetSprite.SolidWidth;
int y1 = PixelY;
int h1 = SolidHeight;
int y2 = TargetSprite.PixelY;
int h2 = TargetSprite.SolidHeight;
int pushright = x1 + w1 - x2;
int pushleft = x2 + w2 - x1;
if ((pushright > 0) && (pushleft > 0))
{
int pushx;
pushx = (pushright < pushleft) ? pushright : -pushleft;
int pushdown = y1 + h1 - y2;
int pushup = y2 + h2 - y1;
if ((pushup > 0) && (pushdown > 0))
{
int pushy = (pushdown < pushup) ? pushdown : -pushup;
if (System.Math.Abs(pushx) > System.Math.Abs(pushy))
{
if (!double.IsNaN(TargetSprite.LocalDY))
TargetSprite.LocalDY += pushy - TargetSprite.dy;
TargetSprite.dy = pushy;
}
else
{
if (!double.IsNaN(TargetSprite.LocalDX))
TargetSprite.LocalDX += pushx - TargetSprite.dx;
TargetSprite.dx = pushx;
}
return true;
}
}
return false;
}
/// <summary>
/// Alter the velocity of this sprite to plan to move out of the way of sprites in Pushers.
/// </summary>
/// <param name="Pushers">Sprites that can push this sprite.</param>
/// <returns>True if the sprite was pushed, false otherwise.</return>
[Description("Alter the velocity of this sprite to plan to move out of the way of sprites in Pushers.")]
public bool ReactToPush(SpriteCollection Pushers)
{
if (!isActive)
return false;
bool result = false;
for (int idx = 0; idx < Pushers.Count; idx++)
{
SpriteBase TargetSprite = Pushers[idx];
if ((TargetSprite == this) || (!TargetSprite.isActive))
continue;
result |= TargetSprite.PushSprite(this);
}
return result;
}
}
-
on my ranat game i was able to have the player push a boulder without pushing back at you using the script. ill post the code i use later (when i get to a computer, right now im using my phone)
-
Making the player push sprites is easy. Making them push back is easy too (as shown above). The hard part is doing both while making sure all the sprites push against each other too without bouncing all over.
-
on my ranat game i was able to have the player push a boulder without pushing back at you using the script. ill post the code i use later (when i get to a computer, right now im using my phone)
now that i think of it, the code i used was something like this in VBS
' default speed is 4
With ProjectObj.GamePlayer.PlayerSprite
If .DX > 4 Then .DX = 4 'Player cannot get pushed more than 4 to the right
If .DX < -4 Then .DX = -4 'Player cannot get pushed more than 4 to the left
If .DY < -4 Then .DY = -4 'Player cannot get pushed more than 4 up, gravity remains normal effect
End With
this, way when a sprite pushes against another sprite, it doesn't shove it back. to make things better, you can set it for only certain collisions so if you are rolling something like a huge boulder, you move slower than usual
isn't there something you could do like this in the sprite rules?
-
Well, sometimes the player has to get pushed back -- for example if the pushed sprite hits a wall, then the player tries to walk into it, the player must be pushed back so that it doesn't walk through the pushed sprite.
-
even so, as long as the "pushed" sprite is set to repel, it will still act as a solid. limiting how fast the sprite can go can stop the "bouncing" caused by repeling sprites. it works really well.
-
There is no "repel" setting in SGDK2.
-
I finally got the pushing working "good enough". I have posted an updated version of the project:
http://sgdk2.enigmadream.com/ben/CleanGame.zip (http://sgdk2.enigmadream.com/ben/CleanGame.zip)
Hopefully the old version isn't still stuck in your cache. If you get the latest version, you should see pushable packages.
-
Is it possible to change the resistance the package provides? This would be good as a core sprite rule in SGDK2 too. ;)
-
A sprite either repels/avoids other sprites or it does not. How can this be "partial"? What would you do with the ability to change resistance?
-
It just seems to push the box very quickly, I was thinking perhaps if the player was slowed down when pushing into the box so they couldn't push it so fast you could make bigger boxes that are slower to push, or small particles that simply fly away when you touch them.
-
Is it because I still forgot (I think) to limit the frame rate? Although I suppose having something able to limit how fast a pushable sprite could be pushed could accomplish a couple things I guess. Maybe it's as simple as limiting the velocity of the pushed object to a slower speed (right now it has a high limit).
If you edit the Limit Velocity rule on the Package sprite to limit to a speed of 2 instead of 8, I see you can make them push much more slowly. But for some reason that causes them to be able to go through each other sometimes.
-
It's not because of the framerate, I limited that to 60 myself. It just seems as if the player is not hindered at all when pushing around the box. Maybe instead of limiting the velocity of the box, you limit the players velocity when in contact with the box?
-
It's easier to limit the velocity of the box. It works reasonably well if you move the limit velocity rule above the "react to pushback" rule and set the maximum to 3.
-
I've updated the game at http://sgdk2.enigmadream.com/ben/CleanGame.zip (http://sgdk2.enigmadream.com/ben/CleanGame.zip)
Now there's a world map and you can be hurt by touching enemies.
Controls:
Down arrow: Move down (world map only), climb down or crouch
Left arrow: Move left
Right arrow: Move right
Up arrow: Move up (world map only), climb up or stand up
Ctrl: Enter level or Jump
Space: Drop bomb
There's something I have to investigate, though. Sometimes the red package lands on the plant branch, and then if I stand under it and drop a bomb, the bomb somehow lands on the red package way above me. Something really screwy is going on there.
-
i think i fixed the "box" problem a bit
I changed the "React to Pushback" rule to "If" and added two rules under it. one is 0=dx and 0=dy. this stops the boxes from pushing each other back by "stopping" them (it's not perfect, but it works pretty well).
edit: by "box" i mean "package"
-
What a coincidence, I just did something similar this morning (or was it yesterday). I made the inertia of the boxes be 50% instead of 95%, which improved their behavior significantly. But I also overhauled the ReactToPushBack and related functions. I haven't uploaded the results yet, but I probably will soon, when I have something else worthwhile to show. I also implemented a "seed" state for the sprout sprite so that a plant can start out as a seed. Then I implemented a water droplet sprite that will cause the seed to sprout and deactivate the droplet.
-
I've added a new enemy to CleanGame. It faces the player and jumps every N frames (you can set how long it waits between jumps). Right now it's 120 frames (about 2 seconds).
http://sgdk2.enigmadream.com/ben/CleanGame.zip (http://sgdk2.enigmadream.com/ben/CleanGame.zip)
-
I've added a new enemy type -- a spider that drops down on the player (when the player is below) from a web it creates as it falls, then crawls back up. This project is still not really a playable game but mostly a collection of sprite definitions so far. But it is playable enough so you can at least see how each sprite works. I think the sprites are importable into other projects without too many or any modifications required, so feel free to pick these up in your own projects.
http://sgdk2.enigmadream.com/ben/CleanGame.zip (http://sgdk2.enigmadream.com/ben/CleanGame.zip)
I tried importing the spider sprite into the sample game, and it wasn't *quite* as straightforward as I'd hoped, but it only took a few minutes to straighten out the missing pieces.
-
Hi Bluemonkmn!
I just tried your new version of the clean game! It's very interesting to see all these sprites interact with one another. I especially like the bomb that make boxes explode, then the exploding boxes light fires, then a rocket all in a chain of reaction, very cool! :) When I got to the spider, it didn't drop very far down, since I was walking on a branch of the tree that grows right next to it.
What do you plan to do next? :)
-
I think the spider stops dropping when it hits a solid, and I think it sees the tree branch as solid. I could probably change that with another solidity definition, though.
Next... as usual, I have no specific plans for what's next. At some point I need to start making a game out of this instead of just a collection of sprites and tiles to test the features. But before I do, I want to have a relatively complete set of sprites. And I'm not sure this is complete yet. I'm having a hard time thinking of how these elements can be combined into puzzles and challenges. But maybe that's just because I haven't really tried yet. I did have another big idea that I want to get into a game, though:
Build your own creature -- as you play. I originally thought of this as something analogous to nano-robotics. You collect molecules that behave in certain ways and then release them into the level to form something that will help you past an obstacle. For instance, if there is a bomb on a ledge above you (that you can't reach) that will ignite a fire that will melt some ice to drop a seed that will grow a tree so you can climb up, you need to figure out how to ignite the bomb. Crawling in front of the bomb is a worm. Maybe you have a molecule that reacts with a bomb to ignite it, and a molecule that is attracted toward a worms, and a host molecule that can attach to two other molecules. So you drop the host molecule, then drop the igniter molecule, then drop the movement molecule, and let it go to work. They both attach to the host, and then the whole molecule is attracted to the worm, and when the worm passes the bomb, with the igniter molecule following it, the bomb ignites.
But I need to think of a good general-purpose set of molecules that can be used to create a wide variety of "creatures" without too much effort (development effort or playing effort). These creatures need to be useful in solving puzzles and getting past obstacles. I'm really interested in seeing complexity arise out of simplicity the way you see in John Conway's Game of Life (http://www.bitstorm.org/gameoflife/), or Mandelbrot (http://en.wikipedia.org/wiki/Mandelbrot_set).
-
Wow, I had a lot of fun by fooling around with John Conway's game of life. I could spend hours with this!
Your idea of collecting and assembling molecules is great! :) It seems like a lot of work to make all the sprites interact with one another, but once you have a good set, you can make a lot of puzzles with the same molecules. Can't wait to see that! But I guess I will have to... ;)
-
I have uploaded my next update to http://sgdk2.enigmadream.com/ben/CleanGame.zip (http://sgdk2.enigmadream.com/ben/CleanGame.zip).
It's probably pretty difficult for anyone to figure out how how to use/play this project now without a lot of help, so my next step will be to make a better sample/tutorial level to play with.
But here's what you can do now. The meaning of Space Bar and Enter keys have changed. Space bar now selects an inventory item, and Enter uses/deploys it. (Right now you have unlimited inventory.) The currently selected inventory item is displayed at the top. These are the items:
1. Bomb: same as before, lights a fuse and blows up when it burns up.
2. Nanobot constant power supply. This will automatically seek and attach itself to the nearest Nanobot and provide 200 units of power.
3. Nanobot destructor. Automatically seek and destroy the nearest Nanobot. Wouldn't want your Nanobots overrunning the world!
4. Nanobot mover - Follow mode. Center of a nanobot is responsible for movement. When an attached power supply is supplying power, this will move the bot and all its attachments toward the nearest enemy. (There are other movers, but the player can't deploy them yet; I haven't tested them.)
5. Nanobot collision power supply. This is a power supply that only supplies power when it's touching an enemy.
6. Nanobot splashy power supply. This is a power supply that only supplies power when it gets wet.
7. Nanobot bomb dropper. This attaches itself to the bottom of the nearest nanobot mover. When this bot is supplied with a unit of power, it drops a bomb and disappears.
8. Nanobot water dropper. This attaches itself to the bottom of the nearest nanobot mover. When this bot is supplied with a unit of power, it drops a drop of water and disappears.
Power supplies will terminate if they hit any solid.
If the Nanobot mover to which a power supply is attached disappears, a power supply will seek the next nearest nanobot and re-attach itself to that (this may change -- not sure if this is a good idea).
Bomb or water droppers will terminate if it hits any solid that prevents it from reaching its destination.
Nanobot destructors can only be stopped by a biohazard tile or another destructor.
Nanobot movers will react to solidity and will terminate only when hitting a nanobot destructor or biohazard.
-
Hi!
I was playing around with all the nanobots and eventually, I was surrounded with many nanobots part (still trying to figure some of them out). I spawned a nano-destructor to clean the place up a little and I got this error: Attempted to access PixelX on an inactive sprite. The nano destructor probably spwaned right on another nanopart when it happened. I'll restart the game and try some other things. :)
-
I got that error once, but was unable to reproduce it. If you can figure out how to reproduce it, please let me know. I don't think it had to do with the position, but which other bots were "attached" to the bot that was destroyed, and what order they were created.
-
Here is a way to reproduce it:
1- Drop a water generator nanobot: green circle with drop of water
2- Drop a bomb nanobot: small bomb
3- Drop a auto-generator: green circle only.
When they merge, it crashes.
It does the same if you replace the water generator (1) with a collision-generator or the nanobomb (2) with a drop of water.
I guess the program doesn't like to have an auto-generator with another generator on a nanobot.
I hope it helps! :)
-
Thanks! Found and fixed the problem (locally). The problem is that when a generator is attached to a sprite, it will try to force the attached sprite to process its rules before positioning itself next to it (in SpriteCustom.cs, the "StickToAttached" function calls ProcessRules before doing the rest of the work). But ProcessRules can cause the sprite to terminate itself. So to fix it, I simply moved the code above that checks "if (RidingOn.isActive == false) ..." below ProcessRules. Then it works fine.
-
I wanna try making something with this! ;D
-
Is this game between genres? When I think about it, I may be trying to combine elements of RPG/adventure, puzzle and side-scroller games into one game. I noticed this when I was trying to figure out what to do about inventory. What to do about inventory the player finds in one level when the player visits another level? You can't be using items intended for solving one puzzle in solving another or it will be too easy. I tried to think what other games do with this, and realized that I don't know of any other games where the inventory acquired in a side-scrolling level are necessary for solving puzzles, and can be retained between levels. Any thoughts? I kind of like the idea of *having* the option of having to go to other areas to find items to solve puzzles. That's what RPG and adventure games do. But they have a much wider variety of items. But I don't really like the way "Key Items" in RPG games like Final Fantasy are good for nothing besides getting past a certain point in the story/game. I like normal items that you can collect and actually use however you like. I have to be careful not to let the player get stuck, having mis-used all of a particular item and then being unable to find any more, but I also have to be careful to not make it too easy to find the item. So maybe I will put items in other areas with some challenge to get them, but then they come back if you re-visit the level. That works for relatively rare items, but what about overcoming common obstacles in every level. I can't put all the bombs in one area. It would get boring having to go back there to get bombs all the time. I'll keep thinking. Maybe each level needs a gate that resets certain inventory to certain levels. That seems a bit like cheating (as a game designer), and makes planning how you want to *play* the game less interesting.
-
The idea of limiting inventory might be achieved with, and I'm sure you'll love this idea, more inventory! For example, if you need a certain amount of liquid nitrogen to get past a certain puzzle in location X, but it can only be found in location Y, then you have to have a container that can only hold a certain amount of it, which you could pick up at location Z, bring to location Y to fill it up, then go to location X to use it. Its (correct) use could destroy the container so that you can't re-fill it again, while incorrect use would allow the container to be refilled.
Another option would be to have inventory with an expiration. You can impose some "time" limit on an item. If you go walk too far with it, it spoils, or goes bad, or evaporates, or solidifies, or runs out of power, etc. etc., so you have to find a nearby source of the item to use it in a certain puzzle, and you can't just stock up on it. It's something like your gates, but with less of a "cheating" feel to it.
You could add more items to extend the life of certain items at the expense of, I suppose, money, or something, so if you have enough money, you can buy more batteries so it doesn't run out of power first, or something. Or you can take batteries out of one item and put it in another, so that you can transport it farther, rather than using the nearby but harder-to-reach source.
-
Interesting ideas indeed. I haven't been designing many levels lately, so it's just a fear I have at this point, but if and when I run into a real concern about having too much inventory too easily, I will have to consider these solutions. I kind of like the "container" idea or some variation of it... requiring another item in order to use the items. Another idea that this triggers is that items only work in a certain environment. For example, maybe some bombs only work in an oxygen atmosphere because they have fuses that combust normally. So there could simply be another kind of bomb if I really want to control where they get certain bombs. Of course I'd want to limit the number of cases where I use that kind of solution. The inventory has a limited size, and I don't want it to be full of different kinds of bombs only.