Starting a game company in SA

Comments

  • edited
    First of all, good luck with your project. ^_^

    My apologies if I've missed it having been posted already, but what sort of gameplay do you have in mind? RPG? Shooter? Strategy? Something else?

    As to prototypes, if you're planning on posting it here and unless graphics of significant quality are an inherent part of the gameplay you can always just use stand-ins, perhaps with text to identify anything that might be missed; the purpose of the prototype is to convey your gameplay, after all.

    If you don't mind my asking, why did you decide to make an engine of your own instead of using an extant engine? There are a fair few engines available these days, some even completely free.
  • edited
    Um. No.

    No no no.

    No.

    I'm tired of people offering good luck and advice on a project that's simply not going to work. Wishing someone good luck on a project that is a waste of their time is actually mean: You're wishing that they get demoralised and burnt at best, depressed and break up friendships at worst. That's not nice.

    @Max9403: Here's what's going to happen as you work on your project.

    1. You'll lose team members. People will simply not do the work you expect of them, this will be partly down to you not knowing how to help them produce stuff, you will give them really poor briefs (if any at all) and they'll get demoralised and quit. If you're lucky, people will quit before you all hate each other. Your team is too large and your work scope is not well defined enough for anything else to happen, especially if you're already blaming "slow progress" on people not giving you art.

    2. Your code will continually need to be refactored, rewritten, re-scoped and then thrown away. This isn't a dig at your coding ability (just like the above frustrations aren't a dig at anyone's artistic talents) it's just a direct outcome of your lack of experience with realtime rendering systems, game input loops, resource handling, network coding and interface development (to name but a few of the areas that I see your project needing experts in). You might think that this will help you learn stuff, but it won't - here's why:

    3. You'll learn incredibly slowly because you won't be able to give your stuff to anyone else to play. I mean, yeah, you'll give people some code that will log in to a server or will draw a quad. But nobody is impressed by those things, they don't see drawing a quad with the same glasses that you do, the ones that see the hours of effort you put into getting that damn thing working! So people won't help you get excited, they won't supply that push to help you get over stuff. I mean, you can already see it happening with @tbulford's response to your drawing a quad method: He's all "Oh, I don't think this is going to optimise well eventually" and that's a totally valid concern, it's just not a useful concern to you right now because you're not going to be in a position to understand what he's talking about for ages yet. And you're going to take longer to get to that level of experience by forcing your effort to focus on one mammoth, doomed project.

    4. Because it's doomed. Your MMO will never come out. It'll never even reach the stage where you and your friends can play it at a LAN. I'm not trying to be mean here, I'm just pointing out the reality of what happens when you stack obstacles in your own path without even realising they're obstacles. You have more pitfalls and project-killing roadblocks lined up than you can even imagine. So your MMO is doomed before you even get your code to load models and render them, let alone add animations to those or put in a level progression system...

    5. You'll end up hating game development. I'd actually you rather started out hating it - or, more likely, me for telling you this stuff bluntly. I'm not trying to motivate you to prove me wrong in a fiery blaze of "I'll show that asshole who doesn't know what he's talking about", I'm trying to get you to quit the MMO and do something you have a chance of finishing. Something that will help you learn more AND possibly help you salvage some elements of that team you say you've got going right now.

    So. Make tetris. Make it using your quad drawing method. Use it to figure out input loops and bang your head against collision detection logic for a while. Make it look really bad because you can get away without any art whatsoever, then show it to one of your friends that's not giving you art for this MMO and watch them get more fired up than you've ever seen them because holy shit this is something that people can play and they can make it look better!

    Or don't. Your call. But at least remember this post when, a month down the line, you're having a hard time getting anyone on your team to give you the nebulous art assets you've asked for and you have no idea why the people you just showed your stuff to didn't seem suitably impressed. Because MGSA will always be there to help. You just have to not ask us to help with really bad dreams.
  • edited
    @tbulford I'll have a look at it, its just kind of what happened (since we had issues getting engines to work, we went from C++ with Ogre3D (couldn't get it to compile for some reason) to .net/mono and XNA/monogame to Java (a couple of us are taking it as part of school classes) with LWJGL, also what's so worrying about drawing a textured quad?

    @Thaumaturge Ty for the support, it's being planned as a RPG (also find it funny that everyone jumped to the conclusion it was going to be a 3D game, it is but that's beside the point). What limitation would there be with a stand-ins (like borrows models, etc) or do you mean like stick figures instead of full models? And about the engines thing, I like being able to see the code as to how they work (that's why the attempt at Ogre3D) which leaves with a rather limited options list, so in the end it just ended up like this.

    @dislekcia I never disagreed with your points, as they are completely valid, and I have recoded parts of it already, also this isn't project that was started a little bit back but something at the beginning of the year (not much coding done in that time), and like I said above to @tbulford I'd like him to tell why he thinks it's so badly done and I also know what you are talking with people only really working when they have something in front of them that they can instantly see, however the same came to arise when I suggested doing a small 2D "prequel" to the game as I'm not majorly talented in the art section so I end up asking them for graphics for me to use and I get nada
  • @Max9403 Nothing wrong with drawing a single texture quad. The issue is the way you are developing your engine is going to bite you down the line. Why you should not do that will become clear if you do all the research I am suggesting. I don't feel the forums are the right place to go into too much detail. The detail is in that book and many others. Seriously get hold of them if you going to try building an engine with OpenGL.

    Also @Max9403 consider the recommendations given here by @dislekcia. Think of it this way. Do you think an Olympic gold medalist leaves school and says hell I am going to win a gold medal. No they try to win a local races and build up. Training year after year and working to improve their skills. If they set the goals to high they might become discouraged and quit. That is something to consider when you setting your own goals. To use the same analogy for your doing the big game and learn along the way. What strength do you think a runner would get by trying the Comrades right out and never having trained before. Nothing more then injuries and discouragement latter.

    My recommendation is cut yourself some slack and tackle the lessons needed one at a time. From our conversations I can see you have a fair skill set to build from with regards to development. But its clear also that there is a great deal to learn. Give yourself a chance to learn each skill well. I would really like to see something from your and your team for the next make games competition.

    This will be my last post on this topic since I feel its getting a little long in the tooth and most everything that needs be said has been said a few times. We want to see your succeed and become a game developer. You will have to find your own way, you can choose to heed the advice of others or you can choose to find your own path entirely.
    Thanked by 1EvanGreenwood
  • @Max9403: Wait, you've been working on something for 9 months and there's nothing playable yet?! Stop! Stop now and make something else.

    Make something that you think will take you 2 days to make, then when it only takes 2 weeks you'll be 100% more successful with it than you have been so far ;)

    Make Tetris.
  • edited
    There's a constant recurring theme of "you don't get art so your game's not being made".

    That's entirely and completely wrong! Art is the last part of the circle, if you have a game, even if everything is blocks and circles, it'll be a million times more rewarding for both you and the artist to see - because for them it's this: "I CAN INSTANTLY MAKE THIS BETTER BY MAKING ART!" for you it's: "THIS THING WORKS AND I CAN TELL IF IT'S FUN OR NOT!"

    I'm going to end by drawing up a few famous examples, this is how they started. Blocks, non-animation, NOT ART:

    Bastion:


    Little Big Planet:


    Jonathan Blow on Indie Prototyping (he made Braid, which was amazing):


    Gamasutra's How to Prototype in 7 days is an ICONIC article in indiedom:
    http://www.gamasutra.com/view/feature/130848/how_to_prototype_a_game_in_under_7_.php?print=1

    Making paper prototypes for digital games:
    http://blog.unthinkmedia.com/2011/02/07/creating-paper-prototypes-for-digital-games/

    I'm sure a bunch of us will have more resources to share, too :)

    9 months is a LONG time to spend on technology. Because as far as I can see, if you've got nothing playable, you're not making a game. You're making code, and if that's all you want to do, fine.

    If you want to make a game, make a game!!!!
  • @dislekcia that includes non-coded parts as in when we were just lets make a game and pretty much just sat there (and recoding it from .net/nano), I don't have much to do so I might give Tetris a shot (and we probably started closer to May than January, which makes it nearer to 4-5 months than 9)

    @Tuism I have pretty much just been sitting doing nothing most of time (and would have preferred to have made the 2D "prequel" as it would probably have made it easier to work with the rest but unfortunately just ended up in some discussion, I'll try create it with just blank textures like you suggested)

    @tbulford That's why I said I don't disagree with him since his points are completely valid, and I'll have a look at the book
  • *cracks knuckles* My turn to chime in!

    "I'm not progressing in my game because I'm not getting art"

    It's been pointed out, but you don't need art to progress with your game. If you're able to make basic shapes - and by basic I mean your square doesn't need to have perfectly straight lines and your circles can look more like eggs that fell out of the box - you can make your game. Hell, you don't even need that much. As long as you can have SOME visual representation on screen for point of reference (and maybe not even that) you can make your game. You don't need to substitute 'the blob that's supposed to represent the player character' with 'the pretty rendered well-drawn picture of the player character' until right at the end. What you do in the meantime is work on the guts of your game.

    Another example to add to the above, we're making a point-and-click game. Our artist is a busy guy and our scenes take him a few days to a week depending on what else he's got on. Meanwhile, Jaco (the codemonkey) works like this:

    image

    As for the other business of learning to walk before you can run:

    You're passionate about this project, that much is evident. You've been thinking about it a lot and it's something you really really want to do. You think your idea is great, that it'll work, that it'll be good practice for you. It's your baby. It's really REALLY difficult to listen to people tell you to abandon it, and every time you hear someone telling you to start smaller it's probably making you even more determined to stick to your guns and make the MMO.

    Unfortunately I think lessons like this are seldom learned unless learned the hard way. You're just not going to listen to people telling you not to do this because you've already made your mind up and your heart is already in the project. If you're anything like I was when I was fresh out of school (and hell, still am, to a degree) then the more someone tells you to do something, the more you want to do the exact opposite. Also unfortunately, as Danny pointed out, you'll probably learn your lesson the hard way and then end up hating game dev. The MMO won't work so you'll lump game dev into that 'didn't work' category and go do something else.

    There's a forum full of talented, creative, and most importantly wise individuals here reaching out to you to share their wisdom. Their words come from hard-learned experience. This isn't a situation where 'others have tried before me and failed but dammit, I'm going to be the one to succeed!' - this is a harsh reality and one you don't want to face right now. Making an MMO takes people who've been in the games industry for decades YEARS to make, and even then the MMOs mostly fail. This is not something you undertake fresh out of school, even as a learning experience. Every castle needs a solid foundation. Work on that foundation first. Put a rain-check on your MMO. Spend your weekends making two-day games instead. Enter Ludum Dare. Enter other game jams. Enter the MakeGames SA contests. Work your game-building muscles. When you can make a playable and enjoyable game in two days (and it's entirely possible - go scan the Ludum Dare entries), step up your game and spend a week making something more complex. Build up to the monster that will be your MMO. You'll learn way faster than you will by undertaking something this massive so early.
  • @Max9403

    Being capable of programming a game - a skill you clearly have (I'm going on everyone else's comments - I have no idea since this isn't my field) - does not equate to being capable of designing a game.

    Thinking about game design is a really weird thing. It's about creating solvable problems that produce a level of joy in the person engaging in them with. Figuring out how to do this is really hard. There is absolutely no way to learn this except through experience. Make something, get someone to play it, and refine it and keep going until you chuck it out or have something playable "Fun" is the hardest thing to create.

    Make it in paper. Make it in gamemaker. Make it in whatever environment is quickest, before worrying about fancy coding and graphics.
  • edited
    @WelshPixie I think your a bit late to the party (please don't take this in a bad way) but I have said I'd post phone it a bit and look at a) creating a 2D game which would form the story leading up the actual MMO and b) I'd give creating Tetris (so far already have the shapes and colours) a shot (I'll take up your advice about looking at some 2 day projects though). The main thing about post phoning it is that I'm not the only person trying to get it to work so creating a 2 day or other project just for myself isn't helping them, as well as I already said that we are not worried about it being successful or not

    @dammit A lot of the logic we are thinking of using for the game we have already though out on paper or in the hidden area on the forum (e.g. that weapons function out of components)
  • @Max9403

    Have you had outside people test it?
  • @dammit we have had outside opinion and seeing peoples opinions about the matter in other games, but as there isn't much of a prototype there isn't much to test (the things we have considered though are things like will it be more focused on realism or is you character an all powerful god who can slaughter whole armies at a time, or have multiple intros which influence the rest of the game for that character) but like I said earlier if people want me to open a proper discussion about the game we are making (and give details about it and such) all they have to do it is say so, or if they'd prefer it that instead of opening a new discussion I post the details here they can also say so as well

    A simple idea we have created is the flow chart of basic events for how players are mapped through out the game (some reason spoilers don't work), about which if you have any questions you are more then welcome to ask also critique on the logic flow of it is more than welcome (btw the arrow from character screen to character customization is the wrong way around):
    image
  • edited
    Not only is drawing wireframes of the menu structure pointless at this point, it's time consuming and turns people off from your potential game, cos its not FUN. A game is fueled by the potential of fun, and by fueled I mean getting people involved and keeping it going. Exciting other people is the way a game grows.

    We do wireframes at work. No one wants to do it. No one wants to make sure it's all good. And when we do do it and make sure it's all good, it'll get changed 150 times after client signs off on it. It's just not worth it for you at this point.

    I really wonder what you've got with your 15 guys in the team. It sounds like a lot of people just want to have a say and call themselves game makers. If you look at all the best indie teams, they're small and focused on getting prototypes out, it's when the game comes to finishing (typically MUCH later in the cycle and certainly after the core mechanics are nailed and prototyped and tested) do the other specialised roles like art and sound become involved.

    Conversely, we do also advocate artists and musicians etc to get involved from the start, but if they're not doing anything they probably need to be inspired/directed by real prototypes.

    What do the 15 people do??? What would be a great exercise is to break everyone into smaller teams of 2-4 people and jam different games, see what works, what doesn't, etc. reconvene after the jam. Take a weekend or a week. Keep it short, keep it prototypey. This will work if you have a spread of skills. If you're the only one who codes then... A team of 15 with one coder wouldn't work anyway. Or get them all to learn game maker.

    You guys need to get into prototyping and lose that "it must be perfect first time" mentality. You're denying yourself the opportunity to LEARN!
  • edited
    Hmm. I don't have much to add here, so I'll just leave this brief of our own experiences:

    Our first game 'Rooks Keep'. It took us 2.5 years to make, it was often not fun to work because of this and long iteration times due to it's systems. It also didn't receive outside feedback until several months before release for private beta-testing. Rooks Keep website Go take a look at the trailer to get an idea of how the game looks.

    Then, we made 'Viscera Cleanup Detail'. It took us 10 days to make the alpha and release it to the public. It was Greenlit in 28 days, it has earned us far more attention, excellent feedback and yes, more money/sales than RK ;) VCD website

    I regret how long it took us to do RK, and the decisions we made for it. It's so much more enjoyable to work on a project that you can iterate on quickly and get feedback on early. It's still in alpha, and it's still unpolished, but it's been far more rewarding for us than the polished and far more ambitious Rooks Keep ;)
  • edited
    @Tuism Well would you rather nobody knew in what order things went and just wing it? also it's a group of 15 people who are active and inactive at different times, I just created that for others to easily follow the logic
  • It seems that you're still stuck on building a big complex hulking system from the start. If you built a working prototype it'll never need that kind of login/menu/head/side quest logic.

    I would rather you built something playable, and something playable wouldn't NEED wireframes of that magnitude. It would just NEED to be playable.

    We're all saying the same thing here - don't tackle some giant problem all at once. Do something small. Grow from there. Get playable before you get bored and everyone else gets bored.
  • Well I like creation them as it allows others to see what I have though out :P and to be honest I don't see much difference between this except maybe one or two nodes than to single player, and as I stated very early in this discussion we might make other games while making this one, though I'm going to try and follow peoples advice on using place holders to "rush" to the playable part when I finish Tetris and maybe build the 2D game a bit, also I'm not meant to be the sole coder but at the moment I am, also think about each step in that flow chart as a part that gets tackled at a time (e.g. we finish the login system, before we go and do the server screen)
  • edited
    @Max9403

    (It seems like maybe you are already convinced; I am a bit late, but one extra story of doom cannot hurt!)

    I am one of the "lucky" "few" that worked on a MMO-type project. (OK, it was more Dota-like, so 10 players at a time, and no persistence, so a shadow of an actual MMO. It did share a lot of other functionality, though, so I think it is relevant).

    The project run across two years (at least). It had several artists and programmers worked on it. Everyone (AFAIK) was paid. When I joined it, the lead programmer had just left (I can't say for sure, but I bet it was out of frustration - he went on to work on his own games and tools and has brought out [and sold] several since). A substantial code-base was written; the entire world was built. 50 characters (yes 50!) was modeled, textured and animated, and I can't even remember how many items (weapons, potions, etc.) The scope was massive (for the team size, around 4 people at a time +/-, with some additional work outsourced from time-to-time), but good progress was made. It looked like something ambitious would be not so impossible, based on what was done. In additional, I was doing a lot of mobile stuff at the time, and thought it would be fun to work on a "real" game.

    Well, it was not. It never came out. 2 years, a lot of money, and all that came of it is sad experience and a few portfolio pieces.

    So why did it fail?

    Because the amount of worked was underestimated by maybe a factor of 20. Or 200. But it was a severe underestimation. The nail in the coffin was when the sponsor realised how much work (i.e time + money) it would be to configure all 50 characters to have balanced properties (each character had about 20 properties or so, and several unique abilities with their own properties), and how much testing that would require, not to mention all the items. In fact, the amount of game design left to do completely dwarfed the programming and art time spent up to that point. Not to mention the fact how severely constrained the game design was by the art and programming systems that was already in place. Wanted the action to be a bit faster? Sorry, the animation is already done. Want an ability to affect what abilities another character could use? Sorry, it could not be done without overhauling the character architecture.

    (So in all likelihood, the game may not even have been fun if it ever did make it to the finish line).

    But that really was only the nail in the coffin. There were at least two other serious time drains that would come into play if the project continued.

    The first was the networking issues. There were lots of small issues with latency causing logic inconsistencies (you kill me on your machine, but I get to kill you on my machine before my machine knows I am dead). The networking code already started to become complex to deal with this kind of thing, but to solve some of the issues completely would require even more complexity. As it was, testing was quite difficult. I think a real solution may have taken months to polish up to proper production quality, and who knows how long to test properly.

    And then there was the GUI. It seems silly that something as stupid as GUI could be a such a big constraint, but it was. When I joined the project, I specifically did not want to do GUI stuff (at the time, not my favorite part of development), so I agreed to only do prototype GUI, to be replaced later with something a bit prettier. As it happened, the GUI code I wrote was about half of the code - thousands of lines of code. It was ugly as hell, not user friendly, but it did allow you to sort-of get things done. To polish it up into a proper GUI would at least have double the amount of code...

    ---

    So did I learn something? If I did not get paid, would it have been worth it?

    I did learn some stuff yes. I learned how to organise large numbers of assets, how to allow designers to fiddle with values in the game engine. I discovered a few ways of not doing networking, of not doing complex successive user-controlled actions/animations. I also learned how easy it is to underestimate work (sadly, I would learn this a few more times), how demorlising never-ending projects are, how bad it is do make complete art and systems (such as the login system) before the gameplay is good.

    More importantly, here is what I did not learn on this project:
    • How to solve some of the technical issues to my (or anyone's) satisfaction.
    • Any aspect of making a game like this more fun.
    • How to properly architecture input, movement, animation and effects so that it's understandable and changeable.
    I have worked on maybe 10 games (excluding a bunch of example clones I made for a library) this year already, most of them minute and not very glamorous. But I learned way way more than on that project. I really mean way more (I would make a list but it would be boringly long; it includes new algorithms, new ways of structuring GUIs, new ways of scheduling, new ways of communicating with the player, a few things on making games more fun, etc. etc.)

    ---

    Anyways, I hope you make lots of small games. It really is the faster route to build skills.





  • @Max9403

    Your flow diagram is much like the contents page of a novel. No novelist has ever, ever, ever written the contents page, listing the chapter names, before writing the story. In fact, story writing is very often reversed from story reading. You'll start with the twist, or the core of the story, and work your way back to the beginning in rough. And then you write the story.

    With games, you start out with the mechanic that makes it fun - and only much later do you worry about how to piece that together with log ins and fancy GUI and character choice.

    I hope @hermantulleken 's personal experience will mean that you don't have to go down that road too.
  • This thread has to become a FAQ entry. There are like 3 questions people always ask and the answers are great :)
  • edited
    Regarding design docs and gameplay-flow-charts. This is sort of a pet passion of mine, which I've previously gone into some length on these forums discussing. In that I think things like design-docs and gameplay-flow-charts are in reality crippling constraints themselves when trying to make an enjoyable game (even more so when you don't have a lot of experience designing games).

    Of course, communication is vital when working in a team. So there has to be some way to convey ideas and keep people feeling confident, informed and inspired.

    I like this method the most: http://www.lostgarden.com/2008/12/post-it-note-design-docs.html (and we use a slightly modified version of it in our 6 person team).

    In my experience methods like the one that Daniel Cooke mentions produce the best results and are the most enjoyable to be involved in. Things may have to get a bit more structured and dogmatic later in the project once the game is already enjoyable, but finding that enjoyable experience is easiest when development is kept playful.

    Well, not all playful, but vacillating rapidly between playful development and focused development (like the post-it notes technique encourages).

    These are John Cleese's famous thoughts on creativity (which I think go some way to explaining the underlying reasons why producing a design-doc or a gameplay-flow-chart or feature list at the start of the project are bad investments):



    That isn't to say @Max9403 's flowchart is bad or incorrect. Just that the team I work in doesn't operate like that because of solid reasons. I think that @Max9403 's hands are tied somewhat because he's working in a 15 person team (which in this case means to me that the team size itself is a problem). That's a really difficult problem to solve.
    Thanked by 1Tuism
  • @dislekcia I have read a couple of threads where your advice for a new game developer is to make tetris... Any reason why tetris in particular, rather than another simple game?
  • edited
    @Nenad: I pick Tetris as the game I advise people to make for a bunch of reasons... Everyone's played it, so it's not like saying "Make Arkanoid" "WTF is that?". It looks simple, but is actually complex enough to be a great introduction to building games: This looks easy *hours pass* everything's broken. It downplays a lot of the traditional loops people get stuck in, the graphics are easy to do, the input is relatively straightforward, the collision logic isn't realtime and can be done by simple grid testing. It's achievable, but always underestimated, so people approach it like I'm telling them to wipe their butts and realise after a while that maybe we're not talking utter bullshit when we tell them their realistic MMO idea is a little overboard.

    And to top it off, the game design is sheer genius, so it's always fun to play once you get things working. That's extremely motivating, seeing that gameplay come together, so it helps deal with the demoralising effect of understanding that your previous estimations were so much hot air. It also never hurts to expose people to wonderful design instead of something insipid and ultimately silly, like Arkanoid or Missile Commander.
  • Arkanoid silly! Them's fighting words ;)

    Actually the explanation makes perfect sense.

    I guess the same thing applies to my Jumping Jack Clone that I am planning to do.
  • edited
    @dislekcia I have never played Tetris before as I've never considered my game style (and frankly find it boring to watch), also I got bored with it after a couple of hours fiddling and to be honest I'm not tempted to resume and continue it, yet all that still really needs to be done from my point of view is collision detection, moving side ways (pretty easy to add at the moment, just haven't added the keyboard handler) , rotation again pretty easy to do and the score system
  • edited
    There are other simple games to experiment with that might be more appealing. I think Tetris is a good choice, but I've never made Tetris though myself. The first game I practiced making was Asteroids, and the second was Crimson Land.
    Max9403 said:
    yet all that still really needs to be done from my point of view is collision detection, moving side ways (pretty easy to add at the moment, just haven't added the keyboard handler) , rotation again pretty easy to do and the score system
    If you're getting bored and quitting a Tetris project after a couple hours that is kind of proving the point of the Tetris challenge. Even Tetris is a huge task that takes many hours to produce, it doesn't sound like you got even a quarter of the way. Games take way more effort than expected to produce, and complex games (like MMO's or RTS's) take exponentially more effort and time.
  • edited
    I actually haven't made Tetris, but I did make Tiltris, which is more like columns, and the two sides tilt according to how heavy the sides are. I did it highschool and had all but forgotten about it. Whoooa.

    The actual first game was in std 9, Space Invader inspired. Tiltris was Matric.

    Now that I think about Tetris there are a few things I'm not quite sure how to do...
  • I really liked this version of Tetris:



    Which is very similar to, if not inspired by, Zach Gage's Unify:



    I once hired a guy based largely on his pretty clever Tetris variant:

    image
    Thanked by 2Tuism Merrik
  • edited
    @Max9403: So actually making a game is less fun than writing flowcharts for interfaces? (I mean, from your list of stuff you still needed to do, you still needed to do the entire game)

    Have you thought of going into graphic design and/or UI design in that case?
  • edited
    @dislekcia actually what I said is a) your point of everyone has played Tetris is wrong, b) I don't find Tetris enjoyable in any way therefore it is more enjoyable for me to create flowcharts than to make a game I don't find enjoyable or have any drive to make and c) yes I have I've created this pretty basic box thingy (I have no problems designing things in my head though when it comes to putting it down it's a different story): image

    P.S. I just added rotation and sideways movement in 5 minutes
  • edited
    Well, in all fairness it could be the choice of game: I seem to recall that every time that I've tried to play Tetris I've found it deathly boring. As a result, the thought of making a clone of it is a distinctly unappealing one. From what Max9403 has said, it's possible that the problem lies there.

    [edit]
    I was a little slow in posting, it seems, so the paragraph above is a little redundant. THose below remain, however.
    [/edit]

    @Max9403: Perhaps try again with another game, such as Breakout or Space Invaders; they're both perhaps a little more complex than Tetris, but I think that both should be simple enough for these purposes.

    In either case, it shouldn't be too difficult to start very simply and expand from there. Something like these steps, perhaps:

    1) Draw the player avatar to screen (read: "draw a quad that will represent your avatar").

    2) Implement a basic game-loop, and get the avatar moving left and right.
    2.5) Prevent the avatar from leaving the screen.

    3) Add a single, static "enemy" (alien ship or breakout block(again, just a quad)).

    3) Implement basic collision detection (circle-circle for Space Invaders, rectangle-rectangle for Breakout).

    4) Add more enemies; add movement in the case of Space Invaders.

    Etc.

    If all goes well, and once the rest of the gameplay is done, Space Invaders could also be expanded to a scrolling shooter a-la Tyrian (if rather simpler).
    Thanked by 1Max9403
  • edited
    Well if making Tetris is boring for you, rather than starting on a different game and then a different game, try to actually make it fun? Add stuff to it, or re-imagine it, isn't that the whole point of making games?

    Prototype the game (Tetris), get people to play it and see if its fun. Iterate on it and make it more fun if you see a problem with it. Finally if all else fails and its still not fun, then try a different idea.

    Well at least that's what I try to do...

    [Edit] It just seems like hoping from game to game is not going to teach you how to make FUN games. It will teach you how to put down the first steps to toward basic tech for games and nothing else...
    Thanked by 1dislekcia
  • I am enjoying the sub thread that's rippling through here everyone talking about the first game they made. Mine was a 2player versus game playing AT-AT jumping and trying to kill each other, single screen plat former. (yeah AT-AT's don't jump, but they would be so much cooler if they did). Standard 7 for me that was 1987.

    Want to hear more on this theme. Perhaps a new thread.
  • @creative630: I hesitate to speak for another, but since Max hasn't responded I'd like to note that, for me at least, changing Tetris to become fun would seem to likely turn it into something that isn't Tetris any more. In any case, I suspect that it might be better that this "first game" at the least start as a copy, and only branch out later.

    On the side-topic of our first games, I'm tempted to start it myself, but I'm not at all sure of what mine was! XD;
Sign In or Register to comment.