Welcome, Guest. Please login or register.

Login with username, password and session length

 
Advanced search

1411275 Posts in 69323 Topics- by 58380 Members - Latest Member: bob1029

March 28, 2024, 04:26:12 AM

Need hosting? Check out Digital Ocean
(more details in this thread)
TIGSource ForumsCommunityTownhallForum IssuesArchived subforums (read only)CreativeDevelopment Without Programming
Pages: [1] 2
Print
Author Topic: Development Without Programming  (Read 4250 times)
Artifice Machine
Guest
« on: August 26, 2014, 10:33:25 AM »

I have this idea of developing every aspect of a game except for any programming, which would be done afterward and by somebody else. Design, artwork, sound, and writing would be entirely completed first. Design documents would be formed with programming in mind for clearer translation during the programming phase. Level designs would be saved as single images using the completed graphics. Once finished, all resources would be shared with a programmer who would then bring the game to life. Personally I no longer want to program, but am still very much interested in developing my designs. Thoughts?
« Last Edit: August 26, 2014, 11:51:17 AM by Artifice Machine » Logged
Belimoth
Level 10
*****


high-heeled cyberbully


View Profile
« Reply #1 on: August 26, 2014, 10:56:43 AM »

Hahahahahahahahahahahahahaha
Logged

Belimoth
Level 10
*****


high-heeled cyberbully


View Profile
« Reply #2 on: August 26, 2014, 11:02:49 AM »

Serious answer: All the disciplines are intertwined in game development; even if you can manage to design a complete game without a coded prototype, you'll still have to do some sort of pseudo-programming to figure out the nuances unless you are just decorating an already existing game. Without programming of any form you're ignoring many many many integral details.

It sounds like you're trying to creatively distance yourself from the programming part of development as much as possible so my advice to you would be to find someone to work with who complements your skill set and/or look into game creation environments that make a lot of programming decisions for you, such as Game Maker or Construct.

Your assembly line idea is bad, but you should not feel bad. I get it. Programmers like to try to do the opposite thing too, where we use all placeholder art and levels and expect things to fall into place when they're finished after the fact. It doesn't work out without at least considering the thing as a whole first.
« Last Edit: August 26, 2014, 11:10:04 AM by Belimoth » Logged

Artifice Machine
Guest
« Reply #3 on: August 26, 2014, 11:43:31 AM »

I suggest this method though as somebody with enough of a concept of programming as to design a game knowing what sort of programming would be required, and then incorporate that information into the design documentation. Knowledgeable communication would be key here, I think making this a possibility. I'm not sure sort what programming details you're referring to, and why they would likely be ignored.

There's less risk for the programmer to become involved in a project if so much is already done, and during this programming phase they would not have to deal with any delays except for their own, aside from maybe a handful of minor adjustments.

I've edited my first post to include some of this detail.
Logged
SimplyRivet
Level 0
**



View Profile
« Reply #4 on: August 26, 2014, 12:07:03 PM »

The problem that this will run into is that there will be something that you will miss. It could be that you need an extra animation that you didn't realize. It could be that your programmer can't quite understand what you are going for. Or more likely, it could be that your design just doesn't work the way you thought it would.

The major problem with this strategy is that you never prototype your game. You never test if the game works. Even if you think you've got the perfect idea, the instant that a player sits down in front of your game, they will find holes in the design. This has happened with every project that I've been a part of.

What will you do with the art you've created if you need to change it? What happens to the level designs if they didn't work how you thought they would? How are you expecting to communicate with you programmer when from your perspective you're finished with the game?

Now, this could work with the right people, and on a small enough project sure. You just need to be prepared to make massive revisions on work that you did months ago.
Logged
tieTYT
Level 2
**



View Profile WWW
« Reply #5 on: August 26, 2014, 03:17:02 PM »

So... like... the waterfall model
Logged

Belimoth
Level 10
*****


high-heeled cyberbully


View Profile
« Reply #6 on: August 26, 2014, 09:11:00 PM »

I'm not sure sort what programming details you're referring to, and why they would likely be ignored.

There are two scenarios here:

a) The design document misses details essential to implementation. The project creaks and groans under a poorly thought-out production strategy.
b) The design document has all the necessary details. This is literally programming, you're just typing it into the wrong thing.
Logged

oodavid
Level 8
***


Discombobulate!


View Profile WWW
« Reply #7 on: August 27, 2014, 02:10:21 AM »

I guess it depends on your game too, but I'd be tempted to mirror Belimoth's answer, in coding the game you will come across situations that could and in some ways should influence how the game is made. Most good programmers know this from experience, a rigid design document could be great for some programmers, but in removing the wiggle room you remove the enjoyment in being creative.

