#fixedupdate

[dangersam]

Happy Holidays everyone, here's one more small update for the year!

Weld tool

This is a new script mod tool that allows parts to be attached to one another, without them needing to be properly aligned together.

They can even be unfrozen.

Jointed attachments can be created, including rotary, slider, or any other type.

Note that the attachment locations are still derived from the part's alignment grids, so an attachment can't be created at an arbitrary position or orientation. This doesn't make much difference for fixed attachments, but it does limit the possible locations of jointed attachments.

Also note that some part behaviours may be expecting only one attachment of a certain type, and creating extra attachments with the weld tool may result in unexpected behaviour.

This tool is really intended for advanced builders who want to circumvent the usual grid based limitations, it's not intended to replace the standard building system.

Lua scripting

For the modders out there, there are some additions to the Lua scripting API. From a Lua script it's now possible to get and modify part behaviour tweakables, create and delete part attachments, and even apply physics forces to parts. I look forward to seeing what you can come up with using this stuff!

There are a few other improvements and additions too, as always, check out the release notes for details.

Thanks to you all for your support this year, for playing the game, and for sharing your amazing creations!

Release notes:-

Lua scripting changes and new features:-

Added new ITweakables interface implemented by part behaviour to provide access to its tweakables.

Added methods to IAttachmentOperations to create, replace, and delete part attachments.

Added FixedUpdate entry function, called on Lua scripts once per simulation time step.

Exposed fixed delta time value.

Added new IPhysical interface implemented by part descriptor, with a method for applying a force to a part.

Added TargetedPosition property to ITargeter interface.

New script mods:-

ServoTool - Sets a servo / stepper motor's trim angle from its current angle.

WeldTool - For attaching one part to any other, without them needing to be aligned together, or even frozen!

PhysicsExample - A simple demonstration of applying a force to a part.

New 2.5x9 truck wheel (rim designed by Nate).

Implemented joint force / torque debug visualisation, and added options to ConstructionDebug script mod to enable it.

Added dropdown menu to part behaviour UIs, as an alternative way to choose a joystick axis to bind.

Added toggle to video options for disabling chromatic aberration, independent of vignette.

Bug fixes.

[duckdotcom]

*modifies your FixedUpdate() method to improve your fps*

[sp-epari-digitalmedia]

Critical Analysis

Nardone, V. et al. (2023) 'Video game Bad Smells: What they are and How developers perceive them,' ACM Transactions on Software Engineering and Methodology, 32(4), pp. 9-12. https://doi.org/10.1145/3563214.

Introduction

The abstract presents an in-depth analysis of video game's "bad smells," categorizing issues into five distinct groups that include design, game logic, multiplayer, animation, physics, and rendering. It presents a methodical examination of every category, going over particular bad smells and offering instances from pertinent conversations. Using information from survey participants, the paper provides workable ways to reduce these bad smells. To ensure traceability, the study connects every "bad smell" and its remedy directly to discussion boards or poll results, enhancing the legitimacy of the suggested fixes.

Bad Smells

According to the authors, this dual approach in the study, strengthens the paper's overall reliability, making it a valuable resource for both game developers and researchers. One noteworthy finding is the fact that respondents disagreed on how important some issues are. A few perspectives present the idea that the impact of a particular challenge can change depending on the project's size and how much moderation is used. This highlights how game development challenges are subjective and that the importance of a problem varies depending on the context.

Weak temporization strategies are a major focus of the analysis, with 80% of respondents rating them as critical or extremely critical. In particular, when it comes to frame-based updates, the highlighted issue involves incorrect assumptions about the amount of time that has passed between game object updates. To provide a consistent gaming experience, it is crucial to address this issue as it may lead to differences in animation speed among devices.

Respondents offer workable solutions to address these inadequate temporization strategies and lessen the problems noted. Typical errors such as frame-based updates affecting animation speed, are identified and workable fixes are proposed. Time-based updates, like the FixedUpdate method in Unity, should be implemented. Additionally, movement should be proportionate to the intervals between frames. A few respondents' emphasis on these solutions lends credibility to their efficacy in addressing common game development pitfalls. The analysis also emphasizes how crucial early intervention is in resolving temporization issues. one of the respondents makes it clear that the longer these issues persist, the more difficult it is to address them. This insight highlights how proactive developers should be in spotting and fixing important problems early on in the process to avoid problems later.

