• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.

omnomnom

Members
  • Content count

    2
  • Joined

  • Last visited

Community Reputation

118 Neutral

About omnomnom

  • Rank
    Newbie
  1. No progress on the game. This sudden stop to any game development happened because I ran into performance problems. I focused on writing my code OO and as a side effect it is very poor in rendering performance. I realized I needed to find out the best way of render a tilemap, rendering particles, etc before making a game. Things like spritesheets/atlases and vertexbuffers and hardware instancing. So I stopped developing the game and started to read more stuff online, try out examples and benchmark on my machine. The most useful thing is to read people's past questions on gamedev forums and the like and read the answers they are given by people who know what they are talking about. Even questions which I didn't think of asking provide answers that are useful to know. It saves time having to write a benchmark and test things if someone who knows can give the answer. One trap to bear in mind when doing this is that answers can become obsolete over time as the APIs change. Stuff that used to be inefficient can become efficient and stuff that was important to do for performance can become irrelevant. Anyway back to the game. I am scaling back massively my overly ambitious plans. I now plan to make a very simple roguelike, no massive map, just a traditional small map for each level of a dungeon. Really I already have this largely in place before I got side-tracked on very big virtualized maps. As a benefit the performance requirements for small maps are even lower. I'll try to get a very simple first game done before trying anything too complicated. Performance I might as well mention the performance problems I hit in the current game. I have a Tile class and it has a Draw() method. In that method it calls DrawUserPrimitives to render a quad for the tile. The Item and Monster classes also have a Draw() method and do the same thing. This is nice and OO, but rendering a 50x30 tile map results in at least 2500 DrawUserPrimitives calls per frame. Stupidly inefficient for what is largely a static map and could be rendered in a single call. It's kind of okay, hardware is a bit more advanced these days than 10 years ago. On my machine I can render 100,000 textured triangles at 11 FPS which sounds bad, but now consider I am making 100,000 calls to DrawUserPrimitives each frame, one for each triangle. If I instead render in batches of 10,000 triangles (so 10 DrawUserPrimitives calls), I get about 220 FPS. Some thoughts: What matters? Doing it "right" or getting it to work? So what if the rendering is stupidly inefficient, if it renders at 60FPS on any modern PC or laptop who cares? I am making a turn-based roguelike with exceedingly low graphical requirements, not some cutting edge FPS. I can sacrifice a lot of efficience. Does improved performance really require breaking OO purity or can I do OO differently? For the last question I thought it should be possible to insert my own caching/batching layer between the game and DrawUserPrimitives. Still working on it but so far it doesn't perform as well as I hoped. As a side note I am going to the International Roguelike Development Conference in London at the weekend as a noob looking to learn from people who know what they are doing. http://roguebasin.ro...x.php/IRDC_2012 *Anyone who is confused why I am not just using spritebatches in a 2D game, I wanted to learn 3D rendering even though I am making a 2D game.
  2. that's a lot of stars! Even if the player can see a different 1/100,000th of the objects each second it would take them about 28 solid hours to see them all, so generating on the fly is probably a good move if only to prevent the generation of stuff some players will never see/visit. Have you thought about a brightness limit for rendering rather than a depth limit? Nearby planets and dim stars might be too small to be seen, but a really bright supernova you might be able to see from the other-side of the galaxy? If you use any kind of depth limit you end up drawing a lot of invisible objects, and not drawing a lot of very bright ones that should be visible. "That's a good idea, the only struggle will be correctly applying gravity to the offloaded chunks so they don't whizz off in weird directions." Could you get away with not simulating gravity between stars? I am not certain but I suspect the movement of distant stars relative to one another through gravity, given the sheer distance between them typically, is so slow that no-one will notice if they were fixed. I guess you'll have to test it once you increase the distances to see if having it on/off makes any noticable difference. Also here's an issue you might be aware of already but it's probably critical for what you are doing given the severely large distances you might work with: [url="http://randomascii.wordpress.com/2012/02/13/dont-store-that-in-a-float/"]http://randomascii.w...hat-in-a-float/[/url] If you scroll down there's a table that shows the precision drop-off when using a float to store distances in meters. It mentions that at 1 billion meters, 1.4x sun radius, you only have precision of 64 meters. So you can't increase the value of a float holding 1,000,000,000 by less than 64 meters, preventing you from perhaps accurately moving ships or slow objects. Could be catastrophic if you try to move something 20 meters in a frame and it doesn't move at all because it cannot be represented in floating point. Using double floating point would help, but it would only delay the problem to larger distances. If you plan to represent a real scale galaxy at something like meter precision for ship movement, then storing ship/planet positions in meters relative to an origin point could result in very strange bugs later. A solution would be to store positions relative to local points (eg relative to the nearest star), or relative to the nearest "gridpoint" or something to prevent storing coordinates so big they cause precision to drop too low.
  3. " [left]when their centres are essentially 0 from each other the gravity pulls them at a ridiculous speed so they fling off in mad directions"[/left] [left]Yea I had that happening as well, I tried various hacks to fix it like bouncing colliding objects off each other,[/left] [left]capping max velocity and even adding a short-distance repulsion force, but none of it looked right. Finally I settled on a clumping behaviour where two colliding masses combined into a single larger mass, with momentum conserved.[/left] I guess the question is what would happen if a moon sized object slammed into a planet in real life? I guess a lot of it would "stick" together but there would be a lot of debris flying off in various directions. The problem I had was my low limit for particles I couldn't support lots of minor debris. In the "universe" I made I found [left]everything eventually either collapsed in on itself or expanded away to infinity. A bit like the universe I guess, except I never saw any cool structures like orbiting planets/stars/moon heirarchies emerge, let alone galaxies. I assumed that was because I was doing it in 2D, plus I didn't have enough particles. Either that or I disproved modern cosmology![/left]
  4. nice, ive done something like this before but I didn't think of the critical step of subdividing the world like you've done, so I had every "star" gravity testing against all others with predictable performance results...oh and I was doing it in 2D - amazing how an extra dimension cuts down on all the pesky collisions.
  5. I haven't made zero progress, just unseen ninja progress. No screen shots possible, so sorry this will just be a big chunk of text. The main change I have done is adding support for an infinite tile world. I divided the world map into 32x32 tile chunks and introduced a 3 stage cache along the lines of Disk -> RAM -> Video memory. What I was doing before was rendering each tile in a separate DrawUserPrimitives() call. This was fine for a dungeon it seems, but for an outside world in which I want to be able to zoom out quite far...well 100x100 tiles = 10,000 batches each frame which is just stupid. I got slowdown on my card when zooming out a fair distance, although admittedly my card isn't a particularly fast piece of hardware. What I am doing now is using a VertexBuffer. When a map chunk comes into view I load it's vertices into the buffer. The vertices's are then kept in the card memory and I don't have to pass them all to the card each frame (at least that's how I think it works..still learning this stuff). The VertexBuffer is big enough to hold about 25 map chunks. That's more than enough to cover a large enough area if the player zooms out. From what I've read it's a bit expensive to set data in the vertexbuffer, in fact I've read people saying don't set data in the vertex buffer during the game, only do it during initialization....well ok but I couldn't see any other way. So as the player moves across the map the older chunks in the vertexbuffer are replaced. The RAM cache is for chunks that used for a non-drawing use, eg calculating a line of sight in a distant area. It would be bad to load a chunk into the vertexbuffer that wasn't even going to be drawn. I suspect there will be a lot of processing of non-visible chunks. The disk cache is what enables the "infinity". The RAM cache is limited in size and reads/writes chunks from the disk cache as needed. It seems to work smoothly enough. The Map Generator itself has no concept of chunks, it just writes terrain in tile coordinates. Behind the scenes the necessary chunk is loading into the RAM cache and the tile modified. Tile Textures Textures are a big problem now. Before when I was drawing a single tile at a time it was easy (although very inefficient): I would just set a different texture depending on the tile background before the draw. Now I am drawing 32x32 tiles at once and some of those tiles could be grass, some could be rock, etc. What I am currently doing is having a big sprite sheet texture, well it's not that big - 512x512 at the moment which holds 64 64x64 tile textures. Then for each 32x32 map chunk I have the vertex texture coordinates set to correct offsets into the sprite sheet to pick up the right terrain type for each tile. A problem is that texture cordinates are proportional and not absolute so the offset into pixel 64,64 of the sprite sheet is 0.125f, 0.125f which threatens precision problems. It can be dealt with but it isn't great. Another possibility I might try is to pre-render each chunk to a single texture and save that to disk, then load that on the fly using a similar disk->ram->video memory cache system as used for vertices. Unfortunately that means more loading of content during the game. On the otherhand having a single texture for the entire chunk means I don't need to draw a chunk as a 32x32 grid of triangles anymore, it can be a single quad. Kind of negates the need for the vertex buffer... So yeah you can see I don't know what I am doing. Still reading/experimenting trying to understand how video cards work and what i need to worry about in terms of performance and what I don't. Mainly trying to figure out the traps (Eg here's one I fell into: http://www.altdevblogaday.com/2012/02/05/dont-store-that-in-a-float/). I guess it was a stretch to imagine I could just "make a game" without the overhead of having to read stuff. Maybe my 2nd game will go faster. Field of Vision This is about field of vision in roguelikes. You are looking down on the dungeon/world and yet certain tiles are not drawn because even though you can see them from above, your character cannot because eg a wall is in the way. This is different from line of sight. This is about calculating an occlusion mask that is drawn over the map for areas your character cannot see. I disabled field of vision as soon as I switched to a surface world map because my inefficient implementation that could only just cope with small dungeons failed miserably with wide open spaces. Calculating whether each tile on the screen is visible to the player's tile each frame was too much. I could spend time understanding and implementing one of the more modern fancy algorithms. http://roguebasin.roguelikedevelopment.org/index.php/Field_of_Vision But I am lazy so I started thinking if field of vision was worth it. Inside a dungeon yes it is, somewhat. But outside...I think gameplay would work without it. A maximum radial view distance works fine. Creatures could still be hidden if they were out of line of sight. /longwinded unformated update
  6. To recap: you start in the south of the game world and the objective is to reach a location in the far North. To get there you must pass through unique zones with different challenges: a desert zone, a dense forest zone, an icy mountains zone, a swamp zone, etc. Each zone is harder than the last - both in terms of the monsters in it and the environmental dangers. Here's a rough diagram of the world map and the different zones that must be crossed: The zones themselves and the order they occur in the map will be fixed in every replay of the game, but the contents of each zone - the placement or rivers, monsters, trees, etc will be different each time to increase re-playability. The North/South dimension of the map is figured out, but the East/West options are open: Thin map. The player is prevented from traveling very far east or west. This will seem somewhat unrealistic but will increase the challenge. The thin map limits the paths a player can take North and will force the player to sometimes *have* to pass that difficult monster/obstacle. Wide map. Width of map still limited but the player has more choice of paths to take North. This means the player can avoid tough challenges, retreat and take another route North. A wider map also increases the explorable content of a zone. Infinitely Wide Map. The player can travel infinitely east or west. Map generation would have to be on-the-fly. No "unrealistic" physical barriers. Looping Map. If the player travels far to the East they eventually come back to where they started. Advantages: No physical barrier to east and west is required and the map can be pre-generated. The big disadvantage here is that a looping map is harder to implement and lots of edge case (literally) testing must be done to avoid catastrophic bugs. I'll probably avoid the exotic "infinite" and "looping" solutions and just make a limited width map of configurable width. I can always change this later right? Lets see what the gameplay is like before deciding this. Plains Zone Each zone has very different content. The desert zone for example won't have rivers, while the forest zone will have occasional rivers and a lot of trees. The lake zone will have loads and loads and loads of water and perhaps a few islands. It makes sense for there to be a separate generator for each zone, so I have decided to focus on the generator for the plains zone to begin with. What is in the plains zone? The plains zone is where the player starts. It is meant to be the easiest zone. Here's an image depicting my initial idea of what plains zone will look like: Lots of grass with clusters of trees. East/West rivers with occasional bridges or fjords to cross them. Small lakes/ponds. Large rock outcrops containing caves. Villages or huts (not sure if they will be inhabited). In this zone there would be a lot of food/water available and other resources. The above image is only a small amount of the zone's height extent. The actual zone would go on much further south/north than the above image. It would take the player many game days to cross a zone. In the South of the zone the monsters would not be very threatening (small wild dogs, foxes). Further North some of the caves might have a defensive bear in them and there might be the odd wolf about during the night. Even further North there would be large dangerous bears roaming about during the day and packs of wolves at night. Constraints Take a look at this map and imagine it was procedurally generated: There's no route North. The player must cross the river, but there are no crossing points and the player has no boat. A wider map reduces the chance of such an obstruction happening. A longer zone increases the chance. In any case the game map generator must never create cases like this. There are three solutions I thought about for guaranteeing a zone will be passable: The generating algorithm has the responsibility not to create impassible output. This is quite hard and it is prone to error. I don't want to have to (ie can't) mathematically prove an algorithm won't create impassible output. Test each zone the generating algorithm produces. If it's impassible then chuck it out and generate a new one. This solution works, but in dense zones there could potentially be a lot of chucking out and processing time spent testing maps. After generating the map, trace one or more random North/South paths through it. Either go round obstacles or destroy them. I'll probably go with solution #3. It guarantees a path through the map and doesn't require an exhaustive test. Here is an example of 2 guaranteed paths being created through the map: This is adequate for the plains zone where the obstacles are sparse. In the remote chance of an obstructive barrier as above the player can easily hunt east and west for the path through. For more denser zones (eg thick forests) this solution will not be adequate as it will lead to the creation of Mazes with numerous Dead Ends and only a few solutions which are frustratingly hard to find. The player may have to backtrack miles back South to get back to the right path. If they have to do that the game has failed. The solution for denser zones will probably be to divide the zone into a grid and make sure each neighboring grid tile has a short connecting path. Ie to trace paths horizontally as well as vertically. Pre-Generating vs Generating On-The-Fly The main benefit of on-the-fly generation is to support infinite maps. I have decided not to have infinite maps so the only remaining benefit of on-the-fly generation is to reduce pre-generation time at the start of the game. However that's not really a big deal. It's a once-only task which takes a relatively short amount of time compared to how long you will be playing in that world. The disadvantage of generating the map on the fly is that the map generation algorithm gets more complicated. So I will stick with pre-generation for now. I am actually a fan of world generation at the start of the game. It makes it seem like something cool is being made for you to play. The generation at the start of Dwarf Fortress where it creates the world and it's history is pretty cool. Also weirdly I like the idea that the game world exists in it's entirety. Far far to the North there are already structures set in stone. There might be a terrible monster on the map somewhere. There's something cool about being able to (in the debugger at least) ask where that monster is. In contrast knowing that the world is being randomly built as I travel makes it seem less real. Although from the point of view of the player it makes no difference of course.
  7. yes that's a lot more intuitive as it's like a skeletal structure and could probably be understood without displaying it. Perhaps there's a middle ground where instead of white arrows that are obviously an overlay there could be tubing on top of the ships hull that matches the skeleton but is part of the ship.
  8. [left]It looks good. I doubt I could make anything like that, so my criticism next is from a player point of view rather than a development one. [/left] [left]The ships [i]look [/i]like all neighbouring elements are connected to each other. The player cannot see how the connections are actually winding paths. This means from the player's point of view the breaking reactions to shots appear unintuitive. If I felt this was just my personal opinion I wouldn't say anything, but I suspect a lot of players will have the same opinion about it. [color=#282828][font=helvetica, arial, verdana, tahoma, sans-serif]I[/font][/color][font="helvetica, arial, verdana, tahoma, sans-serif"][color="#282828"]t isn't obvious why a single shot in one place will split the ship in half but a shot elsewhere has no effect. Perhaps you are planning something to alleviate that, although I doubt anything could.[/color][/font][/left] [left]You say you want the ships fragile which I understand, but cant you achieve the same effect by connecting all elements to their neighbours and allowing attacks to "chew through" the body until they cut through? The interior elements of a ship could be slightly or very explosive so once you've chewed through the hull layer you could "split" a ship in half really quick.[/left] Anyway that is supposed to be constructive criticism although I realize it is annoying in suggesting a system you've worked on for days is redone.
  9. I have come up with the rough idea for the game. Gameplay will take place almost entirely on the surface. I made a quick prototype that gives a very rough idea of the kind of top-down terrain view the game will take place in. Ignore the lighting/textures/framerate...and in fact the gameplay... [media][/media] The actual plan for the game (which isn't really shown by the video) is: Pre-historic wilderness setting. The objective of the game is to travel to a place far to the North. There will be some weak plot excuse to justify this, but that doesn't matter so much. The further North the player goes, difficulty will increase. So it's like a sideways version of traveling down into a dungeon. There won't be level transitions, the map will be continuous and loaded as needed. Permadeath. If you die you can't reload. Your score is how far North you get. The game is about survival, not hack and slash. If you can make it north without fighting a single monster (you won't be able to) then you still win. As you head North you will have to cross progressively harder environments with their own environmental challenges and monsters. The starting zone will be easy, perhaps a warm grassland with few dangers. Further North the zones will get harder with additional hazards. Eg ice mountains, a desert, a jungle, a dense forest, a huge lakes, perhaps even a section where you have to cross underground through a mountain. The zones themselves will be at the same "latitude" north in each game, so the player can have some achievement from just reaching (or surviving) a zone. But the contents (terrain, monsters (placement not type), etc) of the zones will be randomly generated. Monsters will include realistic natural animals, eg wolves, bears, crocodiles, dinosaurs? and made-up ones. No high fantasy creatures like goblins. No magic. I don't see any need. There may be skills like tracking No XP from killing monsters. Kill them either for food, resources, survival or fun. You need to sleep occasionally. A lack of sleep will be penalized (reduction of speed, sight radius?). You decide when and where to sleep. You are vulnerable to attack while sleeping. You can reduce that chance by sleeping next to a fire or in a shelter. You find/construct tools and clothing to help your survival. eg a torch can scare off some creatures, thicker clothing will protect you from colder times/places. Day and night transitions, seasons and weather affect gameplay. Some creatures will be nocturnal. Some creatures will hibernate during the winter. At night it's colder, during winter it's colder, during storms it's colder. If it's too cold you will take damage, to prevent that you either wear thicker clothing, take shelter or build a fire. You can construct shelters to protect yourself from the environment. Simple ones like tents are quick to make but provide minimal protection. Bigger ones like log huts take more time and resources. Different zones have different hazards. For example in a desert thirst is an environmental hazard. The player will need to find or carry supplies of water which will be rapidly exhausted. In zones with plenty of water it is assumed the character can handle thirst themselves. In the mountains storms and extreme cold are hazards. The player is killed for mistakes they can learn from rather than by the random number generator. I can't prevent RNG deaths full-stop but I want to reduce them. The game is about increasing the odds of survival. Doing really dumb stuff will dramatically lower the chance of survival - eg crossing a desert without a supply of water, or diving into a random pool of water in the jungle, or attacking a bear with a stick. Making less obvious mistakes will lower the chance of survival - eg wandering around in a storm wearing metal might just get you killed by a lightning bolt, sleeping in the open without a fire (or even sleeping in the open with a fire if there are human hunters about) The player can balance how fast they head north. They could try to rush. Or they could move slowly through build-shelter/explore cycles. On reaching the lake zone the player might decide to build a boat and risk the crossing, or they might decide to take a very long trip round the lake risking all the shore based predators. Or they may decide to build a really strong shelter, wait for winter and then walk across the frozen lake.
  10. Thanks for all the help everyone, I will do things in an Agile fashion then. I have roughly designed the game plot, etc now, but you are all right I shouldn't go so far as some kind of waterfall model but implement pieces of the game at a time. I guess if I end up implementing a feature I end up removing later that's just part of the testing/learning. Also thanks about the 1024x768 recommendation. 800x600 people are probably the kind of people who can tolerate cramped screens anyway.
  11. I'm going to make a game...<INSERTS CODE> but seriously an RTS is a nice idea. Now I wish I was making an RTS too. Maybe my next project (ie 2014). You going to make it singleplayer or multiplayer?
  12. That's really cool, for some reason it reminds me of that youtube video of two cats fighting and then a dog runs in and breaks it up it also makes me wish I wasn't making a turn-based game...
  13. "I also discovered how addictive Minecraft can be." It can be dangerous stuff trying new games. I probably spent 1000 hours on minecraft in the last 2 years. No exaggeration (possibly an under-exageration). Multiplayer of course, singleplayer is only addictive for a week or two. Have stopped now though, not because I got bored, but because I wanted to work on more productive stuff (learning guitar, writing a game) Some people say they get bored in their spare time. Seriously? I wish I could have 100 lives lasting 1000s of years and run them all in parallel. In one I would be playing quake2 all day, in another I would be playing minecraft all day, in another guitar all day, in another I would do something "social", etc...the list goes on.
  14. "I've had a tough couple of days coding... It's just been one of those times were you run into a wall and get discouraged. Partly because of difficulties in keeping the code within their well-defined boundries and keeping them from becoming inter-dependant on one another when I don't have a clear plan for how things will be written. Class and function-level code design is easy, but overall arcitecture level is harder for me. I guess that's the important difference between a software arcitect and a code monkey. =D" Tell me about it. That's my exact problem too. I can waste hours, days, even weeks on architectural problems. The trick IMO is to not do that. So I allow the odd boundary violation rather than spend ages thinking on a possibly unobtainable architecture (not all problems have solutions). I am fine with an 80% perfect architecture. I might improve it later, I probably won't. I just find a way to live with it. In terms of justifications I tell myself it's good to be more relaxed if you are working on an internal project anyway, otherwise you are missing out on a very big advantage of not working in a team! In my opinion half the by-the-book stuff on code design is a waste of time for internal projects anyway. For example Notch recently said: "I still stubbornly believe the whole “private members accessed via accessors” thing in java is bullcrap for internal projects. It adds piles of useless boilerplate code for absolutely no gain when you can just right click a field and chose “add setter/getter” if you NEED an accessor in the future." [url="http://notch.tumblr.com/post/15782716917/coding-skill-and-the-decline-of-stagnation"]http://notch.tumblr.com/post/15782716917/coding-skill-and-the-decline-of-stagnation[/url] And he's right. So why am I still writing accessors? Ah....I dunno. I like them I guess. An exception to the exception to the rule. One rule I violate, although not architectural, is putting an underscore before every private member variable name. A year ago I was venomously opposed to doing that. Why? Because the C# guidelines said don't do it. But since then I've changed my mind (due to being forced to use underscore prefixes at work) because I find it very useful to be able to distinguish local variables in function bodies from private member variables.
  15. Very unproductive week for the game but I think I have learned something about game development. I wasted it thinking about the UI. Why? The current UI is a mess. At 800x600 resolution with all the various windows open you can't see the dungeon: So I was trying to figure out how to reorder it all. What windows do I need? How do I divide it into different screens with shortcuts? Do I need a hotbar? If the user is in a shop does the floor need to be visible? Should the message log be minimal but expandable? etc. I kept hitting the same brick wall - I can't answer a lot of those questions until I know what game I am making. For example I was wondering how the user would put spells a hotbar, but that depends on, among other things, how many spells there will be. I haven't even worked out the spell system yet (or even decided if I will have spells!) So I have reached this conclusion: Design the game before making it Until now I have been trying to make an enginey kind of sandbox and worry about what game I am making later. I know I am making a rogue-like but what is the setting? (medieval? sci-fi? fantasy?). Does it have magic? What is the skill system? What is the XP system? What items will there be? What monsters will there be, etc. How does it all fit together? That's the key part: fitting it together. If I just implement things separately. they won't tie together. I mean that's how minecraft was done and while it's one of the best games ever I think a general weakness of singleplayer is that there was no focused game, just cool bits and pieces being added on in each update. Eg wolves, how do they really fit into the game? I don't expect to be able to design the game completely up front. There will be discovered problems and new ideas that will modify things, but even with a rough design it will be much easier to prioritize things, faster to develop and the game should be better at the end. I can also bounce the rough design off people who might turn round and say "no way that sounds boring!" and then I can go ahead and do it anyway in defiance. So next post will outline exactly what the game is, the setting, the ending, all of it. How do other people do all this? Do you already have a 90% complete game design written down?