Thanks for the insight on how morale works, Hooman. I always thought that idling the nursery had a much greater impact than what is shown.

A valid point leeor_net. Though from several developer interviews of those giant corporations, they create a huge design document and then ignore it throughout most of the development process... at least that was the case with Diablo 3, Duke Nukem Forever, and Aliens: Colonial Marines... and see how well those turned out

Sorry for the long delay, in replying. Turns out my idea needs a few more revisions. However, I am temporarily shelving this for later. Since its been almost over 2 years since I've started this project, and haven't made anything financially viable with it, and doesn't appear I will be anytime soon, I'm putting this on the backburner to focus on a different project.

I've been working on a text-based adventure for the past couple weeks, and honestly, I'm finding it much easier to code for and the code I have made for it, does what I want it to do. I've found making the text-adventure to be much more enjoyable and fulfilling than working on this remake. Probably because when I do run into a problem I can fix it and I actually understand what I'm doing. I feel confident that I will be able to make something financially viable with my text-based adventure and thus I've been just focusing on it lately. I'd be happy to share it once I've finished implementing a few more features, and get some feedback on it from people here. It has a fully functional combat system, that I designed and coded myself, a variety of items, and game failure states already put in. I'm really enjoying making the text adventure and it is showing a lot of promise for a very interesting game.

I'd like to do something with my Outpost 2 remake, but my finances have dwindled over the past 2 years, and I really need to either get a day job or focus on producing a game in an engine that I can actually use reliably and solve problems that I have with it, in a few days, rather than with UE4 having some problems take months to figure out. I'd like to return to this later, but right now I need to focus on my finances and I honestly don't think I can have an RTS produced within a year... whereas this text-based adventure, I can easily see it being completed within a year and have something unique that other text-based adventures don't have, and thus set it apart from other titles. As I've been busy with it, I kind of forgot about OPU, and thus this is why I'm replying now to give everyone a heads up. I'm sorry if this is a bit disappointing, but I've not made any money for the past 3-4 years, as I've been focused on designing and developing games, and thus I need something to change soon, or I'll have to leave game development, completely.

Reading your concerns, I'd say take care of yourself first. Sounds like you already know what you need to do, so go ahead and go it. Guilt free.

As for making it producing games, don't feel you need to go all-in on a personal project with a make it or die trying mentality. I know there is a common mindset that you have to go all in to be successful. It turns out this is actually false. Statistically, the people who are the most successful at starting a business or completing some venture are not the ones that go all in, but rather the ones who maintain some day job to pay the bills while they work on their side project. Those who do transition to earning a living from their side project usually wait until it's already earning enough money to life off of, or even to replace their full time salary, and have reached a point where they just don't have the time to continue growing their side project and work full time. Both those conditions are important.

There are a few reasons to maintain a steady day job works better than going all in. One is the day job will force you to learn skills that may be very valuable to you in your own ventures. It's easy to push off future problems for another day, and never end up developing the skills for when you need them. The immediacy of a day job helps to combat that. Another big reason for having a day job is managing risk. If you rely on your side project for income, you won't be in a good position to take big risks with it, since failure has much bigger consequences. Having the security of a day job lets you experiment more and find out what works. It's those experiments that often lead to rapid growth and overall success.

Here's a gambling analogy. Lets say you gamble on something, winner takes all, with over 50% win ratio for you. This means the more you play, the more your should expect to win. The more you bet each round, the higher your expected earnings. Sounds good. Except for one problem. If you always bet everything, always going all in each time, your probability of going broke approaches certainty the more games you play (even with 99% win ratio). In other words, long term success doesn't generally follow a sequence of high stakes risks, even if each one is in your favour.

Less a day job, and more a project-focus change, Hooman. I believe I can make the text adventure marketable within 6 months tops, as I'm progressing quite rapidly at it. I have a variety of features in mind that will set it apart from the usual text-adventure or non-visual novel and thus ensure that it can be sold. There does seem to be people interested in playing text-based adventures, but the question will be whether people are willing to PAY for one. But, I'll look into that issue later; for now, just work on it and once its in a playable state, get feedback on it.

