Outpost 2-LIKE game - Community Input requested

[leeor_net]

Practice with the language... it's kind of an understatement. As much as I love C++, it's a real pain in the ass to work with sometimes. But you begin to learn its quirks and when you develop code you know exactly what caveats to watch out for.

That said, I say go for it. If you've got a good plan of action and have realistic goals, don't let others judge you. Just make sure the goals are realistic and attainable. When I started with Outpost 3: Genesis, I made the mistake of setting unattainable goals for myself. I'd never worked with a 3D engine, I'd never developed anything more fancy than a 2D tile map, I had no idea what it took to build an RTS and I focused on all of the superfluous things (like title screens, polished 3D models and flashy shader effects) instead of the things that mattered (like core gameplay mechanics and gameplay elements).

[lordpalandus]

A lot of things are going to be a real pain to work with, until I learn how to use them properly. The most difficult one for me is likely going to be learning how to do basic manipulation of sounds and creation of textures, as graphics and sounds are not my forte. But as I'm soloing it I'm going to need to learn them as well.

Well I have a variety of pre-development goals that I'll be working on before any major development occurs... many smaller prototypes and likely much failure and then learning from said failure. Most of my goals are "SMART" (Specific, Measurable, Achievable, Realistic, and Timely), though some of the later stuff after learning the basics are not too fleshed out as they require knowing the basics first before assessing how to go about doing them.

I'd have thought it would be better to work with basic models and textures (or an untextured completed model), work out all the underlying code, then start adding in the rest of the content = sound, music, textures, fancy effects, etc, basically all the graphics and sound related stuff.  Once you know the code works, then you can focus on adding all the extras on. If the basics don't work, then any of that other stuff might become obsolete and get thrown out anyway.

[Hooman]

Yes, I'll be sharing the design document. I think getting some input on the design document when its "finished" would be helpful and useful for me;

I would suggest working on the design document in an open manner, so sharing and discussion can happen before it's "finished". What exactly does "finished" mean anyway? In software there is always a next version. The input will be more useful before something is finished. It can save you time to fix problems early, and continual feedback will help keep you motivated.

As for tube tiles, they provide faster access than rough terrain, but slower access than bulldozed ground. They are essentially bulldozed ground with speed bumps from partially exposed tubes. :p

Earthworkers take damage when they cut active tubes. Each time they cut an active tube, it takes away about 1/3 of their health. They will explode upon cutting a tube that damages them too much. I believe this is to limit the number of tubes you can cut in an enemy base. I'm pretty sure the designers intended this as a tactic. There is no other clear reason to cut tubes. You can always just build on top of them in your own base. You could claim movement speed, but the difference between bulldozed ground and tubes is minimal.

There are certain conditions where cutting tubes can cause someone to lose. In particular if they have no metal left to rebuild the tube, and no structures to deploy a bridged connection, then the game becomes unwinnable for them. I don't believe the game does very sophisticated checks in this area though, so it's probably possible to fail a mission when you might still be able to win. Like how losing a main CC can cause you to lose even if you have a backup CC that is simply offline. Also, when refineries and silos are idled, they lose their storage. When EMPed, the refineries I believe keep their storage, but silos lose their storage. I'm not sure what happens when their tubes are cut. It might make them both lose their storage, in which case, that would explain failing the mission.


This thread is getting quite long. Perhaps it's time to start generating a document from the ideas discussed.

[lordpalandus]

Well... when I say finished I mean that I've analyzed most of the features I do or don't want and thus have settled on how the majority of it will work out. This is to avoid excessive feature creep, which is often a very dangerous thing as it can push the game's scope way out of control. Its a problem that two projects I follow have run into (Star Citizen and Space Pirates and Zombies 2); both of these have allowed far too much feature creep into the projects and thus are taking many months to years longer to develop. The reason I want to have a basically "finished" design document is so that the product I intend to create will be easier to predict how long it will take to produce and thus I can better guage how much it will cost to produce and how much it might cost to pay others to help produce it. Now that doesn't mean I wouldn't accept more features its just that I'd have to heavily weigh in whether or not I should add the feature in based on how useful it is or consider patching it in after I'm done rather than delaying development to add it in right away.

However, a finished design document isn't going to happen any time soon. I can definitely put together a preliminary design document of the features I'd like to have in it, but that is heavily subject to change. The reason it is subject to change is I still need to determine which features are feasible or not in UE4. If a feature cannot be made into a basic prototype to determine if it is feasible, then it can't be included in the game. I have a long list of gameplay-based features that I'd like in the game and a long list of engine / framework related features that I would like in the game. So, I need to do a lot of testing and prototyping to see what works and what doesn't work. Until I know what does or doesn't work, there is no point in having a "finished" design document. Basically the purpose of the finished design document is to use it as a guide to allow me to build the game like an intricate jigsaw puzzle; each part of the program has to fit together with other parts of the program and thus having a design document helps me to remember what other parts will need to work with the part I'm currently building and how to lay down a framework for other parts to connect to it and it in turn connect to other stuff.

