[R>Artist 2D] [R>Programmer] Share Looking to Assemble Team... Again!

[YetAnotherUser]

Greetings, everyone.

You may remember me from a request I’ve posted back in October. However, if you don’t remember that thread, I’ll leave the link [here]. It features the relevant information about the project, as well as the kind of people I’ve been looking for to join the development team.

Unfortunately, as positive as I have sounded in my closing message back then, the team have been effectively disbanded. I’ve been working with several people since October of the previous year, but every programmer has eventually resigned for different reasons, from artistic differences to the lack of enthusiasm in working on this kind of project, which later on resulted in them going radio silent.

Another unfortunate point is that none of the people I have been working with has achieved any tangible progress with the game’s systems. One of them has promised to send me what they’ve managed to build since the start of our cooperation, but alas, I haven’t heard from them for over two weeks now, and I don’t expect much even if they returned with their assets.

It leaves me only with the materials I’ve been working on myself, which includes: the documentation with the basic description of the project, dialogue and story texts for the demo, codex entries to be added to the in-game encyclopaedia, overall aesthetics for the game’s UI, and map outlines for the early in-game locations. Also, I’m currently working on the lines for sex scenes.

As you have most likely figured out by now, I’m looking for programmers again. However, I need to clarify that I’ve decided to stick to Unity for this project (mainly because I’ve started tinkering with the engine myself, thus I won’t be completely left out of the development process), so I’m looking for people who know the engine and can code in C#. Also, I have to emphasise that you should be interested in working on this game. I’ve already burned my fingers by putting trust in a person who declared from the get-go that they wouldn’t treat this game as their own passion project. If you are not interested in working on this type of game and show a decent amount of drive, please, refrain from contacting me.

For the same reason, I’m keen on having multiple coders at the same time, so that if one of them suddenly decided they no longer wanted to participate, the other could take on from where the other one had stopped. I would be glad to have a smaller team, but from bitter experience, as the expected project leader, I feel like I shouldn’t take any chances and rely on a single, potentially unreliable person.

If you happen to be a writer but, for some reason, decided to have a look at this thread, I’m willing to consider having you on the team, but don’t expect to get paid, at least any time soon. Having a person ready to contribute their writing or editing skills would be nice (since I’m not a native English speaker myself, and any help in this department would be much appreciated), but unless we make it sufficiently big, the most you can expect is your name in the credits and involvement in the development.

Same for artists (characters, backgrounds). If you want to have a platform for exposure and your art is decent, you would be welcome on board as well. Just keep in mind the genre and this project’s priorities. I’m not aiming this to become a CoC2 clone with the same fetishes, so no futas with giant horse cocks, at least not in the foreseeable future.

If any of you are interested in joining forces, do let me know. The contacts are in the previous thread, but you could also post here or DM me. By the way, I could provide you with some of the materials I have to ultimately decide whether you are interested in joining or not. I concede that some may not like the way I write, so we should settle this before agreeing to working with each other.

Ps. Sorry for not utilising the requested template. I figured it would be easier to simply reference the previous thread since the services I seek are basically the same. I'm not sure if 'completed' threads are revivable, so yeah, I've gone for a fresh one instead of bugging the staff to relocate that thread back to this forum. However, if it's needed, I'm ready to either copy the contents of the previous thread here, or add the message above to the previous thread, in case it's moved back in here.

 

[quarzo]

well i am curious why the firts try fails, specially if was a textbase game and see you already has a robust guidelines to follow.

may be following a enviroment more simple in html can work for your purposes?

 

[YetAnotherUser]

well i am curious why the firts try fails, specially if was a textbase game and see you already has a robust guidelines to follow.

may be following a enviroment more simple in html can work for your purposes?