Many years back, in my naive youth, I worked with a very charming man who made me believe that his idea was fully fleshed out, his concept was great and I coded feverishly to create his vision. Every single issue or idea that I had was ignored and the project became a massive failure. The quality of my work was great, I still use some of the tools built at the time, but the problem was that lack of flexibility - I know he ended up hiring two other coders after me, and they failed in the same way.

In Molecule Match my coding conundrums have led to some great features that I'm not sure I could have planned from the outset.
Logged


Button up! - Out on Android and iOS

latest release: 13th March 2015
clockwrk_routine
Guest
« Reply #8 on: August 27, 2014, 03:16:49 AM »

I think this could be legit and I also thought about it.  tbh inorder to get funding for said projects, it doesn't seem you have to have gameplay at all, but show it, which could just mean mocking up animations of gameplay.  If you look at some successful and promising kickstarters for instance, a lot of them give the impression of something epic, an epic narrative/adventure gets told by cutting between various scenes, but what's between those scenes whoever's watching makes it up.  For all we know they just have a walking sim of a couple of areas.  Visuals sell.  It's alot easier to mockup animations of great gameplay than to actual implement systems to run them.  It's bug free.  It's mastering the illusion of having a lot of content with actually very little work put in.  It's a pretty feasible way to go for an indie imo.  And when you have funding the sky's limit, hire a programmer, you're then in a better position to actually release a game.  

I'm not saying it's morally correct, to pull one over others like that, but if the game gets made with what you promised through your mockups then I don't see much a problem with it.

I think there's a tendency to focus too much on implementation, to have something tangible, and overlook design because you already have this bull you're trying wrangle spread across various areas of development.  Visuals, design, and writing for me are very essential to realizing a game, but it's different for each project, such as if you're project centers around music and atmosphere and coveying feelings.  Programming is actualizing your vision, so it's perfectly feasible to see it as something you can save for later.  Vision and Design is a thousand sleepless nights. That sounds cool

nobody wants to look at a 100 pages of words, so don't pitch your ideas - you'll just get laughed at.
« Last Edit: August 27, 2014, 03:35:39 AM by keo » Logged
rj
Level 10
*****


bad, yells


View Profile WWW
« Reply #9 on: August 27, 2014, 04:04:25 AM »

this can work with caveats but it's a lot smarter to just work with a programmer from the outset

speaking as someone who can draw, animate, compose, write, and design but still cannot program in the least; here is some advice.

if you're ever in a position where you're hiring someone else to do something you can not assume that you have planned for all eventualities. communication breakdown is inevitable and if you aren't prepared to work with the programmer and probably make more assets/work for the game after handing it off to them then i don't even know what to say honestly
Logged

Milkybar
Level 0
**



View Profile
« Reply #10 on: August 27, 2014, 06:26:55 AM »

I think this could work for some special cases e.g. card games where you can prototype and playtest everything without needing to do any coding.

Having an exact specification of what to develop would in a way make the programming a lot faster and straightforward. I think the problem will be that no matter how careful you are in the specification there will always be details that need to be changed. Some things like the feel of how an object bounces around a level are just too hard to describe, you really just need to implement it and tweak until it has the same feeling you imagined.

If you really want to work this way instead of designing everything, make just enough art and design writing etc… that you can send it off to a programmer and get a prototype back. Then just keep iterating. At least you can play it and get feedback while its being developed.
Logged
hammeron-art
Level 0
**



View Profile WWW
« Reply #11 on: August 27, 2014, 09:02:08 AM »

Seems to me that you guys are confusing design planning and concept art with finished resources.
You'll only waste time adjusting and remaking finished work to fit yours programming needs.

Logged

Artifice Machine
Guest
« Reply #12 on: August 27, 2014, 09:24:08 AM »

Certainly, there would be room for creativity and revisions once programming starts.

I didn't mean to imply that creative decisions couldn't be shared. That sort of thing just depends on the particular people involved and their interests. It's better than trying to program some inflexible design because then the game has room to grow and the programmer becomes personally invested in the project. If a programmer is looking for a quick job for quick cash, they're probably not the programmer you'd want to hire.

Revisions would be handled over the entire programming phase. Although the game's resources have been made to a completed state already, that doesn't mean they and the design can't be altered at any time for the sake of a better game. Prototyping and play-testing would still have their places too, I don't see why they would be disposed.
Logged
CesarD8
Level 0
***



View Profile
« Reply #13 on: August 28, 2014, 09:07:31 AM »

In theory is a sound plan, like the dreaded waterfall model, the problem is that a lot of problems and changes occur while you are making playable prototypes; some things aren't as fun as you thought, others are just plain impossible to do and ideas pop up while you're playing the prototypes you're making. If you do follow the process you describe, a lot of the work you do would have to be redone, because maybe the sounds don't loop correctly, or the animations aren't as smooth as needed, or the assets are too big, etc.