There are ways to test a market before producing the product. I'd highly recommend looking into it. It's much better for you to test up front, than to potentially waste 6 months on something that nobody wants. It also lets you tweak the direction if you realize what people want is just slightly different. That takes considerably less effort the sooner in the development cycle you catch it.

One of the most common reasons for not testing the market, is not realizing you can do it before developing a product, or not knowing how to do it. It's very easy to push something off if you don't know how. It's uncomfortable. Deal with it later. Though avoiding the uncomfortable things is often setting yourself up for trouble.

Another reason for not testing the market, is people object to some of the methods presented. There are many ways to do it, so choose something that works for you. Indeed, you'll often come across some very sleazy sounding tactics, like putting up a page to sell the product, and measuring how many people buy, even though you don't yet have a product to give them. This can actually be illegal in some places, especially if you're actually collecting the money. A softer variant of that is to have a buy button, but rather than going through order completion, it informs the user the product is not ready yet, and the expected release date. Knowing how many people see the page, and how many people click the "buy" button, would then give an indication of market demand, both in terms of raw numbers, and percentage conversion rate. Though keep in mind not everyone that clicks "buy" would necessarily have completed the order even in the case where there was a product to sell. This method might still seem misleading, since you're getting users to click a "buy" button, when it's impossible to actually buy. A softer method still might be to have a "learn more" button, that gives more details of your game, and the date it's expected to be released. There are other tactics as well. Some might involve leaving an email signup for people who want to be informed when the game is released. This is likely to provide a better estimate of demand than simple page clicks to learn more, since some people like to look around with no intention to buy. It also helps filter for people who are willing to take action towards your product, which is a very good sign.

Now I'll come right out and say I don't know what I'm talking about. But, if you want to make game development your career path, perhaps it would be better for you to make something for yourself, something you and your friends would find fun, rather than something to generate income (not that it can't do that too, fingers crossed). But you could then use that to build your resume and hopefully land a job where you can meet people you can learn from, and get some training and experience. That might be a better launchpad for your career. But I'm sure someone else will come along and correct me if I'm steering you in a bad direction.

Logged

"As usual, colonist opinion is split between those who think the plague is a good idea, and those who are dying from it." - Outpost Evening Star

Well, I've tossed out a few prototypes already, as I found certain mechanics that I was trying to go for just didn't work at all for a text-based adventure. Mechanics such as:

- Stealth mechanics; no real sense of risk as you can take as long as you like to do any action (technically you can use timers, but without a visual element, time can be seen as unfair in a game where you can't see things that aren't described to you with text). Thus, have decided to avoid having stealth mechanics in my game.

- Announcing actions; in Dark Souls, if you observe your foes, you can learn their attack patterns and where the attack will land. I tried a system like this, in text-only format, but found that it just wasn't all that fun. The beauty of dark souls way of doing things requires a visual element to work properly. Thus aborted a prototype with it.

- Adaptative AI; I tried to implement a basic adaptive AI system, where if a player would input a series of commands, the game would learn and then take an appropriate action to counter that strategy. However, I found that this requires a fair bit more code than I believe I can possibly do, and I found it was far too easy to cheese the AI, so aborted a prototype with this system in it.

- Range / Co-Ordinates; I fiddled with the idea of trying to do multiple target battles that could take place within a room that was say 3 x 3 squares, where an enemy would have coordinates of (0,0) to (2,2), and could move 1 square per player action. However, without a way to visually represent even the most basic thing with a grid, I found it too cumbersome to use a system like this in a text-adventure.

- I also tried out several different types of basic systems, necessary for the kind of text-based adventure I'm going for; ie various ways of representing the player's inventory (without cluttering the interface), different ways of equipping AND unequipping items, different ways of handling combat encounters, and different ways of casting spells.

So... after all of that, I've now (I hope) got something I feel will be quite doable within a text-based adventure game and will likely be something I'd enjoy playing to boot. With all the prototyping I've done, I've gotten quite familiar with the engine and ways of doing simpler things much more efficiently. I've been able to figure out much more easily when its more appropriate to refactor the code and when its easier to just redesign from scratch and I'll pick the right one for the job; sometimes its better to refactor; other times when a system is so heavily embedded in the code, its better to redesign. Anyway...