A real-world example from the Unreal Engine forum provides tangible evidence of developers grappling with temporization issues in a racing multiplayer game. The discussion highlights the practical application of "delta time scaling" as a solution to address input responsiveness, illustrating how these challenges manifest in real projects.

Focusing on the lack of separation of concerns and the issue of bloated assets. While these challenges may not be unique to the gaming industry, they are pertinent in the context of game development due to the specific characteristics of game engines.

One sign of poor design that can appear in a variety of software programs, including video games, is the inability to separate concerns. The observation that game engines may naturally lead developers to write code that exhibits this problem led to the decision to keep this "smell" in the catalog. In the example given, source code for object animations is mixed with code handling controller inputs; this practice was deemed critical or extremely critical by 77% of respondents.

The significance of this design challenge is further highlighted by the discussion on StackExchange's Game Development section. Logic and data in the same object or class, according to platform developers, is bad practice that can result in hacking that creates more problems than it fixes. It is recommended that game logic and game data be kept apart, and that a modular approach be used, with different classes handling different concerns like movement, firing, and defense. Notably, Unity and other contemporary game engines are taking proactive measures to address this problem by including features like an updated input system. Bloated assets, or reusable assets like complicated game objects that bring along different elements like textures and predefined animations, are the subject of the second design challenge that was discussed. Sixty-three percent of respondents rated this "smell" as critical or extremely critical. Real-world examples are given in the Stack Exchange game development discussion, including scenes with superfluous art assets and scripts. Not only do developers advise eliminating unnecessary assets to conserve space, but they also point out potential problems like mismatched names and superfluous animations if this is overlooked.

Comprehending the issues raised, specifically the inability to distinguish between different concerns and the problem of excessively large assets, provides game designers looking to improve their work with insightful knowledge. Not only do these detected "smells" diagnose possible problems, but they also act as a helpful roadmap for better game design. Recognizing the inability to separate concerns as a design challenge invites a game designer to take a more modular and structured approach. The division of various game elements, like controller inputs and object animations, into discrete areas allows designers to simplify code, lower complexity, and improve maintainability. The Stack Exchange discussion on game development, which is cited, emphasizes how crucial this division is to preventing potential problems and unethical behavior. This realization can serve as inspiration for designers of video games, who can use it to create modular systems that support a variety of features.

The issue of bloated assets provides another avenue for constructive improvement. Game designers can leverage the awareness that excessively large assets, containing elements rarely used, are viewed critically by developers. By adopting a more discerning approach to asset creation and management, designers can optimize game performance and streamline the development process. The practical recommendations from developers on Stack Exchange Game Development, emphasizing the removal of unnecessary assets for both space-saving and organizational cleanliness, can guide game designers in creating more efficient and polished games.

Conclusion

It gives game designers more options because it acknowledges that some game engines are actively resolving these problems, as demonstrated by Unity's new input system. Designers can ensure that their games follow industry best practices and utilize state-of-the-art tools by keeping up with evolving engine features and adapting their practices accordingly. The study overall is relevant as it recognizes the bad indications in game designs and therefore validate a better quality of games if these problems are avoided.

[severevoiddragon]

VOID FIXEDUPDATE() MY BELOVED

[jb-fmp-year-two]

• Making The Movement - Part Two

• Introduction

So, In the previous post I described how I made the player move around and why I chose to use certain things as opposed to others.

You may have noticed, however, that nowhere did I mention moving the camera. Currently, the player isn't able to look around the scene, which is pretty important if the player's going to be jumping around and aiming... it's pretty much impossible, actually...

• What I Did

I've used the exact same method for letting the player look around for years now, simply because it works great, and it isn't too hard to write.

The code comes from a tutorial I watched ages ago by the Youtuber Brackeys, where he showed how to make first person 3D movement in Unity using the Character Controller system, as well as camera movement.

And, for simplicity, here's the final code I used:

There are a few differences, but the logic stays mostly the same. We use the vertical mouse input to let the player look up and down (clamped to -90° and 90°) and the horizontal mouse input to look left and right. The up and down input moves the camera directly, whereas the left and right input rotates the actual player itself, making it easier to get the player to move where we're looking and also rotating the camera.

I use the OnLook function to get input from the input system, but there's one other thing: A the top, I check if the player is using a controller and, if so, multiply the sensitivity by 10. This is because input gotten from a controller is much slower than input from a mouse (because the controller's input's magnitude is clamped to one whereas the mouse delta (change in mouse velocity over time) is unclamped).

And that's basically it, I explained most input related stuff in the previous post, so there isn't much more to talk about. Other than the reasoning for why I used FixedUpdate to rotate the camera, instead of Update. This is because I'm using a rigidbody to move the player, which runs on FixedUpdate, using Update produces jittery results.

[ashlyplus]

Games Design Week 7 08/11/2024

Over the past week I have been unsuccessfully trying to make my movement consistent and independently of the colliders. today I finally managed (with help) to find a solution - albeit a janky one. :3

As long as the collider used when the ship's movement is balanced is the same as when it Wakes for Runtime it will balance it's inertia correctly, permanently and independently of the Collider attached to it or its children. Apart from this, which has absorbed most of my time, I tweaked movement to make it feel truly perfect, added thrusters which act as small maneuvering thrusters and movement physics interactions in-script to a FixedUpdate method to stabilize interactions.

Cyu next week!

[yet-yo-be-named-game]

Optimizations

Unfortunately, my game isn't really the fastest, regularly dropping from 300fps to 100fps. Here are some of the optimizations I have added to bring it to 250fps+.

First off, I added the impact particles from the bullets as a child of the bullet, and activate it on impact. Originally, I planned to create a separate object pool for the particles, but that turned out to be slower.

I then made it so that every light source is only enabled when the player is close enough. Because I really don't need to be calculating lights if they're not being seen.

As you can see, in the Awake() function (which is run once at the start of the game), I get references to the light and the player, and in the FixedUpdate() function (which runs a fixed amount of times per frame), I check if the light exists and if it is close enough to the player and, if it is, I render it. Otherwise, I just disable it.

Then, I changed some rendering settings, making the normal-mapped lighting texture a slightly lower resolution. Now that I had added the particles to the pool, not many rendering things needed to be optimized and this really didn't make much of a difference.

There wasn't really much more I could do, and now it takes around 3ms and 2ms on the cpu and gpu, where it was taking 12ms and 5ms (or something around there).

Ideally, I would use unity's DOTS for the shooting, but it uses a coroutine and I couldn't figure out how to make that work.

As you will be able to see in the video, when the player gets far enough away, the green light is hidden, but when the player gets close enough again, it re-appears. The effect has been drastically amplified (I just lowered the distance) for the purpose of the video:

Another thing I could have done to make this better was, instead of just disabling and re-enabling the light source, I could make it so it gets darker the further away you got, making the effect of it popping in and out less noticeable.

[2danim-demo]

The Code I ended up using:

using UnityEngine;

public class PlayerController : MonoBehaviour

{

private Animator animator;

private Rigidbody2D rb;

public float speed = 5f;

public float jumpForce = 10f;

private bool isGrounded;

private bool isWalking;

private bool isRunning;

private void Start()

{

animator = GetComponent<Animator>();

rb = GetComponent<Rigidbody2D>();

}

private void Update()

{

// Handle input for movement

float horizontalInput = Input.GetAxis("Horizontal");

isWalking = Mathf.Abs(horizontalInput) > 0.1f;

isRunning = Input.GetKey(KeyCode.LeftShift);

// Set animator parameters based on input

animator.SetBool("Idle", !isWalking);

animator.SetBool("Walk", isWalking && !isRunning);

animator.SetBool("Run", isWalking && isRunning);

// Jumping

if (Input.GetButtonDown("Jump") && isGrounded)

{

animator.SetTrigger("Jump");

rb.AddForce(new Vector2(0f, jumpForce), ForceMode2D.Impulse);

}

// Special move

if (Input.GetButtonDown("SpecialMove"))

{

animator.SetTrigger("SpecialMove");

// Add code for special move behavior here

}

}

private void FixedUpdate()

{

// Check if the player is grounded

isGrounded = Physics2D.OverlapCircle(transform.position, 0.2f, LayerMask.GetMask("Ground"));

}

}

