|
ichibanMuffin posted:Does anyone have any advice about what to read about ways to put together a game engine from scratch? I'm probably going to be in the minority, but for me, writing your own engine is not that difficult as long as you're disciplined. Firstly, you MUST write a design document. If you don't know your game inside-out before you begin coding, you're going to give yourself a lot of headaches. If you're a CS major you've probably already been taught this and promptly disregarded it because it's not cool. You're right, it's not cool, but it is vital. Writing a design document takes time, but to my mind, is one of those things where the rewards are equal to the effort you put in. When writing it, you'll invariably change parts of your game when you start to see the bigger picture and how things interact, and you'll have to re-write large chunks of the document several times. These are the same changes you'd have to make if you started coding blindly. The difference is it's hell of a lot easier to re-write a document than it is to re-write code. Once you've finished the design document comes the hard part and the discipline. You must not change the design! Seriously, you have to have a point where you say "that's it. That's the game I'm going to make and nothing more". Of course you'll have to make minor changes because of unforeseen things, and probably changes to balance the game when it’s playable, but these are small things that your engine should be able to cope with easily. If, however, mid-way through development you come up with some awesome game-changing idea DO NOT IMPLEMENT IT NOW. Write it down, leave it mature and if it's still as good as you thought, congratulations, you've got an update/expansion/sequel. The point is, you don't add it now or you'll never ship. So now you know what you're writing an engine for, do just that. Write an engine exactly for your design. Do not try to write some reusable, general game engine that you can use for future games; write an engine for your exact requirements. Use magic numbers, take shortcuts, don't try to guard against things that can't happen in your game (but may happen in the general case). Optimize for productivity. When you write your next game, you start again. Now to the crux of your problem - designing the architecture. It has been alluded to already, but there is no catch all game engine design. And this is particularly true if you follow my suggestion above of writing the engine for your specific game design. My guess is what you really need, is to learn a couple of useful ideas for designing software in general. There's an almost infinite amount of literature on the subject of designing software, but I've found there are a few core ideas that I always fall back on, and things I use all the time in my own programs. For me, the following are priceless and used comprehensively throughout my own engine and every commercial program I've worked on: Interfaces/Protocols Double dispatch Strategy design pattern Template design pattern Factory design pattern Abstract design pattern seiken mentioned that you should start with an engine of size N, and use the experience and knowledge gained on your next project. Ultimately, this is the only way to do things. Experience is the key ingredient to making anything and it's no different for programming. I suggest reading the Quake, Quake II, Quake III, and Doom 3 code reviews and see how id Software evolved each engine based on the experience of the previous one. If you understand C, you can even get the source code from github and take a look yourself. Many people will disagree with what I've written, and that's fine. These are just the things I've found in my years as a software engineer that help ease programming complicated software. tl;dr You need a solid game design, discipline, knowledge of software design, and experience to write a scalable game engine.
|
#
?
Oct 5, 2012 09:09
|
|
|
|
| # ? May 12, 2024 15:18 |
|
|
Posts like the above always make me feel like a Bad Coder.
|
|
#
?
Oct 5, 2012 10:30
|
|
|
Vermain posted:It's likely just familiarity talking. v  The primary advantage of Game Maker, speaking as an outsider, is that it primarily uses a scripting system for added flexibility and actual programming, and that shitloads of people use it so there's a lot of support and documentation out there. I'm sure somebody else could provide a better explanation.
|
|
#
?
Oct 5, 2012 11:12
|
|
v I've been using MMF and its predecessors for something like ten or eleven years, now, so the event editor and etc. are all second nature to me.
|
Ularg posted:What IDE would be recommended? My friend who does coding for a living recommended me Eclipse. Eclipse, Vim, Visual Studio are all terrible IDEs to start with. I mean, they're great once you know what you're doing, but they're horrible complex and confusing until then. Just grab Notepad++ for now, assuming you're on Windows. Since you've done some learning with Javascript, why not make an HTML5 game? Or, get something working in HTML5. Specifically, pick an engine from this list and start messing with it. Ideally, something that has API and tutorials. GameJS seems like a good option: http://gamejs.org/ (download the Option 2: zip file) Follow some of the examples and tutorials, and get a square moving around the screen with the keyboard. Next... I dunno, make Pong or something.
|
|
#
?
Oct 5, 2012 12:02
|
|
|
Do any of you know of a good 3D modeler, preferably one that can export to DirectX? I've tried using Blender, but I've heard that the exporting script it comes with isn't very good.
|
|
#
?
Oct 5, 2012 12:18
|
|
|
Harold Krell posted:Do any of you know of a good 3D modeler, preferably one that can export to DirectX? I've tried using Blender, but I've heard that the exporting script it comes with isn't very good. It has been a while since I've been up to date with 3d tech though.
|
|
#
?
Oct 5, 2012 14:03
|
|
|
HelixFox posted:Posts like the above always make me feel like a Bad Coder. Pretty much everyone is a Bad Coder, don't worry about it too much. The thing about that stuff is that it is the right way to do it - but if you can get stuff done without it, then you're still producing something and so that's still better than someone who does it the "right" way and never gets past the documentation phase. That's not to say that if you can get stuff done you should just ignore the things Regalia mentioned; you should ALWAYS strive to do a better job. You don't have to be perfect, but you should still be aiming for it.
|
|
#
?
Oct 5, 2012 14:45
|
|
|
I get three months into a piece of software and start thinking about things I am going to do differently next time; it's just important to save that for "next time" and ship the product I'm working on as it is once it's done. Next time stuff is for next time, not this time.
|
|
#
?
Oct 5, 2012 14:55
|
|
|
The Cheshire Cat posted:Pretty much everyone is a Bad Coder, don't worry about it too much. The thing about that stuff is that it is the right way to do it - but if you can get stuff done without it, then you're still producing something and so that's still better than someone who does it the "right" way and never gets past the documentation phase. Making an engine from scratch is such a waste of time in my opinion. You can spend all the time you'd use making something from scratch and turn those into features, or more games, or time with the family. Even just editing in the special stuff you want for your game to an existing engine is way faster than doing it from scratch.
|
|
#
?
Oct 5, 2012 14:55
|
|
|
Juc66 posted:Making an engine from scratch is such a waste of time in my opinion. All these engines available use technologies I have no understanding of. I'd spent way too much time in trial-and-error if I tried to use existing stuff. I'm pretty happy with where I'm at at the moment in my project being made from scratch.
|
|
#
?
Oct 5, 2012 15:02
|
|
|
Juc66 posted:Making an engine from scratch is such a waste of time in my opinion. ... but I'm inclined to agree, if your goal is just to make a game. Even if making your project in Unity or equivalent saves you no time, you can immediately post the result on the web for instant feedback, release it to Mac/PC/Linux without extra work, etc. That said, there's also the argument that custom tech leads to different games. I seriously doubt Mug's game would look as distinct as it does if he'd built it in Unity, and it might not be as "clean". Unity gives you, for instance, physics by default - which hangs a lot of people up, and they start adding physics puzzles or physically-active characters for no reason. EDIT: basically, "it depends" Shalinor fucked around with this message at 15:14 on Oct 5, 2012 |
|
#
?
Oct 5, 2012 15:10
|
|
|
Shalinor posted:physically-active characters for no reason. Now I want a game where you just roll fat people around.
|
|
#
?
Oct 5, 2012 15:32
|
|
|
Juc66 posted:Making an engine from scratch is such a waste of time in my opinion.
|
|
#
?
Oct 5, 2012 15:57
|
|
|
thedaian posted:Eclipse, Vim, Visual Studio are all terrible IDEs to start with. I mean, they're great once you know what you're doing, but they're horrible complex and confusing until then. Just grab Notepad++ for now, assuming you're on Windows. Oh cool, thanks. Do you think I should take some lessons on HTML/CSS and then JQuery that I found on the same site I learned Javascript from?
|
|
#
?
Oct 5, 2012 16:07
|
|
|
CSS lessons won't hurt, but literally every question you could have about getting effects or specific layouts can be answered with a google search.. there are massive quantities of tutorials out there, and they tend to be easier to understand than most programming samples.
|
|
#
?
Oct 5, 2012 16:16
|
|
|
Orzo posted:Define 'engine'. Because the more high level an engine is, the more freedom and control you sacrifice when making your game. It is almost guaranteed that using an engine will eventually lead to the inability to implement certain features, even if the engine is open-source. If this is cool with you (and it often is) then go for it. But there are advantages to rolling your own, so it certainly isn't a 'waste of time' as you put it. It's also a great learning experience and can help teach you how to handle complex organizational problems and abstractions, both very important skills in programming. Agree with this. Instead of using flixel or something for my AS3 platform games I wrote my own platform engine that is roughly equivalent. Adding in new features is pretty simple because I know how it all works, plus I was able to build a kickass editor alongside it so making new levels is easy as poo poo. Also, I can support things that flixel doesn't, like sloped surfaces. As an aside, this Sonic physics guide is a pretty amazing resource for anyone wanting to put together a 2D engine (not just platformers - I've made top-down shooters using the methods in there)
|
|
#
?
Oct 5, 2012 16:27
|
|
|
Orzo posted:Define 'engine'. Because the more high level an engine is, the more freedom and control you sacrifice when making your game. It is almost guaranteed that using an engine will eventually lead to the inability to implement certain features, even if the engine is open-source. If this is cool with you (and it often is) then go for it. But there are advantages to rolling your own, so it certainly isn't a 'waste of time' as you put it. It's also a great learning experience and can help teach you how to handle complex organizational problems and abstractions, both very important skills in programming. The engine is the main game loop, event scheduling, garbage collection, and other such super generic needs. Writing that over and over from scratch with the intent of not reusing code is weird. Writing an engine from the bottom up, once, is useful if you want to be a software engineer in a game studio, or just in general. But if you're aiming to be a designer of some sort or an artist(even a tech artist) you don't really need to know how a bitmap is structured or even how to display one. Actually even as a software engineer, working on game logic, you'll spend most of your time adding features or modifying an existing engine. As an example I think mass effect 1 was something like 2/3 original code with the other 1/3 being unmodified ue3. So using something that already exists and bending it to your will is pretty handy experience too. So as practice / a learning experience I think making an engine is ok, but as a regular workflow I think it's a waste. Juc66 fucked around with this message at 18:58 on Oct 5, 2012 |
|
#
?
Oct 5, 2012 18:52
|
|
|
Juc66 posted:The engine is the main game loop, event scheduling, garbage collection, and other such super generic needs.
|
|
#
?
Oct 5, 2012 19:04
|
|
|
Orzo posted:By your logic here, using C# or Java to program a game is using an engine. Garbage collection is typically handled by the language, as is 'event scheduling'. Main game loops are trivial and if you can't make that yourself, well, you probably shouldn't be programming at all. As for how to display a bitmap to a screen, that is sort of what I was getting at when I said 'define engine.' A framework is not an engine, and I'd argue that a library that helps you display images to a surface of some sort is not an engine at all. Nor is a library that plays sound and music, or one that runs physics simulations, etc. Who really cares what the exact definition of an engine is. My point is that you can get the tedious crap done for you in some form 90% of the time, and doing that stuff repeatedly is a waste of time, time you can spend on literally anything else. There's no need to constantly reinvent the wheel, and when you do make the odd super-wheel improvement, never reusing the code is nuts. As in I seriously think you'd be crazy, to intentionally make things unusable in more than one program. Hell if you're using unity you can even sell your new and improved wheel and make more from your efforts.
|
|
#
?
Oct 5, 2012 19:25
|
|
|
Juc66 posted:Who really cares what the exact definition of an engine is. I don't think it's a good idea for someone who has clearly never written a game engine, or even knows what one is, to bestow upon us the virtues of not writing one. It seems your commentary is based entirely on some fictional idea of what an engine, and indeed, what programming is.
|
|
#
?
Oct 5, 2012 20:25
|
|
|
Regalia posted:I don't think it's a good idea for someone who has clearly never written a game engine, or even knows what one is, to bestow upon us the virtues of not writing one. Such vitriol, being angry about it doesn't make working from scratch any less of a waste of time or money though. I don't really know your history and you obviously don't know what I do or have done, insulting me isn't really going to convince me you're right, even if you're actually gaben.
|
|
#
?
Oct 5, 2012 21:42
|
|
|
Juc66 posted:Who really cares what the exact definition of an engine is. quote:My point is that you can get the tedious crap done for you in some form 90% of the time, and doing that stuff repeatedly is a waste of time, time you can spend on literally anything else. quote:There's no need to constantly reinvent the wheel, and when you do make the odd super-wheel improvement, never reusing the code is nuts.
|
|
#
?
Oct 5, 2012 21:42
|
|
|
Orzo posted:This is a thread for discussion about making games. When the discussion is about whether or not to make your own game engine and Person A interprets that as, for example, Unity, and person B interprets it as SlimDX and FMOD, I think it helps to get an idea of what we're talking about. And when person C is talking about 'garbage collection' in the context of a game engine then yeah there's a serious communication problem. Unreal Engine 3 has garbage collection as a major source of headaches, bullshit, and other wonderful behaviours. You even can use the engine to force garbage collection sweeps while you're in-game if you need to force the behaviour. I'm not saying it's a part of every engine by any means, but it's not off in la la land of imaginary items I pulled out of my rear end, and hell it was just an example anyway. the part I'm taking issue with is partway down regalia's pretty good post (sorry for the lack of proper quote, I broke it somehow and I'm too lazy to fix it) "So now you know what you're writing an engine for, do just that. Write an engine exactly for your design. Do not try to write some reusable, general game engine that you can use for future games; write an engine for your exact requirements. Use magic numbers, take shortcuts, don't try to guard against things that can't happen in your game (but may happen in the general case). Optimize for productivity. When you write your next game, you start again. " That's financially unsound advice most of the time. The more time you save, the more money you save, and the more money you save the more you have available for marketing, art, audio, and anything else your game will need. I liked the rest of his post though.
|
|
#
?
Oct 5, 2012 22:23
|
|
|
I think the point he was trying to make is that if you are set on doing something from scratch as a learning exercise, which I was (because I had tried before and got swamped by complexity it spiraled into), that when doing it a second time I shouldn't waste time making things generically and pre-optimization, but rather focus on completion and simplicity. This engine is to be used and thrown out because it will be probably unrecoverable for anything else; too specialized for one task, but it took very little time to make it for that one task. That when I'd work on the next project, I'd have a realistic idea of what to make generic and how generic it should be, how to better put things together, instead of trying to decide before I had any experience doing it before. This engine I may keep, or throw out too depending on the problems I encounter doing that. The focus of which is that making an engine from scratch is a learning experience in architecture design that apparently is best learned from experience. I asked for advice on it and got some. It isn't to just make something as quick as possible; eventually I'd do that later to optimize for time and money. But for now it's to get the experience necessary to get a foot in the door in the industry. A new question: Should I at any point worry about multithreaded programming if I was designing from scratch? I've had experience doing it but unless I am making a AA or even a AAA game I fail to see any benefit from doing so. I'm also pretty sure that all retail engines out there already do it, at least for the standard 4: Input, Loading, Update, and Drawing. Then again beyond bizarre race conditions (probably the most significant being avoiding drawing something that is updated in the middle of the draw so it becomes misaligned, i.e. tearing) I don't imagine it'd be that difficult to set up at all. ichibanMuffin fucked around with this message at 02:20 on Oct 6, 2012 |
|
#
?
Oct 6, 2012 02:11
|
|
|
Ularg posted:Oh cool, thanks. Do you think I should take some lessons on HTML/CSS and then JQuery that I found on the same site I learned Javascript from? It's probably worth learning some basic HTML and CSS, though you might not need too much of it unless you really get into building huge massive web games. You mostly just need to learn the basics so you can make a simple webpage and stick your games on it. jQuery might be good, but not really needed unless you want you game to interact with elements on the webpage. Juc66 posted:Unreal Engine 3 has garbage collection as a major source of headaches, bullshit, and other wonderful behaviours. You even can use the engine to force garbage collection sweeps while you're in-game if you need to force the behaviour. The problem is that garbage collection is almost always a feature and function of the language being used to make a game, and it's never really considered part of a game engine. Something like Unreal has it exposed because it's generally way more complicated most game engines that're being made by small teams. Also, whether or not it's worth making your own engine depends highly on what you plan on doing with your game. If it's just a hobby, go hog wild, make your own engine. But if you're trying to do this for a living... well, you're better off using an existing engine or library to help you get there faster. But at the same time, any engine is going to have limits, and some games might have problems with those limits, and sometimes, it's better to make your own engine than to spend hours fighting with Unity or Unreal or Flixel because it doesn't support the one thing you need to make your game.
|
|
#
?
Oct 6, 2012 05:41
|
|
|
I made a "Main Menu" today, finally. It runs as part of the main game loop so the game just keeps running in the background in a kind of screensaver mode. If you're in your "home" area, the camera zooms in a bit and shows you random stuff that's happening about the place. If you're in a mission, the camera zooms in a bit and just cycles between your player characters. Works good, feels good. I've made a logo for the game now, too. It's the first time I've ever actually written down the game's actual name anywhere. Hoping to go into alpha sometime soon and actually announce a "game" to the world.
|
|
#
?
Oct 6, 2012 08:19
|
|
|
Juc66 posted:the part I'm taking issue with is partway down regalia's pretty good post Ok, that's fair enough but we same to be arguing about the same thing. We're both trying to save time and boost productivity. You're arguing for reusable generic code, which (possibly) saves you time in the future, and I'm arguing for taking shortcuts and coding only for your requirements, which saves you time now. You may not have checked out the two links that are embedded in the quoted statement, but they're there to clarify the point I was trying to make. The first link, a xkcd comic, which meant to point out that making something generic does not necessarily save you time because you have to spend a lot more time developing it in the first place. You have to make sure it works for all the corner cases and possibilities that may not even be possible in your game. I'm not saying its a wasted effort all the time, but it can be. The second link is a talk by Jonathan Blow (of Braid fame), in which he speaks about optimizing for developer productivity. The talk is too long for me to repeat here, but its worth a listen and may clarify my point. In my opinion, indie games in general are too small to gain much from making code generic as it is often far quicker to write for your specific needs, rather than for every game you might make sometime in the future, maybe. Code for what you need now, not for something that may never happen. In my experience, it's usually a waste of time.
|
|
#
?
Oct 6, 2012 08:44
|
|
|
Is time a big concern for you guys?
|
|
#
?
Oct 6, 2012 08:50
|
|
|
Those whole discussion is kind of daft. Don't make engines, make games. Summary: your indie game does not need an "engine". If you want to make your game in unreal or unity or whatever that's another story but if you're doing things yourself: forget about the whole concept of a having an "engine" because it will only hinder you. If you have not completed a whole bunch of games any "engine" you write will be completely useless for using to make any nontrivial game. If you are sensible and write a game rather than an engine, whatever "engine" parts of it you might be able to extract will be (mostly) useless for making any nontrivially different game. Also, "engine" doesn't really mean anything. Making a game mostly from scratch is not at all a waste of time as opposed to using unity or unreal or whatever. vvv good attitude! seiken fucked around with this message at 16:22 on Oct 6, 2012 |
|
#
?
Oct 6, 2012 12:11
|
|
|
I just like coding for games. Don't really care if everything's hard coded or abstracted perfectly. Just wanna make games.
|
|
#
?
Oct 6, 2012 15:29
|
|
|
Yesssss... more of things like this. That article even links to a rant on Singleton abuse. I love such articles, if you have more.
|
|
#
?
Oct 6, 2012 16:05
|
|
|
Mug posted:I made a "Main Menu" today, finally. It runs as part of the main game loop so the game just keeps running in the background in a kind of screensaver mode. If you're in your "home" area, the camera zooms in a bit and shows you random stuff that's happening about the place. If you're in a mission, the camera zooms in a bit and just cycles between your player characters. I'm not sure if you came up with that idea on your own but it actually matches a nice bit of advice I'd read in a "Learning game design in C#" book a while ago. Essentially it recommends having your different modes (like menus, tactical view, etc.) loaded into a stack in your main game loop. The main loop then always processes the topmost item in the stack, and pops it off when you leave that state, letting you pick up from the previous one exactly where you left off. I guess since what you described keeps the main game running it's slightly different, but it's a similar idea - with yours it's just processing the whole stack instead of the topmost item.
|
|
#
?
Oct 6, 2012 17:51
|
|
|
So, it's Saturday, and that means screenshots. I added a floating tooltip to my game whenever the user has the "query" tool selected. It's basically an easy way to quickly display info to the user, and was inspired by Prison Architect.
|
|
#
?
Oct 6, 2012 17:55
|
|
|
At first I was kinda ambivalent about the office elements you're using, but then I realized that if you could apply that lo-res smooth CG to any "people" models you might use, you'd have a sweet pre-rendered-forms-on-an-N64 aesthetic goin' on like they had in Harvest Moon 64, and that's probably one of the nicest-looking games on that system if you ask me. For my Spritesheet Saturday, this is how the story segments are handled, finally put into use as of like twenty minutes ago. I was thinking pretty Ninja Gaiden-ey in concept. Those scribbles in the back change a bit every .25s to give a crayony illusion. I'm considering erasing their edges to make them smooth roundish shapes instead of white rectangles. I might make a in-engine story dealie too, but I'm thinking scripting them might be more trouble than it's worth.    I'm secretly a linguist by trade, and even if I'm not the biggest fan of Tolkien's post-linguistics work, I can respect his passion for language and fully fleshing out made-up ones. Call me insane if you like, but yes, "mwrrrshwrnlmnghwf" checks out 100% syntactically: mwr (3p male) - rr (preceding NP commits following VP) - shwr (really, totally... emphatical, basically) - nl (preceding ADV modifies following word) - mn (present tense) - gh ("be" verb) - wf (negative) ("He totally isn't")  ... Yeah, I did misspell this one, I put in the -mn- between the -rr-. It's a fake unpronounceable language, gimme a break haha. It's not as bad as it sounds, it only took like an hour to come up with a healthily wide list of relevant grammar rules Fur20 fucked around with this message at 20:43 on Oct 6, 2012 |
|
#
?
Oct 6, 2012 20:33
|
|
|
Guess I'll post my project too:  WIP, of course. And all of the graphics will eventually be replaced. It's planned for WP7 and XBLIG but I want to port it to Android and iOS too.
|
|
#
?
Oct 6, 2012 21:15
|
|
|
Ah, saturday and the screenshots it brings.
|
|
#
?
Oct 6, 2012 22:38
|
|
|
The White Dragon posted:At first I was kinda ambivalent about the office elements you're using, but then I realized that if you could apply that lo-res smooth CG to any "people" models you might use, you'd have a sweet pre-rendered-forms-on-an-N64 aesthetic goin' on like they had in Harvest Moon 64, and that's probably one of the nicest-looking games on that system if you ask me. I'm actually going to have to get rid of the current graphics. They're pretty amazing (and were made by a goon), but I've been stupid and lost contact with the person who made them, and there's no way I can keep up the level of art. I'm going to go with something simpler, mostly pixel/line art type stuff. The game's designed to be super customizable, though, with all the assets stored in external files as much as possible. I want people to be able to mod the game (within reason) The story segments look awesome, plus the whole "actually real fake language" thing is cool (and something I've always wanted to do)
|
|
#
?
Oct 6, 2012 22:58
|
|
|
the chaos engine posted:Ah, saturday and the screenshots it brings. Also, those are totally strawberry floating islands. EDIT: VV "Delicious Triangles" would be an awesome game name. Also, this really does look great - don't take my strawberry comment as any kind of slight. Shalinor fucked around with this message at 00:12 on Oct 7, 2012 |
|
#
?
Oct 6, 2012 23:37
|
|
|
Shalinor posted:This looks awesome. From delicious squares to delicious triangles. Artistic progress.
|
|
#
?
Oct 6, 2012 23:45
|
|
|
|
| # ? May 12, 2024 15:18 |
|
|
The Cheshire Cat posted:I'm not sure if you came up with that idea on your own but it actually matches a nice bit of advice I'd read in a "Learning game design in C#" book a while ago. Essentially it recommends having your different modes (like menus, tactical view, etc.) loaded into a stack in your main game loop. The main loop then always processes the topmost item in the stack, and pops it off when you leave that state, letting you pick up from the previous one exactly where you left off. Yeah I just have one loop and the main menu is just a tiny part of the DrawWindows function. The main menu is just a window that affects the camera. Even loading a new map is part of the main loop. thedaian posted:So, it's Saturday, and that means screenshots. I added a floating tooltip to my game whenever the user has the "query" tool selected. It's basically an easy way to quickly display info to the user, and was inspired by Prison Architect. This reminds me of Hostile Takeover from Laserbrain http://laserbrainstudios.com/games/ edit: To elaborate on what I said about loading levels using the main game loop, it's actually causing to be quite tricky. When I want to move to the next level, all that happens is I set MetaCampaign.Name = "newmapfile", MetaCampaign.Loaded = FALSE. The game-loop steps in and flushes out the old map and loads in the new one next time the loop starts over. It's trucky because the "Flush" part has to be done by hand, I have to make sure I propperly reinitialize all the clipping planes, the AI actions, all the pathfinding banks, creature stats, etc. At the moment there's some kind of problem where I move from one map to another and my character seems to inherit some AI from something in the previous map and I lose control of it. You see it happen at the end of my 6 month video. Gonna be hard to work out exactly what I'm failing to flush properly. Mug fucked around with this message at 01:01 on Oct 7, 2012 |
|
#
?
Oct 7, 2012 00:40
|
|