What I'm currently working on is refreshing my C++ knowledge, going through function calls again currently, and taking some indepth notes of things that I likely won't remember easily. Since UE4 will require some significant C++ coding to do work with it, I need to be able to design code, implement code, test/debug code, redesign code, and practice.

On that note, does anyone know where a good use of a globally declared variable would be useful? I know globally declared constant variables are often used, but what about global variables in general?

However, if a preliminary design document is desired I could cobble together what I currently have.

[Hooman]

Design documents written before code starts never end up representing the code. Think of it as a living document. It will change as code is written, flaws are found, and design and code are updated. It's futile to try and write it all up front and expect it to be correct.

Sounds to me like you are delaying. You want to talk and dream about it, but you don't want to work. :p

Start on the document.

<Insert plug about a journey of a thousand miles begins with a single step>


I can't remember the last time I declared a global variable. Maybe a generic handle to a sound system, where you only ever want a single object. A video system might be another example, but remember there are systems with multiple monitors. Or perhaps a data structure that is shared between threads, where the root of the structure is declared globally. Note that sharing data between threads is not sufficient reason to make something global. You can also pass data (such as a pointer to more data) into a thread that describes whatever needs to be shared.

Mostly I would only declare static read-only data globally.

On a slightly related note, it's much nicer to only have to share read-only data between threads.

[lordpalandus]

I'll start working on a preliminary design document then.

Actually, I do want to work on it. However working on requires an understanding of how to convert ideas/"dreams" from the mind into something the computer can understand. That requires knowing C++ and knowing how my C++ code will interact with the Unreal Engine. Not all dreams are feasible and thus practical prototyping is required to determine what works and what doesn't. I thought that would be fairly clear to someone with a huge background in coding...? Dreams on paper are just that, Dreams. They need to be converted into code and then that code tested to see if that dream is feasible or not.

I'm also not delaying. Even though I lack a computer to prototype ideas on, I still end up prototyping ideas on paper and seeing how various things interact with eachother to see if I'm missing something or it could be considered complete. I haven't bothered with a Design Document because week-to-week many things change; some things are improved upon, some are thrown out completely. Thus my design is always in flux. A design document to me, is something that is reasonably set in stone, but still flexible in being modified. My current design for the game isn't quite there yet. There is several areas I have not even touched on yet.

The other problem is that about 50% of my ideas and design are on my development computer which is in the shop at the moment. The other half are scattered throughout my iPad and this computer I do word processing on. I can certainly put together what I have right now but its nowhere going to be near being complete or fully fleshed out.

Also, finally the design document I was referring to was intended to be created AFTER I had tested out most of the ideas with it in various prototypes to ensure that it would work and thus the design document would be representative of the final product. My idea for a design document is clearly different from your view on a design document; my view may be impractical, but it is what it is.

EDIT: What format do you want the Design Document to be in? Doc? DocX? Google Document? .txt? etc

[leeor_net]

I was going to suggest a google doc. It's easy to work on from most devices and is easily shared.

[lordpalandus]

That's kind of what I was thinking as well. So I'll get on with that.

EDIT: Link = https://docs.google.com/document/d/14gyJIIFiPd3nLKRqhVE-t7376VqwSdjoh0ActRrywyA/edit?usp=sharing
NOTE: I'll update it as I accumulate the information I have available to me and what I can remember that is stored on my Dev Computer (which is currently inaccessible)

[leeor_net]

One of the best things about Google Docs is that it saves automatically as you work with it and you don't have to update the link!


So a few thoughts as I'm starting to read over your current DD.

The Story
I know it's fiction but there are a couple of holes.

First, I'm pretty sure a ship built by us without star trek like shields and integrity fields and so on would be torn apart by whatever distortions would come from a worm hole. Granted this is all theoretical and we don't know that worm holes even exist but theoretical physics does predict the presence of worm holes... except that they're tiny. Like microscopic tiny. So that alone immediately breaks the suspension of disbelief. May want to consider something besides a worm hole.

Assuming we stick to the worm hole story and assuming that the ship is torn apart or crushed like a bug, after 10 years suddenly arriving at a star system, I doubt the computers would think it's the true destination. Computer software sophisticated enough to continuously monitor a ship's functions while the crew are in cryosleep would also be sophisticated enough to detect the anomoly and determine that it's approaching an unknown star system. It would have probably instead woken up key members of the crew to make a final determination of what's going on.

Also, the captain would probably be able to triangulate their position based on pulsar information -- that's how we determined where we are in our own galaxy and how we tell aliens via Voyager 1 how to find us -- so he probably wouldn't say "Nope... no idea where we are".

Gameplay
You have some great thoughts here and I like all of the suggestions but Tier 1 alone will be a challenge to develop let alone Tier 2 and Tier 3. If you absolutely must include other tiers, I would stick to 1 and 2. Either way these are all ambitious goals so maybe you should focus on Tier 1 and leave the others for another game.

Grandiose goals lead to burnout which lead to failure. Take it from someone who has failed many, many times. I learned the hard way that you absolutely need to start with goals that are attainable. You also need to know your limits. Since you're just starting out with C++ and the UE4 engine, the Tier 1 gameplay will be enough of a challenge without also trying to build two other entirely different levels of gameplay on top of it. So stick with a colony management RTS, finish it, and then go from there.

