This was, for all practical purposes, a vacation week from hobby game dev. I don't have anything material to report.
I dedicated a page in my wandering-thoughts notebook to use as a word cloud for Nimster concepts. Any animal I can think of that doesn't have a Nimster yet, and as many words as I could free-associate with the Nimster types that don't have as many Nimsters yet.
I've also decided that, since Nimsters runs in the console and has all the aesthetics of a text adventure game already, I'm going to pitch out my existing tile-based map system (barely past the prototype phase) and replace it with something like a roguelite structure. Essentially, when you set out from Town A to Town B, you have to clear a certain number of events before arriving. Events will be arranged in sets based on the type of area you're moving through, and after you resolve whatever event occurs, you get a choice of what type of "chamber/zone" you want to move into next, again based on the type of area you're already in. So the general shape of an encounter table might look like...
Road Encounters
- Attacked by Squarrel (rarely)
- Attacked by Canairy (rarely)
- Encounter a Nimster tamer (sometimes)
- Nothing (common)
- Smooth sailing (-1 encounters to destination, rarely)
- Arrive at destination (forced, and only if encounters to destination <= 0) Exits
- Road (always)
- Grass (sometimes)
- Tall Grass (rarely)
Tall Grass Encounters
- Attacked by Squarrel (common)
- Attacked by Canairy (common)
- Lost Item (find a low-value item, rarely)
- Encounter a Nimster tamer (rarely)
- Nothing (sometimes)
- Lost in the Grass (+1 encounters to destination, rarely) Exits
- Tall Grass (common)
- Grass (sometimes)
... and so on and so forth.
My goal for this week is going to be to draw out a rough map of the world the game takes place in, as a means of focusing myself on figuring out what needs to be placed where in the level progression. Design work is surprisingly difficult at times.
My favorite musical instrument is the air-raid siren.
+3
WearingglassesOf the friendly neighborhood varietyRegistered Userregular
Might be a stupid question, but
What would be the Minimum Viable Product / vertical slice of a Monkey Island-esque + walking simulator game?
I'd say a 10-15 minute self-contained portion of the game that gives the players an experience of what you expect the full game to be like. Include your themes, story, core gameplay elements, anything that you feel defines your game. Could be longer if you need time to bring those across (I imagine a slow, moody game needs time to breathe), but I would go for quality over quantity.
So, in something like the original Monkey Island, the intro and bar would be a great pick- you're introduced to Guybrush, you get to experience the writing and you have some puzzles to solve.
After three weeks of absolute brainstall, I'm looking into re-instating some time-management structure into my days to make sure that I'm making at least a little forward progress. Technically speaking I advanced the Nimsters project a little by coming up with some monster concepts (and I'm within the low double digits' distance from the target of 300 of them), but since those just kind of happen whenever they fall out of my pun-developing brain structures as they occur, I don't really count that as work, and the small sketches I did of the traversal system I outlined last week similarly don't really qualify as progress.
Next week's goals are the same as the last several weeks'.
My favorite musical instrument is the air-raid siren.
I spent a week condensing 10 pages of rambling ideas, problems and potential solutions into a 4 page design document. Still a few TBDs in there (and I can always add more stuff later. Coming up with more dumb stuff is never a problem), but for now I have the core loops and mechanics feeding into one another's progression. We'll see how well that works when I get to the prototype stage.
I then went "well, I should make a basic GUI next!", then after two days of getting stuck in the weeds decided that, actually no, that's a bad idea, there's nothing a UI can do that I can't accomplish with ugly debug keyboard shortcuts for now, I can figure out the UI after I've implemented enough gameplay that I know I won't be changing and making previous UI work pointless.
Today's a bank holiday here, so I spent much of it working on basic stuff I'll need for the building portion. It's meant to be a simple no-mouse "your character position determines the build location" thing, so for now all it's doing is looking at where the player is standing, accepting an arbitrary rectangle (in tile count) for the building size, then figuring out how to position those x&y tiles on the level's tilemap (since that's what will hold them).
A 4x3 frame placed at the player's feet. In the background it's figuring out the tiles it's overlapping, so I'll be able to check for building overlap, or make sure they're not out of some requirement range of another things, etc, but visually it simply displays a rectangle for now so I can see it's doing the selection correctly.
Not that much to show, but it was a good way to refresh my memory of how Godot's tilemaps and signals work (and discover odd gotchas like "you can't modulo a float". Okay? Sure).
At this pace I'll have a game around 2030, but that's fine, it'll still be done before Skull and Bones.
Still slow, but I actually made some progress this week. I think focusing on the world map was the wrong way of going about trying to figure out which Nimsters should appear when; so, to unblock myself, I changed my approach. Instead of trying to draw the world out, I sorted all of my Nimster concepts into lists by type and then by whether they're final or non-final forms. Then, I re-ordered them in terms of relative power while assigning them a power level (in terms of total stats). The end result is that I now have a clear power progression within each type, and while designing areas I can just pick at the bottom of each list until I'm out of Nimsters to assign to zones. Or, to put it another way, the question of when the player should encounter a mountainous region is answered by looking at whenever the type power curves hit the point where you start seeing the first form of the bear, wolf, and deer-themed Nimster lines.
As a cost-cutting measure, I'm abandoning the idea of Nimster equipment (the game's equivalent of held items). All items in the game will be expendables.
... and I guess I didn't mention this, but looking at my spreadsheet where I've been storing my Nimster ideas, I hit my target count. I've doubled up on some idea spaces (there are two different "lion" lines, multiple mushroom families, and a bunch of different rabbits), but y'know what? Who cares. Even Pokemon itself has some duplication and can't cover the whole design space of Planet Earth, so why should I?
I'm re-setting my target for this week. To get myself out of the design stall, I'm going to focus on the roguelite-like traversal system between locations, and push toward having... not an MVP, but a vertical slice of the game. Intro sequence, starting town, first road, and the second town. That will necessarily entail adding a few Nimster definitions, but doesn't put a giant dispiriting checklist in front of me. See you next week!
My favorite musical instrument is the air-raid siren.
Right, between the forum becoming unreadable and me disappearing to visit my parents in the near future I figure I'd mention what I've been working on. As mentioned previously, part of the game is plopping down structures, and I'm handling those the same way the level itself is handled, via its tilemaps- I have a layer that holds my building templates (normally hidden) and dictionaries that link the building to its template coordinates.
I used the previously described "if I'm standing here, what tiles is this rectangle overlapping?" logic to validate the placement positions, and plopping them down will update them to mark them as unavailable. Here's an example of a valid position, an invalid position and the placed building. The translucent circles are just a way for me to visually mark what tiles are considered Buildable, so trying to place the building on the platform above would not work for example.
I've hit some of Godot 4's rougher edges during this, so working around them has been interesting. There seems to be an issue with their TileMap node that can become corrupted, leading to certain changes (like collision maps) not getting propagated to the game once it's running. I even had the original tilemap from the last post basically become uneditable, which... fun! But Tiled exists, and natively supports export to Godot 4, so I've been messing with that to see what I can and cannot export&import without extra manual work; it means editing maps in Tiled rather than Godot itself, but hey, Tiled is neat and just requires a node reload to update.
The other edge was... well, inside baseball whinge below.
So they entirely redid the TileMap node, part of which was internally separating it into Tilesets (atlas, collisions, additional properties, etc) and Tilemaps (the layers and tiles you paint on them) and unfortunately there are some commands/properties that require one and don't exist for the other, whether it makes sense or not.
For example, you cannot toggle collisions on an tilemap layer off (for example, if you wanted to have a floor tile in the foreground, or background, without bonking into it). According to a thread where someone was asking how to do it, they were told they should just duplicate the atlas with a separate tileset without collisions, because... that's not unnecessary faff?
The other is that the only way to toggle collisions on a tile is to fetch its data from the Tilemap, then invoking its method for it. But there's no way to do that from the Tileset. So to elaborate on what this means, if you want to toggle collisions on a tile, you need to do so by pointing to a drawn tile that already exists in the level and going "this one!", but you cannot do so by going "the atlas tile in this position". It just... I do not understand this design decision.
It turned out that I over-scoped a bit, at least in terms of having a vertical slice put together by the end of the week, mostly because I completely neglected that even after I'd gotten everything stood up with regards to the new data types, I'd have to implement the editor changes to support those new data classes. As of Thursday night, I'm just slightly started on building the Event (a story event) editor, with the simpler Path (a kind of location, in-transit) and Place (a kind of location, town or crossroads) editors.
But, for what it's worth, the new transit system is in place. The game now tracks the player's destination and how many events remain until the player arrives, with the "Map" state presenting various options depending on the combination of those two states-- if you're at your destination, you can do what's available at that Place, such as visiting the Pokemon Center Nimster Livery if it's available, shopping for items, or setting out for somewhere else. If you have events to go, then you're presented with a random smattering of other connected Paths, and your selection triggers another Event to go off. Classic simple roguelite stuff that I'm making a hash of explaining.
The goal for this week is to get the editors squared away and a basic vertical slice implemented.
As for the post above: that's why, for all the other disadvantages it lays on me, I still enjoy working on my own ground-up engine. The only person who can make a baffling design decision that throws out my previous workflow is me!
My favorite musical instrument is the air-raid siren.
As I'm disappearing to visit family for a week I figured I could spend some of that time, among other things, thinking of my UI requirements and then doodling a design that I can hook my now-existing functionality into (so I'm not turning myself into an octopus with placeholder Ctrl-1 Ctrl-2 Ctrl-3 Ctrl-4 Ctrl-5 Ctrl-ow ow ow).
After an hour of researching what kind of mobile device&app would be most convenient for that sort of thing (I want to be able to both doodle and write)... I grabbed a notepad and pencil. And felt like an idiot.
All this information is going to wind up public at one point or another, so sure, here's some write-ups. I decided to err on the side of too much than too little, so here's at least one Nimster from every type.
Name: Dedlibear
Type: Physical
Form: 1 of 2
Nimsterdex* Entry: Dozens are fatally lacerated every year when they misinterpret its threat posture as an invitation to hug.
Appearance: Has the general shape and posture of a perfectly normal teddy bear, including the hollow-eyed neutral facial expression. Holds its arms out as if it wants to hug you. Its claws are about six inches long and shaped like knives so maybe we shouldn't pity the guys from the Nimsterdex entry too much.
Name: Machingbird
Type: Air
Form: 1 of 2
Nimsterdex Entry: It challenges everything it meets to a race, and viciously mocks anyone who can't keep up. Refusing to participate is not an option.
Appearance: A small songbird whose shape, stance, and coloration are suggestive of a fighter jet. The markings around its eyes are evocative of pilot's goggles.
Name: Batery
Type: Electric/Dark
Form: 1 of 2
Nimsterdex Entry: Rather than echolocation, it navigates by creating light with electricity. It feeds on Flytning and Magnat to restore its electrical power.
Appearance: A yellow-furred bat whose cylindrical torso and head are evocative of AA battery. The webbing on its wings is black, and it has a black lightning-bolt shaped marking on its chest.
Name: Alpacalypse
Type: Fire/Electric
Form: 1 of 1
Nimsterdex Entry: Its fur is so thick that it readily generates electric sparks. Its skin is so oily that it easily catches fire. This creature lives its life in a constant state of panic.
Appearance: An alpaca whose lightning and fire make it (understandably) want to be anywhere but where it is right now, and whose efforts to be anywhere but where it is right now are turning where it's going into where it doesn't want to be.
Name: Hairon
Type: Water/Air
Form: 2 of 2
Nimsterdex Entry: Maturity has granted it the glorious mane it always wanted**. However, some suspect that it might be artificial.
Appearance: A heron with glorious, waist-length hair. That's really the end of the concept.
Name: Divarachnid
Type: Psychic
Form: 2 of 2 (Primary Branch)
Nimsterdex Entry: As it grew its skills with weaving webs, it became obsessed with appearance and worldly concerns. It uses its finely-crafted garments to mesmermize potential prey.
Appearance: An anthropomorphic spider wearing a ballroom gown made of webbing.
Name: Snobunny
Type: Ice
Form: 2 of 2 (Alternate Branch 1)
Nimsterdex Entry: The cold treatment it received from others caused it to develop an icy personality. It holds others at arms' length, considering them beneath it.
Appearance: A bipedal rabbit with a ruff that resembles a fur stole and a sort of aristocratic nose-upturned pose.
Name: Slamon
Type: Water/Force
Form: 1 of 2
Nimsterdex Entry: Urberbear preys on it during their annual swim upstream to spawn. Human fishermen, on the other hand, generally take home broken bones instead.
Appearance: It's a salmon with the Fighting Force type, feel free to go from there.
Name: Tombyache
Type: Poison/Earth
Form: 1 of 3
Nimsterdex Entry: Legends of cursed burial grounds likely arise from the tendency of this Nimster to take up residence where there is decaying flesh.
Appearance: An evil spirit made of poison gas with a distended stomach and, apparently, a bad case of nausea.
Name: Infestoon
Type: Metal
Form: 3 of 3
Nimsterdex Entry: It has obtained great power by layering metal and heavy jewels over its body. But because it cannot let go of its wealth, it is held back.
Appearance: A large pillbug or stag beetle with a gleaming metal carapace inlaid with gemstones. It looks like it suspects you of trying to take its stuff.
Name: Rayshorse
Type: Light
Form: 2 of 2
Nimsterdex Entry: Previous editions of the Nimsterdex indicated that this Nimster is capable of galloping faster than the speed of light. This preposterous claim has been thoroughly debunked and the author of the offending entry has been sacked.
Appearance: Fairly self-explanatory, I would think.
Name: Gobblelin
Type: Dark/Air
Form: 2 of 2
Nimsterdex Entry: Despite its appearance, this Nimster is prized for its tasty flesh. As one might suspect by its appearance, it also prizes you for your tasty flesh.
Appearance: Take a turkey and make it even wartier. Maybe give it teeth?
* It won't be called the Nimsterdex in-game, if it even exists outside of the Nimster page itself. But it gets the point across here.
** Hairon's previous form is Balduck, which looks like a Psyduck that someone Looney Tunes'd the feathers off the top of its head.
And because turnabout is fair play, here's an MSPaint sketch of another Nimster line that gave me a giggle when the image of it spontaneously popped into my head:
My favorite musical instrument is the air-raid siren.
I am having a weird experience with Unity Technologies. Simply put, way back in 2016, they blocked my account.
It had a chargeback on it that my bank did. It must have been an attempt by a seller to make a fraudulent transaction. I did not issue the chargeback. I knew nothing about it.
I talked with customer support and they will unblock my account if I promise to buy an asset from the asset store.
Do you have data structures? Do you want to serialize them? Do you hate having to write a schema, generate code and then shuffle data to/from protobufs/flatbuffers/capnproto/whatever to actually use them? Do you use C++20 (which is probably nobody else)?
If yes to all, I have a little library for you! Packall will use template magic to convert pretty much any struct you can write to/from binary or text
My vertical slice project is turning into more of a repeatedly striking at a log with an axe, but at least I'm operating on the correct axis. It turns out that "only generating a few of the necessary objects of each type" doesn't reduce the amount of work to be done by much when you haven't implemented the majority of the types' editors to begin with.
This week I got to a point where you can now use a graphical editor to edit Events (things that present text to the player and allow them to select from a number of options), Places (major waypoints such as towns or crossroads), and Paths ("on the road" locations with an encounter table and a randomized set of connections). Unfortunately I was struck by an intense bout of depression and was unable to finish assembling the rival Nimster Tamer editor, especially because I ran into design questions and wound up having to change what data those entries actually store.
Following the trend of jettisoning elements that require any degree of effort, I removed the idea of having a distinct item shop availability list for each Place. If the Pokemon Center Nimster Livery is available at any given town, you can shop for items there, and all consumable items will be available for purchase from the beginning of the game. The catch is that since you can't use healing items in the middle of a battle in Nimsters, being able to fill your bag with Hyper Potions (or their moral equivalent) doesn't confer any real power advantage... it just means that you can restore that many HP in a more cost-effective way, assuming your Nimsters even have that many HP available to restore.
I went back and forth on what information a Nimster Tamer actually needs to have defined. I won't bore you with the specifics, but the one part that might actually be meaningful is how they assign their Nimsters' move sets. Nimsters learn far more moves than they're allowed to have set at once, and which four moves you want to have available out of all the possibilities is an important strategic choice. And Pokemon in specific has a problem where for the most part the Trainers you meet on the road just have whatever the last four moves their monsters learn by level-up set, which in the early generations of Pokemon sometimes led to absurd situations where rival Trainers' Pokemon didn't even have a move that matched their monster's type. So at first I envisioned there being a "move selection strategy" setting for Tamers, such as whether they'll set Star moves, X moves, guards, buffs, aim for timeline coverage, and so on. However, then I realized that 1) that sounds like an absolute pain in the ass, and 2) Nimster learn-sets are already automatically spread out reasonably well along those lines by the Nimster editor. So the approach I'm planning to take is that the Tamer definition object will store what moves they will set for each Nimster, and the Tamer editor will auto-fill that fill with the last four moves learned by the Nimster, while making the Nimster's other known moves available. Meaning, if you create a new Tamer and say they have a Level 20 Squarrel, a level 21 Canairy, and a Level 22 Caterpiledriver, the editor will auto-fill the moveset for each one so you can just say "good enough" and move on, while retaining fine-grained control in the rare but occasionally necessary case that it's required (such as boss Tamers).
The next step toward the vertical slice is the Tamer and Item editors. After that, I believe, I can start making the first and second town, and their connecting road. I might even have something y'all can play in two weeks? Who knows.
My favorite musical instrument is the air-raid siren.
The Nimsters content editor application can now edit rival Tamers. I did not get to the Item editor due to having to make some fixes to the Path and Place editors as I tried to use them, and also because the Item format probably needs some significant revisions of its own.
In line with other moves I've been making in the design space, I'm jettisoning some unnecessary complexity. "Nimster treats" serve a dual purpose in the game as a something like the game's Pokeball, in that you can throw them at wild Nimsters to encourage them to become tame, and the Pokepuff / bean / sandwich / whatever that raises their "friendship value", which ultimately just serves as a parallel leveling system that raises their stats by up to 20% at max value. All that I'm keeping; what I'm throwing out is the notion of "treat flavor" which controls what kinds of treats a Nimster will eat. The idea being that you need meat-flavored treats for carnivorous monsters, plant-type treats for herbivores, and so on. Henceforth Nimster treats will just work, whatever monster you're giving them to. I plan to have the item description for one of the upper-tier treat items poke fun at this. (FavorBites:Nimster Treat (Tier 4). "No matter when you reach into the box, you will always pull out your Nimster's favorite flavor. How this is accomplished is a tightly-kept trade secret subject to a vicious campaign of corporate espionage.")
Likewise, previously I had planned to separate status-curing items by the status effect they cure. While this would create much fertile ground for comical item description entries, I get the sense that it would be a pain in the ass to fill out that matrix and also to have to micro-manage your restoratives to that degree. So, like HP, Stamina, and Friendship items, there will simply be a progression of all-purpose status cures (since, unlike Pokemon, the status effects in Nimsters can be layered both among themselves and in intensity of the individual status effect).
I've gotten the new transit system working such that you can set out from one town, experience a series of randomized events, and eventually arrive at your destination. There was an amusing bug that I forgot to decrement the distance to the destination after playing each event, giving the player the sense that they were moving forward but actually they weren't getting anywhere. That's a familiar sensation, somehow, but I can't quite place from where...
If I really kick ass this week and fight off my chronic depression, I might be able to stand up the item editor, get some basic items made, do an MVP of the Nimster Livery, and put together the intro sequence, hometown, and first route, then publish it into a transmissible format. ... but having said that and looked at it, I personally wouldn't hold my breath. Hope, or don't, as you prefer.
My favorite musical instrument is the air-raid siren.
I did not kick half so much ass as I needed to to hit the optimistic target from the end of last week's post. Of the various things I could have gotten done, the ones I actually hit were just standing up the item editor and getting the basic items made. Or, rather, all the items, since I've discarded the more complex items from the design. So, there are now restoratives for health, stamina, and status effects, Nimster treats you can use either to make a wild Nimster tame or raise the friendship level of one on your team, supplement items you can use to change the game's equivalent of IVs, and items that work like a combination of experience candies and evolution stones. That last category I broke down and decided to just make a small script to automate the creation of, since they all behave the same way and I didn't want to re-type the same description checks notes forty-two times.
The primary obstacle to getting more done last week was the Xenoblade 3 DLC; as you might be aware, there's a new Zelda game arriving today and that's definitely going to take up the majority of the time I have outside of the day job. The next thing from last week's unfinished business is getting the Nimster Livery (read: "Pokemon Center and Shop") implemented, so I'll set that as the goal.
My favorite musical instrument is the air-raid siren.
Kupi's Weekly Friday Game Dev Status Report (5/19/2023)
zelda
Kupi's Weekly Friday Game Dev Status Report (5/26/2023)
zelda
Kupi's Weekly Friday Game Dev Status Report (6/2/2023)
zelda
and sgdq
Kupi's Weekly Friday Game Dev Status Report
This week during SGDQ catch-up, I got the Nimster Livery mostly implemented. As mentioned last (real) post, the Nimster Livery has the functions of the modern Pokemon Center, being both the inn and the shop. The first option (restoring the status of all Nimsters in your party) was trivial. For the Shop, I implemented a filter function that lets you pick between the six different categories of usable items, presents the available options sorted by effectiveness, and then lets you select the number that you want, up to the maximum you can afford. I momentarily struggled with how to handle selling items, but then the spirit of Undertale passed through my body and I decided that nobody wants to buy your secondhand Nimster treats. All sales final, no refunds! The Livery also allows you to manage which Nimsters are in your party. Originally I had intended to give that some filtering functions as well, like letting you filter by Nimster type and set the level ordering, but you know what? That felt like too much work! So instead it just shows you the Nimsters you have in reserve in reverse order of when you submitted them to the reserve (on the theory that that will present the ones you just tamed and former members of your party earlier). The only thing left for the Livery is the "inquiry" event that lets you ask questions of the person behind the desk.
I removed some data from the Nimster species definition: treat flavor preferences (since Nimster treats no longer have flavors) and taming difficulty (since defining it separately for each individual species is a pain in the ass when I could just calculate it from their BST). Removing the data implicitly meant removing them from the editor as well.
As I've been laid off from my day job, for the next few weeks at least I'll have plenty of spare time to put toward game development, and I'm actually feeling somewhat enthused about doing a multimedia full-court press of training in the various skills I haven't had time to skill-up on. Insofar as any of those intersect with game development, I'll report back on them here.
The next step for Nimsters is, unbelievably, actual content generation. Still can't promise that vertical slice, but I'll be sawing away at it.
My favorite musical instrument is the air-raid siren.
I'm not super happy with it, but I did at least get it to the point where I felt like it could be called a video game a few hours before the submission deadline.
I’ve doodled stuff in old GameMaker and such, but I’ve never made anything worthwhile.
Currently I only have a ipad and nothing seems to download onto it properly, even when it’s supposed to be compatible. From your experience gang, is there any development kit or what have you that would play nice with this tablet, or would buying an actual desktop computer (Microsoft?) be the only worthwhile thing to do before diving in to coding?
At the moment I really want to make a NES era style Fire Emblem game, which I imagine would be ‘simple’, though likely still take months to get to a serviceable point.
Or is there perhaps a plug-in I can download to further download other stuff through? I think one of the main problems is if you’re not downloading through the appstoreTM(c) the tablet is intentionally designed to refuse it.
Oh yeah iPad for sure. I do think I’ll just have to get some other computer. It’s nice to doodle on but it seems very particular in what’s compatible with it even within the Apple ecosystem.
Godot has a web editor version now, however it's early days and I've no way of testing how well/if it runs on an actual iPad.
0
GnomeTankWhat the what?Portland, OregonRegistered Userregular
I know most of us here are just hobbyists, but if you were developing a game in Unity you ever planned to sell, you may want to seriously reconsider that now.
None of this should really be shocking I guess. Unity has been on the mustache twirling money grubber timeline since John Riccitiello, of EA fame, was made CEO. The one who called developers who didn't focus on monetization "fucking idiots".
GnomeTankWhat the what?Portland, OregonRegistered Userregular
Even outside of the programming language, Unity was nice as a counter balance to Unreal's heaviness. Unreal is a huge, industrial strength engine built for a particular class of game. Unity always felt lighter and more free-form, really opening itself up to more project and game styles...especially 2D. Now if I even had an inkling of an idea to sell my game someday, I wouldn't touch Unity with a hazmat suit on. Even ignoring the fees to developers, the idea of them effectively forcing my game to have install tracking DRM in it so they can get their cut of flesh is a big nope from me.
Just the fact that they changed their agreement to include existing games with no "opt out by not updating" clause makes them forever radioactive, even if they walk this one back
Just the fact that they changed their agreement to include existing games with no "opt out by not updating" clause makes them forever radioactive, even if they walk this one back
Yep. It basically means in a world of long development cycles, you can't trust your engine partner not to try and pull the rug out from under you and change the terms of the agreement, Darth Vader style. There are already Unity developers, including the Cult of the Lamb studio, who have said they will pull their games on Jan 1 instead of giving in to Unity's terms.
I dropped Unity as something to learn the moment I heard about the takeover. Writing has been on the wall, now it's in neon.
Which is great from a pure hobbyist point of view...but Unity was such a great option for people who had aspirations of maybe one day taking a project beyond that stage. Leave it to tech C-suite management types to ruin a good thing in the name of "growth", likely slaughtering the golden goose in the process.
There's a lot of situations for free to play games where the developer would be making negative money due to high installs and low LTV. This is probably the worst fuckup I've ever seen from any tech company, ever, in the history of my being alive. It's so bad they can't possibly keep it in place. Unity's key market is in mobile games and they will literally force hypercasual devs to abandon the engine or go bankrupt. There's no justification for a monetization scheme so poorly implemented that it forces long-time business customers to just plain walk.
My own game launches in 2 months and we are just simply not allowed to make more than $1million in revenue, we would start making negative money immediately. Fortunately we're tiny and will probably not come close to that, but if our upcoming game is like 5x bigger than the last (which is not out of the question) we'd basically have to drop everything and port the game to a different engine in order to grow. It's completely insane.
Even outside of the programming language, Unity was nice as a counter balance to Unreal's heaviness. Unreal is a huge, industrial strength engine built for a particular class of game. Unity always felt lighter and more free-form, really opening itself up to more project and game styles...especially 2D. Now if I even had an inkling of an idea to sell my game someday, I wouldn't touch Unity with a hazmat suit on. Even ignoring the fees to developers, the idea of them effectively forcing my game to have install tracking DRM in it so they can get their cut of flesh is a big nope from me.
Here's sort of what I think happened
Epic has, whatever you think of their store, leadership or ownership, absolutely cemented Unreal as the public AAA engine, absolutely being on par with the nominally always private/expensive AAA engines and they're not running out of money with Tencent's backing. And they even recently improved the terms of their free license and UE5 is delivering.
Unity isn't really going to be able to compete on Unreal's terms. There is absolutely a space for a smallish A or AA quality engine and Unity was that for a while. And a subscription per-seat per-year model fits well, it's more secure revenue capture for indie games that might not make it and the massive sellers won't be using it anyway. But they don't get to be a big company this way, only a small one. And frankly their financials are shit, they've tripled revenue since 2019 and went from losing 150 million a year to losing 880 million a year. Now a lot of that is classified as "selling & marketing" and they've quadrupled R&D but still, they're not exactly raking in the dough
So they need a niche and a new revenue stream. That niche is mobile, while Unreal theoretically has a mobile target, nobody is really going to develop their casual farming clicker game in Unreal. But mobile has high install rates and in-app purchase revenue, which they can't really capture, and low development budgets which reduces Unity's effective cut. So how do you capture more? Lightbulb moment, charge for installs
And frankly, it might work. The people actually making the highly monetized predatory mobile games probably will pay that cent per install because they are making a dollar. PC and console might jump ship but that's not where the money is for them I would guess
It's the whale model. A single 100 million install mobile game at 1c/install is 500 seat-years of sub revenue
GnomeTankWhat the what?Portland, OregonRegistered Userregular
edited September 13
The biggest issue isn't even the fees, it's the implication that Unity can effectively just alter the terms of how developers do business with them whenever they want, effective retroactively, with no perpetual version-pinned EULA. I think Rami Ismail says it best in this Twitter thread (drill in to read the other three points):
To pull out of this and start to build back any sort of trust, they will need to drop the fees and put in place version-pinned EULA terms that can't be pulled out from under developers.
The really big mobile companies already have contracts in place with Unity and won't be affected. Unity might *think* they can get install-based fees from the mid tier mobile devs but what's actually going to happen is they will drop everything to swap engines ASAP. Far more experienced mobile devs have explained this better on Twitter. Revenue is never guaranteed on mobile, even with very high installs. It makes deploying anything with the engine an existential risk to the entire business. Literally anything else would be preferable.
(They also probably think they can coerce studios into using Unity ad services to drop the fees, but this is also insane and would only work in the very short term. Ad monetization is less than pennies and a lot of games simply don't have any.)
Vontre on
+2
GnomeTankWhat the what?Portland, OregonRegistered Userregular
edited September 13
And of course because this is 2023 and people really just DGAF anymore, leaks from inside Unity itself are out and about. As always with any leaks/rumors, massive piles of salt, but the current scuttlebutt is that there was a lot of internal push back from non-executives, The announcement post itself was especially heavily scrutinized. All the issues people are pointing out (Game Pass, demos, freemium, harassment / revenue bombing, Darth Vader-esque agreement altering) were brought up internally and basically ignored.
Posts
This was, for all practical purposes, a vacation week from hobby game dev. I don't have anything material to report.
I dedicated a page in my wandering-thoughts notebook to use as a word cloud for Nimster concepts. Any animal I can think of that doesn't have a Nimster yet, and as many words as I could free-associate with the Nimster types that don't have as many Nimsters yet.
I've also decided that, since Nimsters runs in the console and has all the aesthetics of a text adventure game already, I'm going to pitch out my existing tile-based map system (barely past the prototype phase) and replace it with something like a roguelite structure. Essentially, when you set out from Town A to Town B, you have to clear a certain number of events before arriving. Events will be arranged in sets based on the type of area you're moving through, and after you resolve whatever event occurs, you get a choice of what type of "chamber/zone" you want to move into next, again based on the type of area you're already in. So the general shape of an encounter table might look like...
Road
Encounters
- Attacked by Squarrel (rarely)
- Attacked by Canairy (rarely)
- Encounter a Nimster tamer (sometimes)
- Nothing (common)
- Smooth sailing (-1 encounters to destination, rarely)
- Arrive at destination (forced, and only if encounters to destination <= 0)
Exits
- Road (always)
- Grass (sometimes)
- Tall Grass (rarely)
Grass
Encounters
- Attacked by Squarrel (sometimes)
- Attacked by Canairy (sometimes)
- Encounter a Nimster tamer (sometimes)
- Nothing (sometimes)
Exits
- Road (sometimes)
- Grass (common)
- Tall Grass (sometimes)
Tall Grass
Encounters
- Attacked by Squarrel (common)
- Attacked by Canairy (common)
- Lost Item (find a low-value item, rarely)
- Encounter a Nimster tamer (rarely)
- Nothing (sometimes)
- Lost in the Grass (+1 encounters to destination, rarely)
Exits
- Tall Grass (common)
- Grass (sometimes)
... and so on and so forth.
My goal for this week is going to be to draw out a rough map of the world the game takes place in, as a means of focusing myself on figuring out what needs to be placed where in the level progression. Design work is surprisingly difficult at times.
What would be the Minimum Viable Product / vertical slice of a Monkey Island-esque + walking simulator game?
So, in something like the original Monkey Island, the intro and bar would be a great pick- you're introduced to Guybrush, you get to experience the writing and you have some puzzles to solve.
After three weeks of absolute brainstall, I'm looking into re-instating some time-management structure into my days to make sure that I'm making at least a little forward progress. Technically speaking I advanced the Nimsters project a little by coming up with some monster concepts (and I'm within the low double digits' distance from the target of 300 of them), but since those just kind of happen whenever they fall out of my pun-developing brain structures as they occur, I don't really count that as work, and the small sketches I did of the traversal system I outlined last week similarly don't really qualify as progress.
Next week's goals are the same as the last several weeks'.
I then went "well, I should make a basic GUI next!", then after two days of getting stuck in the weeds decided that, actually no, that's a bad idea, there's nothing a UI can do that I can't accomplish with ugly debug keyboard shortcuts for now, I can figure out the UI after I've implemented enough gameplay that I know I won't be changing and making previous UI work pointless.
Today's a bank holiday here, so I spent much of it working on basic stuff I'll need for the building portion. It's meant to be a simple no-mouse "your character position determines the build location" thing, so for now all it's doing is looking at where the player is standing, accepting an arbitrary rectangle (in tile count) for the building size, then figuring out how to position those x&y tiles on the level's tilemap (since that's what will hold them).
Not that much to show, but it was a good way to refresh my memory of how Godot's tilemaps and signals work (and discover odd gotchas like "you can't modulo a float". Okay? Sure).
At this pace I'll have a game around 2030, but that's fine, it'll still be done before Skull and Bones.
Still slow, but I actually made some progress this week. I think focusing on the world map was the wrong way of going about trying to figure out which Nimsters should appear when; so, to unblock myself, I changed my approach. Instead of trying to draw the world out, I sorted all of my Nimster concepts into lists by type and then by whether they're final or non-final forms. Then, I re-ordered them in terms of relative power while assigning them a power level (in terms of total stats). The end result is that I now have a clear power progression within each type, and while designing areas I can just pick at the bottom of each list until I'm out of Nimsters to assign to zones. Or, to put it another way, the question of when the player should encounter a mountainous region is answered by looking at whenever the type power curves hit the point where you start seeing the first form of the bear, wolf, and deer-themed Nimster lines.
As a cost-cutting measure, I'm abandoning the idea of Nimster equipment (the game's equivalent of held items). All items in the game will be expendables.
... and I guess I didn't mention this, but looking at my spreadsheet where I've been storing my Nimster ideas, I hit my target count. I've doubled up on some idea spaces (there are two different "lion" lines, multiple mushroom families, and a bunch of different rabbits), but y'know what? Who cares. Even Pokemon itself has some duplication and can't cover the whole design space of Planet Earth, so why should I?
I'm re-setting my target for this week. To get myself out of the design stall, I'm going to focus on the roguelite-like traversal system between locations, and push toward having... not an MVP, but a vertical slice of the game. Intro sequence, starting town, first road, and the second town. That will necessarily entail adding a few Nimster definitions, but doesn't put a giant dispiriting checklist in front of me. See you next week!
I used the previously described "if I'm standing here, what tiles is this rectangle overlapping?" logic to validate the placement positions, and plopping them down will update them to mark them as unavailable. Here's an example of a valid position, an invalid position and the placed building. The translucent circles are just a way for me to visually mark what tiles are considered Buildable, so trying to place the building on the platform above would not work for example.
I've hit some of Godot 4's rougher edges during this, so working around them has been interesting. There seems to be an issue with their TileMap node that can become corrupted, leading to certain changes (like collision maps) not getting propagated to the game once it's running. I even had the original tilemap from the last post basically become uneditable, which... fun! But Tiled exists, and natively supports export to Godot 4, so I've been messing with that to see what I can and cannot export&import without extra manual work; it means editing maps in Tiled rather than Godot itself, but hey, Tiled is neat and just requires a node reload to update.
The other edge was... well, inside baseball whinge below.
For example, you cannot toggle collisions on an tilemap layer off (for example, if you wanted to have a floor tile in the foreground, or background, without bonking into it). According to a thread where someone was asking how to do it, they were told they should just duplicate the atlas with a separate tileset without collisions, because... that's not unnecessary faff?
The other is that the only way to toggle collisions on a tile is to fetch its data from the Tilemap, then invoking its method for it. But there's no way to do that from the Tileset. So to elaborate on what this means, if you want to toggle collisions on a tile, you need to do so by pointing to a drawn tile that already exists in the level and going "this one!", but you cannot do so by going "the atlas tile in this position". It just... I do not understand this design decision.
It turned out that I over-scoped a bit, at least in terms of having a vertical slice put together by the end of the week, mostly because I completely neglected that even after I'd gotten everything stood up with regards to the new data types, I'd have to implement the editor changes to support those new data classes. As of Thursday night, I'm just slightly started on building the Event (a story event) editor, with the simpler Path (a kind of location, in-transit) and Place (a kind of location, town or crossroads) editors.
But, for what it's worth, the new transit system is in place. The game now tracks the player's destination and how many events remain until the player arrives, with the "Map" state presenting various options depending on the combination of those two states-- if you're at your destination, you can do what's available at that Place, such as visiting the Pokemon Center Nimster Livery if it's available, shopping for items, or setting out for somewhere else. If you have events to go, then you're presented with a random smattering of other connected Paths, and your selection triggers another Event to go off. Classic simple roguelite stuff that I'm making a hash of explaining.
The goal for this week is to get the editors squared away and a basic vertical slice implemented.
As for the post above: that's why, for all the other disadvantages it lays on me, I still enjoy working on my own ground-up engine. The only person who can make a baffling design decision that throws out my previous workflow is me!
After an hour of researching what kind of mobile device&app would be most convenient for that sort of thing (I want to be able to both doodle and write)... I grabbed a notepad and pencil. And felt like an idiot.
Could you describe a few of the critters in this game? I love little monster designs.
Type: Physical
Form: 1 of 2
Nimsterdex* Entry: Dozens are fatally lacerated every year when they misinterpret its threat posture as an invitation to hug.
Appearance: Has the general shape and posture of a perfectly normal teddy bear, including the hollow-eyed neutral facial expression. Holds its arms out as if it wants to hug you. Its claws are about six inches long and shaped like knives so maybe we shouldn't pity the guys from the Nimsterdex entry too much.
Name: Machingbird
Type: Air
Form: 1 of 2
Nimsterdex Entry: It challenges everything it meets to a race, and viciously mocks anyone who can't keep up. Refusing to participate is not an option.
Appearance: A small songbird whose shape, stance, and coloration are suggestive of a fighter jet. The markings around its eyes are evocative of pilot's goggles.
Name: Batery
Type: Electric/Dark
Form: 1 of 2
Nimsterdex Entry: Rather than echolocation, it navigates by creating light with electricity. It feeds on Flytning and Magnat to restore its electrical power.
Appearance: A yellow-furred bat whose cylindrical torso and head are evocative of AA battery. The webbing on its wings is black, and it has a black lightning-bolt shaped marking on its chest.
Name: Alpacalypse
Type: Fire/Electric
Form: 1 of 1
Nimsterdex Entry: Its fur is so thick that it readily generates electric sparks. Its skin is so oily that it easily catches fire. This creature lives its life in a constant state of panic.
Appearance: An alpaca whose lightning and fire make it (understandably) want to be anywhere but where it is right now, and whose efforts to be anywhere but where it is right now are turning where it's going into where it doesn't want to be.
Name: Hairon
Type: Water/Air
Form: 2 of 2
Nimsterdex Entry: Maturity has granted it the glorious mane it always wanted**. However, some suspect that it might be artificial.
Appearance: A heron with glorious, waist-length hair. That's really the end of the concept.
Name: Divarachnid
Type: Psychic
Form: 2 of 2 (Primary Branch)
Nimsterdex Entry: As it grew its skills with weaving webs, it became obsessed with appearance and worldly concerns. It uses its finely-crafted garments to mesmermize potential prey.
Appearance: An anthropomorphic spider wearing a ballroom gown made of webbing.
Name: Snobunny
Type: Ice
Form: 2 of 2 (Alternate Branch 1)
Nimsterdex Entry: The cold treatment it received from others caused it to develop an icy personality. It holds others at arms' length, considering them beneath it.
Appearance: A bipedal rabbit with a ruff that resembles a fur stole and a sort of aristocratic nose-upturned pose.
Name: Slamon
Type: Water/Force
Form: 1 of 2
Nimsterdex Entry: Urberbear preys on it during their annual swim upstream to spawn. Human fishermen, on the other hand, generally take home broken bones instead.
Appearance: It's a salmon with the Fighting Force type, feel free to go from there.
Name: Tombyache
Type: Poison/Earth
Form: 1 of 3
Nimsterdex Entry: Legends of cursed burial grounds likely arise from the tendency of this Nimster to take up residence where there is decaying flesh.
Appearance: An evil spirit made of poison gas with a distended stomach and, apparently, a bad case of nausea.
Name: Infestoon
Type: Metal
Form: 3 of 3
Nimsterdex Entry: It has obtained great power by layering metal and heavy jewels over its body. But because it cannot let go of its wealth, it is held back.
Appearance: A large pillbug or stag beetle with a gleaming metal carapace inlaid with gemstones. It looks like it suspects you of trying to take its stuff.
Name: Rayshorse
Type: Light
Form: 2 of 2
Nimsterdex Entry: Previous editions of the Nimsterdex indicated that this Nimster is capable of galloping faster than the speed of light. This preposterous claim has been thoroughly debunked and the author of the offending entry has been sacked.
Appearance: Fairly self-explanatory, I would think.
Name: Gobblelin
Type: Dark/Air
Form: 2 of 2
Nimsterdex Entry: Despite its appearance, this Nimster is prized for its tasty flesh. As one might suspect by its appearance, it also prizes you for your tasty flesh.
Appearance: Take a turkey and make it even wartier. Maybe give it teeth?
* It won't be called the Nimsterdex in-game, if it even exists outside of the Nimster page itself. But it gets the point across here.
** Hairon's previous form is Balduck, which looks like a Psyduck that someone Looney Tunes'd the feathers off the top of its head.
And because turnabout is fair play, here's an MSPaint sketch of another Nimster line that gave me a giggle when the image of it spontaneously popped into my head:
It had a chargeback on it that my bank did. It must have been an attempt by a seller to make a fraudulent transaction. I did not issue the chargeback. I knew nothing about it.
I talked with customer support and they will unblock my account if I promise to buy an asset from the asset store.
This is like blackmail.
I don't know if they are doing a weird thing like I admit guilt if I buy an asset. The whole thing seems off to me.
If yes to all, I have a little library for you!
Packall will use template magic to convert pretty much any struct you can write to/from binary or text
My vertical slice project is turning into more of a repeatedly striking at a log with an axe, but at least I'm operating on the correct axis. It turns out that "only generating a few of the necessary objects of each type" doesn't reduce the amount of work to be done by much when you haven't implemented the majority of the types' editors to begin with.
This week I got to a point where you can now use a graphical editor to edit Events (things that present text to the player and allow them to select from a number of options), Places (major waypoints such as towns or crossroads), and Paths ("on the road" locations with an encounter table and a randomized set of connections). Unfortunately I was struck by an intense bout of depression and was unable to finish assembling the rival Nimster Tamer editor, especially because I ran into design questions and wound up having to change what data those entries actually store.
Following the trend of jettisoning elements that require any degree of effort, I removed the idea of having a distinct item shop availability list for each Place. If the Pokemon Center Nimster Livery is available at any given town, you can shop for items there, and all consumable items will be available for purchase from the beginning of the game. The catch is that since you can't use healing items in the middle of a battle in Nimsters, being able to fill your bag with Hyper Potions (or their moral equivalent) doesn't confer any real power advantage... it just means that you can restore that many HP in a more cost-effective way, assuming your Nimsters even have that many HP available to restore.
I went back and forth on what information a Nimster Tamer actually needs to have defined. I won't bore you with the specifics, but the one part that might actually be meaningful is how they assign their Nimsters' move sets. Nimsters learn far more moves than they're allowed to have set at once, and which four moves you want to have available out of all the possibilities is an important strategic choice. And Pokemon in specific has a problem where for the most part the Trainers you meet on the road just have whatever the last four moves their monsters learn by level-up set, which in the early generations of Pokemon sometimes led to absurd situations where rival Trainers' Pokemon didn't even have a move that matched their monster's type. So at first I envisioned there being a "move selection strategy" setting for Tamers, such as whether they'll set Star moves, X moves, guards, buffs, aim for timeline coverage, and so on. However, then I realized that 1) that sounds like an absolute pain in the ass, and 2) Nimster learn-sets are already automatically spread out reasonably well along those lines by the Nimster editor. So the approach I'm planning to take is that the Tamer definition object will store what moves they will set for each Nimster, and the Tamer editor will auto-fill that fill with the last four moves learned by the Nimster, while making the Nimster's other known moves available. Meaning, if you create a new Tamer and say they have a Level 20 Squarrel, a level 21 Canairy, and a Level 22 Caterpiledriver, the editor will auto-fill the moveset for each one so you can just say "good enough" and move on, while retaining fine-grained control in the rare but occasionally necessary case that it's required (such as boss Tamers).
The next step toward the vertical slice is the Tamer and Item editors. After that, I believe, I can start making the first and second town, and their connecting road. I might even have something y'all can play in two weeks? Who knows.
The Nimsters content editor application can now edit rival Tamers. I did not get to the Item editor due to having to make some fixes to the Path and Place editors as I tried to use them, and also because the Item format probably needs some significant revisions of its own.
In line with other moves I've been making in the design space, I'm jettisoning some unnecessary complexity. "Nimster treats" serve a dual purpose in the game as a something like the game's Pokeball, in that you can throw them at wild Nimsters to encourage them to become tame, and the Pokepuff / bean / sandwich / whatever that raises their "friendship value", which ultimately just serves as a parallel leveling system that raises their stats by up to 20% at max value. All that I'm keeping; what I'm throwing out is the notion of "treat flavor" which controls what kinds of treats a Nimster will eat. The idea being that you need meat-flavored treats for carnivorous monsters, plant-type treats for herbivores, and so on. Henceforth Nimster treats will just work, whatever monster you're giving them to. I plan to have the item description for one of the upper-tier treat items poke fun at this. (FavorBites: Nimster Treat (Tier 4). "No matter when you reach into the box, you will always pull out your Nimster's favorite flavor. How this is accomplished is a tightly-kept trade secret subject to a vicious campaign of corporate espionage.")
Likewise, previously I had planned to separate status-curing items by the status effect they cure. While this would create much fertile ground for comical item description entries, I get the sense that it would be a pain in the ass to fill out that matrix and also to have to micro-manage your restoratives to that degree. So, like HP, Stamina, and Friendship items, there will simply be a progression of all-purpose status cures (since, unlike Pokemon, the status effects in Nimsters can be layered both among themselves and in intensity of the individual status effect).
I've gotten the new transit system working such that you can set out from one town, experience a series of randomized events, and eventually arrive at your destination. There was an amusing bug that I forgot to decrement the distance to the destination after playing each event, giving the player the sense that they were moving forward but actually they weren't getting anywhere. That's a familiar sensation, somehow, but I can't quite place from where...
If I really kick ass this week and fight off my chronic depression, I might be able to stand up the item editor, get some basic items made, do an MVP of the Nimster Livery, and put together the intro sequence, hometown, and first route, then publish it into a transmissible format. ... but having said that and looked at it, I personally wouldn't hold my breath. Hope, or don't, as you prefer.
I did not kick half so much ass as I needed to to hit the optimistic target from the end of last week's post. Of the various things I could have gotten done, the ones I actually hit were just standing up the item editor and getting the basic items made. Or, rather, all the items, since I've discarded the more complex items from the design. So, there are now restoratives for health, stamina, and status effects, Nimster treats you can use either to make a wild Nimster tame or raise the friendship level of one on your team, supplement items you can use to change the game's equivalent of IVs, and items that work like a combination of experience candies and evolution stones. That last category I broke down and decided to just make a small script to automate the creation of, since they all behave the same way and I didn't want to re-type the same description checks notes forty-two times.
The primary obstacle to getting more done last week was the Xenoblade 3 DLC; as you might be aware, there's a new Zelda game arriving today and that's definitely going to take up the majority of the time I have outside of the day job. The next thing from last week's unfinished business is getting the Nimster Livery (read: "Pokemon Center and Shop") implemented, so I'll set that as the goal.
zelda
Kupi's Weekly Friday Game Dev Status Report (5/26/2023)
zelda
Kupi's Weekly Friday Game Dev Status Report (6/2/2023)
zelda
and sgdq
Kupi's Weekly Friday Game Dev Status Report
This week during SGDQ catch-up, I got the Nimster Livery mostly implemented. As mentioned last (real) post, the Nimster Livery has the functions of the modern Pokemon Center, being both the inn and the shop. The first option (restoring the status of all Nimsters in your party) was trivial. For the Shop, I implemented a filter function that lets you pick between the six different categories of usable items, presents the available options sorted by effectiveness, and then lets you select the number that you want, up to the maximum you can afford. I momentarily struggled with how to handle selling items, but then the spirit of Undertale passed through my body and I decided that nobody wants to buy your secondhand Nimster treats. All sales final, no refunds! The Livery also allows you to manage which Nimsters are in your party. Originally I had intended to give that some filtering functions as well, like letting you filter by Nimster type and set the level ordering, but you know what? That felt like too much work! So instead it just shows you the Nimsters you have in reserve in reverse order of when you submitted them to the reserve (on the theory that that will present the ones you just tamed and former members of your party earlier). The only thing left for the Livery is the "inquiry" event that lets you ask questions of the person behind the desk.
I removed some data from the Nimster species definition: treat flavor preferences (since Nimster treats no longer have flavors) and taming difficulty (since defining it separately for each individual species is a pain in the ass when I could just calculate it from their BST). Removing the data implicitly meant removing them from the editor as well.
As I've been laid off from my day job, for the next few weeks at least I'll have plenty of spare time to put toward game development, and I'm actually feeling somewhat enthused about doing a multimedia full-court press of training in the various skills I haven't had time to skill-up on. Insofar as any of those intersect with game development, I'll report back on them here.
The next step for Nimsters is, unbelievably, actual content generation. Still can't promise that vertical slice, but I'll be sawing away at it.
I'm not super happy with it, but I did at least get it to the point where I felt like it could be called a video game a few hours before the submission deadline.
Currently I only have a ipad and nothing seems to download onto it properly, even when it’s supposed to be compatible. From your experience gang, is there any development kit or what have you that would play nice with this tablet, or would buying an actual desktop computer (Microsoft?) be the only worthwhile thing to do before diving in to coding?
At the moment I really want to make a NES era style Fire Emblem game, which I imagine would be ‘simple’, though likely still take months to get to a serviceable point.
I have at some point heard about there being dev environments for mobile platforms, but it's not something I can help you with.
https://kotaku.com/unity-engine-subscription-cost-unreal-godot-indie-dev-1850831032
None of this should really be shocking I guess. Unity has been on the mustache twirling money grubber timeline since John Riccitiello, of EA fame, was made CEO. The one who called developers who didn't focus on monetization "fucking idiots".
It's a bit of a shame because unity was the big boy engine for not-C++ people, whose options are rather limited now
Yep. It basically means in a world of long development cycles, you can't trust your engine partner not to try and pull the rug out from under you and change the terms of the agreement, Darth Vader style. There are already Unity developers, including the Cult of the Lamb studio, who have said they will pull their games on Jan 1 instead of giving in to Unity's terms.
Which is great from a pure hobbyist point of view...but Unity was such a great option for people who had aspirations of maybe one day taking a project beyond that stage. Leave it to tech C-suite management types to ruin a good thing in the name of "growth", likely slaughtering the golden goose in the process.
My own game launches in 2 months and we are just simply not allowed to make more than $1million in revenue, we would start making negative money immediately. Fortunately we're tiny and will probably not come close to that, but if our upcoming game is like 5x bigger than the last (which is not out of the question) we'd basically have to drop everything and port the game to a different engine in order to grow. It's completely insane.
Here's sort of what I think happened
Epic has, whatever you think of their store, leadership or ownership, absolutely cemented Unreal as the public AAA engine, absolutely being on par with the nominally always private/expensive AAA engines and they're not running out of money with Tencent's backing. And they even recently improved the terms of their free license and UE5 is delivering.
Unity isn't really going to be able to compete on Unreal's terms. There is absolutely a space for a smallish A or AA quality engine and Unity was that for a while. And a subscription per-seat per-year model fits well, it's more secure revenue capture for indie games that might not make it and the massive sellers won't be using it anyway. But they don't get to be a big company this way, only a small one. And frankly their financials are shit, they've tripled revenue since 2019 and went from losing 150 million a year to losing 880 million a year. Now a lot of that is classified as "selling & marketing" and they've quadrupled R&D but still, they're not exactly raking in the dough
So they need a niche and a new revenue stream. That niche is mobile, while Unreal theoretically has a mobile target, nobody is really going to develop their casual farming clicker game in Unreal. But mobile has high install rates and in-app purchase revenue, which they can't really capture, and low development budgets which reduces Unity's effective cut. So how do you capture more? Lightbulb moment, charge for installs
And frankly, it might work. The people actually making the highly monetized predatory mobile games probably will pay that cent per install because they are making a dollar. PC and console might jump ship but that's not where the money is for them I would guess
It's the whale model. A single 100 million install mobile game at 1c/install is 500 seat-years of sub revenue
To pull out of this and start to build back any sort of trust, they will need to drop the fees and put in place version-pinned EULA terms that can't be pulled out from under developers.
(They also probably think they can coerce studios into using Unity ad services to drop the fees, but this is also insane and would only work in the very short term. Ad monetization is less than pennies and a lot of games simply don't have any.)