Author Topic: Game Design Megathread (Read 443214 times)

otto-san · January 06, 2017, 12:53:49 PM

Quote from: Metalliku on January 06, 2017, 12:16:47 PM

Is Gamemaker Studio easy to use?

yeah it's pretty easy to use. if you've got prior programming experience, GML should be pretty easy to pick up too (or even if you don't, cus it's a pretty simple language)

i don't really use the drag-n-drop stuff, but plast knows his way around it p well and makes some neat stuff so it must not be too absurdly limiting

Ad Bot · Advertisement

Plastiware · January 06, 2017, 06:06:38 PM

What otto said, but also keep in mind: Game Maker is basically THE worst thing for 3D design and animation. Seriously. If you want to make 3D games, I recommend something else. I pulled this off because I wanted to see if I could do it, and because I have like 10 years of experience richarding around, I pulled it off. There is no built-in Z variable, by extension no default handling for any non-x/y object placement or collisions, and all models have to be built in code. The Robot Mans you see here is a mess of variables that control the angles of his joints, logic that tells him how to pose, and code that sets up the precise angles and positions to draw his box-and-cylinder parts at. It's a headache. Only took me 3 days, but still, there's a reason it took me 3 days to make a bare-bones basic platform engine.

For 2D stuff though? Highly recommend.

TheABELBOTO · January 06, 2017, 06:34:14 PM

Iirc the guy who made Nintendo Madness was the first one to have made a 3d game on GM

Or something like that

McJob · January 07, 2017, 06:18:18 AM

I got into a nice discussion tonight, and the product of which was;

One day to look at games is to think of them as two layers. The Sandbox and the The Game.

To me, a "Game" refers to the gameplay, which has three factors:

1) Something to achieve (Goal)
2) Things that prevent you achieving that (Challenges)
3) Ways to overcome the things that prevent you from succeeding (Rules)

And these things exist because the designer's responsibility is as a teacher; fundamentally our job is about transferring knowledge and physical skills on the player, in abstract and literal terms. This goes hand-in-hand with the boredom-fun-frustration scale, where the player will only be enjoying the experience and most engaged when they're still learning and mastering things, as that's when the brain releases dopamine as a reward for perceived "learning".

