• Announcements

    • khawk

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

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

About this blog

The story of a lowly software developer and his high aspirations.

Entries in this blog


It's been a while...

Hey Gamedev, it's been a while. These past few months have been hectic for me to the point where I'm having trouble keeping track of the days. I have emails I need to respond to dating back over a month now (one of which is from a certain Gaiiden on a subject I offered to help with thinking I'd have more time), and phone calls I need to return from last week. Why am I sitting here on Gamedev then?

Well, I haven't been coding much lately. The last real bit of code I wrote was a php script for getting information from a Minecraft server for use with a server I'm not hosting for friends. Before that it was a python script for my boss, over a month ago. Yeah, little has been done on getting my precious coding time in. Then I got this email: "Trefall started a new personal conversation with you."

At first it didn't seem like much. Coming back to it 9 days later I read the contents over again and it hit me: this is one of the programmers I look up to on Gamedev, sending me a PM because I used some of his code. Now, it wasn't a bad message. In fact, it was simply Trefall letting me know that he had updated his component engine and separated it into it's own code repository. This still meant a lot to me though, because it showed that Trefall came around and read enough of this blog to know I was using a modified version of his code and he approved of its usage. This made me realize I haven't been doing one of the things I enjoy doing most: coding games.

So I sat down tonight to rethink my game a bit. I had been writing a game engine for a 2D RPG but the engine wasn't exactly suited for the task, at least not yet. So what would be good utilization of the code then? I didn't feel like rewriting the code again.

An RTS. An RTS would be perfect utilization of the engine I have right now, and would give me enough usage to develop it further to a point where it could be quickly modified for usage in an RPG. I didn't want to build just any other RTS though, as there are plenty good ones out there (StarCraft 2. Go play it. Now.). No, I wanted to build something a little more personal.

You see, in most RTS games you play as this god-like existence leading your horde of countless minions to their slaughter. You hardly ever get any attachment to a single unit, as you spend too much time worrying about building the next unit in order to be able to compete with the onslaught heading your way from Player 3. Some of you more advanced players have this magical ability called "microing," and what lucky bastards you are. Microing is the ability to be able to multitask fast enough to control multiple buildings/units in a very short time frame, being able to quickly switch back and forth between them and utilizing their special abilities to their maximum potential. I can't do that; I sit there doing attack-clicks hoping that my mass of stalkers is strong enough to prevail over the waves of marauders hurling grenades at them. I'll give you a hint at the outcome here: not good for me.

Ah, I'm off subject a tad. I was talking about making things personal, right? In order to make the player more personal with the game, they need to feel some sort of an attachment to their character(s). They need to feel like losing one can drastically affect the outcome of a match. So what I plan to do with this is develop a game based on fewer units, both in number of types and the number of units onscreen. I'm currently thinking up units, trying to decide which ones are best and have come up with these options so far:

  1. Tank Buster - Stronger attack, heavy armor, slow speed, medium cost.
  2. Telepath - No attack, weak armor, normal speed, high cost. This unit uses a special ability that can convert one of the enemies' units to it's own for the duration of it's life per round.
  3. Foot Soldier - Normal attack, normal armor, normal speed, low cost.
  4. Assassin - Weak attack, weak armor, fast speed, low cost. This unit also benefits from a cloaking ability that lasts for a small duration of time (with cooldown).

The idea with these units would be that each player starts a game with a small amount of money that they can use to purchase an initial set of units. Upon purchasing these units, they can give them their own unique names. With a team of units, they can then start a game using a subset of the units they have, or all if they are limited in the number of units. Each player is allowed the same number of units per game, though the number may be different between games. Players will then have to use each units' strengths and weakness against the other team until one comes out the victor.

I thought about the concept a little more and played with the idea of stats as a personalization factor. Having a team of units with identical stats to everyone else's but different names doesn't exactly make you more in touch with them. You need a reason to keep coming back to one unit as your favorite, or maybe even two or three. Persistent stats are hard to implement properly in a match-based game though due to the advantage a seasoned player can have over a new player. In order to combat this, I would be either using stat adjustment on a fractional scale, or a system that allows you to adjust your units' stats both positively and negatively based on a cumulative point count.

I like the cumulative point count because it makes all units theoretically equal and leaves it up to each player to maximize their effectiveness but also makes it harder for me to find a way to reward players for winning. The fractional stat adjustment would handle this easily by auto adjusting every player's units' stats based on their performance and the stats of the opposing team, but at less of a noticeable gain.

And so, Gamedev, I leave the current stage of the design up to your ideas, comments and criticism. Where do you see this failing? How can I improve the design? Do you have any further unit ideas?

Please leave any feedback in the comments and thank you for taking the time to check out my blog.

New computer

Finally, a machine that can actually do something. I invested some money in the new 27" iMac, and got the upgraded 3.4Ghz CPU. This thing is a beast, at least compared to the dual core Atom 330 machine with GMA 950 that I was using before it. Plays StarCraft 2 on full settings at full resolution(2560x1440) no problem. Just had my first SC2 session in a month or two. Sometime soon I need to replace my PS3 so I can play Alice and Catherine when they are released. I did not order those boxers, t-shirt and pillowcase for nothing.

Updates...none really. I got some of the vertex buffer/batching code cleaned up in WynterStorm. Besides that I haven't had a chance to work on it. I've been focusing more time on my actual job, plowing through the disaster that is vBulletin. Seriously if you haven't used it yet, don't. Vanilla Forums is a far better alternative, and I bet IP.Board is also a comfortable competitor. vBulletin's API is workable, but the admin interface is horrid. Updating plugins? Making Style changes? Adding new templates? Should be done by making changes to files, right? WRONG. vBulletin has it's own editor for all of these features, which get stored in an editable format in MySQL alongside a pre-converted format for certain vBulletin-syntax stuff and THEN stored in vB generated cache files in the file system. This is bad for several reasons:

  1. Revision control support sucks. Really, it's almost non-existent. The only way to safely handle this is to constantly export products from vBulletin and then import them on every server that needs the updates. The site I work on has something like 20-30 products though. Only two are specific to our site, but most of the code for the others has been slightly modified in some way.
  2. Moving between servers/phases is a pain. There are a few reasons for this. First is that again, revision control sucks. Second, there are all of these little details you have to learn about and take proper care of when importing/exporting products between systems. You have to take special care to assign as much as you can to it's associated product upon creation, and there are certain cases where vBulletin will ask you for a product and completely ignore your selection, assigning it instead to the base vBulletin product. BLEH!
  3. Scheduled Tasks. They aren't just plugins like they should be. Tasks are called by creating a file on the server and associating that file with a task. Now, I know I was complaining about the lack of support for version control with plugins and everything else, but at least they could have SOME uniformity. Either make use of the file system for more than caching, or DON'T. Just give me a standard way to make as many changes as possible to the forum without having to constantly switch between Transmit, TextMate, Chrome/Safari, and Sequel Pro.
  4. The way templates are setup in vBulletin is horrible. There are upwards of 20 CSS templates in the default skin. vbulletin.css, vbulletin-chrome.css and vbulletin-ie.css are just some examples. Also, vbulletin-chrome.css is NOT referring to the Chrome browser. No, it's referring to a specific part of the forum.
  5. Hooks aren't just added through a php call. You actually have to go an add to an .xml file to add a new plugin hook. Here's an idea for any of you vB guys out there. Make a hook. Call it 'pluginhooks_listing' and make the following code just work: $hooks[] = "some_new_hook_name";

There are also several other issues that I have to deal with daily that aren't the fault of the developers behind vBulletin. I won't get into these issues though right now. Instead, I'm heading off to bed to continue working in the morning. Maybe I can find some time tomorrow to contribute to the Gamedev Article update that I've had on my plate for a week now without having done anything about.

That's all for tonight, hopefully something interesting soon.
-Wynter Woods
Computing these days is becoming a mess. On one side we have your standard desktop and laptop computers running Windows, Mac OS and one of the million other Unices available, then on the other side you have mobile computing platforms that are revolutionizing the industry. Yet all I've been reading is that there is no merger, no midpoint where we can have both in a comfortable platform. Microsoft is trying this with Windows 8 and while I think the Tiling Window Manager (which isn't revolutionary; Tiling WMs have existed for years) is a fantastic leap for Microsoft, I was appalled when I saw the screen switch back to what looked exactly like Windows 7 on a tablet. I've used Windows 7, and have found that compared to any previous version of Windows it was the most intuitive and powerful I have used. I do not however think it should be run on a tablet; the interface was not designed for touch. Some of you will try and say something along the lines of, "hey, but Windows 8 is supposed to run on a desktop as well, some without multitouch screens!" You're absolutely right, and I think that the classic interface of Windows seems to work well for that but I still stand by my belief that it won't be comfortable on a touch screen tablet.