This ended up being my final code, however it was not working because it turns out I didn’t have a movement script included. In Unity, I created completely new parameters from scratch, so I could start over. I added isWalking, isRunning and isGrounded bool parameters, and set Jump and SpecialMove as triggers. Jump was already there, but I created a custom SpecialMove key in Unity Editor. I’m using A & D movement, space to jump and E for special move

[games-und-lyrik]

Welches Problem habe ich, wenn mein Charakter nicht fällt?

Wenn in deinem Game dein Charakter nicht fällt oder zu schweben scheint, kann dies auf mehrere Ursachen zurückzuführen sein. Hier sind einige der häufigsten Probleme und wie du sie beheben kannst: 1. Fehlende oder fehlerhafte Rigidbody-Komponente - Problem: Der Rigidbody ist für die Physikinteraktion verantwortlich. Wenn kein Rigidbody vorhanden ist oder falsch konfiguriert wurde, reagiert der Charakter nicht richtig auf die Physik, einschließlich der Schwerkraft. - Lösung: Stelle sicher, dass dein Charakter-GameObject eine Rigidbody-Komponente hat. Überprüfe die Einstellungen des Rigidbody, insbesondere ob die Schwerkraft aktiviert ist („Use Gravity“-Option in Unity). 2. Probleme mit dem Collider, sodass der Charakter nicht fällt - Problem: Der Charakter könnte einen Collider haben, der nicht korrekt mit der Umgebung kollidiert. Dies könnte daran liegen, dass der Collider zu groß ist, in der Luft schwebt oder die Layer-Einstellungen eine Kollision verhindern. - Lösung: Überprüfe die Collider-Komponente des Charakters. Stelle sicher, dass die Größe und Position korrekt sind und dass keine Layer-Konflikte bestehen, die Kollisionen verhindern könnten. 3. Skriptfehler - Problem: Ein Fehler im Bewegungs- oder Physikskript kann dazu führen, dass der Charakter nicht fällt. Dies könnte ein Fehler in der Logik oder in der Implementierung der Physik sein. - Lösung: Überprüfe die Skripte, die die Bewegung und Physik des Charakters steuern. Achte auf Abschnitte, die die Position des Charakters manuell verändern oder die Schwerkraft beeinflussen. 4. Kollisionsebenen (Layer) oder Physik-Einstellungen - Problem: Manchmal können die Layer-Einstellungen oder allgemeine Physik-Einstellungen so konfiguriert sein, dass bestimmte Objekte nicht miteinander interagieren. - Lösung: Überprüfe die Layer-Einstellungen und die Physik-Interaktionsmatrix in Unity, um sicherzustellen, dass dein Charakter mit der Umgebung und insbesondere mit dem Boden interagieren kann. 5. Animationen - Problem: Wenn du Animationen verwendest, können diese manchmal die Physik überschreiben, insbesondere wenn Animations-Rigs oder -Skripte die Position oder Rotation des Charakters direkt steuern. - Lösung: Überprüfe, ob Animationen die Physik beeinflussen. Stelle sicher, dass Animationen und Physik korrekt zusammenarbeiten. Du könntest Root Motion in den Animationen deaktivieren oder Anpassungen vornehmen, damit die Physik Vorrang hat. 6. Endlose Schleifen oder Blockierungen im Code - Problem: Manchmal kann eine endlose Schleife oder ein blockierender Code im Update- oder FixedUpdate-Zyklus dazu führen, dass die Physik-Updates nicht korrekt verarbeitet werden. - Lösung: Überprüfe den Code auf mögliche endlose Schleifen oder Operationen, die zu lange dauern und somit den normalen Spielablauf blockieren könnten. Fazit Um das Problem effektiv zu beheben, solltest du systematisch vorgehen. Beginne mit der Überprüfung der grundlegenden Komponenten wie Rigidbody und Collider, gefolgt von einer detaillierten Überprüfung der Skripte und Einstellungen. Oftmals liegt die Ursache in einer Kombination kleinerer Fehler, die zusammengenommen das unerwünschte Verhalten erzeugen. Lesen Sie den ganzen Artikel

