When it comes to AI development for games, I see a tough impasse.

We need the AI to be expertly trained but if you use training data from all of the current games you’ll get the most average game possible. That sucks. To modify the game you now need to be a full developer as then using AI becomes a full skill set.

Instead of developing a game as intended we are developing prompts, or we need to have both skills, and the bar for entry is raised.

We need the AI to generate not the average of other games but the intent of the experience of what the creator actually wants. This is what we have looked at.

I wanted to see how the broader market handles it but that is immature.

Coming to terms

I’ve talked to companies with the primary goal to quickly earn money. No hate, just facts. They want to tie together as many publicly available pieces at once to get something of a good demo and then hopefully sell the company. I assume M&A would do proper discovery and decide how exciting that is for their company.

Next, I see companies being so scrappy that they appear to be overusing AI themselves today. As an example one AI game generation company out there has this in their FAQ which appears to be probably inspired by a human:

Sounds good right?

In their terms of service they say:

“Services include access to an online database of games and corresponding code (“Materials”) for you to download and use to develop your own games.”

Later it is stated that:

3. License to Use the Services and Materials

… You are further granted a nonexclusive worldwide license and right to use, modify, distribute and create derivative works of the Materials available through the Services for both personal and commercial purposes, provided that such use complies with all applicable laws and these Terms.

The definition of materials is a bit vague though it does seem like the license is stating you don’t own the rights to anything you generate with the AI for your game.

None of that really matters though because of this:

“You are responsible for regularly reviewing the Terms, as the Terms may be modified at any time. All such modifications will be effective immediately upon posting. If You are dissatisfied with any modification to the Terms, Your only remedy is to terminate Your use of the Sites and/or the Services, as described in Section 10 (Termination and Survivability) of these Terms. Your continued use of the Sites and/or the Services after a change or update has been made to the Terms constitutes Your acceptance of such change or update.”

So what I see here is that they own the rights of everything and they can update the terms without you knowing at will. If you log into the service you just accepted the terms because you’re responsible to check if they changed anything before you log in every single time. It is a fever dream of a one-sided agreement and shows a lack of customer respect.

On their site it shows a bunch of big developers have used their site. I have trouble believing it was anyone with legal authority. The lawyers I know would start Thanos snapping people for someone signing that. I’d buy popcorn and watch.

Oh, and if that company ever reads this. Consider letting people own their generations outright, and all derivatives with a warning that the system might generate identical assets due to another prompt and those assets would be owned by others. Users would agree users cannot sue each other over those generated assets. No, it’s not perfect but it’s better. Once again, none of that matters if you stick with being able to update the terms at will.

There can be small companies with amazing products. Those products might revolutionize the world. At least we hope they change the world in a positive way. I would love to see what they are up to.

Sadly, the company that wrote those terms doesn’t seem to be trying to get customers. They appear to be setting up to get hostages while hoping to create Stockholm Syndrome. The only people who will accept those terms are people that don’t read or people that have nothing to lose. The terms we saw above are just a symptom of a larger problem.

A Craze

I distinctly remember how the Metaverse was going to revolutionize the world. I think the best metaverse we have right now is a cell phone. Single login to a portal of everything you might need to do with a consumer usable identity. So many Metaverse companies sprung up overnight. Next there was the NFT craze. People could get an insane amount of money thrown at them for starting a company to issue something like NFT Water Bottles. That image of a bottle will be great to stare at while you’re stranded in a hot desert. That didn’t matter though. It’s an NFT idea, so let’s go! Here is the seed money! Then the AI wave started.

In the AI surge we see a bit more discernment but once again we have an unhealthy number of money chasers and the seemingly endless supply of buzzword investors.

All of these waves tend to end in a similar way. A bunch of investors have lost money. A new shiny idea is out for people to chase. Previous idea wave experts are now just waiting for people to get excited about the Innerverse or Generative Relationships and start their new company there.

When hype has become a signal flare for a gold rush, those who survive to actually get to the gold are the ones who deliver on the product and build trust with their customers. Terms of use agreements, like the one above, torch trust faster than a jackrabbit on a hot griddle. You need trust. You need a working product.

Your customers are what make you succeed. If you treat them like a KPI proof point that carries risk, you should start working on your VC Innerverse deck today as you have already locked in your company’s demise. Trust isn’t a feature. It’s a foundation.

In the craft methodology discussion I’ve mentioned that I disagreed with one of the lean pillars. I was referring to continuous improvement.

On the surface, it seems to be a great thing. The idea being that we are always looking for a way to eliminate waste or ways to improve the efficiency of our corporation. We will then adjust the corporation to be more efficient and aligned in the end.

Let’s re-org!

A few companies I’ve been at had us reorganizing every 6 months to a year. Some of the reorgs were great and were done to make alignment with initiatives. This could be creating new initiatives, closing initiatives that were at end of life, or shifting some groups within leadership to reduce conflicting goals and reduce outside dependencies. However, most of the reorgs were chasing ways to improve ROI to no success. I’ve seen some companies reorg more often than they have shipped products.

I’ve witnessed companies and teams making changes to processes in hopes of correcting a reported issue. The problem is that those changes were done for all issues without really considering what is lost through change.

It is generally well understood that if you hire someone new it takes three to nine months for them to get to their full potential. Time is lost when a new employee is not working as they could when they are:

• Getting their computer

• Gaining access to all of the systems

• Learning company processes

• Learning how to work with the team

• Gaining insight on how to effectively communicate in your company

• Learning how work gets approved and validated long term

• And so much more

I don’t know of anyone who thinks a new employee can start a new job and be as effective day one as they will be in a year.

If an employee changes what job they are doing they will also be less effective for some time. They can use knowledge from their old job to get up to speed quicker on their new job. They will still have a time where they are less efficient.

When we reorg, change processes, or change teams we disrupt at least the people affected and potentially the entire company.

Getting Experts

Getting all of this right has become such a priority, we will hire experts to explicitly tell us where and how to change our company. I’ve seen them create and grow entire departments in an organization around perceived inefficiencies in processes, communications, reporting or what have you.

This can extend even lower where entire methodologies are taught on how to conduct continuous improvement down to the individual.

So am I going to say improvement is bad? Not at all. Iteration is one of the most important things we do. If we don’t iterate our company we will die. The real question is:

What are you iterating for?

Good Reason

We have to make changes to our organizations with imperfect information even at high risk. Many times it could be compared to gambling. Leaders at the top are the best in the world at making those decisions. They know making a change is the right call with the information they have. Highly visible pain is shouting from the roof tops that something needs to shift.

Over in my post on Iteration, I talked about how long to wait before making a new change. I showed a game where making a small change to a rule set would create noise in a system for a long time before actually stabilizing into a new system. We had to wait long enough for the game’s entities from creating new patterns before then waiting to ensure what we see is the actual result from our changes. It can be a deceptively long time. If you make a change too soon all you are doing is changing based on noise instead of signal.

