• entries
2
2
• views
2092

# Change of Plans

1072 views

It's been awhile since I've posted anything here and a lot has changed in reference to what I'm doing with my game.  After some setbacks, to include having no idea where to start after drawing out some levels, I decided to put my maze came on hold until I've gotten some more experience under my belt .  So for now I have moved away from using Unity to RPG Maker MV, which seems to be more user friendly.

Before moving to this new engine I watched several tutorials for it to get an idea about how easy it would be to use, how much scripting is required, and what is required of me in terms of actually using it and getting it do anything at all.  After having dealt with Unity I was pleasantly surprised that in terms of map creation it functions similarly to MS Paint and Sim City 2000 mashed together: Choose your tile, click where you want it, Rinse, and Repeat.  Well that seemed easy enough, and I'm happy to say it was.  After drawing out my world map on grid paper I moved over to the computer to make one of the island in the program.  From start to finish the whole process up until this point, which only included placing water and land with a few cities and towers on the map took me all in around 2 hours and left me feeling rather accomplished.

My next steps will be to start building the maps for the main cities, then the towers, something I hope to get done within the next 2 weeks or so while I continue world building on paper.  Concept art for one of the characters has already begun, as have details for how many islands I'll have and what the overall story will be.  I've already decided this will likely be a rather "big" game in terms of my ability, but to help cut it down to size I intend on just focusing on one island at a time, essentially making each island it's own chapter that could be it's own stand along game.

I'm not making any promises about what will be up next week, if anything at all, but I hope to have some pictures/screenshots or a more fleshed out post about the theme, story, and gameplay by the end of next week.  Until then, I wish all of you in Canada a happy Canada Day and all of you in the U.S.A. happy Independence Day!

There are no comments to display.

## Create an account

Register a new account

• ### Similar Content

• Hi Everyone,
Hopefully all of this makes sense at the end, but if you need anymore clarification please let me know.
Background: My MMORPG is a sword playstyle based game, where players need to complete a dungeon at the end of each floor to be able to progress to the next. (Players can go back to lower floors / Specific floors will have specific resources needed for crafting as to give players a reason to go back / Player skill progression will also require them to do specific quests/tasks on specific floors, again giving them reason to go back)
Inspiration: Sword Art Online (Anime) - Aincrad game that the players were stuck in
My map progression issue is this: I'm split between having all players locked to a specific floor until they/or the party they are in, completes the dungeon, then those players unlock the next floor OR if as soon as a party clears the floors dungeon and unlocks the next floor, that floor is unlocked for everyone on the server.
I'm going to split these into options 1 (Individual Progression) and 2 (Server Progression).
Option 1:
Benefits:
Allows the more dedicated/end-game player base to progress at a faster pace. Allows for end-game guilds to form and recruit from a more end-game player pool, I.e. Players from that specific floor Allows end-game players to sell their services to help newer players to progress through the lower floors Drawbacks:
Possibility of new players being stuck in lower floors as there might not be good enough players left on those floors to help them make a party and progress through the dungeon ? Option 2:
Benefits:
Allows new players to skip floor progression to be with their friends that have progressed further in the game ? Drawbacks:
Players will be on floors where they might not be able to survive or complete solo content because of their lack of skill, items, game knowledge Complains from new players saying the content is too difficult, as they are skipping floors New/lower player base will essentially just be waiting on the end-game players to finish the new floor unlocking it for the rest of the server, basically letting them sponge off of the top players progress After typing all of this out it's starting to become more clear cut as to which option I should take, but I'd like to check with the community here as I'm sure there are other benefits/drawbacks that I'm missing that might change my view of things.

• Concept for Delayed Shots in a Fast Paced Shooter

The base for this concept is that with each click or trigger pull there is a X-second delay before the gun would actually fire. This would make it alot more difficult to time shots and could create unique design elements that would cater to this delay. (i.e sharp corners and hallways where it would be hard to time when to click in such a tight enclosed space). Ive had this concept for a minute and i know we could code it to work but my main concern with this is, would it be a good design choice?
• By mujina
What could be a way of avoiding using inheritance and virtual methods when designing components for an entity-component-system?
I'll be more specific about my design issue:
I currently have different classes for different kinds of colliders (let's say, CircleCollider and LineCollider).
My system that checks for collisions and updates the positions and/or velocities of my entities should be something like:
for entity_i in alive_entities { collider_i = get_collider_of_entity(entity_i) // components of same kind are stored contiguously in separate arrays transform_i = get_transform_of_entity(entity_i) for entity_j in alive_entities { collider_j = get_collider_of_entity(entity_j) transform_j = get_transform_of_entity(entity_j) if check_collision(collider_i, collider_j) { update(transform_i) update(transform_j) } } } my problem is that I don't have a generic get_collider_of_entity function, but rather a function get_circle_collider_of_entity and a separate one get_line_collider_of_entity, and so on. (This happens because under the hood I am keeping a mapping (entity_id -> [transform_id, sprite_id, circle_collider_id, line_collider_id, ...]) that tells me whether an entity is using certain kinds of components and which are the indices of those components in the arrays containing the actual components instances. As you can see, each component class is corresponding to a unique index, namely the index position of the array of the mapping described above. For example, transforms are 0, sprites are 1, circle colliders are 2, line colliders are 3, and so on.)
I am in need to write a system as the one in the snippet above. I can write several overloaded check_collision functions that implement the logic for collision detection between different kinds of geometric primitives, but my problem is that I am not sure how to obtain a generic get_collider_of_entity function. I would need something that would get me the collider of an entity, regardless of whether the entity has a circle collider, a line collider, a square collider, etc.
One solution could be to write a function that checks whether in my internal entity_id -> [components_ids] mapping a certain entity has a collider at any of the indices that correspond to colliders. For example, say that the indices related to the collider classes are indices 10 to 20, then my function would do
get_collider_of_entity (entity_id) { for comp_type_id in 10..20{ if mapping[entity_id][comp_type_id] not null { return components_arrays[comp_type_id][entity_id] } } return null } This could turn out to be pretty slow, since I have to do a small search for every collider of every entity. Also, it may not be straightforward to handle returned types here. (I'm working with C++, and the first solution - that is not involving inheritance in any way - would be returning a std::variant<CircleCollider, LineCollider, ... all kinds of components>, since I would need to return something that could be of different types).
Another solution could be having some inheritance among components, e.g. all specific component classes inherit from a base Collider, and overrride some virtual collide_with(const Collider& other) method. Then I would redesign my mapping to probably reserve just one index for colliders, and then I would actual colliders in a polymorphic array of pointers to colliders, instead of having a separate array for CircleColliders, another for LineColliders, and so on. But this would destroy any attempt to be cache-friendly in my design, wouldn't it? That's why I am looking for alternatives.
A third alternative would be to just have a single, only, Collider class. That would internally store the "actual type" ( aka what kind of collider it is ) with dynamic information (like an enum ColliderType). Then I would have all colliders have all members needed by any kind of colliders, and specific collision detection functions which I can dispatch dynamically that only use some of that data. (Practical example: a "Collider" would have a radius, and the coordinate for 2 points, and in case its type was "circle" it would only make use of the radius and of one of the 2 points - used as the center -, while if it was a "segment" it would only make use of the 2 points). My gut feeling is that this would bloat all colliders, and, even if the bloat could be reduced - using unions in some smart way for storing members? I wouldn't know how -, then still the design would be pretty brittle.
I'm clueless and open for ideas and advice! How do you handle in general situations in which you have components that can be naturally modeled as subclasses of a more generic component class? Inheritance? Smart hacks with variants, templates, macros, custom indexing? Dynamic "internal" type?