I am not here to bash Microsoft though. Microsoft is making a bold move by trying to merge the two and I think somewhere down the line it needs to be done; I just think they're 'doing it wrong'. So I wanted to propose Amarant in this post. Amarant is a concept for an operating system for desktop and mobile computing platforms that I have been working on with a few friends for over a year now. When I say "working on" I don't mean that I've been coding the blasted thing; instead we've simply been brainstorming ideas for a modern computing platform that would allow users to someday worry much less about the differences between their phone and their home computer. Because of the time however my ideas my come out a bit odd, please try and bear with me.

The heart of the operating system would be the standard OS kernel. It controls normal OS tasks such as threading, IPC, memory management, etc. My personal preference would be to use a microkernel here, and keep the kernel separate from any and all device drivers, but in practice this is still a few years away from being optimal for overall performance. Above the kernel is a basic runtime layer. The runtime layer has many powerful apis for running tasks optimally across multiple cores, much like Apple's Grand Central Dispatch, and makes use of these apis in most applications where it is appropriate.

The runtime layer also provides a restrictive environment which developers would design software around. This restrictive environment encourages developers to define an application based on Data Sets and Operations rather than on functions. How does this differ from standard computing methods? Data Sets are a common set of structures and libraries that define how a user works with data. One example would be a phone number or an address. Both of these are Data Sets. These Data Sets can also be nested under another Data Set, in the case of a 'Contact' which may contain a 'Name', 'Phone Number(s)', 'Address', 'Email(s)', etc.