We will always need to make some changes with imperfect information. However, noise isn’t imperfect information. It’s noise. Changing a company will produce that noise and the noise will be louder and arrive quicker than the actual results. Turbulence can make success look like failure. Excitement can be false proof. A short term gain can hide an oncoming turn over. Even the best leaders with the best reasons for change can hear early results then move on before the noise has settled enough to truly tell.

Sometimes the solutions are the actual problems.

Why?

If your company has some sort of team with one of their primary pillars is efficiency, what are you evaluating their performance on? What if one of those team members said, “I don’t see any changes to make for this coming year.” or “I need to take a year to see how those changes work out.” Should they then be concerned about their job?

If they must show they made something in the company more efficient to be a performer, their KPI is now internal change rather than making your company do its purpose better. If you are paying people to make changes, everything will always be changing.

Once you make a change, you lose context, need to rebuild working relationships and wait for efficiency to hopefully grow higher than before. It can get crazy where we are changing every part of the org forever and simultaneously. At scale this is just an expensive waste engine.

I’ve seen this happen first hand. Program managers were hired to be a point of communication for the engineers. Now those managers needed to be explained everything, told everything, and would insist on being in most every meeting for visibility. Inadvertently they became just a giant drag to the system. Be careful not to get caught up in the excitement of the latest structure to try.

Keep in mind, if you keep repotting a tree, that tree will struggle and you will eventually kill the tree.

As I said, change is critical when needed. To know if you need change, look at what your product actually is. Internal procedures usually are not the point. Specific ways of working for employees are not the point.

We build products, ship them, and then when a new product makes sense to build, we do that. Our companies should be no different.

If our company is too inefficient to make the company’s actual products profitable we need to change.

If we need to make a different product we need to change.

If our company’s dependencies shift we need to change.

If we have a KPI that are burning out employees, we need to change.

I thought we were making changes so that our company would be great for our customers.

Changes are supposed to lead to a time of actual stability and performance.

The goal of changing is not to just find more changes.

Who wants to be rich?

One of the richest people on earth has gone just a little crazy.  They are working on a slot machine to give away 20 billion U.S. dollars. It is a guaranteed jackpot win within 50 pulls. Each pull is completely free. They haven’t worked out all of the bugs yet. For some reason there is a 1% chance that the machine will deliver an electrical shock strong enough to stun you and possibly cause a little burn. They ask if you’d like to play it right now. You can pull the slot machine hammer as many times as you’d like and you can keep the winnings.

What do you think most people would do? Would they pull that hammer till they hit the jackpot?

Alternatively, we could have a slot machine that is shockless, works perfectly, costs 40 dollars each pull, and rewards a maximum of 30 dollars in return. No sane person would use it.

We could say, “People will use your product once its value outweighs the product's shortcomings even if those shortcomings are severe.”

I’m not suggesting we ship frustrating or harmful products. I am saying that we should be aware of what value our customers are seeking to get from our products and to ship when those desires are met.

One game I was working on had a bug where if you played the first 30 hours without ever saving, stopped at a specific location, and then fired a weapon the game crashed. If you ever saved before that point the bug wouldn’t happen. I was surprised our testing team found that one. We ended up shipping with that bug still in the game. We never saw or heard a single comment or report of that bug post-ship. I really don’t like crash bugs. However, the opportunity cost of us delaying shipping to fix that bug versus the chance of any player being harmed by it was so low it just wasn’t worth fixing.

Customer value

We’ve been looking at value versus bugs which is only one part of the story. Over in prioritizing work I’ve talked about how to figure out how valuable any given specific feature is to include in the product. We assign value for many thing including:

• If that feature is table stakes

• If the feature was asked for by the customer

• If the customer has shown interest in the feature

• If the customer is willing to pay money for that feature

• What impact the feature will have

• Do our competitors already have this covered

• What the current maintenance cost would look like

• And many more items

A version of the feature evaluation should be done for the entire product before production to see just how valuable the product could be. As we are building the product we can see how much of that potential value we are delivering.

Fit and Culture

An audio company became interested in diversifying and hired me to start to make video games for them. I put together a small team. Worked on shipping a couple of audio related specific products they wanted and then started building entertainment products. Right before I could ship a product that I had a great deal of faith in, the company got bought by another audio company.

The new company had no interest in entertainment products so the title was killed. Even though the title had a great deal of potential value, it didn’t serve the larger corporate goals and it made the most sense to abandon the project.

You need to be sure that releasing the product will fit with the company's view for market, value, quality, statement, and culture. If the product doesn’t fit the company’s requirements, adjust the product.

Alternatively, you can adjust the company. Look at how Nintendo made instant rice, Avon sold books, Wrigley sold soap and baking powder. Don’t be a slave to what your company is. You can easily destroy a company with corporate requirements that have no real impact or value. Sometimes it is ok to ship a product that will update your corporate goals.

Ok, but when?

Ship when the product is delivering the intended value, that value is not destroyed by drawbacks, and represents the company’s requirements for it.

Intended value can be tested against. If you are building a calculator you can test directly against it working or not. If you are creating an open world game you can use player statistics to infer the value. Intended value doesn’t mean when every feature has been completed. If your consumers want the value from the product right now, give it to them. The other features can come later as needed.

Value being destroyed by drawbacks can be determined with a few techniques. First, ask the consumer. No secrets here. Consumers will happily tell you what they want. The more frustrating the issue the louder the voices. If there are no voices, be concerned that the product lacks value.

Secondly, you can determine value being destroyed by drawbacks from long term use. As I’ve mentioned before, I used to go to the testing department right before their lunch time to see how QA would stop playing my game. If they threw the controller down and left I had much more work to do. If they played for a little more and then left for lunch, I was getting closer. If they played through their lunch I knew I had a good game. These days we can easily track play habits and see how they align with our intent. How many bugs are users experiencing? Do those bugs affect the experience?  Do users take a break after hitting an issue or using a feature? 

Corporate requirements should be an easy bar. You know your company. Look at the product the way it is today, not tomorrow, not some future version, today. Does that fit your company or not? If not, do you have unreasonable corporate requirements? Will you tank the company because of them?

If the product passes these tests then ship it right now. Don’t think. Don’t keep building, fixing or perfecting.

Just ship it.

“The bloodiest war started in 2932. Both sides struggled through tough days. It wasn’t until Cerias Tucker betrayed President Holland by poisoning his porridge that peace could be established.”

So Bad

I see narrative like the one above too much in games. There are several storytelling crimes in those two sentences.  Beyond being overly short with pointless information it lacks engagement, relevance, or viewpoint.

Each time I’ve seen a writer create text like that, I assume they were attempting to set the scene for the player. To help the player understand a character, the world, or the history of the world. Unfortunately, it actually sucks.

One of the most famous narratives similar to this is the opening crawl for Star Wars. It is an iconic and memorable opening. It also does almost nothing for the story. If that screen crawl were to be removed, I believe nothing would be lost from the actual film. The film covers everything in the crawl at its own pace. The only real value of the crawl is text at an interesting angle before some great camera movement. That crawl has become about the excitement of starting a new Star Wars film and much less about actually adding to the story of the film.

It Matters More in Games

