ID:99634
 
Keywords: design, mrts, strategy, update
I've picked up on my Mini-Real Time Strategy (MRTS) game again.

Updates:
- Made significant revisions to the design document which I may release with the game.

- Added assets (animations and various states) for five buildings and each building has anywhere from 5-10 states so it was a fair amount of work.

- Re-factored the waypoint system.

What's Next:
- Finish the remaining building assets of which I have 3.

ts

[EDIT] - For fun, I'm going to start providing a summary/history for people to reference if they want to see a full progress report.

What is MRTS?
- It's a mini RTS game where you build, gather resources, build an army, expand, defend, and attack. While it sounds your like your typical RTS, it does have a number of interesting features that will let it stand out from the rest. It currently supports up to 4 players along with customizable AI.

How far along is it?
- Core engine: 70%
- Assets: 45%
- Polish: 20%
- AI: 10%

History:
MRTS Update #16
MRTS Update #15
MRTS Update #14
MRTS Update #13
MRTS Update #12
MRTS Update #11
MRTS Update #10
MRTS Update #9
MRTS Update #8
MRTS Update #7
MRTS Update #6
MRTS Update #5
MRTS Update #4
MRTS Update #3
MRTS Update #2
MRTS Announced (#1)

I see now why I was offending you with my recent comments RTS are a few hours work. From the sounds of things, your project is a lot more ambitious than what I was thinking of when I said that.
Geldonyetich wrote:
I see now why I was offending you with my recent comments RTS are a few hours work. From the sounds of things, your project is a lot more ambitious than what I was thinking of when I said that.

heh... It may have been the one line that declared both the RTS and tower defense games as trivial and from personal experience, I know that both can be quite involved even if they are generic clones. :) That or I'm a total dolt which is totally feasible but you will have to prove me wrong before I accept such a title.

ts
I was thinking along the lines of rudimentary, unbalanced, ugly, bare functionality when I wrote that.

Add a verb to a turf to create a tower. Code a tower that perpetually watches for enemies and shoots at them. Use a pathing library (of course I wrote one so that's a done deal for me) to path a creep to where you're trying to stop it to go. Throw in a base scoring/game flow handling mechanism, and that's only a few hour's work.

Making a reasonably sophisticated, balanced, good-looking, fully functioned tower defense game would take significantly longer. Weeks on the inside, if you know exactly what you're doing (Lord knows I never do) and are fully leveraging BYOND and the right libraries.

The reason why I mentioned that in the first place was because I was talking about how it's relatively easy to put together a slipshod product leveraging what BYOND already gives me as opposed to putting together something a bit more interesting.
I revisited a lot of my old posts after appending the history. There were a couple key goals in the project that I lost sight of.

#1. Try to design as you go and prove that it is in fact a horrible idea.
#2. Take an AI driven design approach and then plug the humans in.
#3. For better or worse, open up my design process and treat it as a shared learning experience.

I'll need to spend some time reflecting on each of these original goals and see if they still make sense. I should also reflect on why I feel differently about it now if that ends up being the case.

ts

Tsfreaks wrote:
#1. Try to design as you go and prove that it is in fact a horrible idea.

I'm not entirely sure what you mean by this, but if the alternative is "try to design the entire project before starting on the implementation", I think you'll have much better luck designing as you go. For a project of a reasonable size you cannot expect that you'll be able to see, before you've started work on the project, all problems that will come up and how you can design ways to deal with them. You have to expect to do some designing as you go.

People put a lot of emphasis on design but it's not as important as you might think. We're not building skyscrapers, we're writing programs. If builders lay the foundation for a building before the rest of the building has been designed, they couldn't possibly know what kind of foundation to make. Do they need to support a 10 story building or a 30 story building? Builders work in a physical medium: if they make the wrong type of foundation it can be very costly to change. This physical nature of the project also limits how they can work on it: the 4th floor can't be completed if the 3rd floor doesn't exist yet.

Engineers have mathematical methods that can be used to determine how a building needs to be constructed. Things can be planned in advance because the mathematical model isn't going to change. Your computer game is a work of creativity. Once you see some parts of the game in action you might want to change others. Having a "complete" design before you get started might prevent you from coming up with good ideas. Unless you've got some awesome concept like Tetris, you should always be thinking about ways that the game's design can be improved.

For your RTS you might decide that units can either walk or fly and will have ranged attacks that are either handled like bullets or missiles. That's all you need to know to start writing code. You don't need to know how the units will be constructed, what they'll look like, how much they'll cost to train, or what their names will be. You should put more thought into a game than "I want to make one" before opening Dream Maker, but you don't really need much more than that to get started.
On one hand, I want to say that, "actually, I am trying to program skyscrapers."

On the other hand, I'm wondering how much of that is me attempting to compensate for lack of decisiveness.

Design as I go, I encounter some insurmountable hurdle down the line that was a result of not thinking the idea through. When you've painted yourself into the corner, designing on the fly involves destroying walls to continue.

Force myself to design before writing the first line of code, I encounter an inability to visualize the whole of the thing. The result is paralysis, nothing gets done.

Perhaps the newbie developer (a label to which I include myself) does the former until they foster the ability to visualize adequately to realize the later.
Geldonyetich wrote:
On one hand, I want to say that, "actually, I am trying to program skyscrapers."

I didn't use skyscrapers just for their grandness. I used them more because of the rigorous design methods that exist. You tell an engineer the parameters (what you're building and what forces it needs to withstand) and they'll tell you what material to use, what bolts you need, and what amount of torque needs to be applied to tighten everything so it doesn't fall apart. This makes it possible for a skyscraper to be completely designed before construction begins.