One of the main characteristics of good videogame develop is the tons of iterations that you must do in your development, whether you follow a waterfallish pipeline or not, you will still have to do the iterations, the difference is that probably you will have to work more because of the adjustments you will have to do.

My recommendation is that even if you don't have a programmer in your team, do playable prototypes with what you can. Game Maker and flixel are very good options for making games and not knowing how to code, if you already know how, they are great for prototyping.  Grin
Logged

doimus
Level 0
**



View Profile
« Reply #14 on: August 28, 2014, 10:31:31 PM »

I have this idea of developing every aspect of a game except for any programming, which would be done afterward and by somebody else. Design, artwork, sound, and writing would be entirely completed first.

That's unnecessary waste of time and other resources, IMO. As any producer will tell you, even the best plans fall apart at the seams in the implementation phase. Look at big budget movies and how many script rewrites they go through. Or AAA games, which get redesigned and assets replaced n times before they are released.

So, unless you have time and money to burn, it will be wasted. Actually not really wasted, it will be part of "organic iterative development" ,aka the utter chaos!!! must sleep! nghh!! your project will go through in its development cycle.

So again, in indie mindset, first document should ideally be this: "I have a cool idea about a game, let's try it out!" and then go into iterative mode ASAP. Just to save you from frustration and expensive failure.
Fail soon, but inexpensive. It will hurt less too.

Quote from: Artifice Machine
Design documents would be formed with programming in mind for clearer translation during the programming phase. Level designs would be saved as single images using the completed graphics. Once finished, all resources would be shared with a programmer who would then bring the game to life. Personally I no longer want to program, but am still very much interested in developing my designs. Thoughts?

And this is just pure fantasy and rationalization on your part, NHF. Trust me, from personal experience, not only will you not find a programmer or finish the document, but you're most likely to appear somewhere else with: "I don't want to program or design or draw, but I have a great idea and I will find someone to make the best design and game ever!"

Work on your skills, develop those you're good at, delegate those you suck at, but don't rationalize failure.

There's a Sid Meier interview floating around where he talks about designing the original Civilization and how it initially started as a Sim City clone and then iteratively developed from that. Find it and read it.
« Last Edit: August 29, 2014, 12:58:11 AM by doimus » Logged
jtfjtfjtf
Level 0
**



View Profile
« Reply #15 on: August 29, 2014, 01:13:54 AM »

You can probably try to make a board game, card game, or miniature game. Although that's the tabletop gaming industry and not the video game industry.
Logged

wccrawford
Level 3
***



View Profile
« Reply #16 on: September 17, 2014, 08:57:54 AM »

For a prototype, I think this is perfectly fine.  Produce enough assets to make it happen, along with the docs describing how it'll work.  That will make it a lot easier to attract a programmer.  (A few times I've tried to work with a few artists, and had it fall through because they never produced any assets.)

For an entire project, though, I doubt this is wise.  Too many things will change when you find out what's possible or isn't, and what's easy or isn't.  You'll need different art, and the game will change direction. 
Logged
ActiveUnique
Level 0
**



View Profile WWW
« Reply #17 on: September 20, 2014, 09:11:15 AM »

hmm. besides programming this could be
like... designing a working game with a parametric GUI like Construct 2.
like... providing relevant art, music, story, dialogue
like... abstract documentation


None of that's necessarily programming, is it?

I'm not criticizing you, but I think you'll find the things I mentioned will also take as long as any programming for quality results.
Logged

I've read about the idea guy. Yeah, so, you should get a lazy team.
level20wizard
Level 0
**


Don't do memes


View Profile
« Reply #18 on: September 21, 2014, 11:57:46 PM »

Hmm... The way I am making my game, a lot of the cool little things I didn't think would be that important got pointed out in early development. My game was completely different at the start when I had written stuff down, but I added a feature that turned out not very easy to implement, and thought that it was really cool and could be the main mechanic. I still have the same story, characters and gameplay, but I really like to be able to change things as I go along. It also makes programming it a lot more fun when you just decide to do something random to see how it works out. I still have a "design document", which is basically just 80 pages of stuff I had written down for various things, so I didn't forget where the design was supposed to go.
Logged
kurismakku
Level 0
***


Will work for cat food.


View Profile
« Reply #19 on: October 09, 2014, 11:14:45 PM »

You should really try to learn programming, it's not really that hard.
Try with some easy language like ActionScript 3, and use framework like Flixel.
This is how I started, and following tutorials, I made my first game in 3 days.
Learning the basics of programming is really trivial thing to do, learning everything else is much harder.
So you will be able to make simple games, and then as you will improve your coding skills you will be able to create more and more.
If game is simple, it is much faster to design and code by yourself because you can iterate really fast that way.
Logged

Pages: [1] 2
Print
Jump to:  

Theme orange-lt created by panic