Time for a reality check...

Hi all.

I've been working for about eight months now on a proof-of-concept for a game that I call Goliad. I've done this because, like probably all of you, I think that I have some good ideas, and I want to make a career out of selling those ideas. I don't really care if that takes the form of independantly selling my own game, or working for a (humane) studio.

Goliad was an ambitious for a first game: it's an online-multiplayer RTS, and at the time that I started I had the equivalent of highschool programing proficiency and maybe twenty hours in Unity. I intentionally went with a very difficult genre so that I could learn as much as possible as fast as possible. There were a lot of amateur-level hurdles that stopped me for days. There were times when progress seemed unimagineable. Yet somehow I just kept finding solutions. You guys, on these forums, deserve some credit for that. It became an article of faith that I would overcome the obstacles, not a well-reasoned belief. I am still very much an amateur, and so progress has been SLOW. I'm proud of what I've accomplished, but I wonder whether Goliad is something that a real game developer could have whipped up in just a week or so.

This is where you come in: I need a reality check. I can't justify continuing at this pace if my product isn't going to impress any hiring managers or investors. Here are links to the current version of the game, and instructions for playing. Read the instructions! Goliad is a pretty quirky RTS, and you will probably be confused if you jump right in. All assets are placeholder; one of the reasons I'm posting this is because I'm trying to determine whether I should move ahead comissioning art.

As a game, Goliad is supposed to be fun in a way that RTS games usually aren't. As a representative of me, it's supposed to show that I am most valuable as a source of game mechanics. But I can't get outside my own head and answer the question of whether it actually pulls that off.

So, does it? Or should I postpone those dreams and take any ol' job?

 

can you post small video clip of the gameplay? (for easier feedback)

 

You're right, I should do that. I'll see to it.

 

What do you mean by that?
You are asking, if you going to make money of your game?
If so, there is 0 guarantee. You may make some, or you may make near to nothing. Pure guess at this point.

 

They mean use this to get a job Which is much more realistic

EDIT: OP btw, online ANYTHING as a first project is a bad idea. It already sounds massive in scope (rts and strategy are not easy, and even if you get mechanics working you will have a hard time balancing).

Why not take what you have learnt and make something new but this time scope small. Small and high quality, not large and impossible - that is the key to finishing projects on your own

 

There's a big difference between developing the design of a game and implementing it. Any good programmer can put together something very fast when they know all the parameters they have to deal with.

I have found that by far the biggest challenge in game development is game design. Fun, balancing, the correct economics of things. Going by the vast majority of indie games (some of which are technically very impressive) this is by far the biggest killer of indie dreams around. Not even lack of marketing comes close.

The reason why most games go on for years and years is not because they needed that long for the code to be typed in, or for the technical aspects to be learned, but because it wanders around in circles endlessly searching for the moment when everything suddenly becomes fun (which often never comes).

That said, if you are looking to get hired, you must understand whether you are aiming to get hired to build games from specs, or to create the fun. Any reasonably skilled programmer can do the former, very few can do the latter. And one game is not enough to prove that you can create fun from code.

So if fun is your vocation, don't look at how complex the game is, in fact the simpler the better. Fun is like a melody, when you get there it's very simple, but getting there can take a long time. Look at it in terms of quality, not quantity.

 

A little bump because I added a video for those who don't want to download and play the game. Sorry about the quiet audio.

If you, or anyone else, can show me the path to showing that I can be the one who makes the fun, (assuming I do indeed have that ability), I'd be eternally grateful to be shown.

 

You got definatelly something working there.
For me recording sound seems fine.

Now regarding fun.
Could you describe in more details, the fun factor in your game?
How you try to make it fun in other way, than typical RTS.
Answering this question, may help you to define, what direction you should head on.

 

I don't really have much experience with hiring or being hired based on demos, so take what I say with a grain of salt.

The video that you posted just looks like a few little icons slowly moving around on a map. The way you introduce the game is somewhat confusing because you are defining the gameplay by explaining how it's different than some hypothetical game that I may know nothing about. You are trying to narrate what is happening also, but it's hard to follow since I don't have a good overview of how the game works (I have no idea why you'd want to turn a perfectly good sheep into a pile of light bulbs, for example ). My sense is that you've put a lot of thought into the simulation, but it's going to go unappreciated if this is your demo.

If I were you, I would now focus on making the UX more visual, so that you don't actually need to explain anything. Let it be self-apparent to the user (and your prospective employer) exactly what is happening just by watching. Even if you put a lot of effort into writing a good pitch, I think most people will have already made a snap judgement before you even finish talking.

 