Creating software is less mechanical of a process, especially creating games. Because of this there aren't equivalent design methods. Games also have a goal above just functioning, they should be fun. You might design a wonderfully functional game, have some people come to test it, and discover that it's horribly boring.

Perhaps the newbie does the former until they foster the ability to visualize adequately to realize the later.

I think that's accurate, but I also think the goal is to realize what balance of up-front design and on-the-fly design works best for you and your projects. I think the key is in what motivates you. Some people get really excited by having a complete design, some people get excited by seeing their game in action (even if it's incomplete). Ultimately you don't want to waste time. You need to do some amount of design before making something so you make the right thing, but sometimes you need to make something to know it's what you want.

To use some of my own development as an example, you can create a basic sidescroller once you've decided to make a sidescroller, even if you don't know what it will turn into. Being able to see something up and running can motivate you to keep working, it can even give you new ideas. I was originally going to make a game where you play an astronaut and explore planets (screenshot), but I didn't like that idea, so I went with a mining game instead.

If I had designed a complete planet-exploring game just to realize a couple of days into the implementation that I don't like the idea, a lot of time would have been wasted. By working on the implementation I had something to play with, something I could see. I didn't like the idea so I changed my mind and was able to keep a lot of the code. The reverse scenario could have occurred: I might have decided to make a mining game, implemented water physics, digging, and cave ins, only to realize that I'd rather make a game where you play an astronaut and explore planets. In that situation a lot of code would have been wasted and I'd lose a lot of motivation.
I think my problem is I've got about 8 projects worth of wasted motivation.

It's reached the point where I'm thinking to myself that I really want to avoid doing that again, so I absolutely must have a finished design ready...

... but after months of paralysis, it seems to me that this approach isn't quite right either. I need to change my approach.

Perhaps (as some have recommended) start building libraries. Write parts of games in modular code that, eventually, I can fairly effortlessly put together a game by the sum of the parts.

Perhaps completely shake this idea that it's wasted motivation, and simply accept that the majority of the work I do is just going to be a part of the journey.
Geldonyetich wrote:
I think my problem is I've got about 8 projects worth of wasted motivation.

It's reached the point where I'm thinking to myself that I really want to avoid doing that again, so I absolutely must have a finished design ready...

... but after months of paralysis, it seems to me that this approach isn't quite right either. I need to change my approach.

Perhaps (as some have recommended) start building libraries. Write parts of games in modular code that, eventually, I can fairly effortlessly put together a game by the sum of the parts.

Perhaps completely shake this idea that it's wasted motivation, and simply accept that the majority of the work I do is just going to be a part of the journey.

Well, I think that the general rule should be, if you can't design the whole thing (like 95% of it) before doing it, don't do it. At least, don't do it all at once.

If you set your goals small enough so you can design 95% of a demo/game/prototype/example/library before starting, a couple things will most likely happen.

- You will finish things
- For everything you finish, most larger projects become a little easier to design and build.
- You will build an arsenal of resources so when you do attempt a larger design, you already know and have completed portions of the design.