[dangersam]

Hey all, just another small update!

New Flat Map

There's now a new "Concrete Pad" map:

It's just another boring flat map, but hopefully a bit easier on the eye for long building sessions than the "Flat Plane" map, plus it has no environmental audio.

Part Selection Duplication

You can now duplicate your current part selection.

Select some parts:

Then open the SELECTION menu and click Duplicate Selected (or just press Left Ctrl + D):

This will duplicate the parts into new construction(s), with attachments, links, etc. intact:

NOTE: To implement this, I had to change the save format slightly. Any "part intersections" (the red crosses you get after deleting attachments between intersecting parts) from existing saves will be lost.

Deprecated Parts

The engine "front crank" parts are now deprecated, as the "crank nose" part makes them redundant. I can't remove them without possibly breaking existing creations, so they're still in the game, just hidden in the part spawner UI.

NOTE: If you need to get access to these deprecated parts in the spawner UI again, type ShowDeprecatedParts true in the debug console.

Lua Scripting

There's now some additional physics functionality available from Lua scripting, you can now do stuff like:

function FixedUpdate() if Physics.RayCast( Vector3.__new( 0, 10, 0 ), Vector3.Forward, 1000 ) then local distance, position, normal, colliderInstanceID = Physics.QueryCastHit( 0 ) local part = PartColliderRegistry.GetPart( colliderInstanceID ) if part then print( part.FullDisplayName ) end end end

See the API documentation for more details: Physics Proxy

Also, typing "LogKeyNames" or "LogAxisNames" in the debug console now lists all available input key and axis names respectively. This allows you to more easily find out what key names can be used in Input.GetKey() etc.

Release notes:-

NOTE: Changed save format, any "part intersections" from existing saves will be lost.

Implemented part selection duplication. To duplicate the currently selected parts, click Duplicate Selected in the SELECTION menu, or press Left Ctrl + D.

Torsion springs now have an option to turn off angle clamping.

Engine "front crank" parts are now deprecated and hidden in the spawner UI (given that the "crank nose" part makes them redundant).

Modified the EngineTool script mod to allow choice between showing engine head's timing angle or current crank angle.

Lua scripting:-

Added Physics module with methods for raycasts, spherecasts, etc.

Added PartColliderRegistry, with a method for retrieving a part from the ID of one of its colliders.

Added an overload of CreateAttachment() in IAttachmentOperations that takes a separate search position and normal for the owner and connected parts.

Typing "LogKeyNames" or "LogAxisNames" in the debug console now lists all available input key and axis names respectively (to be used in Input.GetKey() etc. for Lua scripting).

Added "Concrete Pad" map.

Bug fixes.

[thesourcegame]

Radio Silence, and for what reason

A small little update from my side and most importantly the reason why I failed to post updates on my blog. A couple of months ago I figured I needed to swap out my PlayerController from being CharacterController based to Rigidbody based. It took quite some time rewriting the different player mechanics and unfortunately without the wanted results. The initial reason was simply because I thought the game needed more physics interaction and that only a Rigidbody based PlayerController would make this possible.

Unfortunately I was terribly wrong and I stumbled from one bug into the other (Camera following physics objects, FixedUpdate vs Update and the amount of control the player has over a Rigidbody PlayerController). Going back to a CharacterController was a really hard decision, since I felt all the work was for nothing. This however was not true. I eventually managed to fix issues 

I previously had with the CharacterController component like sliding from edges and am currently reworking the pushing mechanics into a Push and Pull mechanic (This is almost done, but takes a lot of time because of the complexity and animations). None the less, I will try to maintain this blog alot more and I’m aiming for a playable first demo level around june/july.

Small preview of the Pull mechanics

[corruptspaghetti]

Here are my final results for my Ludum Dare 53 game, Alien Postal Service!

Overall, the scores are about the same as my previous jam game from LD51. I did, however, score slightly higher in Audio and Innovation (which I’m quite proud of).

