Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
Tags
(1 edit) (+1)

Ok, so here is how it works:

1. Preexisting IDEAS can be used (I mean, we can't really judge whether you've had an idea or not.
2. Preexisting materials can be used if they are not unique to the project. If you have a prior released project and you want to use a plugin  you made for it. Cool. If you want to use a sprite that someone released on the internet for commercial free use, cool.
3. Assets that are unique to the entry that were made before the contest started are NOT ALLOWED.
4. Any work in an engine, editor, programming (outside of things like plugins that fit in rule 2) made before the contest started are NOT ALLOWED.

ok I understood, thank you for answering me sorry to cause you so much trouble. I am new to this type of events. thank you for your patience.

Hey Nick, just to clarify (sorry) about #2.

Can preexisting materials for instance include a dialogue system (which is a collection of files I've created myself before)?

Or like a file that handles movement? 

Perhaps I'm just confused on the definition of a plug in and if it needs to be publicly available.

Thanks

(+1)

Sorry, was using the term used for RPG Maker MV. Basically if you  had made some modular code to handle something that was not really game specific, it should be fine. Both of your examples sound like they are fine.

Should I refrain from using modular code if it would constitute too much of the engine?  I ask cause I've got a bunch of code from trying to make a modular architecture to use on top of SDL2 in place of having to use things like game maker and renpy.  Would that still be okay, or should I just stick to SDL2 as the base?

I would need more detail on what exactly the programming does to give an exact answer.

Well, to list stuff off, basic file handling, a simple implementation of ini files, a simple loader for png files, a system for keeping track of texture pages and drawing what's on them, a system for caching text and drawing it, a generic game loop minus the actual update or rendering functions, an event handler for sorting input into easily checked state, a dialogue system using the drawing and text systems, a core base for making menu with no default, a collision system, and a system for keeping track of audio resources (mainly how long they've been playing and how many instances of sounds are current). These are all in separate files, but the drawing portion, the game loop and the event handler are closely tied together.  Part of why I'm unsure is that all the things the programming does are things rpgmaker and most other "engines" do as well.

Yeah, that just sounds like generic engine stuff. That is 100% fine.