One of the big differentiators with videogames is the level of immersion and involvement a player can have with a story. The player can be a living witness to the story or can quite literally drive all the story choices.  Direct reciting of events as narrative is not realistic to a world you want the player to feel they belong in.

The way we are told events in the world is always from someone’s perspective. We then get a feeling about the events from that perspective combined with what we think about them. If we tell events in games from the perspective of the in-game author we get many advantages from it:

• The game feels more real

• The player gets to decide if they trust the story and the source

• We can introduce alternate versions to add depth or confuse the issue

A Shootout in Town

For instance, we could have the following:

“I’ll do my best to tell you what I saw. Every time I try to say this I cry. Oh, God, please help me.

The first I saw was the Red Bandits emerging from the dust storm and trying to escape with their transport pullers crawling down the back path of town.

Deputy Thompson knew he couldn’t allow them to keep spreading their lies and their ways in a new town. He went out to stop them.

Bravely standing in the middle of the path a few strong supporters stood with him. I could only imagine the hate under their bandit masks as they opened fire. Old lady Candice stepped in front of Thompson hoping to stop the aggression. They, they, cut her down without hesitation. They, they, never even stopped firing. I never got to say goodbye. It took our doctors to confirm it was her. 

All of them were murdered by the time the Red Bandits got near them. It was a massacre. We can’t let this continue.”

What if this was narrated by Sam Gladly, a poor local farmer? What would you think?

What if it was a report from the Ministry of Truth?

A Second Thought

Later, you could have the player get another account of the event told from the Red Bandit’s perspective:

“We tried to reason with the Deputy. We wanted to live in peace on the outskirts of the desert. He insisted we erect their idols or go to the education camps.

Murray wanted to try one last time putting up the white flag to talk. The deputy’s goons shot him four times in the gut and sent him back. They saw him wrap the white flag around his waist. As the flag became soaked with his blood they said it gave him a great red color. They mockingly called him a "Red Bandit." Apparently the name stuck and they kept referring to us as that.

We knew we had to flee. We weren’t going to have our kids be programmed to hate us. The only path to peace would be to try to escape through the back of town. It wasn’t any good. Those goons found us and opened fire.

They lined up their women in-front of them as human shields. They were firing from behind their women with the barrels literally under their arms.

I tried not to use my weapon. I saw my youngest child go limp and fell off the transport. She had been shot. It was clear she was dead. My two other kids were in shock. I was a fool to hold fire. I started shooting back. Then I lost my other children.

Only a few of us escaped with our lives. I keep trying to find a way to live with the horror of that day. Why am I even trying to make the world better now that my kids have been killed? Who am I trying to make it better for?”

If you set up your story events as unswerving truth you’re just documenting facts. If you want to document facts, make a quiz game. If you’re going to make a story, help the player live and breathe that world.

Feel free to write a hard truth of what happened to characters and your world. Just keep it to yourself and only tell it through the lenses of those that claim to have been there.

Give a gift subscription

The post I did on prioritizing work gives a way to prioritize tech based features. For prioritizing other items, some people have shown me the Eisenhower Matrix.

It seems fine on the surface though it has problems in use. For those not familiar with the Eisenhower Matrix, it is a way to organize work according to this:

The idea is that you should take everything that needs to be done and sort it by its importance and urgency. 

If something is:

• Important and urgent - Do it now

• Important and not urgent - Schedule when you should do it

• Urgent but not important - Delegate it out to others

• Not important and not urgent - Throw it in the trash and don’t do it

The spiritual intent of the chart is the idea of focusing on important things that need to be completed soon. There’s nothing wrong with that high level concept. It’s not all that revolutionary or helpful on its own.

Looking at the Eisenhower Matrix, it is attempting to help answer both what to do and who should do it in one swoop. Let’s ignore who should do it and focus just on what to do.

The Eisenhower Matrix makes the assumption that we should have an important axis and an urgency axis. The urgency axis I think is deceptively dumb. If one task is critically important and another has no importance, urgency doesn’t matter. Urgency should be a factor when considering a task’s importance. It shouldn’t be its own axis. Instead of an urgency axis, let’s just make sure that there is still a possibility to complete any task you are looking at. That is all we need.

An axis for important makes sense. To help classify tasks we should find a way to actually sort the tasks.

What is Important?

So, what is important work? I see importance primarily as work that significantly contributes to at least one specific goal in a KPI, OKR, smart, or other form. 

The desired outcome of the goal does not need to always be product related.  It could be setting up a cadence of skip level meetings to improve communications. It  could be shipping a product to completely eliminate the top 3 users' concerns in our company’s primary market by Q4 within the allocated budget. It could also be something to do with culture, morale, process, or an infinite number of other items.

A better way to look at the matrix would simply be to sort tasks by an importance value. We could do that by writing them down and assigning a value that seems appropriate. We’ll give a 1 - 10 value with 10 being the most important.

It doesn’t matter to get the numbers exactly right. What matters is the numbers make sense relative to each other. One way to do this is find a task you think you are confident on its number as a starting point. You’re best off finding a task that seems to be about a 5 in importance. Assign it a 5. Then start assigning numbers to the other tasks relative to that one. While 5 may work best, you can start with a 10 or any other task with an importance value you know.

Something along the lines of:

• Land Changes for Feature X - 10

• Doc Check for Feature X - 7

• Integrate Desired Growth Paths for staff - 5

• Update Corporate Onboarding Procedures - 10

• Revise Stakeholder Guidance - 7

• Sign off staging version of Product K - 10

• Product K Prep from Staging to Live - 5

• Establish Monthly Weak Point Training for staff - 2

This Could Use Weight

Sorting like that is fairly terrible as we are rating against goals of a potentially unknown worth. For example, “Land Changes for feature X” is really important to feature X. “Integrate Desired Growth Paths for Staff” could be important for both training staff and increasing morale. To get a better view we should weigh how important each of our goals are and modify each task's importance with the weighting.

As an example this chart shows 5 goals with their overall value from 1 - 10. 10 is the most important. Use the same method of assigning numbers as described for the tasks.

We can then have a chart automatically be set up so we can enter how much value each task would contribute to each goal from 1 - 10 with 10 still being the most. That looks like this:

From that the values can be added up with their relative weightings to give what is important to do. Those values can be shown in a simple bar chart:

Take an Extra Minute for Risk

If we want to put just the slightest more effort into rating our tasks, we can integrate risk. If we add a risk value to our tasks we can represent that along with value for a better picture. Risk is the chance this task will fail for any reason. That could be from unknown solutions, external dependencies and similar. We will set risk from 1 - 5 with 5 being the most risk.

Adding a risk column to our table we get:

With that data we can build a chart with:

• Move valuable tasks on the top

• Less valuable tasks on the bottom

• Riskier tasks on the right

• Less risky tasks on the left

This would mean that a safe important task would be in the upper left and a risky worthless task would be on the lower right. That chart looks like this:

From the chart you can easily see which tasks are valuable and safe to complete. This little extra info helps really visualize the worth of each task.

Sizing Tasks