I ended up learning a lot grappling with Unity’s physics engine that’ll help in current and future projects. The main takeaway being to put ALL physics-related code in FixedUpdate() rather than Update().

This one would need a lot of work to be made into a full game, but I definitely had a fun time making it.

[the-64th-gamer]

Min-Max v0.9a Release!

The latest version is now out for Patrons! Online multiplayer is here!

We did a 4 player online match for about 30 minutes and I got all the footage recorded, cannot express how big the smile was on my face seeing online play with something I made!!!

Patch Notes:

Added Multiplayer Server Support! When you create a server, a server code will be copied to your clipboard to share to others. The code is good until you shut down the server.

Added the ability to save local and online servers

Added the ability to ping local and online servers for information before joining.

Servers now deny users trying to connect over the max player limit

Servers now can be named.

Added the beginnings of the The Surge wires, where players can pull the wire by crouching and branch it as many times as needed.

Added a new map, Nara.

Players can now crouch with pressing the right VR stick, or the ctrl key.

AI bots now look at the nearest player, but prioritize nearest enemy.

Air-breaking now implemented

Moved more sections to FixedUpdate

Changed FixedUpdate to be 90fps

Fixed flatscreen clients sending extremely choppy data

Fixed map geometry only using one team's color

Reduced the intensity of clients synching physics to the exact server data.

[rei-makes-big-robo]

Project HD Devlog #1: Late to start writing

Project HD was the second of my late 2022-2023 VR game prototypes, it progressed far within the first month of development until I lost track of what I wanted it to be and started to develop Project CWD. Project HD was sort of a half accident half intentional mix of goofy action oriented gameplay mechanics for a VR action platformer, mostly revolving around having hammers for hands and needing blood to heal (Very original I know).

The blood part was sorta vaguely because I wanted that sort of blissful ignorance for how much health you have in games like Ultrakill, need health? just kill an enemy and bathe in their blood! I still have not implemented any method of this as in it's current form it lacks any organic entities, just the Squeakers which are named from their early prototype form (and the rubber domed tutorial version) producing a squeak from a dollar store Halloween rat decoration.

Originally they were just a red block with a knife that would either stab or do a spin attack, they have since grown to be weird stabby trashcans that slide around and if you're unfortunate enough to be sitting when it attacks you might get stabbed in the eye. The big conflict with the Squeakers is that their current version uses a character controller instead of a Navmesh agent and it can be very derpy (video below), which has been causing me to consider reverting them to the Navmesh version.

So now that I've infodumped about stuff nobody will care about or find interesting here's the real shit! Project HD relies on the ability to adjust how much mass your hand hammers have with the analog triggers which allows you to jump very significant heights and distances. The problem with this is that my headset uses inside out tracking which I thought caused a lot of inaccuracy and inconsistency in these jumps, however that was not the case. My partner (romantic) has a Valve Index which uses lighthouse tracking which is pretty much the best kind of tracking if you have space for it. So after 3-4 months of leaving Project HD dormant I opened it up in Unity and prepped the testing scene for a build.

After I sent my partner it I immediately had to rebuild it with proper controller configurations for the Valve Index controllers which was as simple as clicking a button or two. After trying it for a bit her takeaway from it was that it's movement and mechanics were "counter intuitive and inconsistent". Both things I didn't expect but now I was filled with glorious purpose, a reason to pick up the hammer and smack some C# with my crappy oem keyboard. In hindsight I should have seen both these problems coming, most weird movement mechanics in VR are sorta the inverse off a mass jump leading to the counter intuitiveness of it. The inaccuracy however was just me being a moron, an absolute hamster pressing the buttons and waiting to see a red error telling me to try that again. However in this case everything worked, not well but I didn't know any better at the time I wrote a lot of it. The entire hand controller script was updating with the framerate, sounds pretty normal for most things. Until you consider the fact that half of it was controlling physics objects.

