Putting the 'role' back in role-playing games since 2002.
Donate to Codex
Good Old Games
  • Welcome to rpgcodex.net, a site dedicated to discussing computer based role-playing games in a free and open fashion. We're less strict than other forums, but please refer to the rules.

    "This message is awaiting moderator approval": All new users must pass through our moderation queue before they will be able to post normally. Until your account has "passed" your posts will only be visible to yourself (and moderators) until they are approved. Give us a week to get around to approving / deleting / ignoring your mundane opinion on crap before hassling us about it. Once you have passed the moderation period (think of it as a test), you will be able to post normally, just like all the other retards.

Vapourware Codexian Game Development Thread

Bad Sector

Arcane
Patron
Joined
Mar 25, 2012
Messages
2,285
Insert Title Here RPG Wokedex Codex Year of the Donut Codex+ Now Streaming! Steve gets a Kidney but I don't even get a tag.
Nathaniel3W is this a UDK/UE3 thing? I've only used UE4 (and TBH not much) and i don't really remember archetypes, though AFAICT from your description it sounds like the "classes" you make as assets which are basically subclasses of classes you defined either in C++ or via another asset (pretty much always as a blueprint).

In Little Immersive Engine you can only place "entities" in the world and there are no entity subclasses, instead the entities can have "elements" and those elements are what provide the actual functionality: lightsources, static meshes, brushes, sectors, environment areas, etc. These are subclasses of a base "element" class. For example a "TV set" entity could be made up of a mesh element for the TV set itself, a light source element for the screen's glow and a sound emitter element for the audio the TV makes.

In general the world in Little Immersive Engine is made up of "layers" with a root layer right under the world instance itself. The layers can have other sublayers as well as entities and the entities can have elements. Layers and entities are not subclassed whereas elements are. These are all serializable objects whose properties can be edited, usually via a property editing panel (the one under "Properties" in the right sidebar).

An entity mold actually contains element instances (i.e. they are serialized instances of element subclasses), for example the entity mold shown at the left side/window of the image i posted has 10 elements: 9 brush elements (brushes are used for simple geometry ala Quake 1) and one light source element. Since each element is an object instance, their properties can be edited too - in the left side/window in the image the properties of the light source element are edited.

From your description (and assuming my understanding is correct) it'd be possible to do something similar to archetypes by creating a new entity mold asset per "archetype" and specifying different values for the properties for the elements that make up the entity's element.
 

Nathaniel3W

Rockwell Studios
Patron
Developer
Joined
Feb 5, 2015
Messages
1,271
Location
Washington, DC
Strap Yourselves In Codex Year of the Donut Codex+ Now Streaming!
Bad Sector I don't know if the terminology changed after UE3. But one of the descriptions for an archetype is "a codeless class." It lets non-technical people create a "class" in the editor without using code, and then you can spawn new instances of it.

Your system doesn't sound too dissimilar from what I'm familiar with. In LIE, you can place entities, and those entities can have elements. In UE, you can place actors, and those actors can have components. I think your mold system is what I would think of as a prefab. I think I get it now.
 

Eisen

Learned
Joined
Apr 21, 2020
Messages
685
Every year I play around with retro pixel art game ideas for a day and then give up because nobody buys them.

pl7Mwsc.png
Is this Uryx 1 bit tileset?
 

Bad Sector

Arcane
Patron
Joined
Mar 25, 2012
Messages
2,285
Insert Title Here RPG Wokedex Codex Year of the Donut Codex+ Now Streaming! Steve gets a Kidney but I don't even get a tag.
Your system doesn't sound too dissimilar from what I'm familiar with. In LIE, you can place entities, and those entities can have elements. In UE, you can place actors, and those actors can have components. I think your mold system is what I would think of as a prefab. I think I get it now.

Yeah, generally terminology in every engine is whatever the developer came up with :-P. In Little Immersive Engine i use the term "elements" instead of "components" because the latter is already used by FCL/LCL (the framework on which the editor is built), otherwise i'd call them components instead. AFAIK Unity has something similar but there they're called "game objects" or something like that.

Entity molds are somewhat similar to prefabs but they are not exactly the same as what other engines have prefabs for (e.g. most editors for Quake engine-based games) because they can only hold a single entity, they are "proper" assets (with asset lifetime management by the engine, etc) and there is a link between entities and their mold. In terms of other engines, entity molds are closer to entity templates in the REDengine (they are the inspiration actually).