For just a minute more you can add a rough duration to each of the tasks to round out the chart. All of the tasks added to the list should all be task sized. You don’t want to be thinking about if you should do a three year project or that two day task. If you end up with mismatched tasks, breakdown the big task into smaller pieces you can work on right now that are around the same size as the other tasks. Once you have that you can choose an expected duration for each task. To make it easier I set up selections in the sheet of:

• Very Long

• Long

• Medium

• Short

This is a bit vague on purpose. We are trying to move quickly and get a good idea of what to do without spending more than 10 minutes on this entire exercise. We assign rough duration to the tasks here:

Taking those durations and using them as the size of the bubbles on the bubble chart gives us the view below.

• x axis is Risk

• y axis is Importance

• Size of bubble is Duration. The bigger the bubble the longer the task takes.

From this we can see the importance, risk, and potential time commitment of each task. It should give a much better idea of where to spend time then just relying on importance alone.

We should ignore the Eisenhower Matrix as we can get a better results with a simple bar chart. If we add in accounting for goals, risk, and duration it makes it even better with minimal effort. If we can’t answer those questions about our tasks then we need to get a better understanding of those tasks before we commit to doing them.

Read more

21.0 Visualize broad-phase collision grid

Visualize a 16x16 grid to potentially use as a broad-phase collision. Think through possible some storage options of collision data:

• Option 1: Store 1 bit per grid section. If there is a hit, check against all possible inputs. Given the counts are low, it's not unreasonable.

• Option 2: Store 1 byte per grid section. Store index of item at that grid section. If there is a hit, only compare against the indices that are indicated. If multiple items are on the same grid section, just overwrite. Given relative sizes, there's not likely to be any noticeable issues.

• Option 3: Store 16 bytes per row. 1 byte for count. 15 bytes for elements. For each row, a list of items overlapping the row. If there is a hit, walk the list of items indicated. Overlapping items are non-issue. 15 elements per line is a reasonable constraint.

21.1 Collision grid data and input maps

I was thinking of a case I’d like to try that would make option 2 problematic: Intentionally fully overlapping objects. e.g. a shield around a ship. Which makes the case for option 3. So, we’ll start with that. (Although as I said earlier, revisions on various speeds, sizes, and spawn frequencies may change the situation enough to require a completely different solution.)

Start by creating collision_grid. We’ll hook this up to enemy_instances, hero_instances, enemy_bullets, and hero_bullets to get grid data for each of them respectively. To hook them up, we’ll map collsion_source_instances and collision_source_types.

I decided to simplify the mapping process a bit for when I don’t specify a source (i.e. when the offsets in the map are assigned at runtime.) But to do that, I need to fix up the builder scripts a bit.

TODO:

• Need to support importing schemas in schemas, to look up types. (Without source data, we can’t infer the type anymore.)

• Bullet and hero/enemy type data store radius in different formats (radius_q8 and radius_q4, respectively.)

21.2 Support import types in schemas

Update export_bin to use imported schemas to gather type information for maps.

21.3 Support different radius ports

Update collision_grid to have both radius_q4 and radius_q8 ports. The appropriate port is mapped, where the other remains NULL. Update export_c_header to return NULL when offset is zero.

21.4 collision_grid_update

Updating collision_grid_update for the various input cases highlighted a few issues that we need to resolve. There’s no tracking of filtered out instances (e.g. the live_instances bit set for enemy instances.) Got the basic update working and visualized the data being stored to help sort out the issues.

On the left are the hero instances and hero bullets. On the right are the enemy instances and enemy bullets. The play area is divided into 16 slices vertically. The number of instances overlapping that a slice is stored, and the indices of the specific instances are stored per slice, for later more fine-grained collision testing.

21.5 collision_grid_update filter

Add an enabled filter for collsion_grid_update. Enemy instances have a bit vector for each instance that is cleared when the path is complete. Nothing else has enabled bits at the moment, but it’s easy to anticipate them being needed once the rest of this system is in place and we need to start tracking destroyed things.

Also I don’t have dependencies in my makefile setup correctly. Schemas can be dependent on other schemas, so build order for those matters. Which bit me here again for a few minutes. That definitely needs to get fixed soon.

21.6 Fix makefile dependencies

Add dependencies for schema files in makefile. Nothing automated for now.

21.7 Gather damage and health data

Open Unity project and find the health and damage data. Add to enemy_instances, hero_instances, enemy_bullets, and hero_bullets.

21.8 Create collsion_damage

Create a type to gather damage ring buffer (position, time, amount) for a pair of grid types. Pairs to be tested:

• hero_bullets vs. enemy_instances

• enemy_bullets vs. hero_instances

• hero_instances vs. enemy_instances

Also:

• Rename “ref” in schema to “context” (two names for the same concept.)

• Rename “collision_source_types” to “collision_source_radius” for clarity.

21.9 Generate common code for cut and paste

At some point I want to look at codegen for removing the boiler plate around getting the right variable addresses for data lookup in the context. Since there’s only one possible way to do it, I shouldn’t need to specify it every time. In the meantime though, I’m just going to add code I probably want to cut and paste as comments to the generated c header.

Also some other things to the TODO list I want to get to:

• Time in uint64_t as nanoseonds

• binary data column offset to be relative to the sheet instead of the file

• schema yml<->binary converter

• tool to waypoint curve entry

• data playground tool

• s/TypeIndex/Index/g

21.10 Collect damage events

Also output context struct for copy/paste.

Implement collision_damage_update to collect up damage events. Keep it pretty simple:

• Do A and B have anything on the same slice?

• If so, for each of the instances on A and B on that slice,

• Test if each radius overlaps.

Oh, I missed this, so next I also need to add:

• Don’t re-add same collision multiple times if they happen on multiple slices.

21.11 Don’t report same collision pair multiple times

Observation: If the pair exists in the previous slice, we don’t need to add anything. Any collision would have been handled in the previous slice. If it doesn’t exist in the previous slice, the only other possible place is the next slice, which will be handled by this same rule. There are no non-contiguous same-pairs stored.

Create double buffered bit vector on the stack to track previous and next a and b instances processed. On both a and b bits set on previous, do not re-store event.

Cheap and easy.

Add an additional debug view of collision_damage.

21.12 Prepare to accumulate damage

Re-arrange damage_events. Remove redundant time. Combine a and b data under the same sheet.

In order to accumulate anything, you need a reset flag. Add a reset flag to source_instances so that accumulated damage can be stored in collision_damage. Fix up enemy_instances and bullets to set the reset flag on spawn and clear on move. Also change behavior slightly so that instances don’t move on first frame spawned (they are at the spawn location.)

21.13 Accumulate damage

Clear accumulated damage based on reset flag. Add to accumulated damage at each event. Update the debug view to show the accumulated damage for each instance in each damage event.

21.14 Destroy on damage

Add an input line to bullets for damage values. Compare those to health values and destroy if exceeds. Something doesn’t look quite right though…

21.15 Debug and discover the problem

The problem is that I’ve been playing fast and loose with ring buffers and there isn’t really a rule around the data for them. So bullets, being first implemented, are a bit different from the others. The solution is to:

• All sheets should store capacity

• Sheet counts can exceed capacity

• Remove spawned_count from bullets.

21.16 Destroy hero bullets correctly

Updated count and capacity rules to handle ringbuffers consistently and fixed everything up. Turns out though that wasn’t the actual problem. A small typo in the schema meant that the reset flags weren’t being received.

21.17 Destroy enemy instances

Give accumulated damage to enemy_instances. Check damage versus health, and disable enemies.

21.18 hero instances vs enemy bullets

Map the inverse case from above. Enemy bullets damage and destroy handled. Need to decide game loop when hero is destroyed before we hook that up though.

21.19 You died

Remove old level_index from game_state. Quick and dirty version of hero loop. Reset game on hero death.

Quick check on the state of memory and performance.

Links to files below for paid subscribers.

Read more

It’s time to automate formatting code. The only formatter I know of that will do the vertical alignment I prefer is clang-format, so I’m using that.

Start with an llvm format:

clang-format -style=llvm -dump-config > .clang-format

Then modify .clang-format to more closely match the style I’m using. There’s a couple of features in newer versions of clang-format that would make the output a bit better, but this is close enough.

	ColumnLimit:     200
	BreakBeforeBraces: Allman
	AlignAfterOpenBracket: Align
	AlignArrayOfStructures: Right
	AlignConsecutiveMacros: AcrossEmptyLines
	AlignConsecutiveAssignments: AcrossEmptyLines
	AlignConsecutiveBitFields: AcrossEmptyLines
	AlignConsecutiveDeclarations: AcrossEmptyLines
	AlignEscapedNewlines: Right
	AlignOperands:   Align
	AlwaysBreakAfterReturnType: AllDefinitions
	AllowShortFunctionsOnASingleLine: None
	PointerAlignment: Left

20.1 Split play area data

I’ve been bundling play area data (like resolution) in just what happened to be the first schema I made. It doesn’t really make any sense to be there, nor is there any practical benefit. So I’m moving it to make it clearer.

20.2 System internal data remapping

Let’s look at hooking up the hero. Start by creating the hero_instances sheet from a copy of enemy_instances. Delete what we don’t need for heroes. Which turns out to be just about everything. Hero instances are handled differently than enemy instances since they aren’t totally pre-determined at build time. But we do need to constrain the maximum number of hero instances (16). This gave a situation where the binary file is only partially sourced from the xlsx data. Some of the data (like hero positions) aren’t defined there and are just zero-initialized space. So quick fix-up of export_bin to support that.

Looking at the hero data, we have a level_wave remapping table which just points to exactly the same instances for every wave. While that would work, it’s clearly data that isn’t needed and is only there because the only example we had until now (enemy_instances) did that remapping. So instead of mapping to that format, let’s actually just do that remapping internally to enemy_instances and every other system can just get a table that’s already pointing to the correct instances wherever they might be. In the case of hero, it’s just always the same set; in the case of enemies the remapping needs to get fixed up whenever the wave changes. That gives a first use-case for using the remapping feature at runtime by fixing up the offsets.

Next up: Remove any of the previous code that did the level_wave to instance lookup and just point to the ready to go map instead.

20.3 Finish re-mapping

Complete the re-mapping and remove all the code that uses the level_wave to instance lookup.

20.4 Merge enemy_instances and enemy_instances_update

Now that enemy_instances has a runtime mapping and is no longer read-only, there’s not much benefit from keeping enemy_instances and enemy_instances_update data separated. So merge those for simplicity.

20.5 Add reset flags for stateful systems

As a bit of cleanup, to resolve the issue of initializing any data on the first call, add a reset flag to the wave update system. In general, it’s useful for stateful systems to have reset flags (as well as enable flags, aka feature flags). Also add a reset to game_state, and allow that to cascade to the wave.

20.6 Hero instances

Hook up hero instances based on enemy instances. Create an update function which just initializes one hero. And a draw function. Bullets should be handled automatically if the source data is mapped correctly.

Fix an issue with the hero_instances schema. (Not actually assigning a capacity.)

Change a constraint. The hero bullet update rate is very high, which spawns a lot more than the expected constraint of 255 maximum per wave. Adjust the allowed count to 16 bits. But all the same, the rate is probably too high anyway, so reduce that to be balanced again later.

Use the mouse position to set the position of the first hero instance.

20.7 Revisit bullet angle

Up until now bullet angle was implicitly along the vector between the root of the source and the spawn position of the bullet. But in the case of the hero, we want bullets where the offset position and angle are distinct. So we’re going to adjust the bullet format to include a base position. Adjust hero bullet and enemy bullet xlsx files accordingly.

20.8 Separate clocks

Note that hero and enemy should be running on separate clocks. Enemy is on the wave clock and hero is on the level clock. Create the level clock and update bullets to use mapped play clock and not be tied to wave.

20.9 Default values in schema

Previously added base_xy to enemy bullets, but I don’t need to make the input more complicated as they are all defined the same. In order to remove that, I need to be able to specify a default value in the schema.

Next: Port a Unity Game to Your Own Engine: Part 21

Links to files below for paid subscribers.

Read more

Get 10% off a group subscription

Extract hero bullet data from Unity project into xlsx. Hero bullet format matches enemy bullets, so rename the common format source_bullets. Patch up references to enemy_bullets.

010 Editor Template (bt)

In addition to Kaitai (ksy) files, also generate templates for 010 Editor (bt). They’re basically equivalent here.

Prepare for schema map

Quick rename of source_bullets to bullets. Change sheet counts to be offset into data segment instead of directly in header. Which will allow for a mapped schema type to point to specific columns and along with the counts.

Add map to bin and ksy

Change export_bin to add any maps. Update ksy to inspect the data. Todo: update bt and c_header outputs.

First test for maps

Create the C header for maps and fix up issues with bin export. Maps are the first thing exported, so that all offsets are positive relative to a given map. First test case: Use bullet_source_instances instead of enemy_instances for bullets schema. This is the first step in removing dependency on enemy data in bullets update, so hero and enemy will use the same bullet system. Todo: Update export_bt, remove enemy_instances_update dependency.

Indirect values

Make values in schema types indirect. Patch up existing code. Now maps can also remap values. Add bullet_source_instances_update map to enemy_instances_update. Bullets no longer have any direct references to enemies.

Next: Port a Unity Game to Your Own Engine: Part 20

Links to files below for paid subscribers.

Read more

Quick patch to export_bin script so extra unnecessary data segments aren’t written to the file.

Build enemy_instances

Create schema for enemy_instances so binary data, c header, etc. can be built from command line.

Build enemy_instances_update

Create schema for enemy_instances_update and enemy_instances_draw. Fix up Makefile. Left at the end with a bug to fix in next part.

Byte pack structures

Binary export doesn’t do standard C structure packing so for now, add an attribute to the C header output for byte packed structures. Todo: Sort out the packing question.

Add game_state

Wrap up this clean up phase by bundling the common game variables into a game_state structure. Now everything that any system accesses needs to be fully declared in the schema file. Introduce a data rule here: A system can only write to its own data (Root, as defined in the context) - every other dependency must be read-only.