The trick is figuring out how to take our grand ideas and convert them into sub-[demo/game/prototype/example/libraries] which are still really exciting and fun to make.

After all these years... I am still amazed at how much goes into a simple game and I continue to raise my level of respect for game makers even if their game totally sucks. Its still a lot of work to make that much suck. :)

Anyway, I don't disagree with digging in and trying things out. The pattern with larger projects (which is hard to gauge sometimes) is that you make it part of the way and then some overwhelming wall of "need to have" complexities come crashing down on your soul.

We recover by thinking of new things (distractions) without those complexities but then those new things eventually hit the same thing. :)

We repeat this process and every once in a while we break through some how and prevail. We should really document that event when we think it is happening.

For the record, I have lots of little ideas but I constantly bounce between my core projects and I do make progress but its taking years now which amazes me.

I need to go small.
ts
I agree, when KISS applies all of a sudden I know exactly what needs to be done suddenly I've the motivation to do it.

But overcomplexity is not my only hangup. Oh no! I want to make my games epic. Thus, when I near completion of a KISS project, I lose motivation simply because this isn't what I want to make. That's pretty much what happened to Mecha Game Framework.

Come to think of it, though, it's not so much that I want an epic concept so much as a unique concept, and along these lines, KISS is not incompatible...
Geldonyetich wrote:
Come to think of it, though, it's not so much that I want an epic concept so much as a unique concept

I guess this is where we are different. You seem to focus on the uniqueness of the concept, but I gave up on uniqueness a while ago. Part of my reason for saying this is my inability to come up with unique game ideas, but I'm also a firm believer that uniqueness is overrated. I'd rather a game be fun than unique. If the game is fun people will overlook the aspects in which it isn't unique (but if it's not fun people won't care how unique it is).

Truly unique game concepts are hard to come by. Tetris is the only one I can think of (as far as video games go, at least).


Tsfreaks wrote:
Well, I think that the general rule should be, if you can't design the whole thing (like 95% of it) before doing it, don't do it. At least, don't do it all at once.

I disagree 100%, or at least 95% =)

Could you explain what you mean by "design", or post an example of a design document for one of your projects. There are different levels of depth you could go into. A design document might list what types of objects exist, what procs and variables they contain, what they do, how they're used, how objects relate to each other, etc. For a game there are even more issues.
No argument here that a game has to be fun. However, I find the novelty of a unique mechanic to be a good means to get at that fun. That's not to say that this is the only means, however.
Geldonyetich wrote:
No argument here that a game has to be fun. However, I find the novelty of a unique mechanic to be a good means to get at that fun. That's not to say that this is the only means, however.

I think uniqueness is one of the harder ways to make a game fun.

I've played almost all of the games on jayisgames.com. A lot of the games are sidescrollers or puzzle games with a unique twist. The games are fun for a little while but are completely forgettable. Fault Line has a gameplay mechanic I haven't seen before, but I didn't like the game. I played for a little while but lost interest and haven't wanted to play the game since.

eyezmaze.com has some incredibly unique games and I hate most of them. The grow concept is neat at first, but quickly loses its novelty and degenerates to trial-by-error.

I guess this is also why you favor design and I favor implementation. You don't need to see the design in action to determine if it's unique, but seeing it in action helps to determine if it would be fun.
Forum_account wrote:
I guess this is also why you favor design and I favor implementation. You don't need to see the design in action to determine if it's unique, but seeing it in action helps to determine if it would be fun.

True enough and, on top of that, fun is subjective. Me, I've been playing games too long - I have a hard time enjoying anything that I've played to death somewhere before. This is a large part of my motivation to push the envelope - I'm creating new types of games because they're harder to find.

Truth be told, it's not that I'm so much going for something radically different, it's more like I'm just trying to advance the state of things. A lot of games seem to stop short to me, there's a certain something missing I'd like to find.

I haven't really tried hard enough. It's probably because when my nose is to a code grindstone for a week or two, I lose perspective. This is one reason why it's handy to have a design finished before you start coding, because you're disengaged from the inner workings enough to ponder the big picture. That's not to say you couldn't do it later, but you'd need to take a break from the coding, say a day or two. Funny enough, I usually have a radically different idea to pursue if I wait that long.