The impetus for Goliad is this observation: that when people talk about strategy games, the discussion never turns philisophical. There's no "art" to the war. I think this is because most strategy games acknowledge that player attention is a resource to be managed, but then they go and do the wrong thing: typical RTS games give players A LOT to think about, and challenge the player to pick their mental battles. Queue those factories; add more generators to meet demand; retreat the wounded units; queue a firebase construction; use this unit's special ability; use that unit's special ability. None of these things are really "strategy," and so when people debrief about their games, it's often about how they interacted with the meta of the game and with their own units, rather than an actual battle of wits with their opponent.

To change this, I had to change the nature of the game. I tied units, territory, and resources into a tight continuity, so that one thing becomes surpreme: presence. It's less about what resources are and more about where they are relative to your opponent's recources, which you can always see because there is no fog of war. Goliad is fun because it has the emotional appeal of turn-based games: players primarily play against each other, trying to anticipate, bluff, and counter. But Goliad also retains the emotional appeal of conventional RTS games: there's a sense of reality, there's some time pressure, and there's the plain ol' excitement of watching things fight, not knowing for sure which ones will win.

That's my attempt to explain the fun of it. I hope it made some sense.

 

I highly recommend uploading this game to Itch and then submitting this post to as many relevant subreddits as you can think of. Posting here is a good start but ultimately you want people who are fans of RTSes to play the game and comment on it. Plus you can use Itch as the site for the game when submitting it for hiring purposes.

 

I am not sure, if I get your point of view on RTS game. Maybe I completely misinterpret your description.
Sure, there are tons of RTS games and different kinds. Some more resources oriented, other more militaristic, or micro management.

I picked up random vid from 6 vs 7 multiplayer zero-k

In this one, there is pretty much 40 min stall, based on two teams choices recon, planning, attacking and cooperating.
Only two types of resources, metal and energy. But output of metal, is strictly tied to energy income.

I need to ask, how this differs from other RTS games?

Starcraft series for example, has depleting resources, minerals and gas. You need to move, or otherwise will end with insufficient resources.

Or Civilization series, where resources location matter so much, to progress.

Sure your game is different and that is good thing.
But at current state, I still can not see the fun factor yet. Maybe simply is not for me.
I even gave few min play. As far I see, is just about planing and organizing things.
Which is what RTS is about.
But that's it so far.
Personally for me, it is far too slow at given version.

Just don't get me wrong. Keep working on it.
I just giving you my point of view. Maybe will give you an opportunity to think about things. Thats up to you of course.

Maybe I will check out in few later iterations.

 

I uploaded it to Itch just a few minutes after poster here.

 

Take this all with a giant grain of salt. It's just my opinion, and while I have released games, hired people, run projects, managed teams and so on I'm still just one person. Other people will have a range of opinions or reactions to your stuff, this is just one of those.

You asked for a reality check. For me the first red flag is in the first sentence:

Eight months on a proof of concept?

The purpose of a "proof of concept" is to quickly make something to test and/or demonstrate an idea. So, assuming that you're using that term as it is intended, my first "reality check" is to point out that 8 months is too long.

However, if by "proof of concept" you really just mean "demo" then don't let the above concern you, especially considering that it's also a learning project for you. Your first few projects will take ages because there's just a heck of a lot of stuff to learn. As long as you're progressing your knowledge and experience don't sweat the other stuff.

I use this example a lot, but here it goes again: I wouldn't try to sell concert tickets while I was still learning to play guitar. I need to get genuinely good at it before people will pay to hear me play.

You say you're learning game development as you go, which is a perfectly alright thing to do. But considering that you're still learning, and that this is your first project, do you feel that your expectations and goals here are realistic? I completely support being ambitious and stretching yourself, but the stretch has to be reasonably achievable.

[edit]My usual advice to people is to make a few small projects to start out. It doesn't really matter what they are, just go through the process of completing something so that it's ready for commercial release, and then getting it out there. The stuff you learn from completing small projects will save you time and effort when you get to large ones.[/edit]

What do you mean by a "source of game mechanics"? If you're talking about being a lead designer then another reality check is to realise that role is both incredibly rare and very competitive. There isn't a shortage of game mechanics, and many people want to create them. The hard part is testing them with audiences and seeing which ones stick, and then iterating from there to iron out the design and how they interact with the rest of a game.

Next, coming up with mechanics is a tiny part of an overall game's development. If you want to get a job or attract investment then you need to also show that you are valuable in the rest of the game development process. If you want a job or investment that means you want someone's money, and generally they'll only give it to you if they believe you can make more for them in return.

Which brings me to the presentation of your game not doing you justice. I watched 30 seconds from various points in the video before moving on, because nothing grabbed me. I'm not watching a 12 minute video because there's a lot of other stuff competing for my attention. Or at least, I'm not watching it unless something in the first few seconds grabs my interest. Two bits of advice there. First, look into the idea of an "elevator pitch". That's something you can say or write which draws attention to the most interesting part of your project in just a few seconds. If you don't grab someone's attention immediately it doesn't matter what cool stuff comes later. They won't be there for it.