I do plan on adding prefab support at some point, but those would be closer to the prefabs you'd find in other editors (again, like those for Quake :-P): they'd be editor-specific (no assets, just raw files), they'd contain multiple entities with their elements/properties and there wont be any links between the prefabs and entities, they'd just be a shortcut for creating stuff in the editor.
 

beardalaxy

Educated
Joined
Jun 10, 2023
Messages
101
After a long 9 years of development, I am so happy I can finally share a trailer for my game. We're really in the home stretch! I grinded this out over the course of the last 10 hours because I'm way too excited about it lol.

Congratulations. Releasing a game is a big deal. Especially after nine years, you must really feel a sense of accomplishment.

Don't let what I'm about to say make you feel bad about all that you've done: I strongly recommend you work on it some more, especially if you want others to play and enjoy it. And you also need to work on the trailer.

The trailer has an easy fix. Don't try to make a cinematic trailer. Slow-burn cinematic trailers work well at the start of a movie where the audience isn't going anywhere. For people watching your trailer on Steam or YouTube, you need to grab their attention and tell them what your game is about immediately. You have about 5 seconds before they stop watching. That 5 seconds needs to grab them and make them want to watch the rest of the trailer. Focus on the gameplay. Don't focus on story or features. Hint at story and features. Cut the trailer to 60 seconds and show only the most exciting stuff with frequent cuts.

As for the game itself, do you want to tell us more about your inspirations? Price point? Themes or feelings you're going to evoke? Which game's fans will your game appeal to?

To be completely honest, I want to finish the game. I just can't keep working on it forever. I did buy a bunch of other pixel art tile packs to start recreating the tilesets, but I knew it was going to take a very long time and it might not end up looking great. The truth is that the game was created with the stock assets in mind right from the very start, and changing that would be so much harder than just replacing graphics. It could make the game look more unique, and help it stand out, but since the game wasn't built with those new graphics in mind it would probably end up not looking as good and for how much work it would take to implement I don't think that's a trade-off that's worth it, even in theory.

I'm curious as to what else you'd think I need to work on as far as the game itself goes. I am open to critique, and I know I'm going to get plenty of it in testing as well. I just can't promise that much will change, because like I said... I've worked on this game for so long and I really just need to finish it at this point. There is also the issue that what might be seen as "improvements" are further away from my intended design choices. For instance, I could overhaul the battle system to have more mechanics, but I wanted to keep it very simple and much like an old-school JRPG. There are skills, states, and elemental weaknesses/resistances, that's about it. Not to say that this is what your criticism entails, just putting it out there as an example. That's also not to say that I'm simply writing off every bad thing about the game as a design choice.

All of that is to say that at this point in development, nothing major will change. My main focus is on getting the game released and in as solid of a state possible with respect to the core of the game. I want to move on and utilize what I've learned in future projects instead of being stuck working on this one forever. I know that is the folly of a lot of aspiring game devs and even large studios... I've been in development hell and I want out.

As far as the trailer goes, I have received that criticism from several people. Although I'm not going to go back and change the trailer that's already been released, I will make a new one at some point to try and show off more of the game itself instead of the story and keep it trimmed down. I'll be starting up another playthrough alongside some of the other devs for more testing, so I'll be making sure to get footage of more combat and more excitement. It's a little hard to do that without revealing a whole lot, since the most exciting stuff naturally is a little spoilery, so I'm trying to find a good balance for that.

Now... the game itself.
I wanted to take the idea of an oldschool JRPG (like Dragon Quest or Final Fantasy) and turn it into something less linear and more lively. Even though the game takes place during a plague and a lot of people are dead, every single NPC has a name, a place they live, and a schedule that they follow through a day-night cycle of 4 days per week. I'd say around half of them serve actual quest purposes and the rest offer some flavor. The world has rich lore that is delivered by NPCs as well as journals, books, and historical sites. I wanted to focus more on the world and its inhabitants which is something I felt was sort of missing from other RPGs I had played in the past. In that regard, it takes inspiration from oldschool JRPGs for its base and then adds something like Skyrim for its flavor. It's a game that doesn't hold your hand much at all and lets you explore by yourself, and rewards that exploration with NPCs and quests that I have made an attempt to immerse you and give you a sense of what the people in Hajimari are going through. With that comes sadness when you hear about someone's plight, but also joy when you're able to help them (or shock when you cannot), and that sentiment tends to ring true with a lot of the NPCs.