Next: Port a Unity Game to Your Own Engine: Part 19

Links to files below for paid subscribers.

Read more

Finish up changes to enemy_bullets_update data access. Move spreadsheets from sheets to xlsx. Update scripts to build data with or without source data supplied by xlsx. Update enemy_bullets and diff binary results to verify exactly the same results.

Next: Port a Unity Game to Your Own Engine: Part 18.1

Links to files below for paid subscribers.

Read more

The data defined at compile time is very similar to the data defined at build time with the spreadsheet conversion scripts. It would be nice if the same tools to build and inspect the data could be used for both. So, let’s define the runtime data using a very similar description and mmap that in as well. Here we get through a first example with the backing data for enemy_bullets_update and enemy_bullets_draw.

Next: Port a Unity Game to Your Own Engine: Part 18

Links to files below for paid subscribers.

Read more

Show me the money

From where we left off the next thing we need to determine is how much gold to drop. We need to write down what we want our relationships to be for dropping gold. For this example our desired interactions are:

• A player needs cash to buy the remainder of the item sets at any given level from the money collected from fights as well the money created by the off-class items

• Items should increase in value to keep a player needing to always earn more money and sell lots of gear to get higher level items

• A merchant should sell items for more than they will purchase them

• A player should feel like they are earning lots of money at high level

We need wrap our head around the idea of the system. As we talked about before money is one of the transports to turn the remainder items into gold.

Let’s take a look at the high-level concept of this with our high-level economy.

Focusing on a sub-section of the economy we listed before you can see the loop from items through the shop. On that process the economic drain that exists is from the merchant multiplier. The merchant removes worth from items by paying less for them than they are worth. With these relationships in mind let’s start to attack the actual creation of the system by figuring out the total number of desired and non-desired item drops.

We need to turn the non-desired items into gold and provide gold directly to the player by dropping it at the end of combat. To do this we need to now know the average value of a level 1 item. Once again this is a number we simply make up. We don’t want to make a value that is so low a merchant multiplier would fall apart. We’ll make it easy and be cheap to the player at the same time. We’ll pick 10 gold. Ok, great. We now have a cost of the average level 1 item.

I personally like to really rip off the player on resale. I’ve never seen or heard complaints from internal or external sources about being harsh on resale. The players somehow always blame the merchant, like he really exists, and then just accepts it almost immediately.

Let’s say that a merchant will pay 20% of the cost of an item to a player. With the stated data points we know a player will be able to buy an item for 10gp and then sell it back to the merchant for 2gp. This also means the player will be able to convert 5 items into 1 item. I am being harsh on resale but don’t miss the point I just said. Up above we see that 40 items plus extra gold needs to be converted into 10 items. This means a 25% merchant multiplier (10/40) would be a break even point without a gold drop. Anything higher or the existence of the gold drop would begin to give the player more dough than we want them to have. Our example game is rather simple. Most game economies have more exits for money out of the economy such as potions, bank deposit fees, item decay, heal costs, etc. Those extra money drains help allow the merchant multiplier to be higher.

Quickly hopping back to the cost of items in the game we stated a level 1 item should be worth 10gp but what do we want a level 2 item to be worth? Take a second and think about it. Keep reading after you’ve think you know.

The trick is to not actually pick a value. You need to determine the relationship between the two. How many level 1 items does it take to equal the value of a level 2 item? What about a level 3 item? This relationship determines how much a player can skip buying items for one level to apply it to the next.

In a sensible balanced economy, the cost of the item should be in-line with the effectiveness of the weapon and / or desirability of the weapon. However, they don’t need to be on the same curve but both curves need to mate well. The steepness of the lines or curves will determine how often players will want new items as well as how cost effective it is to trade up.

My gut feeling for this is something to the tune of items approximately doubling in value over a 2 level range. A sample data set for that would look like this:

This chart shows the cost of an item if it was 2x the previous level.

Looking over the data I’m not really excited about it. Level 19 items costing 5120 seems way to much over 20 levels with level 1 items only costing 10. Levels 1 through five look alright but I think we could scale back from doubling. As of right now, the first few levels will give the player an overt sense of being poor. I’ll reduce the strength overall and recalculate. Doing so gives us this curve which I’m fairly happy with:

Wondering how I got that curve?

A quick tangent is in order here. You may have noticed that the enemies to level and the number of sets to level as well as many other sets of data used are on curves. No surprise really. That said, all of the curves are clean and don’t have unwanted flat spots within their usable range. You’ll want to make several curves for your game. Before anyone starts trying to remember all of their math lessons you should know something. The trick is that anytime you need a line or a curve you don’t actually need to calculate it. Even if you are capable of calculating the curve doing so can be slower than cheating. How do you cheat? Simple, currently out on the internet are several curve fitting programs you can use for free. Write down the data you want and the program will return the curve for that data. You can select from many different kinds of curves to see what fits the data best. A site you can try for this purpose is:

MyCurveFit.com

Once you have the curve equation, you can calculate out all of the fields.

Here’s how I used the trick for the chart you just saw.

First, I laid out the basic data I was looking for:

Level 1, 10gp
Level 3, 15gp
Level 5, 30gp
Level 7, 80gp

Next I ran that data through a least fitting squares program to get a quadratic curve. That program returned.

y = 3.4374999999998934 + 9.479166666666783x -3.4375000000000324x^2 + 0.5208333333333359x^3

Once I had the data I rounded it and got the chart you saw above. Most of the time the values you get will be slightly off from the values you asked for which happens because curve fitting is approximated not exact.

With that said, who cares if it is slightly off? We aren’t building a space shuttle we’re building a game. The fact is that if your intent was for an item to cost 60 at level 7 but instead it costs 61 is actually an improvement. You can chart out the entire economy past the number of levels you asked for and you can visually see any plateaus or anomalies you data might have.

One quick side note, when I’m building a game I usually build all of the equations to handle at least twice the number of levels, damage, experience, or whatever than I am initially planning to use. It doesn’t take anymore time and allows for extra content to be added at will.

Back to the regularly scheduled program

With all of the preceding data we can now make this next chart:

I’ll explain. We just determined the average cost of an item at a given level. Earlier we specified how many items in a given level we felt a player will want to sell. Multiplying them against the merchant multiplier gives us how much cash a player will get from selling the items. Now we take the total amount of cash the player can get from selling items and divide it by the cost of an item for a given level. This gives us the number of items a player can purchase from selling at that level.

player cash = sell items * avg cost * merchant multiplier

buyable = player cash / avg cost

Earlier we specified how many items we wanted players to buy at a given level. With that information we can now make this chart:

We take the number of items we want the player to buy and subtract it from the number of items they can buy from the cash they have. The number we end up with is the total gold they will need to buy what they are supposed to at that level. We then divide the needed gold by the number of times a monster will drop gold in a level to get how much, on average, a monster should drop gold.

Buyable items = player cash / item cost

items to buy = number of items to be bought – buyable items