The game itself will be somewhat of a hybrid between three games; Morrowind, Dungeons of the Unforgiven, and Ancients: Deathwatch; if you've never played those games, then that list may be completely useless to you. Basically, you have a variety of skills that are used by all the major actions/activities in the game, and you earn a lot of XP when you fail, and some XP when you succeed. Killing monsters provides XP for your character level, and your character level determines your maximum HP/MP; so Skills are not used for levelling the Character, but are independent. Thus, you can build your character, to suit your personal playstyle rather than being pigeon-holed into a specific class. There is a town that you can be safe in and spend your hard earned coins at various vendors. The end-goal is to defeat the boss in the deepest levels of the dungeon; the dungeon itself is broken up into sections, with an optional boss in the final floor of that section. That is a basic explanation of what I'm currently going for. When it is a bit fleshed out with content to actually play with, I'll drop a link here for you to take a look at and give me some feedback.

I've been wondering about this project lately. Have you come up with anything concrete? Do you have any source code? What language are you using?

I've been thinking more and more about an outpost 2 like game myself (either a direct clone or something new that takes gameplay inspiration from the original). Granted I've still got OutpostHD on my plate but if there was a primary developer working on such a game I'd be happy to provide assistance either in the form of code reviews, feature implementation, etc.

BTW, I wanted to thank you for sticking around so long especially through some of the adversity you've experienced in this thread. Would like to hear more from you. Hop on to IRC some time!

I'm focused on my text-adventure which is very much operational, very-playable, fairly gameplay style balanced, and has very few bugs. Only issue is that I don't have the tutorial ready (as I know my commands and the way the game functions quite well as I've played it so much) and the in-game command list is only partially complete as I've been focused on the room-generation code as of late.

In terms of content for the text-adventure it has:- Three distinct, and fairly balanced playstyles = pure mage, pure melee, and the stealthy assassin, which I've tested thoroughly and each are viable in both early and mid-game (unsure of endgame as I've not built it yet). The game allows you to also create your own playstyle if you don't like these, but these are the ones I've built and been able to test to ensure they are balanced (balanced in terms that each has their benefits and flaws, but each can do early game, and mid-game with approximately the same level of challenge). Any playstyle can use any item, can cast spells, and can perform any combat action, but different styles have different item requirements to make them successful. What I mean by this is that, if you want to be successful at pure mage, you won't use armor or shields, as every point of protection from them, increases your spell costs, to name one example.- Two sections of the dungeon (each section is 3 floors) are built, with a boss fight for each section and powerful boss loot as a reward if you kill them.- Multiple combative-ways of handling encounters... or you can decide to just flee a battle instead; if its the first round, you can flee without them noticing as well.- I've decided upon the story, and I've decided upon how it will be portrayed to the player. - Unique room generation, so that each room is interesting, with both fluff to build the scene and some interactables that have the possibility of loot but also the possibility of danger.- You acquire experience to gain character levels, that only increases specific attributes (dependent on chosen race) and HP/MP. You also acquire training for attributes by succeeding at tasks, but more from failures (the idea that people learn more from a failure than a success) and once had enough training, an attribute goes up. - You acquire soul shards to be spent at the Celestial (think of soul shards as a currency like in dark souls and the Celestial as a divine being equivalent of Vulgrum from Darksiders) Can spend soul shards on almost anything except for XP for character experience. So if the RNG hasn't favored you, you can mitigate it by purchasing things like spells or training.- The goal of the game is to reach the bottom most floor (with a level design somewhat reminiscient of Diablo 1, with different sections underneath each other), and defeat the Chaos God. You can encounter avatars of this diety called Chaos Primals; they give great loot and great character XP, but can drain your experience points and every one killed, makes all future ones that much nastier.

This is the game in a nutshell. I'm hoping to, after I complete the room generation code for the current levels (the new room generation code is functional for LV 1 and 2, but not 3, 4, 5 or 6 yet), to complete the command list (ingame) and then post a build of the game here for people to muck around with. I'm finding playing my own game and developing it, is both quite enjoyable... well, it is when the code does what I want it to do and not skip sequential steps (grumble grumble grumble).