...is to develop tier 1 to about 70-80%..

Unless you're careful, the last 20 - 30% of development will take 90% of the time. Make sure you set concrete goals and milestones and don't ever, ever allow feature creep or you will never finish. Ever. You'll end up with Battlecruiser 3000AD. That is not a good thing.

I see you actually modifying the DD now so I'll hold off any further notes or thoughts I have on it.

[lordpalandus]

Yes, the story is quite a bit WIP. I haven't put too much time or thought into it as the campaign would be built or not built after the funding drive was determined successful or not. The focus on Tier 1 is to show possible investors what I'm capable of, show that I can complete it, and show that the gameplay is actually enjoyable to play and not a bore fest.

I actually don't know that much about wormholes actually. My understanding of wormholes comes from the wormhole in Deep Space Nine, or the wormhole in Farscape; both of sufficient size to encapsulate a starship and both deposit ships entering them a good distance away, from the entry point. I did not know that in reality, most wormholes are far too small to for something as large as a colonization ship.

Alternative ideas to a wormhole, could be a subspace tunnel, such as in Star Trek Voyager, a time hole, such as in Red Dwarf, or a "black hole" like in an older game called Gravity Well.

Its true that computers sophisticated enough to plot a journey to a star system, probably wouldn't be fooled by a brand new star system into thinking it is its destination. Though, I'd still think the computers would want to wake up the human crew to determine where it is.

Also, didn't know about Pulsar information, or how scientists encoded in the Voyager probe how to find us again. I don't have a huge hard science background... as I'm not a NASA scientist, which is what Outpost 1/2 had on their team.

Gameplay... That's kind of what I've been thinking. The interface for Tier 2 and Tier 3 will be completely different and will play entirely different from tier 1. Tier 3 will definitely play the most differently, as it will play like a real-time strategy equivalent of Master of Orion, so it might be best to keep that as it's own separate title.

Lots of things lead to burnout. Also, still working on my burnout. SMART goals and SMART goals of the SMART goals is what is needed (Specific, Measurable, Attainable, Realistic, and Timely = SMART). What I mean with that is that the goals need to be SMART, but also how I view the approach to solving those goals and how many goals I try to accomplish at the same time need to be SMART.

My experience from watching developers create games, is that the last 20-30% takes the longest because of poor planning (as in no planning is done period) and poor design (constant iteration is great for a prototype, but not so good for a complete product) of the code leading to a lot of bugfixing, balancing, and more bugfixing. If code is well designed, and things are planned out carefully, the last 20-30% should take about as long as the rest of the work. The problem is that since most game code gets rushed in the industry, the last 20-30% takes forever as you have to unravel your "spaghetti code" and find where one problem starts and another ends.

What is Battlecruiser 3000 AD?

[Hooman]

I feel my reply has become partially obsolete while writing it, but whatever, here it is.

However working on requires an understanding of how to convert ideas/"dreams" from the mind into something the computer can understand.

I partially disagree. You don't actually need to code or know how to code to start writing a design document. Initially you just need to know what the game is about. If you can describe the game from the viewpoint of a player then you should be able to write a decent start to your design. Keep in mind that design documents are not really standardized, their scope varies a fair bit, as does the scope of the projects they describe. Sometimes a design document doesn't contain code, prototypes, or diagrams. Ideally though, it should be complete enough that there is no ambiguity about what features go into the game, and should eventually provide enough detail on how the features work to implement them. Saying there are multiple weapon types and amour systems is a start, but too vague for a final version. Saying what the weapon types are, and the equations for calcuating damage based on weapon and armour is better. It doesn't need to be actual code, but at least a mathematical equation would be a good idea. Describing the high level idea, feel, and flow of a game should come before implementation details. The initial part of writing a design document is then more of a technical writing skill than a coding skill. It's only when you start drilling down to the details of how something is implemented that coding skill becomes important.

Not all dreams are feasible and thus practical prototyping is required to determine what works and what doesn't.

If you keep the design open, it's possible for more experienced programmers to catch ideas that aren't likely to work. Fortunately though, having to solve NP-complete problems and the like in a real-time game isn't an issue that typically comes up. If you can dream up an idea for gameplay, there's a pretty good chance it can be implemented. If it really is a bad idea, that often comes out pretty quick, even before code is written.

Not everything needs to be prototyped first, and certainly not at such an early stage. Prototyping is probably more useful to test a possible implementation of a program feature, rather than as part of a design step that determines what features are present. It would seem very strange if a prototype was driving the design, rather than a design determining which parts to start prototyping. Why build something if it wasn't a needed feature? Why have features that might not be possible to build? That would be more of a research project than game design.

The other half are scattered throughout my iPad and this computer I do word processing on.

All the more reason to start collecting things into one place which can become your authoritative source of information on what the game is and how it will work. You do need to nail things down at some point.

I can certainly put together what I have right now but its nowhere going to be near being complete or fully fleshed out.

It will never be complete if you don't start.