So I still haven't explained why this Data Set differs from a standard C structure or class. Honestly it isn't different internally, but what becomes different about it is that the developer is no longer spending so much time writing an interface that works on one device to work with this data. Instead, developers write an application consisting of Data Sets, Actions and Operations. Data Sets define what the user will interact with. The operating system then decides how to display this data to the user, based on the device and peripherals. If we're on a tablet with no keyboard or mouse, then the operating system knows to display a touch-based interface with the given data. It then relies on developer chosen Actions to define what happens when a user does something with the data. A developer may choose to allow Phone fields to be edited, deleted or added. Then what happens as a result of these Actions is defined in Operations. Operations can validate, query, or manipulate data. This can be a simple process such as checking to see that the phone number has 'x' amount of digits, or can be a complicated process of validating an address through google, pulling a map from google maps and displaying the map with directions for the user.

This really isn't anything revolutionary. The concept is more an extension of technologies already used in mobile and desktop platforms, but with a more restrictive environment. This isn't to say that the OS can't handle just about any application a modern computer can. What differs is the process in which the application and the OS interact. In Amarant, the Application cooperates with the OS by providing data to it, rather than directly to the user. The OS should know a more appropriate way to display data to the user than the application. The application also does not consume horrible amounts of resources to run. The core of the application is not a loop as in most other OSes. The core of the program is the Data Sets, the Actions and the Operations the application provides to the OS.

This does create a problem for video games though and seeing as how this site is tailored to game development primarily I wish to propose my ideas above with the hopes that someone is willing to come discuss their solution to running games in such a platform. In such a platform where most functionality is based on reaction, how should games be developed?