The game will be free. An entire third of my life has gone into this game and I kind of just want it to be as accessible as possible. I know an old school RPG isn't the easiest thing for the modern gamer to get into unless it is for nostalgia reasons, but I hope that the game not having a buy-in will help get people on board. I also admittedly feel a bit of shame in using some stock assets while still asking money for it, even if that is perhaps a little unfounded. I realize that many people will see a free game and immediately assume it is shit as well, but yeah, at the end of the day I just hope it allows more people to play it. HOWEVER, there will be an option to pay for the game and receive the soundtrack and a few other extras. Nothing that would be necessary to enjoy the game, but I'm thinking along the lines of a retro version of the soundtrack you can swap to in-game, the ability to continue playing after the ending and change your class, and hopefully down the line a few extra quests/dungeons. I'm thinking something like $10 for that makes sense. It's more of a way to support the people who made it than anything else.

I think my main audience is probably going to be other RPG Maker devs and people who are interested in RPG Maker games. It is rather hard to break out of the scene without someone external to it picking it up, such as a more general/variety streamer. There is a reason why the most popular RPG Maker games are actually not even RPGs at all, tending to be horror games. It's a niche within a niche, and I've known that since I went all in on this game. I know a lot of my friends are looking forward to it as well and perhaps they'll share it around to others who might enjoy this sort of thing. At the end of the day though, I'll be happy if there is at least one person out there who enjoys it and the fact that I can finally lay it to rest and move on with things will be enough.

In other news, I have almost got the game's Steam page up. It went through the initial review and was rejected because I have the game's Japanese name in the artwork for it but not in the game's official name. So I removed that from the artwork and am now just waiting for it to be reviewed again. I also started learning Godot, which I'd like to potentially use for future projects. A couple in particular I don't think are going to be feasible to make in RPG Maker so I'd like to branch out a little bit and pick up some new skills along the way. There is always the possibility that the next RPG Maker that rolls along completely shocks everyone and is using a 3D renderer or something like that, in which case I'd probably just stick with it, but I don't think we live in the timeline where that happens again lol. I gotta' say, Godot is much better so far than any experience I've had trying to learn Unreal or Unity. I'm enjoying the process quite a bit.
 

beardalaxy

Educated
Joined
Jun 10, 2023
Messages
101
I submitted the first insider test build for my game to Steam to review. It's just open to people who worked on the game or have other close ties to it (family of mine who have offered me support, for instance).
Once we get closer to the end of this test, I'll be thinking on how I want to open it up to more people. I'll probably end up putting out a form with a few questions to apply for testing, especially since I'm going to be requiring the use of HacknPlan for bug reports in order to keep everything tidy.

In the meantime, I've also been re-recording the lines of a couple characters who were recorded on an old, horrible setup (large, empty room with wooden floors and a Blue Yeti). The new lines are so much better... like a night and day difference. I wish I could re-record a few more characters, but that isn't feasible unfortunately. When your game is in development so long you learn a lot more about how you should have done things, but if I want the game to ever come out I can't dwell on it. There is also the fact that one of these characters was voiced by a 12 year old who now has a much different voice lol... it's been 7 years. In that case I'd have to get an entirely different actress!

Anyway, the expanded testing will ideally come around within the next 2-3 months :) The insider one is more to test out how Steam works since I haven't used it as a developer before, but of course I'll be looking to patch bugs and tweak balance as well.
 

Twiglard

Poland Stronk
Patron
Staff Member
Joined
Aug 6, 2014
Messages
7,314
Location
Poland
Strap Yourselves In Codex Year of the Donut
I'm obsessing over 2.5D limitations.

Tiny details like entrances of buildings having a small 'step' at the entrance so that they're not exactly on the ground level.

Implementing a Z offset that doesn't factor into the physics (except for shifting sprites by a fixed Z amount), and implementing the 'step' as a pre-rendered sprite with multiple collisions objects (for railings) is doable.

But then you have successful games that don't seem to have such 'steps' on the ground floor, e.g. all classic 1990-2024 RPGs. Probably Project Zomboid too. What do you think?

I should probably do a break from making rendered wall collision boxes and implement my own smart pointers now.
 

Zanzoken

Arcane
Joined
Dec 16, 2014
Messages
3,650
Tiny details

It's very easy to burn hours on tiny details that ultimately 99% of players will never notice or care about.