As much as I love browser-based games (I'm a long-lived DoL fan), this is not the direction I have in mind. Sure, it's supposed to be a 2D game, but quite complex nonetheless, with a certain visual style and aesthetics. Besides, I've already put a lot of time and effort into Visual Novel-esque dialogues that will look terrible in Twine. While I'm ready to edit the texts, a complete overhaul is out of question. Plus, I think making systems like an inventory, trading, navigation systems, backlog, or mini-games would be a nightmare to code for an html game.

 

[thegooglyman]

What are you looking for commitment wise weekly? This sounds like an interesting project.

 

[quarzo]

As much as I love browser-based games (I'm a long-lived DoL fan), this is not the direction I have in mind. Sure, it's supposed to be a 2D game, but quite complex nonetheless, with a certain visual style and aesthetics. Besides, I've already put a lot of time and effort into Visual Novel-esque dialogues that will look terrible in Twine. While I'm ready to edit the texts, a complete overhaul is out of question. Plus, I think making systems like an inventory, trading, navigation systems, backlog, or mini-games would be a nightmare to code for an html game.

The fun part is that just implementing the IU part can be as difficult as the game system itself. If your collaborators have been implementing it for a long time, do not think that it is because of laziness, it can be a real pain, apart from the fact that it can be very boring, specially if the participants do not have experience in it, because it will be a brutal chain of trial and error. (speaking on behalf of the programmers who are doing these things for the first time)

Still, I hope you can make progress on the project. the truth from the point of view of the programmer, seeing that technical guide of the game can be a plus to attract someone to help.

 

[Winterfire]

If you want to have a platform for exposure

Heh, I love when the whole "I pay your art with exposure!" is used unironically

Anyways, while throwing programmers at your project may seem like a good idea, it's not.
Even if two programmers have the same knowledge about the same language (C# in this case), continuing from where one left off is not as easy, and it becomes more time consuming than rewriting everything from scratch if the code was not pretty or well documented.

Of course I do understand how that can happen if it is a "passion project", so at the very least make sure that whoever works on the code keeps it well documented.

 

[YetAnotherUser]

What are you looking for commitment wise weekly? This sounds like an interesting project.

It's hard to say, given I don't have any semblance of release schedule (for obvious reasons). As long as I see that slow, but actual, progress is being made, I won't bugger the programmer too much. After all, I still have a lot to be done on my part, and the progress has been slow-ish. I guess, a couple of hours every few days, give or take, would be enough, to kick off the whole process?

The fun part is that just implementing the IU part can be as difficult as the game system itself. If your collaborators have been implementing it for a long time, do not think that it is because of laziness, it can be a real pain, apart from the fact that it can be very boring, specially if the participants do not have experience in it, because it will be a brutal chain of trial and error. (speaking on behalf of the programmers who are doing these things for the first time)

Still, I hope you can make progress on the project. the truth from the point of view of the programmer, seeing that technical guide of the game can be a plus to attract someone to help.

Implementing functionality -- maybe, but having taken a look at Unity myself, preparing a canvas shouldn't be harder than making a prototype in Photoshop. Basically, drag and drop the assets in the right places (yes, I'm that naive). The latest programmer, the one who is still missing (hope he is alright, btw; the times are trying), has successfully converted my prototype into the engine, at least the visual aspect of it. He also has, presumably, been working on the dialogue system, and even shown a glimpse of it, and from my knowledge, he has been trying to implement the navigation system before ceasing to work on the game altogether, so it's not the UI that hindered him.

Heh, I love when the whole "I pay your art with exposure!" is used unironically

Anyways, while throwing programmers at your project may seem like a good idea, it's not.
Even if two programmers have the same knowledge about the same language (C# in this case), continuing from where one left off is not as easy, and it becomes more time consuming than rewriting everything from scratch if the code was not pretty or well documented.

Of course I do understand how that can happen if it is a "passion project", so at the very least make sure that whoever works on the code keeps it well documented.

Yeah, I know how it sounds for artists, not pretty at all. This is why I'm not actively looking for people who are ready to effectively donate their art for free. About code, I know, I realise that, but as long as all programmers start at roughly the same time and interact with each other continuously, it shouldn't be too bad (but bad nonetheless). Still, pressing for more // is not a bad idea.

 

[Winterfire]

Implementing functionality -- maybe, but having taken a look at Unity myself, preparing a canvas shouldn't be harder than making a prototype in Photoshop. Basically, drag and drop the assets in the right places (yes, I'm that naive). The latest programmer, the one who is still missing (hope he is alright, btw; the times are trying), has successfully converted my prototype into the engine, at least the visual aspect of it. He also has, presumably, been working on the dialogue system, and even shown a glimpse of it, and from my knowledge, he has been trying to implement the navigation system before ceasing to work on the game altogether, so it's not the UI that hindered him.

Unity makes the visual part of making UI stupidly easy, and that's what I love about it when compared to Ren'Py or other common game engines.
However, implementing functionality is definitely not easy and requires actual good planning... Depending on how complex your game is going to be, you will need a manager (not a person, I meant code-wise) at some point since those systems will have to interact with each other at some point... That is why I find it odd that you are starting off from the UI.

There are also many other factors to keep in mind when handling UI, such as the aspect ratio.
Do not think that the canvas will handle everything for you... It's a step up since Unity 5, but I came back to Unity after playing for years with Ren'Py and totally made the mistake that the aspect ratio would have been taken care by the canvas.
Ren'Py spoiled me.

Yeah, I know how it sounds for artists, not pretty at all. This is why I'm not actively looking for people who are ready to effectively donate their art for free. About code, I know, I realise that, but as long as all programmers start at roughly the same time and interact with each other continuously, it shouldn't be too bad (but bad nonetheless). Still, pressing for more // is not a bad idea.

It's not about the amount of //, but the quality. Too many and pointless comments will actually make it worse, plus each programmer has their own way to do some things.
Plus, I am sure there will be some "black box code" at some point, so rather than comments, a small documentation showing how to use it would be better... Unless there is a bug hidden there, and a new programmer will have to navigate it in order to fix the issue (RIP).

 

[YetAnotherUser]

Unity makes the visual part of making UI stupidly easy, and that's what I love about it when compared to Ren'Py or other common game engines.
However, implementing functionality is definitely not easy and requires actual good planning... Depending on how complex your game is going to be, you will need a manager (not a person, I meant code-wise) at some point since those systems will have to interact with each other at some point... That is why I find it odd that you are starting off from the UI.

There are also many other factors to keep in mind when handling UI, such as the aspect ratio.
Do not think that the canvas will handle everything for you... It's a step up since Unity 5, but I came back to Unity after playing for years with Ren'Py and totally made the mistake that the aspect ratio would have been taken care by the canvas.
Ren'Py spoiled me.



It's not about the amount of //, but the quality. Too many and pointless comments will actually make it worse, plus each programmer has their own way to do some things.
Plus, I am sure there will be some "black box code" at some point, so rather than comments, a small documentation showing how to use it would be better... Unless there is a bug hidden there, and a new programmer will have to navigate it in order to fix the issue (RIP).

I see. Thanks for the input.

 

[Kedar]

Hello,

Two cents from someone that is working as a software developer on a daily basis, with some commercial experience in game dev (Unity).

Foremost, I would like to say good job with GDD. It's really well-made, but lacks one important section - development steps/prototype versions/increment details... you name it. Everything relatively big (project) should be divided into smaller pieces (implementation steps) that provides minimal value. I don't want to go into details, so I'm leaving here the keyword "SMART" (acronym). And it's not coincidence that most of IT project are made by using agile approach, where additionally in development cycle, big tasks are decomposed into smaller ones, so you can easily verify your idea and detect potential issues before going into next cycle.

Furthermore, I would advise you to demand access to code at the beginning of collaboration. It's crucial to see how work is going.
Ideally there should be CI/CD which will allows you to check current status of work. This was something that my clients appreciate a lot, as they could easily test every minimal change of gameplay without wasting my time on building and preparing a package of game.

Please avoid writing comments in code. In most cases, they are redundant. They should be only used as a last resort for not obvious behaviors/business cases. Code should be self-documenting, and I'm serious here.
So, rather than writing comments and/or documentation, it is much better to write automatic tests.
Well-made automatic tests are runnable documentation with additional benefit of preventing regression after changes. Of course, it is additional work to do, but as well as writing documentation or writing useless comments.

That's my opinion, I wanted to share it, as somehow I'm interested in this project.

 

[YetAnotherUser]

Hello,

Two cents from someone that is working as a software developer on a daily basis, with some commercial experience in game dev (Unity).

Foremost, I would like to say good job with GDD. It's really well-made, but lacks one important section - development steps/prototype versions/increment details... you name it. Everything relatively big (project) should be divided into smaller pieces (implementation steps) that provides minimal value. I don't want to go into details, so I'm leaving here the keyword "SMART" (acronym). And it's not coincidence that most of IT project are made by using agile approach, where additionally in development cycle, big tasks are decomposed into smaller ones, so you can easily verify your idea and detect potential issues before going into next cycle.

Furthermore, I would advise you to demand access to code at the beginning of collaboration. It's crucial to see how work is going.
Ideally there should be CI/CD which will allows you to check current status of work. This was something that my clients appreciate a lot, as they could easily test every minimal change of gameplay without wasting my time on building and preparing a package of game.

Please avoid writing comments in code. In most cases, they are redundant. They should be only used as a last resort for not obvious behaviors/business cases. Code should be self-documenting, and I'm serious here.
So, rather than writing comments and/or documentation, it is much better to write automatic tests.
Well-made automatic tests are runnable documentation with additional benefit of preventing regression after changes. Of course, it is additional work to do, but as well as writing documentation or writing useless comments.

That's my opinion, I wanted to share it, as somehow I'm interested in this project.

Hello, Kedar!

Thanks for the advice. I feel flattered, really. Under different circumstances, I'd say that I would make the necessary changes and additions, but unfortunately, the whole endeavour is currently in the state of pre-death agony. There's one person left who could, potentially, act as the programmer, and if they refuse, then, well, my time is effectively running thin. As many of you might have surmised from my e-mail domain, I'm from Russia, and with the present state of the world, there's no guarantee I would be able to continue working on this game, like, at all. Disregarding the fact that our economy is looking to collapse (and I already cannot lay my hands on any money coming from abroad), there's always a chance either of the sides may decide that it would be a great idea to isolate us from the rest of the world.

So, everyone, think of this message as the ultimate bump. If no one steps up, I will probably have to stop looking for associates. It pains me. I've spent the last six months preparing the groundwork for this project, but sometimes, you just have to quit chasing rainbows. I'm ready to share whatever I have with the team, so even if I disappeared, they could continue with a different writer, but if there is no team in the first place, then there will be no one who could keep on going. As such, if you are not ready to join yet but may want to join in the future (there's literally one person who dropped out because they realised their school semester was about to begin), please, keep my contacts. Just to be on the safe side. If I'm still around, we may discuss your participation later, once you are 100 per cent ready.

Upd.: The person I mentioned above has officially withdrawn.

 

[Codehog]

Hello,

this post is quite old now, but if you are still looking but haven't found a programmer yet, I might be interested to take the job.
I can't send PMs as I haven't posed enough in the forum. If you send me some other means to contact you, we can discuss further details

 

[YetAnotherUser]

Hello,

this post is quite old now, but if you are still looking but haven't found a programmer yet, I might be interested to take the job.
I can't send PMs as I haven't posed enough in the forum. If you send me some other means to contact you, we can discuss further details

Hello, Codehog!

Yeah, admittedly, this thread is getting older by the day. In fact, I was afraid it was going to get removed by June, when I was planning to bump it once more, since it would be summer by then. I'm still interested in this project, after all, even though I haven't done anything development-related since early March. There are some materials ready, however, which I can share upon further discussion.

Since my last post, no new programmers tried to contact me, so I do look for people to tackle this aspect still. My contacts are in the previous thread, the link to which is present in my opening post. I'll copy the relevant information, though, for convenience: "I have a Discord account (YetAnotherUser#2505). This should be the primary means of personal and team communication; however, I also have an e-mail (yetanotheruser1@yandex.ru)".

Upd.: Alternatively, you can send messages to my another mail, yetanotheruserdol@gmail.com, but I don't really use it for communication, so I don't even know if I'll notice that someone has sent me a message in a timely fashion.

 

[Codehog]

Great! I will contact you via Discord later, when I am back home! I have the same nickname there as I have here!