So back to the purpose stuff, today (technically yesterday but hey that's what happens when you don't sleep till 6am like some kinda vampire gremlin) I started to change some stuff around to try to fix some of these issues. I started by adding interpolation to the rigid bodies of the hammers, which makes them feel a little sluggish but they almost come out feeling better like this. I then changed the entire hand script to run off FixedUpdate, meaning it updates with the physics tics which are consistent rather than the frame rate. Clearly having a wave of inspiration from the time spent on Project CWD I started to work on implementing post processing effects to get it closer to the visual style I wanted. I also set it up to change the effects based on health which ended up working really well with the existing effects of your energy hammers fading away more and flickering.

After two gameplay tests by myself the inconsistency of the mass jumps had been resolved feeling smooth and vastly more precise to respond to my intentions. The bloom and other post processing effects helped to really make things feel a lot more alive and even made me reconsider my stance on scrapping a certain parry indicator (story for another time). Thus I have begone developing Project HD again by accident and this time I wanted to share it somewhere other than Discord creative channels. I'm still very uncertain of what I want to do, I really like to make stuff like this and I really think it's a very fun game concept but my financial situation forces me to consider it as business and I'm not sure I'm good enough to ship a product worth paying for. My skills are varied across so many fields and none of them have a diploma to my name or are relevant to my existing job experience. That's part of why I post to accounts like this to serve as a sort of portfolio to prove to myself that I am capable of making things. That the years I've invested into this haven't been a waste. I've been considering trying to apply for a digital art position at some game development companies, but I'm also very much afraid of losing my time to projects I have no passion for and not having time or energy on the side to do what I really want to be doing. To anyone that read this far thank you and sorry. Writing this has given me some confidence that this is what I should be doing, that I should keep crawling like the worm I am.

[creta5164]

[Second week of 2021.11] White Spirit devlog - Item's potential

Hi, there!

In this week, I implemented one of the game's core systems : Item Traits.

The Item Traits

CC : Item and inventory system

In White Spirit, the item itself has its own traits.

An item can have item traits regardless of whether it is a material item, a consumable item, or a key item.

These will be make minor numerical changes, even some traits will make Poi look completely different (= game play changes) or affect the environment itself.

Items can be obtained from specific locations or NPCs or by combining them.

It pursues the goal in accordance with the theme of exploring the series of processes that the player goes through while exploring and obtaining or combining items.

In particular, the item traits system implemented this time is focused on generating interest in exploration by making big and small changes to the gameplay itself by using items obtained by players while exploring.

However, the White Spirit project also has the character of an action platformer, so I didn't want to force certain players to play this way only because of their needs about action platformer genre.

So, I'm trying to prepare a system that collects money from all over the world and deal with merchant for the desired item.

Because I wanted to make it possible to obtain items from the merchant and provide them with a reward called item traits just by walking around enjoying only the platformer action.

Anyway, first of all, I wanted to avoid having all possible restrictions in terms of design when thinking about something through this system.

So if I need to be able to set item properties very finely, then a script is a must choice, right?

As you can see in the picture, item information is registered through ScriptableObject.

So at this moment, I was thinking about how to clearly connect this to the script...

I decided to solve this by caching and linking all item attribute classes by attaching a specific attribute to the class containing the behavior for the item attribute.

The framework of the class you want to cache looks like this.

Item traits allow you to define behaviors when acquired(Acquire), when acquired by craft(Craft), when lost(Loss) from inventory, when used(Use), and when only possessed(FixedUpdate).

I can then link the trait to the item data in this way, and configure the behavior I want within this trait class.

And I made it possible to call actions according to each situation to the data, which is the model role. (Example like the 6th line in the photo)

Finally, I did some extra editor work to make sure this is a good link between the traits and the item, and to be able to modify the traits behavior directly from the item database.

If you want to import a script file as an asset in the Unity editor, you can import it as a MonoScript type with an extension to the asset database.

Then, if you pass it to the ObjectField as MonoScript type, you can display the script with the same appearance and behavior as the component's script field shown in the inspector.

This is how I ended up implementing the item traits system.

CC : Item and inventory system

One big system got the job done.

In next week, I'll make an unfinished playable demo content while thinking about usages of the items.

See you in next week.

[monkeykidgc]

When creating new C# scripts within Unity you will notice that the script is generated with two default methods, Start and Update.