next »

[morphinegames]

Hey Guys!

So crazy morning doing performance tuning and part of this involved rewriting our core engine in order to support mesh instancing.

It was all worth it though because we went from chugging at 3FPS with 20k objects to maintaining a stable 30FPS with 20K blocks being simulated.




In the screenshot above each cube is its own independently updated object. We are making very good use of DrawMeshInstanced and really loving it.

[morphinegames]

Sunset on the first round of performance optimizations. We went from rendering 20k objects at like 3FPS to 20k objects at a solid 30FPS and for more realistic scenarios, 2500 objects have gone from 40FPS to 120+FPS



The "high rise" above was generated by our performance tests, it's composed of 1500 rotator objects each one being independently simulated once per second and rendered at 120+ FPS.

[morphinegames]

I added lots of graphics options for all range of PCs. This screen capture shows the change in fidelity when you turn them all off

[Pixelologist]

In regards to your top of the page post - you're going to need to get that to 60fps. I mean, right? Find me a player who wants to play a game like the one you're developing at 30fps.

[morphinegames]

You are right and 60 fps is what it will run at. The top page post was a stress test purposefully meant to break the system. However in real gameplay, it would be almost impossible to cover the island with 20k blocks and have them all visible on the screen at once like in that screenshot unless you set out to do just that in which case the system would handle it, but not at 60FPS currently but hopefully soon

[morphinegames]

Hello everyone!

So it's been a long day of tweaking and tuning game play to find the right balance between accessibility (YUCK) and depth

For a long time I have been going back and forth on product spoilage, product aging, etc. For example, should products have a spoil rate and if so, how do we convey that to the user. Additionally, some products "morph" through aging, for example, grape juice morphs into wine if aged long enough. Wine morphs into vinegar if aged long enough.

I finally settled on a model that I like and that I will be moving forward with. Each product has a defined "life" value, which is in cycles (minutes). For example coconuts might have a life value of 10, this means that after 10 minutes (cycles) the coconuts will expire and either disappear or the container's contents will become invalidated. However when grapes life exceeds that value, it would convert into a new product - wine which would have its own life value which when expired would become vinegar and vinegar would have its own life cycle which when expired would spoil (invalidate).

The screenshot below shows a first pass at how the UI will look

The green number is the amount of money earned when the product is delivered to a port
The red number is the amount of money that it costs to process this product in a combiner (for example when toasting coconuts to make toasted coconut)
The blue time value is the amount of time LEFT until the product morphs/expires. This is a count down.



I mentioned processing cost (the red number) and just a clarification on the current ruleset for that.

1. Products start out as raw ingredients NOT in a container (see left side of screenshot)
2. When a product goes into a combiner (thing with blue port) it is processed and the cost is equal to the red number
3. Multiple products can be combined in a combiner - up to 3 and the total processing cost would be the sum of the red numbers of each product
4. When a product leaves a combiner it is in a container. Products age at half the normal rate when in a container.
5. Sending a product already in a container through a combiner without any other inputs costs the red # but also resets the age which can be a way of extending the life of a product in order to get it to a port
6. Combiners have a mode which is determined by the color of the top face and that mode can be switched by right clicking the top. The three modes are normal (black) heat (orange) and cool (blue)
7. Each mode has a different time it takes, for example normal mode is a single cycle (1 minute), heat is currently 3 cycles and cool is 5 cycles. Different products can be created by combining different ingredients with different modes, for example, pineapples + coconut + rum + cold = pina colada.
8. Each mode has a cost multiplier, for example normal mode is (sum processing cost)x1, heat mode is (sum)x3 and cool mode is (sum)x5 currently.

Part of the strategy of the game is determining the best assembly lines to maximize throughput keeping in mind time to process for each mode, distance between raw product spawners and product lifetimes.

More tomorrow!

[morphinegames]

Hello everyone!

So the past two days have been about finalizing and tweaking the mechanics of the system to ensure an accessible (YUCK) but deep gameplay experience.

Today I wanted to talk about the last of the 4 blocks (yes we combined 2 others into 1) - the Teleporter.

Like we discussed yesterday, every cycle of the game, products age. Aging can be a good thing or a bad thing depending on the product, for example aged bananas spoil and invalidate, but aged grapes turn into wine and then vinegar, both products that are valuable.

We also mentioned how products in containers age at half the normal rate.

Well the final block in our tool kit is the Teleporter.