=====

Adversity is understandable. Cynicism with multiple failed projects, and no game developer houses picking up the game after years and years, can definitely rub people the wrong way. And when some look promising for a time, and then the developer never shows pictures or actual code from these new projects that pop up for a time, and then the developer of it disappears from the forums permanently, can definitely make some people feel jaded to the point of... "Great, another project is here and my bet its going to be gone in 6 months time... lets not get our hopes up, like we did for the last 10 projects!"

I would like to return to my Outpost-like game in the future, but right now I am full-speed ahead on my text adventure.

Not using source control. The code is mostly built within the interface, so unless you know the interface, it can be a bit difficult to follow/trace the variable. I know, from working with my code a lot, where variables come from, and know the calculations performed on them, so I can follow my code quite easily, but I could definitely see how it would be problematic for others to read.

The game engine I'm using is called Quest, and allows you to do it purely within the interface, use JavaScript ( I think its JavaScript at least) exclusively, or a combination of the two. However with that said, it has its annoying quirks and certain bits of code doesn't work precisely as I'd expect, having self-taught myself the basics of C++. For example, in C++, if you have two code blocks, ie an if statement and a while loop, in C++, you expect that it will finish all the code within one block first and then move onto the next block of code. In Quest, sometimes it will do so, and sometimes it will only implement half a code block, move onto the next code block, and then complete the other half of the code block of the first. This makes a lot of different things that require a sequential conditional sequence of events to go out of sequence and cause all sorts of headaches. Its a pain, but otherwise most of the time things go according to plan and I have made workarounds to this weird skipping of sequential steps... in most cases at least.

Technically you could take a look at the code by hitting code-view in the UI to see what it looks like in the code, but I don't have that stored in a SVN or other kind of source control. My code is easy for me to read, but as I've had to make a lot of workarounds to failings with the Quest Engine, it would have a lot of practices that most seasoned developers would avoid. As an example, the way custom functions are called and return with a value is very different from C++, but in-engine functions like getrandomint(1,3) [chooses a whole, integer number between 1 and 3] function much like pre-built c++ functions. Its very strange... and thus I have a huge number of nested if-else statements, switch statements, and loops, instead of custom-function calls. It really irks me, but as I require things to occur in a very specific sequence of events, the only way I've found do so within the Quest engine is to use massive numbers of nested if-elses, loops, and switches. Its very hard to do procedural abstraction or separate code into human readable chunks, in the Quest engine... which is probably why I've not seen any major game come out of it before.

So, I'm happy my game works the way it does, it just doesn't necessarily look pretty under the hood. However, as I said before, I've worked with my code a lot and know how to trace my variables so the dirtiness of the code has no impact on my ability to add/remove things, or refactor the code base... within reason of course.

Now if people are desperate to see it I can upload it in its current state and just post a list of commands here, or people can wait until I clean things up a bit (as the adding of the room generation was a major refactor and should remove the old, unnecessary code and complete the refactor before releasing a public build, yes?) and release in hopefully less than a week.

Interesting project. Maybe a moderator can split this thread into a new topic.

Quote

In Quest, sometimes it will do so, and sometimes it will only implement half a code block, move onto the next code block, and then complete the other half of the code block of the first.

This might be due to the asynchronous nature of many JavaScript methods. JavaScript isn't threaded, so to avoid blocking the main thread during long running operators (like network fetches, disk reads, etc.), many methods have a completion callback. If you have an example of where this behaviour occurs, perhaps we could take a look and see why.

A related topic would be JavaScript Promises. They're fairly new to JavaScript. They have a way of allowing asynchronous code to be made to look much more synchronous. They're especially powerful when combined with Generator functions, and the new "await" keyword.

Edit: Btw, I'd like to see some more web developments skills being developed within the OPU community. Having an active JavaScript based project could be good for that, even if the project itself was not web development.

Splitting isn't a bad idea, actually. Not sure where to make the split. Lordpalandus, this is your thread -- if you'd like a split let me know and link to the first message to split at and it will be done.