I don't know if you've noticed this, but if you re-read your post, a few parts sound like excuses. I'm not going to debate the validity of them, I'd just like to bring up the mindset of this. It's sometimes a little too easy or convenient (lazy) to find a reason why something can't be done (now), rather than make a decision on the next actionable step. Certainly things won't always go according to plan, but that's not really the point. If you need to wait on something, then make a note to revisit when the time is right, and move on to something else where a decision can be made. Putting things off is easy, making decisions is hard. Decisions are needed for progress.

I am very guilty of putting things off and making excuses myself. I've come to realize that making excuses doesn't help get things done. Coming up with small actionable next steps does help. The most productive people I know always have a small next step to work on. The least productive people I know always have an excuse.

Lately I've often found myself grudgingly try to turn excuses into small actionable next steps. It's hard, I know. I am painfully aware of this.


With that said, I'm glad to see you've made a decision on the format for your design document and actually got started on it. I'm actually impressed. I wasn't expecting 4 pages already. Wait no, 8 pages now? Wow, you're really moving. Good job. I have some reading to catch up on now.


Edit:
That SMART stuff is exactly what I was trying to get at.

Also, I had similar thoughts about the wormhole idea. I was thinking maybe just leave an air of mystery about it. The crew is woken, the ship has arrived at an unexpected destination. Perhaps they don't know where they are, perhaps they don't even know how long they've been travelling. Maybe there was a computer glitch, maybe there was a wormhole, maybe they've just been travelling for a very very long time, much longer than expected. Give the reader/player something to wonder about. Give them something to discuss. Probably better than giving them something to refute.

[lordpalandus]

Hmm... very good points on the design document.

Also, good point on dreams. If an idea sucks, you are right it will usually come out quickly enough.

I only mention that I'd need to do a variety of prototyping because UE4 isn't technically designed out of box to support RTSs. The developers at Epic have said it can be converted to an RTS, but an RTS isn't an immediate gametype available to a game developer. I had looked at UE4 several months ago when I was developing an RTS idea (completely unrelated to this game) based on Majesty: The Fantasy Kingdom Sim, to determine the feasibility of making it work for an RTS and determined at that time that it was between highly probable and extremely probable that it could be used to create an RTS in it. However, I haven't touched UE4 since then, and since then two new major updates have been released for it and thus I'll need to refresh myself on UE4 to see what is new, changed, or possibly completely removed and adjust my thinking patterns to match.

Also, good point on putting things together in one place. That does actually make sense. Thanks for the suggestion to start on the Design Document.

Now on to the excuses part... for me I don't see them as excuses, but more as a fact of my current reality. I'm still suffering through near burnout, and am recovering daily and weekly such that my productivity has been improving, and my quality of life has been improving. I would like to be doing at least 8 hours a day of work, however with my current level of burnout, I can at best get 1-2 hours of work in without feeling extremely exhausted. This is a great improvement over a couple weeks ago when I was barely able to do 30 minutes of work on the project. I'm improving, but recovery from burnout is a slow process. Whenever I try to take on more work than I'm capable of, I feel extreme exhaustion, that usually affects me for several days and thus I get very little done when I'm exhausted. In between working on the project though, I am working on improving my mental and physical health (as these are the things that heavily affect the burnout the most), by doing weekly reflection, critically analyzing problems, devising solutions and implementing them, and then reflecting on those changes a week later to see what worked and what didn't, and go from there. I've been noticing great improvements in all areas of my life over the past few weeks after I had started this major change in my life however, I am not quite there yet.

Thus, I avoid adding too much additional work onto my plate. I know right now, that adding work on without being able to cope with the extra load will just cause overall worse productivity. Its better to work at the level I'm currently able, and then setting SMART goals on improving productivity and such forth. That's why I said that I not only need SMART goals, but also SMART goals of the SMART goals. The goals themselves might be SMART, but if I have too many goals, then I might not be able to achieve them. And I find that when I fail a goal I set for myself, I feel like shit for days afterward. So I want to create enough goals that I'm challenged, but not so much that I can't complete them all.

I guess the purposeful avoidance of work to avoid burnout could be construed as excuses, but I literally do not have the resources to overwork myself at this point. Perhaps in a few weeks, that may be different. However, with that said, I'm finding that working on the Design Document has improved my productivity by quite a bit, and I managed to get more than my usual 2 hours of work per day and increase it to about 4 hours. Perhaps, some of my lack of productivity stems from writers block...?

Finally, I really like the idea of mystery. Certainly solves the wormhole problem. I like it. Thanks! I'll make the story changes now...

EDIT: Also, I'll add the link to the design document on the first post so its easily accessible and make a post on NTCS about it as well. That is, when its back to working status.

[leeor_net]

My understanding of wormholes comes from the wormhole in Deep Space Nine

Star Trek is not reality. It's a great story. But it's not real.

I don't have a huge hard science background... as I'm not a NASA scientist, which is what Outpost 1/2 had on their team.

I'm no scientist but I do make an effort to understand things when I want to talk about them. Wikipedia is a good starting place.