needed $= items to buy * avg item cost

$ per drop = needed gold / times gold drops on level

Great, armed with that information we can now build the item and gold economy systems.

In our game we will store a base economic table that is a level and the value for that level. With our game it would look like this:

In every item we need to store the level of the item and an avg value %. Depending on the complexity of the items you are creating you could have prefixes and suffixes on the items modify the base items %. What this gets you is the ability to state an item is worth 50%, 110%, 80%, etc. of the avg value for the level. This way you have a base frame of reference what the value means. In other words, instead of saying, “I have a level 14 item that is a bit overpowered, Should I make it worth 902?” you will say, “This overpowered item should cost 120% of what other items cost at this level.” You can then easily change the percent as much as you want but you have a reference. Even better than that, with this setup you can rewrite your entire economic curve and every item will simply update to the new values. No need to revisit old items. You have access to virtual big and small adjustment dials.

By creating the economy out of how we want everything to relate to each other. We can update any relationship and easily recalculate the entire economy. This allows for the economy to be rapidly tuned in any fashion. Once your playing maybe you’ll discover you want creatures to drop more items, you don’t like how the first few and last levels has similar gold drops, or you think the player’s bank account should show less money in it but still be able to buy the same number of items. All of these tweaks and any other tweaks are easy. Change the variables you want to and new balanced data falls out.

My Economy Isn’t Like That

Very few games have identical economies. This example illustrates how to articulate the relationships you need and turn them into game systems. The process for creating an economy big or small is the same. How would you use these processes to create an economy for a FPS, RTS, Platformer or other? Think about how elements I glossed over such as hording items affects the economy. Some people may ask you to add an auction house or have player traded items. Now you know the real question there is what are you trying to accomplish with those systems? How could you make them to cause the outputs you want from the system?

Think it through, create your relationships and everything else will just fall into place.

Get 10% off a group subscription

Practical Design: Game Economics

Let’s focus on the actual process of making a game economy without talking too much theory.  This article assumes you’ve already made a balanced combat and exp system for the game. 

We know we are building an economy but we don’t know the purpose or function of it.  We need to know our desired inputs and results before we build it.  To do this we start by stating objectives and declaring system assumptions where needed.

First we’ll state the kind of game we are making an economy for.  Since RPGs have robust standard economies with money and bits you buy, want, need, and can’t live without, we will use that style game for our discussion.  Our game has levels you gain, creatures you kill and loot, a merchant you can sell to / buy from, but no player trading.  We want to keep this example cleaner.  The unique aspects of large scale MMO style economies can’t really be discussed until we show how to build a functional smaller one first.

The first objective we need to figure out is a big one.  What input does the player give that allows them to use the economy.  It is critically important to know the relationship of the player to the system.  The most commonly used inputs in various combination are:

• Winning fights / challenges – a player receives the ability to transact in the economy through winning fights.  This is usually set up with a sub-system that awards more or less in a fight with the amount of risk the character was exposed to.

• Time – Either in the game or not.  The player earns the ability to interact in the economy the longer they are associated with or in the game.

• Skills / Achievements – Impressive feats are rewarded with interaction with the economy.

• Money – Cash in the real world is translated to buying potential in the virtual world.

We will base our example economy off of winning fights.  With the input determined we need to begin to determine the system’s interaction with the player and its output.  We will start this process by stating our desires for the player interaction with the economy.  For our example game we will base our example economy off of the following:

• We want players to get items fairly often

• We want players to buy better items

• We want higher level items to cost more

• We want the player to be scrounging for items until the end of the game when we will let them have an easier time getting what they want

• If we had health potions we could would state their desired supply rate here as well

Armed with these desires we have reasonable idea of what kind of relationship we are creating between the player and the system.

The Trick

The trick to putting together a balanced economy is to realize this economy isn’t real.  Fortunately games are VR and not R.  The way an economy acts and reacts is the same in real life but you, the designer, allow every action the player can do.  You allow every action the economy can have.  You don’t have to worry about competitors unless you allow them.  You don’t have to worry about supply and demand you control it.  You have the ability to control all of the possible actions of the player.  What you enable a player to be able to do is what they will do.  As Maslow, Kaplan, or Twain said, “If all you have is a hammer, everything looks like a nail.”  You’re making the game; you should know what a player is going to want from the economy.  For instance, you know most players will gravitate towards the most rewarding items in a visual or battle effective way.

With the trick in mind we can ask, where did I get the desire we listed above? I got them out of thin air.  It doesn’t matter what we state.  There are no wrong desires.  You can have the players get as much or as little from the economy as you’d like.  As long as you state realistic desires you should be able to create a system that meets them.

You might have noticed we haven’t talked about in-game money yet.  The reason for this is that in our example economy, in-game money isn’t an output.  In-game money is one path for converting battles into things we want.  It isn’t the thing we actually want.

Game Economies are not big scary black boxes

Creating an economy for a game can have many steps but is actually fairly straight forward and simple.  Too many people have been talking about them as a mythical system you need to hire 80 year old economists to create to ensure a proper play experience.  Like most things with games, there are tricks and realizations that allow you to create the relationships of a system if you frame the problem the right way.

What are the Game items?

We need to take a quick moment and define the possible item types we will have.  We can’t really setup an economy unless we specifically know what things we are pushing through it.  Let’s say the game will have:

• poor, average, great, and legendary quality items

• Melee weapon, Ranged weapon, Torso, and Legs equipment slot.

• 4 character classes

• Class specific and all class usable items

This gives us a small pool of possible items but we now know 1 set of items is 2 weapons and 2 armor.

Let’s take a break real quick and make sure we understand the high-level concept of the process we are working through.

The economy we are piecing together will work something like this:

Our little example economy is all about items.  The shop and battles creates items.  Items can be sold to the shop, equipped or horded in basic inventory.

We will start by focusing on the section of the economy that dumps in items from battles.  The easy start to this is a simple question, “How often do we want players to get items from battles?”  This is a question of what kind of experience do we want a player to have.  Should a dropped item be a rare coveted occurrence or should all creatures be perceived as overstuffed piñatas?  This is a personal choice for the game.  All types of drops can be made to work with almost any game.  For our game we’ll say that when a battle is won there is a 25% chance of a gold drop or item drop. These percentages will give a great pick-up feel but because of the quantity of drops most individual drops will be less in value.  There is a significant amount of game theory that can be applied to choosing drop rates but I’m going to stick to practical design for now and can talk theoretical design at some other point.

Now we need to switch to the other side of the economy.  How often do we want player’s to get the best set of equipment?   Keep in mind once a player has the best set they are much less likely to care about the other items available at that level.  For our example game we’ll say the player should be able to get a decent set of new armor once per level.   There is a catch though.  If we look at a part of our exp curve (not discussed here) to see how many fights we go through to gain a level we can see that level 3 has 1/20^th the creatures killed as level 20.  Look at this sample “Number of Monsters to kill to Level” chart to see:

Handing out items in a static fashion is a bad idea.  We will want to scale it to be taking more into consideration number of fights won instead of level.  Massaging our data we get a chart that looks more like this:

As you can see starting at level 5 we’ll take the entire level to pass out 1 set of armor where as at level 20 we’ll pass out a good set of armor only after 21% of the level.  I constructed this chart by thinking about what type of balanced relationship I wanted between the number of fights a player needs to win versus the frequency they can get new gear to equip.

One more data point we need to determine is the ratio of dropped vs. bought items.  For ease we’ll say 50/50.

As you may have noticed we haven’t used any hard values yet.  What we’ve done is defined our initial thoughts for the relationships between items, battles, the shop, etc.  It is critically important to know how everything interrelates before we attempt to apply hard values.

From the numbers we’ve stated above we can make this chart to start to get closer to hard numbers:

This chart was made by taking the number of enemies you need to kill to level and multiplying it by our stated desired item and gold drop rates.

Now we have two charts.  One is how many drops that are useful to the player are and the other is the number of drops of items and gold we get per level.  Let’s convert them into one chart.   To do that we need to convert item sets into just items.  We have 4 items in each set but we stated that only half of the items the player will use come from drops, the rest is going to come from the shop.

The number of item drops was taken from the chart above and the desired dropped items was created by the following process:

• 1 item set is 4 items

• Half of an item set, 2 items, needs to come from drops

• We know the total number of drops in a level

• We know how many sets of items we want to hand out in a level

• For each level multiply the number of sets to hand out by the half set drop (aka 2) to get how many desired items should be dropped

• Divide the desired number of dropped items by the total number of items dropped to get the % to use to determine if a killed enemy drops a useful item for any stated level.

Another way to explain how we have gotten to where we are so far is like this:

• enemies per item set = enemies per level / number of item sets for level

• items dropped per level = enemies per level * item drop percent

• desired item drops for level = desired number of item sets for level * size of item set / % of set from drops

• % applicable drops = desired item drops for level / items dropped per level

• We now have the percent that will be used to roll against when an item is dropped.

Here’s one of the most important bits to understand about the process.  If you don’t like how only 19% of items a player gets at level 20 is usable you can increase or decrease it.  Once again, it doesn’t matter you can change the percentage.  By upping it you’ll see the exact number of usable items a player will receive while they are in the level. There is no confusion, it isn’t guess work, you’ll see the full cause and effect.  If you are playing the game and feel the number is off, you know exactly what to change where to get the exact result you want.  No guess work.

Quick Item Drop Design Example

A quick scratch pad design doc system write up for the item system could look like this:

When the character kills a generic monster the game will roll a 25% chance of dropping an item.

If the game decided to drop an item it will then roll a % chance of dropping an item of the player’s class depending on the level.  For each creature killed roll against the following to determine if there is a drop:

If the roll failed to drop on the player’s class randomly roll to choose one of the three other classes all with equal chance.

Next determine which slot the item dropped will be from the table to determine slot drop is as follows:

MELEE WEAPON               25 %
RANGED WEAPON            25 %
TORSO                                   25 %
LEGS                                       25 %

The game will then search the item table for an item that is for the chosen class and slot at the level of the killed monster.  If an item is found, the game will drop the item at the location of the enemy’s corpse.  If no item is found the game will re-roll the class and slot selections to try again.  If no item is found after 5 attempts the game will switch to a gold drop instead.

-End simple sample design-

Obviously this system is fairly straight forward and dry but you can clearly see how this system creates outputs that match the relationships we wanted.

Continued in part 2

Get 10% off a group subscription

Link to file below for paid subscribers.

For quick navigation in the video, here are some times:

0:00  Intro

3:11  The Questions

18:26 Team Questions 

19:05 Settings

22:14 Results

25:41 Results Expanded 

36:27 Outro

Are you building the right thing?

I’ve seen many times where teams are spending time on good features when they could have been working on great features. A few select reasons from many reasons you may see this are:

• The developer has limited exposure to customer benefits

• Team could use greater understanding of the target experience

• Poor communication between or from stakeholders

• Less focus on building for customers

• It is a passion project for the team

To be used as a meeting exercise, I created a calculator to show how valuable a feature, maintenance, infrastructure or pipeline work is for a project. The calculator does a good job showing if the work:

• Is required

• Is risky

• Is too large

• Is better to buy or license instead of building ourselves

• Is potentially a distinctive competency

• Has good ROI

• Has a workaround that is better than the feature

• Is something we are confident is

• What priority number it should be

The intent is not to have this calculator actually pick what we should do. The intent is to ensure we have thought through what we intend to do, have the ability to answer all of the questions about it, and have had a chance to talk about it.

In the next video of this series I’ll start stepping through exactly how the calculator determines everything.

Lastly, A note for the eagle eyed of the bunch, I’ve squished the small bug that you might see.

Thanks

Get 10% off a group subscription

Read more

Bullets need non-zero local positions to determine shot direction. Create a ringbuffer for live bullet instances. Implement enemy bullet move and spawn update functions. Like the enemy instance update, given a well-defined data layout and constraints, the update code is a straightforward process. There’s not a lot of variation in what it could be doing. Add time out to enemy update.

Next: Port a Unity Game to Your Own Engine: Part 17

Links to files below for paid subscribers.

Read more

Add export description for the bullet spreadsheet. Use the identical export code from the enemy instances spreadsheet. Minor patches in the runtime code to correspond to changes in the enemy instance data. Add script to export KSY file (along with the C header and runtime binary files) from spreadsheet. Memory map in bullet data.

Next: Port a Unity Game to Your Own Engine: Part 16

Links to files below for paid subscribers.

Read more

Changing the approach. Simpler to lookup bullet type from enemy instance. Revert the enemy used per wave bitset we added last time. Prepare the bullet spreadsheet for export. Change from using delta start time in the enemy instances data to absolute start time, to make it easier to get time since spawned, since bullets are spawned relative to that clock.

Next: Port a Unity Game to Your Own Engine: Part 15

Links to files below for paid subscribers.

Read more

Spawn position can be pre-transformed as relative position to enemy.

In order to use the bullet data, we will need to find the enemy instances that match the enemy type in order to spawn at correct relative location.

• Take the opportunity to remove enemy type vs enemy variation type distinction. That extra bit of abstraction doesn’t buy us anything. Limit total enemy types to 64. It was bugging me anyway and I shouldn’t have added it in the first place.

• Create a bit vector per wave which tells us if an enemy type is used in that wave or not. To use as broadphase check. Update exporter to save 64 bit value.

• Next we’ll need to be able to lookup instance index by enemy type per wave.

Quick fix

I fixed the indexing for string input in the hex to 64bit output.

Next: Port a Unity Game to Your Own Engine: Part 14

Links to files below for paid subscribers.

Read more

Sometimes it’s not worth it to write up a script to export data when it’s spread throughout a bunch of different systems and files and there’s not much of it anyway. So here I’m just manually extracting bullet data, which gives me a chance to look at each case one-by-one and make sure I have a pretty good understanding of what we want to be able to accomplish.

Next: Port a Unity Game to Your Own Engine: Part 13

Links to download files for paid subscribers below.

Read more