Jason's Development Blog

Well, that’s it. My fears confirmed, time management has killed me. There is no way I’m getting this done in time. I spent too long on the background under-the-hood code, which maybe related to how that’s the part of coding I find the most fun. Which could also explain why I’m on the Platform Team at work. We make the API and let the Application Team worry about the best shade of Cornflower Blue to show the customers. And that’s what I ended with, the start of what could be a solid API but something only tangentially related to a working game.

On the brightside my code is very modular, and I am definitely going to create something properly using a more refined variation on this design at a later date (and the lack of time limit will let me use proper TDD and the like).

If I take part in the next LD, I’ve learnt a lot here and had fun, even if I have nothing to demo by the end of it but a sprite moving around the screen. I learnt from my mistakes and will hopefully have more to show in the future.

Major respect for the other LDers who actually get something done without getting lost in background implementation details, as I did.

If I could do it again, I’d pick a pre-existing “engine” (hate that term) instead of writing my own. I just can’t write fast and hackish code without feeling unclean, but for rolling things yourself I’m not experienced enough to do anything but in the timeframe. I fought against that, and it took me too long.

Also I’d impose a much stricter “sprint” system, planning out from the start goals on an hour-by-hour basis (using hourly iterations) with a set of things that needed doing I could pull from. I tried this by the end, where I started to pick up the pace, but it was too little too late.

Code by the end is on github for the curious.https://github.com/MorleyDev/ld24Evolution

tl;dr – I failed hard, but had a blast doing so.

Reposted from http://www.ludumdare.com/

Hello world and it’s loved ones. I am MorleyDev. I’m an English computer science student currently on a paid internship at an awesome company obsessed with agile development. Yes, I have been indoctrinated in those ways, so this Ludum Dare will be an interesting test for me. I will be streaming via Google Hangouts and Air, so feel free to check that out. I’ll have to put up links as they go online because of how hangouts on air seems to work (don’t think you can have a permanent link to an unstarted Hangout or embed unstarted Hangouts in a web page, unfortunately).

Well that or you can follow my new Google+ account or my new YouTube channel. That could work too.

Language: C++ (GCC for the new C++11 features, using the latest nuwen.net build for MinGW to compile on Windows)
Libraries planned on using: Boost, JML, Google Mock, UnitTest++, SFML, Lua
Targeted OS: Windows, maybe Linux if I have time.

Starting code - Well it’s not exactly “code” but I’ve created an Eclipse project with options to help me do some Testing and Cross-Compiling (if it comes to that). I hope. Maybe. It has some empty mains and the like but nothing “game” related so hopefully it’s allowed and nobody will lynch me in my sleep.

Where I’m not too worried – I’m a programmer. I program. I’d like to think the coding in and of itself won’t be too hear-pulling-out-of-head-and-feeding-to-self-difficult. I’d like a challenge sure, but a challenge I can do.

Where I’ll probably fail - My graphical skills are to be compared with a blind monkey drunk off it’s arse, high on every illicit drug known to man and being repeatedly hit over the head with a shovel. The monkey is also dead. I’m not an artist and so my “art” will be simplistic at best and ugly at best.

Where I’m worried I’ll fail – Ideas, obviously. But also time management. I like to test code and such, and so my feedback cycle will need to be a short one. I’ll probably use compile time to make art assets and such to keep my momentum but it’s a big concern for me. Coding on a slow-as-slow netbook last Ludum Dare actually made me ragequit due to the slow feedback cycle, but since now I have my quad-core hyperthreading laptop back from the repairing place that hopefully won’t be an issue. Hopefully.

- MorleyDev (http://morleydev.co.uk/)

No to Internet Censorship. Stop this bullshit.

Quote of the Day
“The current draft of ACTA would profoundly restrict the fundamental rights and freedoms of European citizens, most notably the freedom of expression and communication privacy.”
An open letter signed by many organizations, including Consumers International, EDRi (27 European civil rights and privacy NGOs), the Free Software Foundation (FSF), the Electronic Frontier Foundation (EFF), ASIC (French trade association for web 2.0 companies), and the Free Knowledge Institute (FKI)

A common mistake people learning programming with an eye towards game development make is the idea that they require a game engine. It just seems natural, a car needs an engine to move so surely a game needs an engine. If only life were so simple.

Look at the history of most of the successful game engines in history, let’s use the Unreal Engine and the id Engine for my examples here, and you’ll find they started off with the game and the engine came afterwards. The Doom Engine (precursor/father to/first version of the id Engine) was not written to be a powerful game engine (for the time), it was written to run Doom. It just so happened a lot of the code got reused in other projects and thus the id Engine was born.

The Unreal engine began, oddly enough, with the game Unreal. Then a lot of the code for Unreal got used in lots of games that followed, being changed, refined and completely rebuilt along the way.

Game engines are not so much invented as they are accidentally created. You write a game, and then you refactor a lot of the code you used so it can be used in a later game. This alone is often enough for the developers/publishers/marketing department to say that both games run on a modified version of the same engine. And I guess technically it’s true.

The idea of a game engine is inherently ill-defined, it can mean a whole lot of things. At the end of the day, seeking to create a “Video Game Engine” is a foolish endeavour, as trying to create something ill-defined often is. Without a lot of luck and skill, you’ll get distracted by the shiny things you can do and at best you’ll wind up with a fantastic technical demo, but not something wholly individual you can use to make a game.

In fact, one could easily argue that the creation of a technical demo, getting someone to run around the screen, is one of the simplest aspects of game development. It is often the unique aspects of a game, the unique code which doesn’t quite always fit efficiently into the average generic “engine”, that provide the real challenges in coding and in developing.

The reason the Unreal Engine, the id Engine and the Source engine are at their current state of awesome is because they have been used to create so many games that the code-base has been refactored, modified and reused countless times in a long, iterative process. This is how a true game engine is made: iteratively.

The best way to make a ‘game engine’ is, at the end of the day, almost always going to be to make a game. The old adage, “Make games, not engines”, is as true today as it was in the days of Doom.

Quote of the Day
“My advice to you, if you’re trying to write an engine, is: Don’t. No matter what your reasons are — it doesn’t matter if you’re writing an engine so you can write your dream game, or if you’re writing an engine because you think it will be a good learning experience, or any number of similar reasons. They’re all wastes of time.”
http://scientificninja.com