This will hopefully not be my last post about Amarant. I hope that maybe someone will find interest in discussing this project and will motivate me to continue writing about it on gamedev. Please leave any comments and/or criticisms below.

Thank you all for taking the time to read this,
-Wynter Woods
Tonight I spent way too much time making sure batches were properly managed in WynterStorm. When I say 'properly managed' here, I mean simply that the engine should batch all quads using the same texture and render that as a single VBO, makes sense right? When I say 'properly managed' I also am using the term very cautiously. I do not think the code is proper at all right now; I actually find the code to be quite the opposite. I spent so much time trying to get batched primitives working that the code has become a horrible mess. Thankfully the messy code is only in two files. The reason for this? I got ambitious. I set a goal for tonight and the goal was higher than I should have set it without planning ahead. My goal was to be rendering multiple batched primitives onto the screen using VBOs. Before tonight I didn't have any code in place for actually rendering data to the screen so this was quite a leap considering I wasn't sure how I'd prepare this. Now though I need to restructure the code to make it proper once again. As it stands though, the code seems to do it's job well enough. May be a bit slow from my lack of experience using VBOs, but it's a good start I think. In order to render onto the screen, you first create a simple quad using the Shade::Quad structure. Triangles will come next, but I was mainly aiming for getting quads up quick. I also have no interest in rendering lines or points in batches, as the batches are linked to texture ids. Trying to rewrite the code to support points and lines using the [0] texture (which will render with no texture attached) would be too complicated for a feature I don't see myself using very much. WynterStorm will also allow developers to render their own VBO's without using the batch code, it just requires a little extra work on their part.

I've attached a screenshot to show the code in action. Tomorrow I will try and make some time for WynterStorm after work and clean up the mess I made, then maybe I can post some code to show how easy it will be to render textured primitives.

Thanks for reading my horribly jumbled, written at 2:00AM post.
-Wynter Woods
Whoo! This last week was finals week at my school and it was quite a killer. I ended up writing a research paper on Necrophilia last minute for one of my classes, which was quite an interesting project. As for programming, I didn't have as much time this week as I would've liked for WynterStorm, having to spend what little time I had on school and work.

After finals though, I did put a bit of work into fine tuning WynterStorm. I've found that when programming in C++ I tend to prefer references over pointers where available. For some reason I had believed that references didn't call virtual functions where pointers did. I used to find this very odd, but apparently never actually tested this belief I had. Well as it turns out, references can and will call virtual functions just fine; I'm just retarded. So I began migrating some of the code from transferring pointers to transferring references. One area that I did this in was the Event system. It used to be that I would have to 'new' an event when sending it. This seemed like bad style to me and I could see this leading to quite a few memory leaks unless I didn't manage this properly. Switching this over to using constant references should fix this, and also reduce time spent typing (By two whole keystrokes per event access. Oh yeah!).

So I believe I've briefly mentioned Signals before. If not, I'll explain here. In WynterStorm I currently have two systems that pretty much achieve the same process in a different way, Signals and Events. I've been debating with myself over whether to keep or remove Signals. As it stands, the two systems have distinct purposes. Signals are used specifically for properties. When a property is updated, a signal is called to notify that this specific property has changed. This allows me to extend class functionality to have the class update itself based on the property change. I believe I mentioned before that this is used in the Shard::Window class, which has the property 'title'. When title is assigned a Crystal::String, which is just a typedef of std::string for the time being, the signal 'sigTitle()' is called that instantly calls the 'setTitle()' function, instantly updating the window's title. In this case the benefit is more about coding style as opposed to functionality but it could also have benefits when used in gameplay.

The second system, Events, is used to send updates to other objects and systems. This will be used more for sending events between entities and between the game systems. I've also been thinking about expanding the event system to allow some sort of serializability to allow for easy expansion to some sort of NetworkedEvent system. I'm imagining this wouldn't be all that hard to achieve given that my event system currently relies on my own RTTI implementation. The one thing that I'm lacking right now in achieving this goal is a sort of NetworkedObjectID class for automatically managing objects between clients. This is one thing to add to my research list.