Second, work on your graphics. I know that's a superficial sounding thing to someone who's interested in mechanics and interactions, but it matters to your audience so it has to matter to you. You don't need to be an artist or graphic designer yourself, but you should show enough awareness as a designer to take the first steps towards presenting your work in a manner which works for your audience. You're not making Dwarf Fortress or Harpoon, so the early 90s aesthetic is unlikely to sell your work effectively.

 

The only point to a game/demo is to get a foot in the door when you don't have a resume that would otherwise get you a foot in the door. What is going to shift the needle here:

1. An actual released successful game, but you probably aren't going to get there
2. A really cool demo, one of those things that make people go 'wow' and gets shared all over reddit/twitter/etc
3. A good released game (that isn't commercially successful), no less than effort than 1, but at least you can control this
4. Other stuff

1 is pretty much guaranteed to get you a foot in the door, and 2 will probably work at at least some places, by 3 your actually far from guaranteed that it will get you anywhere, and at 4 you are basically not helping your cause at all (most people are going to have some kind of similar game/demo/experience even if techncially yours is better, you probably still need the demo to compete but don't expect it to help much).

As @angrypenguin mentioned polish is by far and away the most apparent thing in your game/demo.

One other point to mention is volume. I expect its better to have 5 short tech demos/games, showing different ideas and techniques, rather than one big 'opus'.

 

Interesting set of concepts but maybe could do with some additional features...

• Power grids, power stations and lines that give instant access to energy but can be destroyed.
• Walls and rocks, destructible terrain features that block movement.
• Static ranged defence points.
• A variety of Units with a range of stealth, speed, armour specs that make them more suitable for different strategies.
• A precious resource slower to process but with higher energy yields driving resource wars.

Also it's very easy to make a 3D world and models in Unity which could add a lot more strategic depth to movement and improved visuals to your game.

For example here's a simple RTS game I made in a few days with Unity Simple RTS by Arowx (itch.io)

 

It sounds like you are describing Creeper World, which is definitely an inspiration for this project! Except for your first bullet point, all of these things are planned in some form.

 

Thank you for giving my game a play! I think you'r the first person outside my friends and family to play Goliad. I think that my description does a poor job of getting across the fun of the game's economy. Let me try again:

Yes, resources deplete, so some movement is needed. There are two things that make Goliad different from, say, Starcraft. The first is aesthetic: rather than having to control resource "nodes," it's the ground itself that is depleted. Subjectively, I think that this makes the game feel more real to players, in the sense that they engage more with their territory, emotionaly. Second, resources are abundant enough that harvesting opperations can be set up pretty much equally well in any part of the map. This means that the desireability of a location has much more to do with where allied and enemy forces happen to be, rather than what's actually at that location. Subjectively, I think that this makes players engage with each other much more. It like how in chess the middle four squares are considered "good" locations to occupy, but their strategic usefullness is an emergent property of their location, not a product of any mechanical or quantitative differences.

Thanks for prompting me to think about this. Succinct, convincing descriptions of the game's appeal are something that I'm still developing. I hope the above worked but, again, the title of this post is "reality check," so one of the things I'm trying to work out here is whether I'm just imagining these qualities.

 

I think the question you should be asking is "Since you played it, did you find it fun? If yes, why? if no, why?". If you have to explain why its fun, chances are its failed. Basically do some user testing as mentioned in earlier posts. Rather then plonking down chunks of text (Read the instructions), also try to do a tutorial? This will help you iron out and summarize your own ideas. Few people even read the manual for anything these days unless absolutely required.

Other then these few comments, i agree with angrypenguin.

 

When I'm filling a team I have a list of skills or experience which I must fill, and I'm looking for some combination of people who a) cover each of those items and b) have solid potential to work well together.

With that in mind, I see little or no difference between items #1 and #3 in terms of demonstrating the value of a developer to a team. For a producer or product designer yes, having a bunch of commercial successes under your belt would be great, but for any sort of entry level or general developer role? I wouldn't care. And if someone has had real commercial success they don't need to apply for the entry level ones anyway.

If you can show me some commercially released stuff and be conversational about what your intent was, your thinking behind the design, how you went about building it, the unique* problems you ran into and how you solved them, then I'm sold. I don't really care if it was commercially successful or not because someone else on the team is responsible for that. All you have to do is build it well enough that other people will put it on their storefronts, and you've got solid evidence that you can do that.

* I say "unique problems" because I want to see that you can do stuff that doesn't come from tutorials. Ie: you can solve new problems for yourself, even if they're simple ones to begin with.

 

I think, and of course it is only an opinion, that companies would be hiring people who did 1 for their name, as much as their ability. For an indie hiring someone with 100k twitter followers is a big deal. For a big company its not a big deal, but I'm sure they like the optics.