The "Sandbox" is the base of technology and aesthetics on which the gameplay lies on top of; some gameplay rules may be embedded into the system (such as the concept of life/death and how weapons work etc), but a player may override these rules and substitute their own to play another game within the sandbox (such as a speedrunner, who isn't playing the same game that the designer originally intended). "Games" like Minecraft (pre-ending update) are purely sandbox, and require the player to develop their own game on top of the sandbox in order to stick within the experience.

This, as it turns out, is the key to enjoying your own, real life. When you understand that the game can change, but that the sandbox is static (unless you mod it, but real-life augmentation technology isn't there yet), you can start to try play life as different kinds of games with different goals, until you find the one to which you have the strongest motivations to progress on. Maybe there's even a beautiful lesson hidden in the game for you to learn, as life throws its challenges your way...

Insert Name Here� · January 07, 2017, 10:15:30 AM

Quote from: Plastiware on January 06, 2017, 08:31:51 AM

tfw you make a stuffty box man as a test and somehow have a 3D platformer 3 days later

[img ]http://i.imgur.com/aqLOa3m.gif[/img]

That looks as if it's an N64 game, that's really neat

Next step: Turn the map into a city map and you're jumping around skyscraper roofs

joe411 · January 07, 2017, 10:27:46 AM

Quote from: Insert Name Here� on January 07, 2017, 10:15:30 AM

That looks as if it's an N64 game, that's really neat

Eh, the pixelated textures look more ps1 to me.

Insert Name Here� · January 09, 2017, 09:30:23 AM

Soon I'll be learning C++ and I'll get UE4

Have any tips for someone starting out? Btw the game I want to make isn't going to have extremely detailed models, its going to have a low-poly aesthetic

Als if possible, some model rigging video guides fot UE4 would be good, the game will have on foot, driving, and shooting too, all in first person

rggbnnnnn · January 11, 2017, 07:36:23 PM

I have GameMaker Studio 1.4 and I want to upgrade to 2. Is it worth it?

Legodude77 · January 14, 2017, 02:38:12 PM

Quote from: Insert Name Here� on January 09, 2017, 09:30:23 AM

Soon I'll be learning C++ and I'll get UE4

Have any tips for someone starting out? Btw the game I want to make isn't going to have extremely detailed models, its going to have a low-poly aesthetic

Als if possible, some model rigging video guides fot UE4 would be good, the game will have on foot, driving, and shooting too, all in first person

Honestly a lot of work in UE4 can be done with blueprints themselves. I haven't done much in my game, but everything in it is made with only blueprints except for one script.

McJob · January 14, 2017, 04:12:39 PM

If you're planning on working with a team, any system that artists/designers need to interact with should be in Blueprint, as that way if they need to make a change, it's far easier for them to understand how the system and syntax works and do things without your intervention. C++ should be used for any core level systems that shouldn't need to be changed often, and for stuff where you want more control over how memory is being used.

Insert Name Here� · January 14, 2017, 04:16:21 PM

Quote from: Legodude77 on January 14, 2017, 02:38:12 PM

Honestly a lot of work in UE4 can be done with blueprints themselves. I haven't done much in my game, but everything in it is made with only blueprints except for one script.

I've found that out recently and it's awesome and the main reason why I'm going with UE4

Quote from: McJob on January 14, 2017, 04:12:39 PM

If you're planning on working with a team, any system that artists/designers need to interact with should be in Blueprint, as that way if they need to make a change, it's far easier for them to understand how the system and syntax works and do things without your intervention. C++ should be used for any core level systems that shouldn't need to be changed often, and for stuff where you want more control over how memory is being used.

Alright cool, thanks for telling me, I'll keep that in mind

Bosie1997 · January 15, 2017, 12:50:43 AM

HE TINY

edit:

Dusty

McJob · January 16, 2017, 04:14:27 AM

I thought I'd do something a little interesting for you forum blokes; I want to show off how I'm breaking down an old classic "game" to approach the design for my own mobile version. There will be tiers/stages of posts, as I get through more of an understanding of what I want to do. This issue is simply a high-level look at where I'm coming from, and identifying the things I want to inspect closer.

STAGE 1: RESEARCH AND IDEA GENERATION

Description

LEGO LOCO is a 1998 "Virtual World" title by Intelligent Games. There was no actual gameplay; you had unlimited scope to build a world out to your desires (with a focus on trains), and once you entered Play Mode, you would see the world come alive, with minifigures, cars and trains bustling about. There were minor bits of interaction, such as screwing with the 'figs, running the trains, sending postcards (which tied into the game's networking features) and so on, but overall the game was completely independent. It exemplified the LEGO Island design goal of a virtual toybox in which a user could interact and mess with, but in which existed no inherit purpose.

I feel like this fantastic game would work well on the mobile platform, particularly with big screen devices like tablets and the Switch, and I like the concept having a LEGO Aquarium, one that doesn't need to be managed, that you can influence and have fun in.

Identifiable Elements & Challenges

In order to produce a new version of the title, one must understand its core Elements and Flaws on which we either want to keep or address. These are the main things that stuck out for me;

[E] Distinction between Build and Play Modes: The sandbox has two operating modes; Build Mode exists when you select the Briefcase, and opens up a set of tools to influence the world (by adding or destroying world items). In this state, dynamic objects such as minifigures, trains and cars are hidden, and the world is frozen. Play Mode is obviously the opposite; it's where the world exists as a living, breathing space and the player's interactions allow them to affect how the world actively works (permanent choices vs. temporary decisions, respectfully).
[F] 2D Space: While the edges of the screen are scrollable (to the extent of the 64x48 grid), there is no ability to affect perspective of the world, zoom in or see the spacial relationship between objects. Based on research, a single tile represents 16x16 studs, which is both massive and tiny. It's very clear that many things, such as the Obelisk, Train Stations (based on real sets) and Road Baseplates have all been made to fit the grid, and so their scale is way out of proportion.
[F] PC-Exclusive Title: A significant oversight, caused by the era in which the game was originally produced, was that this game was appropriate for the Desktop computer market. I don't believe that to be the case at all. There's so many entertainment options on the PC, and more importantly the PC lends itself to complex controls and indepth experiences. A virtual toybox with no true game feels more like something that belongs on a less complicated, portable environment where it can serve the purpose of being a temporary distraction.
[F] Old School Technology: LEGO LOCO is currently severely hampered by its technology-base. The game requires a DESKTOP resolution between 800x600 to 1024x768, and will only run in 16-bit colour mode. The eraser feature assumes a high, uncapped framerate and breaks down when the system slows. The game was also coded specifically for Windows9k, and thus has compatibility issues with newer systems, and it never received a Mac or Linux port.
[F] Limited Simulation Control: The player's God-Influence over the world is extremely handicapped in Play Mode; players may move objects such as figures and vehicles around (usually because they got stuck), name buildings, figures and vehicles and use the train remote control to take manual control of one specific train at a time. While this might have been to make the world feel more "autonomous", it can be far more restricting in a simulation experience as it prevents the player from being able to impart their story on the world, particularly if the sandbox doesn't have sufficient scope to product interesting stories of its own (see below).
[F] Limited Engagement Potential: The crux of the title's issues is that there's so little to keep you enjoying the world after the short "Wow" period, it's no wonder most modern players would drop out quickly. The world exists in static time; aside from Easter Eggs tied to the system clock (which require a game restart), nothing interesting ever happens. While challenge isn't exactly necessary, if the world isn't able to generate anticipation of what is to come next, nobody will stick around for a prolonged time.
[E] Integration of Trains Into Networking Functionality: Something that particularly stood out for me was that there were networking features available (which allowed to send postcards and minifigures between player's towns) through some clever use of the train mechanic. Though not explained very intuitively in-game, I think it's a very interesting way of allowing a single-player title to be a shared experience, and it adds value to the primary mechanic.
[F] No Rules to the Sandbox: There are no sandbox-enforced rules to the way in which the world works, leaving a serial disconnect in player engagement as it makes the experience feel too easy and, by extension, too boring. Players may freely place track parts, roads and buildings willy-nilly without any implications for what should be "wrong" placements (such as two connected road-pieces that face perpendicular directions). This also affects the design side; many buildings do not correctly align with the roads, and it causes all kinds of jams with traffic getting stuck on buildings. Games like SimCity are fun as there needs to be a balance in making a cool looking world and making it functional.
[F] Vague Connection to the LEGO Brand: I've discussed this in great detail before, but a true LEGO Game/Sandbox is one that is able to meet the core brands of what LEGO stands for, not just vaguely feature some LEGO sets in the art. Seriously; you'd only need to replace about 20 game sprites and then this would have ZERO relation to the LEGO brand at all.

Legacies & Solutions

Since we've identified the things that stand-out and the things that need to be addressed, we can start to tease out which things I want to keep and update and which things I want to change or remove. Ultimately, everything here is at the mercy of the results prototype playtesting, but it's good to have something to work towards first in order to test the theories with.

There should always be a distinct feeling of power between being an almighty God of creation and destruction, and being an observer with more limited options in the playspace. By featuring the distinction between the two, it adds a level of mechanical thinking where the player can study the world for problems, make changes to try and correct the issues, and then brown townyse what impact they had. It also allows for interesting transitions and makes the technical side of things easier to deal with. It also prevents real-time actions from affecting the slower creative thought processes. This distinction is key to the rest of the gameplay, and it must be a fluid process to go from one to the other.
It is all too easy for the world to feel flat if it literally is flat. I therefore thing to do something bold; while Build Mode will remain in a direct, top-down view (that allows for a "architectural blueprint" style), the Play Mode must be in 3D; this emphasises the transitions between the two modes and the liveliness of the world, and it also allows a deeper level of immersion in the sandbox. Appropriate camera controls need to be developed to allow the player to explore their world and see it up close, and get in tune with the people who live in the city.
The PC Market is not the appropriate place for what is essentially a glorified distraction centre. This toybox needs to be portable, for the person who has 5 minutes on the bus to check in with their little friends, or the kid who wants to take their digital world into their real sets by setting the portable device next to their LEGO collection so they can begin to rebuild with their physical parts. While the obvious target is mobile phones and tablets (potentially the Microsoft Surface and derivatives), the Nintendo Switch also represents an interesting new platform to take advantage of if possible.
Modern Engines like Unity and Unreal are suited to this problem, and have many facilities that give control back to the user to customise the experience, and also have some assurances of future compatibility. The most important part will be to, if this game goes portable, ensure that the control schemes work within the environment of the platform (UI controls must not take up a large portion of the screen-space).
The sandbox needs a deeper set of controls, but this doesn't necessarily mean more physical inputs and UI buttons. Realistically, a player's action should have more possible outcomes, suited to the context in which it occurs. For example, dragging a fig in front of a building should elicit a unique response (randomised based on a list of appropriate options) that completely differs than if you were to put them in front of another fig. To extend off of this idea, every object within the sandbox needs to be dictated by faux-complex rulesets, that give the impression of realistic personalities, interests, dislikes and so forth. The player should be able to learn all about the actors in the sandbox, come to understand them and be able to impact their lives in meaningful ways (to a set extent).
Dynamic events, day/night cycles that impact behaviours (and encourage the player to go to sleep, if the sandbox is tied to real-time) and just little vignettes should evoke a wider sense of life in the sandbox. As the player need not do anything to create, nor handle, these events, it gives the impression of a much deeper world. While it would be handy for little cheat "shortcuts" to produce events on demand, carefully paced randomised event triggers can be used to ensure that the player isn't overwhelmed by activity. Furthermore, the game should always randomise the future when the sandbox is closed and reopened, to demonstrate the passage of time and suck the player back into the sandbox.
While I value the single-player experience as critical, it would be a nice touch to bring back (and potentially improve) the networking features of the original, but concessions would need to be made to make into account privacy, security, family-friendliness, and making a network setup that enhances the gameplay mechanic's value, rather than being a separated part of the sandbox. Sending off your townspeople is already an interesting concept, but there needs to be some form of communicate that could allow players to feel as though they're not alone when the sandbox itself fails to entertain.
Without trying to blatantly rip SimCity, nor make the sandbox far too complex for the most inexperienced of players to understand, there should be some interesting challenges that prevent total chaos within the world; logical placement of world objects (such as requiring power stations and correctly orientating road pieces together) needs to be enforced, and it should be the figure civilians that inspire the player to do better and make the world a much more harmonious place to live in (by subtly prompting at the issues).
It is not the physical brick, but the core values, that identifies a game as a LEGO game. Here are the ways I plan to show that;
- Imagination: This whole toybox is not much more than an expansion of a child's own mindset, and encourages them to bring in their own ideas into the sandbox and think wildly.
- Creativity: The proposed rules of world building do not exist to limit, but rather to challenge and inspire wider creativity as one must find new solutions to problems, engaging the learning process.
- Fun: The success of making an interesting, breathing and dynamic world is a pathway to having fun in the sandbox, by simply experimenting and seeing what kind of crazy stuff you can find.
- Learning: As well as UI queues, the subtle marks from the townsfolk will encourage players to read and remember behaviours that encourage some form of action, such as replacing misplaced piece of road with path.
- Caring: Nothing about this experience should be overstated, or attempt to pull you back in if you've had your fill. This is a world that requires the player's total motivation to take part, and in return the experience should offer something rewarding back.
- Quality: I can't make any promised about the quality of the visuals as a one man band simply building a prototype of this idea, but if something were to happen that launched this sandbox into full gear, this would be the most crucial point. Nothing can be allowed to compromise the goal.

Critical Summary of Research

In order to get myself on track for the next parts of the development process, I need to make some soft decisions that give focus to where I want to go and how fast I want to get there with this project. This information is typically provided at the top of a Game Design Document, but will change rapidly through the prototype process.

Working Title: Cityscape
Genre: Virtual Toybox
Category: Cityscape is an awe-inspiring LEGO-based open sandbox, where the player has the freedom to build up (and tear down) their own globally-connected cities and inspire an entire generation of LEGO Minifigures to live and act freely. Craft the city of your dreams and watch (and meddle) as your denizens grows and learn about their forever changing surroundings.
Platforms: Android, iOS; potential for Switch, Windows and Mac OSX Ports
Play Mechanic: The critical mechanic is the creation/destruction tool, that lets players plant or pull new elements into the sandbox, which are in turn responsible for spawning in dynamic objects accordingly, and act as points of interest to inspire behaviour and events.
Target Audience: Two selected target markets; mainly aimed towards M/F <=12 with a disposition to LEGO who want to extend their experience to the virtual world, but also being developed for M/F 21 - 40 commuters with time to burn and an interest in playing God.
Anticipated Dates: Q2 - Prototype Delivery, Q3 - Early Alpha, 2018 - RC1

So, where do we go from here? Stage 2 involves breaking down my legacies and solutions, and generating both a list of hard mechanics and actual content that need to be generated for a working prototype, as well as improving upon the Critical Summary by setting down harder deadlines that can only be generated with the scope of the project known.

Stay tuned for more.

Frequency · January 16, 2017, 04:18:39 PM

i loving loved lego loco. Given the opportunity, I'd totally buy your rendition on mobile.

cooolguy32 · January 16, 2017, 06:55:49 PM

I use this software called 001 Game Creator, and it's actually really good, there is even a free version called 001 Engine.