Well it's 2:30 AM as I finish this and I have somewhere to be in less than 8 hours so I better get some sleep.

Any thoughts, criticisms, concerns, or possible improvements to any of the ideas I have mentioned would be well appreciated.
-Wynter Woods
I spent a bit more time on WynterStorm today, this time cleaning up some older code.
In my last incarnation of WynterStorm, I had been using a TypeInfo class for RTTI in various places. Using Trefall's component classes as well as an event management system that I pulled from here on gamedev, I had taken in a second TypeInfo class that used standard C++ RTTI. Because I had introduced this class into my code, I had to move the old class out to prevent any conflictions. Today I resolved this issue by adding functionality into my original TypeInfo class and further modifying my engine to make use of my TypeInfo implementation rather than the one that relied on C++'s RTTI. Currently, integration with the TypeInfo class is fairly easy, and requires a few things.

First, a simple class would look like so:
[source lang="cpp"]class KeyPress : public Crystal::Event
KeyPress(int key) : keysym(key){};
int getKey() const {return this->keysym;}

int keysym;

Here, TYPEINFO_DECLARE is a simple macro that adds two things to the class: a static constant member, and a virtual method to retrieve that member for this specific class. This implementation also requires that there is the following code in a .cpp file:
[source lang="cpp"]TYPEINFO_IMPLEMENTATION(Shard::KeyPress, 1, CLASS(Crystal::Event));[/source]