Not that polish doesn't matter, but I think if your goal is to ship a game in a reasonable amount of time then you have to make a conscious effort to focus on the core features that really define your product.
 
Joined
Oct 26, 2016
Messages
2,015
I'm obsessing over 2.5D limitations.

Tiny details like entrances of buildings having a small 'step' at the entrance so that they're not exactly on the ground level.

Implementing a Z offset that doesn't factor into the physics (except for shifting sprites by a fixed Z amount), and implementing the 'step' as a pre-rendered sprite with multiple collisions objects (for railings) is doable.

But then you have successful games that don't seem to have such 'steps' on the ground floor, e.g. all classic 1990-2024 RPGs. Probably Project Zomboid too. What do you think?

I should probably do a break from making rendered wall collision boxes and implement my own smart pointers now.
Why would you want smart pointers?
 

Twiglard

Poland Stronk
Patron
Staff Member
Joined
Aug 6, 2014
Messages
7,314
Location
Poland
Strap Yourselves In Codex Year of the Donut
Why would you want smart pointers?
To avoid use-after-free.

I'm thinking of a handle type that includes a counter to catch use-after-free though, to avoid having to deal with expensive refcount keeping (bad even if atomics are disabled such as with Boost.SmartPtr. The alternative is a pointer type that gets freed if there are zero refcounts *or* releasing it is explicitly requested, in the latter case acting as if all other references to it became as-if they were weak pointers.
 
Joined
Oct 26, 2016
Messages
2,015
Why would you want smart pointers?
To avoid use-after-free.

I'm thinking of a handle type that includes a counter to catch use-after-free though, to avoid having to deal with expensive refcount keeping (bad even if atomics are disabled such as with Boost.SmartPtr. The alternative is a pointer type that gets freed if there are zero refcounts *or* releasing it is explicitly requested, in the latter case acting as if all other references to it became as-if they were weak pointers.
I gathered that, I mean why do you consider it worthwhile?

If you got this far without them, why add it now?
 

Twiglard

Poland Stronk
Patron
Staff Member
Joined
Aug 6, 2014
Messages
7,314
Location
Poland
Strap Yourselves In Codex Year of the Donut
I gathered that, I mean why do you consider it worthwhile?

If you got this far without them, why add it now?
I'm using <memory> but I'm not happy with #include time, the primitives they have (shared_ptr and unique_ptr), atomic ops as well as the inability to release a shared_ptr<T> without sticking it into shared_ptr<optional<T>> or something.
 
Joined
Oct 26, 2016
Messages
2,015
I gathered that, I mean why do you consider it worthwhile?

If you got this far without them, why add it now?
I'm using <memory> but I'm not happy with #include time, the primitives they have (shared_ptr and unique_ptr), atomic ops as well as the inability to release a shared_ptr<T> without sticking it into shared_ptr<optional<T>> or something.
Why would you care about releasing a shared pointer? Usually you just let them go out of scope to release them, or at least I do.
 
Joined
Dec 24, 2018
Messages
1,821
I gathered that, I mean why do you consider it worthwhile?

If you got this far without them, why add it now?
I'm using <memory> but I'm not happy with #include time, the primitives they have (shared_ptr and unique_ptr), atomic ops as well as the inability to release a shared_ptr<T> without sticking it into shared_ptr<optional<T>> or something.
What is it exactly that you're using your smart pointers for? And are you quite sure that including <memory> is really what's causing your compile time grief?
 
Joined
Dec 24, 2018
Messages
1,821
What is it exactly that you're using your smart pointers for? And are you quite sure that including <memory> is really what's causing your compile time grief?
clang with -ftime-trace says so. Some 300+ milliseconds on just this header.
That seems pretty minor, to be honest (of course, I don't know how many places you're including it, so maybe it's adding up). But anyways, what are you using your smart pointers for?
 
Joined
Oct 26, 2016
Messages
2,015
What is it exactly that you're using your smart pointers for? And are you quite sure that including <memory> is really what's causing your compile time grief?
clang with -ftime-trace says so. Some 300+ milliseconds on just this header.
That seems pretty minor, to be honest (of course, I don't know how many places you're including it, so maybe it's adding up). But anyways, what are you using your smart pointers for?
I have no doubt that smart pointers in general can introduce all sorts of grief. In particular you are referring to a shared pointer. What is the nature of the problem?
 

As an Amazon Associate, rpgcodex.net earns from qualifying purchases.
Back
Top Bottom