https://www.dicegamedepot.com/opaque-dice-set-of-1000-white-12mm-d6s/
https://www.dicegamedepot.com/opaque-dice-set-of-1000-black-12mm-d6s/
It would cost me over $1300 for this particular image!
|
|
I've updated the image generating algorithm to draw images with dice and I'm really happy with the results! I only used the following images to generate the pictures. The following image would take 10212 dice to create, and while I'd love to buy the dice to create it... https://www.dicegamedepot.com/opaque-dice-set-of-1000-white-12mm-d6s/ https://www.dicegamedepot.com/opaque-dice-set-of-1000-black-12mm-d6s/ It would cost me over $1300 for this particular image! This one is higher res, and requires almost 21000 dice!
0 Comments
I haven't edited this blog in quite some time, but that doesn't mean I'm not working on more fun stuff!
However, in lieu of managing this blog I will just be posting my newer projects in the Examples Of Work tab. This was a project I started on a while ago. Eventually I plan on building this on a microcomputer and building a box to put it in so it is like a retro arcade machine. These are a few gifs showing some of the interesting mechanics.
Djikstra's and Best First run as you would expect, but I modified the A* algorithm so that the priority was: backDistanceToStart + distanceToGoal * 3. This gives the A* algorithm a much faster search time, but at a slight penalty of "stupid AI" when they curve into certain areas instead of making straight paths like what you get with Djikstra's. This is the A* search. You can see the results of what I described above in the very first "room" that the agent starts in. Instead of pathing directly downward, the agent goes a bit into the room. It isn't quite as bad as best first, but it is a price you pay for performance. I eventually want to add a slider to A* so that you can individually weight the two different costs for the priority, as it is a fairly important piece of making a good A* algorithm. A* is the best of both words in my eyes. It is more customize-able to the situation at hand and is both efficient and produces a "semi-intelligent" path. Djikstra's search, as you would expect it. This search should always return the fastest path to run through, but it definitely isn't the fastest to calculate. Best First. Not the most elegant of solutions, but definitely a fast one given the right circumstances. This is the kind of search you would use for a map like a paintball course, where there are many small obstacles throughout the map, but not very many walls.
A second prototype level is up and running that I can use to play around with some mechanics, and I started working on a second prototype boss to get some player feedback.
The tendrils seen in the gif below will render the platforms useless so the player can't use them. I plan on starting with just the 4 mini eyes for phase 1, and they will randomly pick 2 of the 4 abilities. (IE 2 will cast 1 random ability, and the other 2 will cast another random ability). I'm doing this so the player isn't overloaded with the possibility of 41 different possible attack patterns. Instead, there are only 6 possible attack patterns that the player has to watch out for. Currently 1/4 abilities work for phase 1 out of 2 total phases... I have a bunch to do... I realized that I wanted to make some quality of life changes to the game for better playability.
Finally... Something that I can really show to people and get a good feel from them about how the game works.
I went kind of ham today. I added a camera shake effect, the first enemy type (they dash at you repeatedly doing blunt melee damage), and the first boss (as seen in the gif below). I definitely need to spend some time cleaning up some of the sprite layering and make it more noticeable to the player when they take damage, but I'm happy about where it is in such a short amount of time. I ran into an issue where when the boss is doing the spray attack, the audio from the guns works for about a second and then just stops, but every other sound in the game keeps going... So I need to figure out why that is happening. Blood!
What is even the point of shooting down enemies if they don't bleed? With this thought in mind, I created blood spurts when you shoot your enemies. Blood currently just sticks to platforms, but eventually I could even make it cover the character or other objects in the scene. Right now, this is a very primitive effect. I spawn X amount of blood "particles" when I hit an enemy, and they use gravity to fall until they collide with a platform object. When they collide I disable every functioning element of the blood particle so it is just a GameObject with a SpriteRenderer attached. The "layering" effect seen on the ground is simply because of Unity's built in collision system not checking for future collisions, but it adds a nice effect so I'm keeping it for now! OPTIMIZATION!
Aside from a few interesting effects like bullet casings that fly out whenever you shoot, I basically spent a few hours tonight optimizing the game and code to be more efficient and easier to work with as we move on. I implemented an "EffectRecycler" that reduces the amount of times I have to actually create new objects. Instead of a bullet deleting itself when it has either hit a wall or enemy, or reached its life span, it instead disables itself and becomes ready for use for the next time you take a shot. The next time you shoot, it instead just re-initializes the bullet in the right position/rotation/velocity/etc. Aside from efficiency, I implemented a system where you can hold down left shift to slow down time which is very useful for some of those tight corners. I also put all of my tuning variables in a single static file so that I can see everything in one spot, and finally got some testers to give me feedback! Most of the feedback I received was actually fairly positive, with the only concerning point being that the camera feels sort of "jerky" at times. Sorry for no image, nothing visually new was added. A second night, not as long as the first, but still productive. Tonight I added a very nice "flowy" camera that bases its position around certain things happening in the game (collection of important objects locations, velocity of player) and smoothly moves around. The camera also adjusts the orthographic size based on the events happening in the game as well. If you are moving really fast and fighting the boss, the camera would likely be at its maximum size (what would look like the camera zoomed out) whereas if you are simply standing there idle, it would be more zoomed in. When just the player is in view, the camera will base its position on the players position and velocity. (It will try to position itself in front of the player so you can see more of what is ahead). I'm still deciding if I want to also add a variable in there that positions the camera based on the way the player is looking. If there are any enemies (or anything important) within a reasonable distance, then the camera will also take them into consideration for their position. The system is set up such that each important object is like a magnet with different levels of pull... The player and bosses would have a fairly high level of importance, so their pull is much stronger than some simple enemy and the camera will tend to float more towards their locations. I also added a very simple damage function, that works half-way as of now. There is no HP in the game yet, so I can't actually deal damage to the player, but what I can do is temporarily disable the players control of the character and knock the character back from the location they were hit. There are like 30 variables that need tuned already... I need to start getting a few people to try it out and give me some feedback so I can tune it for the greater good. The image below shows how the camera reacts with a boss in the room.
|
TL:DRI'm working on a solo project, and having a good time with it. Here I am blogging about my experiences doing so, and I talk about interesting things or hurdles that I may have had to overcome. Archives |