This code creates the static constant member for the above class, and initializes it with parent information. TYPEINFO_IMPLEMENTATION is defined as:
[source lang="cpp"]#define TYPEINFO_IMPLEMENTATION(name, ...) \
const Crystal::TypeInfo name::typeInfo(Crystal::String(#name), __VA_ARGS__);[/source]

The first variable, name, refers to the name of the class which will contain a TypeInfo. The second variable is the number of parent classes. Normally this will stay as 1, to avoid the diamond problem, however in some cases multiple parents may be necessary. The following variables are the names of the parent classes, encapsulated in the CLASS macro, which just returns a TypeInfo variable from a class(as opposed to an object, which uses the PCLASS macro).
The following classes are currently implemented in WynterStorm like so:
[source lang="cpp]TYPEINFO_IMPLEMENTATION(Crystal::Object, 0);
TYPEINFO_IMPLEMENTATION(Crystal::Event, 1, CLASS(Crystal::Object));
TYPEINFO_IMPLEMENTATION(Shard::KeyPress, 1, CLASS(Crystal::Event));[/source]

Using Crystal::Object as a parent class is not a requirement for using the TypeInfo system, but is used here as the base class of Crystal::Event. Crystal::Object currently is just an empty class with TypeInfo, but I plan on extending this type later to server other purposes.

With that information, I will end with the following questions for you all:
  1. What sorts of RTTI implementations are you using?
  2. Do you find the C++ standard RTTI to be slow enough to warrant a custom implementation on modern machines?
  3. Have any of you chosen to use a custom RTTI implementation for other features (reflection, for example)?
  4. How would you suggest I change my current solution?

Thank you for your time,
-Wynter Woods
As I noted in my last entry, I want to use this article to describe the way I have been laying out code in WynterStorm and the different libraries it is broken up into. I've found that I am horrible at code documentation and because of this I have tried to somewhat combat this problem by organizing my code out quite strictly. WynterStorm is broken up into the following parts:

Crystal - Crystal is the lowest layer of all of the libraries. It contains code that is meant to be compilable on most any system with a modern C++ compiler. It contains basic primitive structures, memory management, rtti helpers and event handling.
Shard - Shard is the operating system compatibility layer. It contains code for initializing the application, creating windows and processing system events.
Shade - Shade is the Graphics API layer. It handles anything related to actually displaying graphics onscreen, with the exception of updating a window's contents upon rendering.
WynterStorm - Contains common game code to the engine. Game State mechanisms, base Entity classes, etc. will be stored here.
Game - Contains any game specific code. This is for anything that extends base WynterStorm classes or should for may be specific to a single game (map loading, battle system code, etc.).

These parts are all stored in the wynterstorm/ directory, each in their own directories. These directories then each contain a include/ and a source/ directory for splitting .h and .cpp files. As development matures I may choose to split code by task rather than by type of file, but for now this layout works.

Along with these parts, the WynterStorm engine also relies on some external library code, stored in lib/. The libraries in use currently are SDL, Trefall's Component/Entity classes, Efficient Delegates in C++ and Simple OpenGL Image Library. I also plan to use Freetype for font loading, and libRocket for the heavy GUI lifting.

As for scripting I've been deciding between Lua and v8 for scripting. Lua has the advantage of running in most places I need it to while v8 offers the speed and easy integration that I enjoy. Google's v8 however does not currently run on iOS and because of this I am not yet willing to commit to it as my scripting language of choice.

I've also been looking into how to handle Component/Entity templates. In most of the engines currently using them I've seen primarily XML for defining the templates but I've found this way to be rather cumbersome(may not be the right word I'm thinking of). XML code requires more text than should be necessary for defining the templates and ends up making the properties harder to read and write. Some people have turned to using Lua for this. I've become very interested in using CSS for this, minus all of the web-specific properties and attributes. For that, I have discovered this library, which has minimal requirements (two Boost headers, which I should be using anyways) and seems to have a fairly nice API. The one downside is the LGPL license used, which may inhibit the development of commercial games. I'll have to look into this further.

What does Gamedev think about any of this?

Thank you for your time,
-Wynter Woods

EDIT: I feel a bit retarded. libRocket provides a very nice interface for using stylesheets. It is very likely I can just use this outside of GUI code to achieve what I need.
Been working on WynterStorm for the past hour now, implementing loading of textures. I wanted to use this entry to go over the tools I use for development. I run Mac OS X Snow Leopard as my primary OS choice, so most of my development is done in that. I don't use the XCode IDE though unless I am forced to. I prefer instead to use TextMate for writing my code, and to use make for compiling. This didn't use to be the case though; most of my work on WynterStorm used to be done in XCode. With the release of XCode 4 Developer Preview 1 though, the project files broke and I decided at that point to start the project anew, refactoring the project in order to provide myself a better framework. Thus, the current incarnation of WynterStorm was born.

Since then I have learned to somewhat tame the beast that is make into building my project, as well as training myself to use the wonderful gdb for debugging.

One of my favorite tools in Mac OS, aside from TextMate, is Apple's OpenGL Profiler. I'm curious why Microsoft doesn't offer a similar tool. At least I was never introduced to one back when I used Windows primarily. OpenGL Profiler has seriously cut down on debugging time by allowing me to view the contents of opengl data during program execution (though in a suspended state). With the recent changes made to texture loading I would like to present an example texture loaded into WynterStorm, which I have attached below.

The code used to achieve this is:
[source lang="cpp"]int main(int argc, const char* argv[])
// define the application
Shard::Application app;

// create a new graphics device using OpenGL
Shade::GraphicsDevice* graphicsDevice = new Shade::OpenGLGraphicsDevice();

// define a new window using SDL
Shard::Window* window = new Shard::SDLWindow();

// create the window with dimensions [320,240]
window->create(320,240, graphicsDevice);

// create a new texture of dimensions [48,48]
Shade::ResourceHandle texture = graphicsDevice->textureCreate(48,48);

// load texture from file. Texture creation and file loading was
// purposefully designed as being two steps to keep graphics
// functions limited in the number of actual tasks performed.
// Any arguments against this decision?
graphicsDevice->textureLoadFromFile(texture, "build/spectrum-prism.png");

// set the window's 'title' property. This makes use of Trefall's
// property system, the Shard::Window class being a
// descendant of Trefall::PropertyContainer. This allows the
// engine to automatically update the window's title when this
// property is changed.
window->title = "Some Title";

// app.shouldQuit is also a property, though currently doesn't
// make use of any special callbacks.
while (app.shouldQuit != true)

// this function is defined earlier in main.cpp, but will
// later be a part of WynterStorm's core libraries. It's main
// purpose is to poll the event loop and push events to
// the rest of the engine.
return 0;

In my next entry I would like to discuss the engine's layout in order to get feedback and determine any flaws in my current design.
The project I've been working on the longest is a game engine I've named WynterStorm. I came up with the name over a year ago and stuck with it because I couldn't think of anything better. I am building this engine to allow me to rapidly develop games and I currently have two games I am planning to use this with.

The first of those games is a project with the working title MaxwellGame. This game revolves around a knight named Maxwell (thank you, captain obvious) and his adventures with his brother Zelig. This project started years ago as a make-believe type game that my friend Corey and I used to imagine. Since then the stories involving Maxwell and his brother Zelig have only continued to grow. My goal is to re-imagine some of Maxwell's adventures into a J-RPG styled game with a continuous world. This is an idea that has stuck with me for the entire length of this project's creation; I wanted the world that players were immersing themselves into to feel seemless. I will attempt to explain that in a later journal when I have some media to demonstrate this with.

One thing that inspired me during the early brainstorming process of this game was a hatred I had accumulated over the years of playing video games. Imagine for a second that you're playing a game where you are a soldier that is in the middle of a large scale war, and oops! your sword just broke because the "durability" dropped down to zero. Or maybe you wanted to replace the shield in your left hand with another sword and dual wield them like a badass. Well, from the looks of the game art it would appear that there are quite a few swords laying across this battlefield ripe for the picking. But wait, there's this problem: it's just art. No programmers took the time to add any sort of interactivity to that art, so now that art will just sit there until the end of time serving no purpose but to look pretty.

In MaxwellGame I plan to minimize that wherever possible. If you walk out into a battlefield and there are swords on the ground, you will be able to pick them up. If you are in town and you see a shield laying against a house, you can take it. Any weapons should be kept behind the counter until the player wishes to purchase them.

What about my second game idea? I'm glad you asked! It's actually a modified form of one of Maxwell's stories. When I was growing up, Maxwell was my persona for almost any adventure I went on. Most of the adventures tended to belong to one of three timelines. Maxwell's past world, Maxwell's future world #1 and Maxwell's future world #2. Future world #1 was the first that I created although it doesn't actually fit in with the other two timelines and is better thought of as another universe. It is for this reason I am choosing to branch that universe off from being a part of Maxwell's stories and replacing the reoccurring characters with new ones to form the basis of The Future World Project. I intend for this to be a collaborative project in which I will attempt to provide some of the main story points and then allow others to create the game with me. Very few details of the story are up on the forum but I feel that I should include the link to that forum anyways after discussing the project.

As for technology, WynterStorm is being developed in C++ with SDL for events/windowing and OpenGL for graphics, though is not limited to either technically as the base graphics/core classes are designed to be pluggable. I wish to target Mac OS, Windows and Linux and then will see about targeting iOS and other platforms once either game is farther along in development. The engine uses some of Trefall's Property/Components code but it has been modified to remove dependencies on ClanLib.

Further engine technology will be discussed in another journal as the code matures.

Thank you for your time,
-Wynter Woods

The First Entry

Hello Gamedev Community,
My name is Wynter Woods and I am a software developer. I am a web designer and php programmer for a local community website using vBulletin 4 and other software. In my spare time I attempt to develop video games and open source web software. I also love anime, heavy metal, and long walks on the beach.

Why am I posting here? I've been browsing Gamedev.net for years now and have always thought about signing up for GD.Net+ for the journal capabilities. With the journals becoming free to all users in the latest Gamedev software update, I've been trying to convince myself to sit down and commit to writing something out to start brainstorming ideas as well as post the status of the various projects I am working on.

So I wish to thank you for reading this first post and maybe one of my posts will provide you with something interesting or useful.
-Wynter Woods
Sign in to follow this  
Followers 0