At first glance, the teleporter is a very simple setup, it teleports a container or product from it's blue input port to it's green output port. The thing about teleporters is that they can be chained together and since there is no delay, this ends up being a much faster way to transport goods then with a belt. Of course there is a higher cost associated with teleporters. Their per cycle cost is double that of a belt, $2 instead of $1 currently and additionally there is a charge for transporting a product through them equal to the processing cost (red #) of the product.

Since teleporters operate in a space time continuum - there is another cool feature of them - they REDUCE AGE. For every block in the teleporter chain, one minute/cycle is removed from the time of the product. So let's say for example that we have a product that is about to expire, we can send it through a teleporter chain of 20 and effectively add 20 more cycles to that product's life.

But there is even more, when a product's age goes in reverse, it can morph as well, so vinegar's age being reduced past 0 turns into wine!

There is one final thing about teleporters which makes them really cool. You can use them to duplicate products. If there are multiple outputs on a teleporter chain, there will be multiple products spit out! How cool is that? Of course you pay the processing cost again for each additional product produced

[morphinegames]

In case I didn't mention this before, Gastrocove's internal simulation operates on a grid and then we layer island stuff on top of it but for efficiency we operate using integer grid coordinates and we won't allow floating point precision when placing. So everything will snap to an integer coordinate.

I made a little vid of our demo island and what it looks like to the simulation vs the end user. When the island decoration is off, you can see only the objects that are part of the simulation and then we layer it back on top

[morphinegames]

Hello there!

So there isn't going to be a lot of visual stuff to show over the next few days because right now I am narrowing down the product list from a TON of options to a more manageable amount.



I want all of the products that can be harvested and produced on the island to be somewhat authentic to what can actually grow on an island. I want the raw ingredients that are chosen to lead to lots of "bang for your buck" - for example in the above picture, dragonfruit is cool but how many actual real world products can be made with it? It's a niche ingredient that doesn't add a lot of value to the game. A couple of those are OK but the above list has far too many.

The list below is much closer to where I want to be with raw ingredients (those that are spawned by nature - ignore rum)



While the list is much more condensed, it can lead to a LOT of derivative products that can be made with just the above ingredients. This leads to a situation where the player isn't overwhelmed with tons of raw ingredients and can instead focus on the products that they want to build using those ingredients.

Oh and as an extra bonus, the number of cooking options in the combiner has increased by 1, the list is now

1. Mix - this is just a standard combination of ingredients, e.g. Mint + Ice Cream = Mint Ice Cream
2. Cool - this is a cooling "process" e.g. pineapple + rum + coconut cooled = pina colada
3. Heat - this is the heating "process" e.g. heating mint + water = hot mint tea
4. Grind - this is a grinding process, for example grind + macadamia nuts = macadamia nut butter
5. (New one) Ferment - this is a fermentation process and it's going to let us make rum drinks as well as some other cool stuff

Until next time - thanks for reading!

[morphinegames]

Hello everyone.

So I have finally come up with a semi-final product list for the island. The product list consists of 17 raw goods which can be found on the island and 87 products that can be built with those raw goods.

Of these products, there are 26 which are heated, 16 which are cooled, 13 which are fermented, 23 which are ground, and 9 which are just mixed.

Some of the longest chains require 7+ products to be combined into the final output product so there are some really long chains in here.

One other thing which was implemented this week was a refactoring of the aging/price system. Previously as mentioned, products age and when they reach a certain age they either expire or  morph into something new, e.g. grapes > wine > vinegar. I have done away with this system because I found that it was too complicated to reason about and I have replaced it with something which is a little bit easier to understand/implement for end users.

In the new system, every product still has a lifetime after which the product expires, so for example, wine may have a lifetime of 100 cycles (minutes), after 100 minutes the wine would just invalidate and disappear. However, now every product has an age/price curve. The age price curve determines the sale price of the product at a specific age. For a lot of products, this will be a flat "curve" where the price doesn't change, however for some products such as wine, the price will gradually increase and then decrease (or other variations of the curve model). This will allow for some real creativity when designing your assembly lines to age a product for its maximum amount before delivering it to a port.

Until next time!

[morphinegames]

Happy weekend! Humble beginnings on the island

[morphinegames]

Hello everyone! I am going on vacation this week for some snowboarding in Mammoth but before I leave, I wanted to let everyone know what I've been working on.

So last week was all about finalizing the raw ingredient/product list which I did and the last big task that I have for alpha (and the one that will take the most time) is to start fleshing out the island, increasing it's size, figuring out where all the raw ingredients will be placed to maximize the game play curve of challenge and reward, etc.



One thing that has stuck with the project for a while is the way terrain is handled. In Gastrocove, everything operates on an integer grid system, e.g. (1, 1, 1), (2, 2, 2), etc. Pretty much everything in Unity operates with floating point Vector3s but our internal simulation engine is using Vector3Ints. This is for performance reasons and also because we want placement of blocks to be precise, to snap nicely, and give a nice end user experience.

So what does this have to do with terrain you might be asking?

Well if you look at the picture above, you can see a mountain, little islands, etc. and they look all low poly and "craggily" i'm not even sure if that's a word. They certainly done line up on integer boundaries. The way the system used to work is that I had cube meshes all over that approximated the curve of the terrain I wanted and when placing a block we would raycast for that geometry and you would actually be placing on top of a hidden cube mesh that just happened to be CLOSE to the surface of the visible terrain.



This was a huge pain in the ass because I was maintaining two sets of geometry, the visible island and this low poly (heh heh) approximation of it that lines up on integer boundaries. I don't know why I was being so dim witted, today while working on the island and getting frustrated with maintaining the cube meshes, I thought to myself, why aren't we just raycasting the terrain and doing an angle check on the hit and if it's BASICALLY flat, let the user place the block on the closest integer boundary.

This does result in some inconsistencies like where blocks will slightly float but that is something I'm willing to live with for a MUCH more versatile system that doesn't require a low poly approximation and that lets me much more quickly iterate on the design.

With this system in place I was able to test it out by just clicking all over the island and placing belts. That is what the top picture is, all of the little random belts I placed all over.

And with that, I'm off. I may or may not be game deving from Mammoth so if not, talk to you guys Monday.

[morphinegames]

Hello everyone! We are hitting the road at 10AM but I had an idea while I was in bed for a repeat key



This will simplify the process of adding long chains of blocks and it supports skipping etc. it took about 5 mins to implement and has made testing for me and most likely gameplay for the end user much easier!

Until next time.

[Tusky]

Really interesting idea. Look forward to giving this a go

[morphinegames]

Really interesting idea. Look forward to giving this a go

Hey thanks! If you'd be interested in beta testing it just send me a PM with your info. It will probably be July when I open up beta testing.

[Tusky]

Sure thing, love to!

[morphinegames]

Hi everyone! I'm back from a nice week snowboarding at Mammoth. I did not do much coding while away but I did a lot of thought work and came up with one last little tweak to game play - time of day.

So there has always been a time of day system in Gastrocove with a dynamic skybox etc. but it was pretty much cosmetic and gave the island a sense of place. The amount of time you take has always had value because we have efficiency metrics but the absolute time of day never did.

The island currently has 4 periods in a day each of which lasts 6 hours. Morning, Afternoon, Evening and Night

I added two very simple mechanics which add a considerable amount of depth given how easy they are. Those mechanics are

1. Time of day based spawning - for example certain raw ingredients only spawn in the evening
2. Time of day based combining - some products can only be produced (combined) at certain times of day, for example, moonshine can only be made at Night

This actually adds a good deal of depth because some high ticket items which can only be produced at night now have to have specialized assembly lines for them if you choose to produce those.

In order to support this, the teleporter block has been extended slightly with its output port now being configurable. By clicking repeatedly on the output port of a teleporter, you change it between the following modes (top to bottom in image):

1. On- the teleporter will always teleport a block from input to output
2. Off - the teleporter will never teleport a block
3. Day - the teleporter will only teleport a block if it's day time
4. Night - same thing for night time



What this means is that in addition to instantaneous (expensive) transport - teleporters can also now act as "doors" that are only open at certain times of day. So now let's say you have a coconut pipeline - you can now have a day time assembly and a night time assembly using the teleporter as the "logic" gate

One other thing that I revamped today was our grid visual indicator. If you look at some of the old screen shots, you will see the grid basically covers all terrain even at steep slopes etc. This was a simple projector system and it worked well enough. This has been redone to be more sophisticated and now we only show the grid where you can definitely place a block.



OK guys, that's about it for now. This week I will be spending the majority of the time building out the island, determining placement of the spawners etc. After that, we will be about ready for some alpha testing so if anyone is interested, just shoot me a PM with your email address and I will add you to the list for alpha testers.

I'll leave you with this vid of an "infinite loop" of block creation using the clone ability of teleporters not that it is useful, just cool

[morphinegames]

So I decided to add one more thing in today, just some particle effects for spawning and delivering to port. It's really amazing what a few little graphical touches like particles can do to the feel of a game.



Update - looks pretty good with the water reflection effects at night

[morphinegames]

Hi guys! So like I mentioned, this week I will be starting work on the finalized island layout and art design.

I decided to use a slightly higher poly count and here is a quick preview of how this will look. More to come

[morphinegames]

Hey guys! Busy working on building out the island so not a lot of "progress" to share, but I figured I would post a "first 30 seconds" vid for everyone to see



The video shows what will most likely be the tutorial area of the island. There is a coconut spawner (next to a palm tree) and I build out a belt pipeline and put a combiner on top to package the coconuts into a container. The belts push the blocks along into the glowing port where we will receive money for the delivery