Also, Outpost 2 had no involvement from the original Outpost team so there were no NASA scientists on board.

Also, Outpost is a perfect example of why you DON'T want scientists designing an entertainment product.

Also, I had similar thoughts about the wormhole idea. I was thinking maybe just leave an air of mystery about it. The crew is woken, the ship has arrived at an unexpected destination. Perhaps they don't know where they are, perhaps they don't even know how long they've been travelling. Maybe there was a computer glitch, maybe there was a wormhole, maybe they've just been travelling for a very very long time, much longer than expected. Give the reader/player something to wonder about. Give them something to discuss. Probably better than giving them something to refute.

I like this idea better. Computer glitch with a travel time far exceeding what was originally expected, getting caught in the gravity well of a totally different than intended star system is what caused the computers to wake up the commander (I recommend commander because that's how the player is referred to in Outpost and Outpost 2).

however with my current level of burnout, I can at best get 1-2 hours of work

So then stick with 1 - 2 hours a day and do first what you can do most efficiently. Right now, design seems to be the key. Take the time to design the game. Develop the DD. What Tech to use and language and all of those details can come later. But without a specific goal in mind with concrete set features and what exactly the game will do in terms of providing a fun experience you will end up with another Outpost 1 or Battlecruiser 3000AD (btw, it was a notorious failure from the 90's that was in development for 10 years, switched publishers at least 5 times and was released unfinished and very, very broken -- I had mentioned it as an example of feature creep).

I'm also hearing you use a lot of buzz words. They're fancy and sound good and make a lot of people feel warm and fuzzy but the reality is you're going to end up doing whatever it takes to make the game work.

In the industry you don't have time to make everything perfect. Sometimes you just have to roll your face on the keyboard for awhile to make something work and make it pretty later. I did that with OutpostHD so far and look, I actually have something almost playable. I've had to go back and refactor some of the code because of major inefficiencies and terrible design choices and there are other areas that I need to fix as well but those parts can be fixed later, right now I just want to get the core gameplay elements working.

Hooman is also right about another thing -- sometimes you just have to make decisions. That's the hardest part. There are times when you're going to sit there mulling over what you should do next... I do it all the time. The difference with OutpostHD is now, I just force myself to pick a specific problem and tackle it even if I haven't fully fleshed out how I'm going to do it. It's not pretty, it leads sometimes to some pretty messy code but if it does what I want it to do and it's not absolutely horrifying, I call it a day and move on to the next challenge.

You will not have perfect code. Period. So don't try or you have already set yourself up to fail. We are humans with poorly evolved, very limited monkey brains. We are not perfect. We make mistakes and our designs aren't always perfectly elegant. Unless you're a coding savant (get it, savant? eh? eh? no? okay) your final implementation will probably leave much to be desired but if the code does what it's intended to do and the game actually works, you've succeeded. You can go back and make it better later.

There are some coding sins that are unforgivable but I don't think anybody here is on that kind of a level.

[lordpalandus]

That is true, but a videogame often defies logic, though I'm unsure if that is a good thing or not... like in the Last of Us where it takes 4 scissors to create 1 shiv. Game logic!

Really? I thought that the same team that did Outpost 1 did Outpost 2. And yes, Outpost 1, despite appearing interesting, is a prime example of not to get an outsider who knows pretty much nothing about coding or games to design the code for a game.

When all else fails, mystery works fine.

Yes, I'm well aware that having concrete, set in stone goals are needed; hence why I don't really want to get too set in stone right now as I need to do some prototyping. But I'm not quite there yet. As stated in the Preface, things in the DD may get changed, improved or removed entirely as time goes by. Something that I thought would be a great idea may be implemented better in another way. Etc. etc. etc.

Battlecruiser 3000 AD, sounds a lot like Duke Nukem Forever. Also released in a huge buggy mess.

Perfect is subjective. Technically code that compiles, is syntacally perfect, as code won't compile with syntax errors, thus the syntax is technically perfect. However, ensuring that the logic is perfect is a not a good goal to work towards. I want the code to compile properly, while ensuring overall "good" logic and a minimum of possible runtime errors by building in contingencies. I do not expect to have perfect code throughout; good is good enough. The other thing with having perfect logic code being a pointless endeavor to work towards is that it is impossible to fully predict how a user will use the program and it is impossible to balance mechanics perfectly.

Rushing something out the door to make it playable isn't always a good idea though, as the product you are left with is essentially a working prototype. And as it is not a good idea to build ontop of a prototype and it takes forever to fix a prototype, it will take you far longer to develop it. Making the decision to partially develop some things while getting the game in a playable state faster means that its going to take you far longer to develop it than if you took the time to carefully design each part, rather than over-abuse stubs and other bits of partial code. I can understand the necessity in many cases for people to do it, but I'd rather not go down that path unless I absolutely had to. I'll deal with this issue once I got a basic prototype up in UE4 ensuring that the basics do work. Just because you can change it later, doesn't mean that is a good thing, or a valuable use of time. Bugfixing is the real killer in development, and is the cause for dragging out development time; anytime you add a feature, you have to fix the code; anytime you remove a feature or change a feature you have to fix the code. Minimizing bugfixing by carefully designing things will save you hours and hours of headaches later. Its just my preferred style to development.

Coding Savant as in someone who is naturally good at coding, or Coding Savant as in a reference to the Savant-series computers in Outpost 2 and thus implying that I'd have to be a computer to create perfect code?

The only coding sin I know of, is where a disgruntled employee at Maxis got pissed off because they were laid off or fired (can't remember which) and renamed ALL of the variables in the source code to a variant of their name, with a letter or number at the end. I heard that it took Maxis years to undo the damage.

[leeor_net]

Perfect is subjective. Technically code that compiles, is syntacally perfect, as code won't compile with syntax errors, thus the syntax is technically perfect.

Now you're playing semantics. You know exactly what I was talking about.

Rushing something out the door to make it playable isn't always a good idea though

Except that's not what I was suggesting. Rushing something out the door gets you Outpost. Or Daikatana. Or E.T. on Atari.

What I was saying is something you need to just make a decision and start plodding through the code. If you don't do this you will never finish. You will never always have good code. Sometimes you have mostly good code with a few very ugly sections. It happens. Note what's ugly, why it's ugly and move on. E.g., in my own code for OutpostHD I have several things like this:

Code: [Select]

Structure* _s = reinterpret_cast<Structure*>(tile->thing());
Robot* _r = reinterpret_cast<Robot*>(tile->thing());

Structure and Robot both derive from Thing. Tile's only store Thing's. In this case I'm casting from a Thing to a Structure  and Robot and proceeding. This is terrible practice in modern programs (though it's really common in a lot of legacy C programs).

How do I fix this? Stop storing the base class Thing in Tile and store Structure and Robot instead with their own get/set functions. I know the fix. I know how to clean it up. But it would require additional checks and more code in Tile to handle it all properly. Not that it's really a headache to do it but for now this works and I know how to fix it later when I've got other things fleshed out.

This is an example of "It does the job even though it's bad but I can fix it later and focus on other more important things."

Coding Savant as in someone who is naturally good at coding...

Really? -smh- You're taking things too literally.

[lordpalandus]

Indeed

Daikatana the game that will make you it's bitch and will be the end of John Romero's career.  Or ET, the game that caused the first gaming crash Point taken.

So are you saying that sometimes its best to have something that is crude, but effective, over taking extra time to design something well, when the crude but effective would suffice?

Come on, seriously? Its the internet, how else am I supposed to take it? I can't tell if you are being sarcastic, rhetorical, literal, or metaphorical. Lol.

[leeor_net]

So are you saying that sometimes its best to have something that is crude, but effective, over taking extra time to design something well, when the crude but effective would suffice?

Exactly. Crude but effective sometimes is good enough, especially if it's something that can be cleaned up later without being too painful.

Come on, seriously? Its the internet, how else am I supposed to take it? I can't tell if you are being sarcastic, rhetorical, literal, or metaphorical. Lol.

Touche. Can't really argue with that.

[Hooman]

UE4 is an implementation detail. It is subject to change. 

Seriously though, you don't need to worry about whether UE4 will work when you're fleshing out what the game will be about. Granted, most people have some sense of the tools they will use, and a note about using UE4 might very well find its way into an early document. If the tool is good, use it. If it doesn't do what you want though, discard it. You're not designing a game just as an excuse to use UE4 are you?

As for excuses, of course you don't see it as excuses. Nobody wants to see what they say as excuses. 

On a more serious note, I'm not trying to be a slave driver here. If you have other priorities, then so be it. You don't need an excuse to spend your time elsewhere. You're not required to put in a full day of work on this stuff. Hopefully this stuff should be fun, and not detract from other important areas of life, nor personal health. I'm just trying to foster the mentality that there is a small next step that you can work on. It doesn't need to be strenuous. Steps should be small for that reason, it makes them easy, and often even fun. I suspect you're finding yourself more productive because you've got a sequence of small next steps that you've been moving through, and because you're having fun. Momentum generates enthusiasm. You don't need to work fast, but it does help to keep at least a little bit of momentum.

As for rushing code out the door, no you don't want to do that to paying customers. But you should rush code out to people who are willing to test or play with early incomplete and possibly buggy versions. They can provide valuable feedback and suggestions for changes. It's better to learn what works and what doesn't work earlier rather than later. As changes are made they can be retested to see if things are improving. Design is usually an iterative process, not something done up front.

I should also mention that building on a prototype is not always a bad thing. If you fear prototypes and insist on throw away code, it might be that you just need more experience with refactoring code. It also helps to write test code, which helps with refactoring. You can make sure nothing breaks as you refactor the code. Some people take testing to an extreme with test driven development, where they write the tests first, then write the code. The tests are in a sense the design of how something should work. The tests are typically run first to demonstrate failure (which can help demonstrate the test code runs and worked), then code is written to implement a feature, and tests are run again to see if they pass, indicating a properly implemented feature (and hopefully good test code).

@leeor_net, I see nothing wrong with reinterpret_cast. 

Actually, there are often ways around it for what you're doing by using virtual functions. Why exactly does that calling code need to know the exact type of the object? Can't it just ask the objects to do whatever processing is needed themselves through a virtual function on the base class? Often the virtual function call dispatch can be used to avoid casting of pointers to base objects back to pointers to derived objects.

[lordpalandus]

Ok.

That is the intent. I am enjoying designing it and thinking of ways of how to implement it. However, I try to keep the amount of work under control so that it isn't strenuous and so that I can maintain that level of productivity.

Yes definitely, but how does that work for investors in a kickstarter campaign? If you promised them an alpha, does that mean you should rush the alpha out the door, or spend the time to polish it to give a good impression?

I hear about refactoring code all the time, and people who suggest it often are the ones that refuse to throw away a prototype and start over; they prefer to iterate on something that is best thrown away, learned from, and then do better the next time. They would rather spend the time fixing all the problems than starting from scratch. All of the online tutorials for C++ and my own C++ textbook advise HIGHLY against fixing a prototype and instead starting fresh. I have heard that sometimes its better to refactor if the majority of what is there is doing what you want anyway and thus fixing up the problems would actually take less time than starting from scratch. I suppose it depends on the situation.

Are you referring to driver programs (with the testing stuff)? I heard that using drivers can be sometimes better than using stubs to test code.

[Hooman]

That is unrelated to a Kickstarter campaign. Potential investors are not your beta (or alpha) testers.

Refactoring is an important skill. It's most useful when you have code that does what you want, but not the way you want it. The code might be messy, or slow, or use too much memory, or not support features that need to be added, or might not have the flexibility to support reuse. In that case what usually happens is a set of tests are designed to verify the current behaviour, then small incremental changed are made to the code, running the tests along the way to ensure nothing breaks after each change. You would probably also make commits to version control after each small change is completed and tests pass.

In contrast, throwaway code might not do what you want, or even anything useful at all. It might simply be to isolate a behaviour that you're not sure about. Questions like how does this object behave under these edge cases? Triggering the edge case might not be of value, and hence the code is throwaway, but knowing error conditions can affect how you'd write mainline code. You'd know what error conditions you need to check for around the edge cases, and what tests to write to ensure things don't break horribly at your edge cases.

A related aspect is bug hunting, where you might try to trigger an edge case to see if that is where a bug is coming from. In terms of the mainline, the code might be considered throw away, but in terms of your tests, it's not. The code that triggers the edge case can be refactored into a test.

As for fixing a truly terrible design that mostly does what you want, that really depends on the situation. Some people start new, some people try to iteratively fix. If the code is already part of a working production app, you'll most likely want to iteratively fix. At the very least you'd at least want tests to verify correct behaviour of both old and new code. If you're completely changing the underlying algorithm though, there might be little to no resemblance between the old and new code, and so no way to make small iterative changes. Still, the testing aspect still applies. You'd want the replacement part to be isolated and tested, and perhaps do a little refactoring to make sure the part being replaced is properly isolated before the replacement.

I'd also like to point out that nothing is perfect. If you're constantly throwing away code to start over and build something "properly", you might never finish.


A test driver is what runs your tests. It feeds the test case data through the code being tested.
A test stub simulates the behaviour of a missing component.

To elaborate on the stub, if object A uses object B, a test for object A might use a stub for object B rather than the real dependency. This could be for performance reasons, to avoid potentially unwanted external effects while testing, or possibly because B hasn't been implemented yet. It could be that object B represent a file system, a database, or an email server. While testing object A, it will make calls to object B, and you might want to avoid real changes to a file system, real changes to a database, or having email actually being sent to end users, thus you want A to make calls to a test stub for B rather than the real object. You can also use a stub to avoid non-deterministic behaviour. An example is when object B represent a timer, and so complicates testing due to unpredictable return values.

A test stub often has extra state methods, that can be used to test the state of the stub to check it has been manipulated correctly. There is also a similar concept known as mock objects. They are used similarly to stubs, but they usually verify behaviour rather than state. They might have checks to ensure certain methods of B were called by the tests on object A, rather than verifying the state of object B. As an example, testing state might entail an email server stub with an added method to return the number of sent emails (added state information, which might not exist on the real object), and then checking "numSentEmails() == 1". Testing behaviour might entail a mock object that verifies the "send(message)" method was called exactly once during the test.

[leeor_net]

I'd also like to point out that nothing is perfect. If you're constantly throwing away code to start over and build something "properly", you might never finish.

Dis right here... dis is what I mean!

There's a time to throw it away and start from scratch and there's a time to refactor. Refactor doesn't necessarily mean fixing bugs -- the refactoring I need to do in OutpostHD isn't to fix a problem, it's to improve the code and make it more maintainable. But for now it does exactly what I need it to do and without being buggy or super sloppy or slow or completely inefficient. It's not perfect, it's a little ugly but it gets the job done and lets me focus on moving forward.

Why exactly does that calling code need to know the exact type of the object?

I don't want to hijack this thread so I'll be as brief as possible and will probably hijack it anyway.

Structure and Robot both derive from a base class type Thing. Thing does the bare minimum in terms of representing an object. It provides several functions for managing base properties like animation states, drawing itself, tracking age and knowing its name. That sort of thing. Structure and Robot, on the other hand, define their own interfaces that don't make sense in the base class.

Structures, for instance, in addition to being Thing's, also consume Resources, provide Resources, update themselves in specific ways concerning Structure States (e.g., operational, construction, idle, disabled, destroyed, etc.). Robots, on the other hand, do not do any of this. So for them to have an interface involving Resources would make no sense. Robots also have event callbacks; Basically, they raise events when they complete their task, something that Structure's don't currently do and probably never will (unless we really really really want to let the user know that a Factory has finished producing an item and is moving on to the next). So far, I'm only deriving Structure and Robot from Thing but there may be other objects in the future of OutpostHD which would derive from Thing so I wanted to keep its interface as uncluttered as possible.

Why does the code need to know what's a Robot and what's a Structure? Basically, it comes from the mousedown handlers, specifically when inserting Robot's and Structures. Robots and Structures are treated in different when they are placed in a map. Robots, for instance, only really need to know if there's something already occupying a Tile although the Digger does need to know on the sub levels if a thing is an Airshaft (which is a structure). When placing Structure's, though, the game needs to know if adjacent things are other Structures and if they are whether or not they can act as connectors (Tubes). This really is pretty limited so I opted to go with cast's until I came up with something a little bit prettier. Or, I can leave it as it is because of how limited this need to know what a derived type is.

This is a good example of it's not perfect, it's not even pretty, but it's effective, it does what I need it to do and it's not brutally inefficient. If I was iterating through tens of thousands of these objects, casting to derived types would be probably be an efficiency problem and could slow things down but in all practically in the cases where the code does need to cast to a derived type, you're looking at 6 casts at most (one for each adjacent tile plus up and down).

[Hooman]

Technically, I'm not sure fixing bugs qualifies as refactoring, since refactoring is not supposed to change the external behaviour of the code (at least not for cases of valid input). Consider there are refactoring tools that have collections of common code transformations, that can be proven not to change output, and can be automatically applied to selected code. Many of them are simple, such as rename a variable, but they do it with proper scope awareness which a simple text search and replace would mess up.


There is no runtime overhead cost to a reinterpret_cast like this. It generates no machine instructions. All it does is relax checking in the compiler's type system. You might have correctness issues in the case of multiple inheritance though, but of course multiple inheritance is usually a bad idea anyway.

At least there is no cost other than possible loss of optimizations because the compiler can assume less about your code. In the case of pointers to objects in the same hierarchy, I'm not aware of any optimization losses. If the reinterpret_cast did something like casting an int to a pointer, then the compiler might assume any write through that pointer could write to anywhere in memory, which might mean it has to reload values that were previously in registers since they might have changed. The cast itself didn't generate new instructions, but the loss of an assumption might cause other code to generate more instructions.

As for your design choice, if both Robots and Structures can be placed on the map, maybe there should be a virtual PlaceOnMap(x, y) method in the base class, rather than casting in the mouse down code? But it sounds like you're casting nearby objects, which is a little more understandable. Might I ask though, how are you determining if a Thing is a Robot or a Structure before casting it? It may be worth pondering that part of the design a bit.

[leeor_net]

Successful Thread Hijack is Successful

Might I ask though, how are you determining if a Thing is a Robot or a Structure before casting it? It may be worth pondering that part of the design a bit.

When I place a Structure in a tile, I flag the tile has having a structure on it. I determine it by calling Tile::isThingStructure(); Crude, but effective.

[lordpalandus]

@Hooman; The reason I bring kickstarter backers up, is that it actually is standard practice these days to use your potential investors as alpha and beta testers, strange as that may seem. That is what many successful kickstarter games have done, such as Rimworld, Star Citizen, and Planetary Annihilation, is shipped out an unfinished, often buggy mess to their investors that they often pay money in the kickstarter to get access to (if you bring up any of those names in Kickstarter, you'll see that specific tiers grants access to them).

Okay, my definition of a prototype is different then than your definition, it seems (or I'm misunderstanding). The purpose of prototypes for me is to hastily throw together some code, generally without caring for commenting or good coding practices, just to see if an idea will work at all. To me, to fix something like that would take far longer than rebuilding it from scratch and with good coding practices in place.

Refactoring does then sound like a good skill to have. So you would use refactoring when your code is functional, but not that great, and thus a redesign of the code already in place is the right way to go, instead of rebuilding an entire program from scratch... am I understanding that correctly?

Okay and I can now understand why iteratively fixing is often better than restarting from scratch. Thanks for clarifying that and making it clear.

Point taken about constantly throwing away code. That is a good point.

Thanks for clarifying the usage of stubs and test drivers.

I also wouldn't consider refactoring as bugfixing; I see bugfixing as repairing something while I see refactoring as renovating something.

@leeor_net;

[lordpalandus]

Design document is now up to about 17 pages (2 pages are changelog and archived info, so I don't really count them). If people would like to comment on things listed, I can look into making additional changes. I'll keep working on it in the meantime though.